Planet Explorer Project Synthesis

We felt that traditional product strategy models in the form of personas and user stories were not thorough enough for uncovering real motivations and pain points, while balancing that against evolving company goals. We used the Jobs to be Done framework for uncovering and prioritizing needs. I facilitated stakeholder and customer interviews as well as prototype testing, which included garnering support from Sales and Customer Success teams and educating Product and Engineering on user research and design thinking.

We understood that our users undertook three main tasks:

1. Monitoring an Area of Interest (AOI)
2. Identifying change over time
3. And sharing those insights. 

To address these needs, we embarked on recreating a lay person’s suite of geospatial tools. Saved searches would alert users to new, incoming data of an area of interest. Since the IA was at risk of becoming cluttered, we settled on grouping images by day, displaying top-tier meta-data, and allowing the user to drill into each day to access slices of raw imagery.

To help with identifying change over time, a compare tool would allow users to toggle between two slices of imagery. That later grew into what we called Change detection. An automated way to alert users to anomalies within selected AOIs.

We wanted to help our users tell and share their stories through tools like annotate, time-lapse, and share. Users could then customize the way change is identified and displayed, and to what degree. Measurement tools allowed internal and external users the ability to monitor and identify key features and objects of interest and make real-time, high-impact decisions. 

Insights

1. Parsing through our wealth of data was laborious and time-consuming. How might we better display our information to accommodate a constant need for scalability? How might we better flag anomalies and automate change detection and notification?

2. Educating a public already familiar with Google Earth was key. Do lay users have a need for this level of recency? Do they understand its value? Should we design for them at all?

3. Catering to all levels of expertise is possible. Basic mapping tools are critical, along with more advanced analytic processes. How might we provide adequate training, onboarding and messaging to our users at each level?

4. Verticals and personas are tertiary, as the jobs they are trying to accomplish are essentially the same. Focus on asking 'why' and drilling down to the core issues.

At the same time we also worked on ad hoc customer requests. The Japanese government enlisted us to create a satellite tasking app that allowed users to queue requests for imagery at a specific place and time. This scaled to become a product made available to all Planet customers. 

The challenge of working in a brand new market with endless applications required an exploratory mindset backed by data. One area that I was keen on championing was our value to the journalism and media community, who would not only benefit from a richer storytelling experience, but would also help us communicate Planet’s value prop to through the global distribution of our imagery.

We were up against a handful of other competitors in this space, and the main complaint from our journalist users was that the turnaround time for imagery took too long, resulting in other companies winning the front page of outlets like the New York Times more than once. At the time, many news outlets did not have dedicated media managers like the New York Times, who were versed enough with geospatial imagery to follow the prompts we provided on how to access the imagery themselves. Therefore a typical delivery process required that we contact our one data viz designer at 4- 5am, who would then prepare the image for publication through processes like color correction and annotation.

Job mapping helped us break down our internal user’s workflow into distinct phases to strategize for our consumer facing tool.

The need to tell a story about change over time, lead us to working on a timelapse feature that produced a shareable gif. Google Earth Engine had a strong storytelling feature using beautiful Earth imagery, using timelapse. Our edge lie in the scale and recency of our imagery, making it more actionable to most industries. Google’s imagery was often 6 months old or more. 

This tool was then folded into the Explorer app, enabling a greater range of capabilities, such as comparing and annotating within timelapse, further meeting users needs for a high-revisit, low latency way to access relevant imagery, perform an analysis, and share actionable insights around the world. 

Lessons learned during this project: how to work within an engineering lead organization and get buy-in and how to be intentional with building out an endless number of features