Image courtesy of Death To Stock
Does your product team know your customers’ needs? Do your designers and engineers understand your customers’ behaviors and motivations?
Discovering and defining the right problems to solve is—I believe—one of the most difficult parts of the product management process. Without a clear process or framework, it can be difficult to know where to start.
Our team at EverTrue combined a series of product management techniques that happened to yield a successful result for a new product we were developing; it helped us build empathy for our customers, define key problem areas, and outline our customers’ specific Jobs to be Done.
The process helped us work through the murky waters of research synthesis and problem definition to quickly arrive at a meaningful Minimum ValuableProduct. Instead of the traditional “MVP” defined by the Lean Startup, which focuses on viability, we were focused on validating customer value. Our goal was to uncover and validate the minimum functionality required to solve our customers’ unmet needs.
We’re sharing our experience in the hopes that it will help other product teams. This article details the process that helped us get to our Minimum Valuable Product, which includes the following steps:
- Gain empathy: Review existing research, identify gaps, and fill gaps with targeted customer interviews.
- Synthesize research: Write Job Stories and define Situational Segments.
- Define & prioritize problems: Define key problem areas and prioritize areas with the highest benefit to customers within the context of their User Journey.
- Prototype & test solutions: Choose the highest prototype fidelity necessary to validate the solution and test with customers.
If this process is familiar to you, we’d love to know how you’re using it to develop new products or to improve existing ones.
GAIN EMPATHY
Gather existing research & look for gaps in your understanding
We’ve had success at EverTrue building a product that helps customers with advanced searching and segmentation, but we’d learned from recent interviews that this was only a small part of their day job. Earlier customer conversations suggested accessing data and planning meetings while traveling was painful, but we weren’t yet confident this pain point was most important problem to solve. To build our confidence, we dug into existing research. Luckily, at EverTrue we talk to our customers and potential customers frequently, so existing research was easy to find.
First, we revisited interviews with gift officers—the customer segment that travels most frequently. After reviewing those conversations, we had a better understanding of the gift officer’s role in an organization and how he structures his day. We also uncovered how the role differs from other roles in the advancement office in the context of travel. However, we were missing distinct examples in which gift officers were struggling to make progress using existing products, so we took to the streets to gather specifics.
Fill gaps in your understanding with new research
Julie Lungaro from our design team lined up interviews with gift officers as they visited the EverTrue office. She also scheduled interviews in our customers’ offices to better understand the context of their behaviors. After interviewing five customers of varying experience levels, we discovered enough about their daily routines to fill the gaps in our understanding.
SYNTHESIZE RESEARCH
Extract Job Stories from your research
Why Job Stories? Good Job Stories clearly separate a problem from any specific solution, which helps designers and developers create the best possible solution by focusing on the customers’ motivations and desired outcomes — the drivers of action. Learn more about creating Job Stories.
Our next hurdle was to combine and make sense of our research. We had some intuitions about the most painful aspects of the gift officer’s workflow — and places where software could help — but we had to see if the research backed up our hunches. We did this by writing Job Stories based on the content of our interviews. In total, we had around 25–30 stories.
With this many Job Stories, we began to notice similar or adjoining Situations. This was our clue to group stories into Situational Segments.
Group Job Stories into Situational Segments
What’s a Situational Segment? Job Stories are defined by three components: Situations, Motivations, and Desired Outcomes. A Situational Segment is when a group of Job Stories share a Situation. Read more about Situational Segments here .
Once we grouped all of the Job Stories into Situational Segments, we could see which Situations occurred most frequently.
We found clustering around these Situation Segments:
- Preparing for a trip
- Contacting and following up with prospects
- Managing meeting notifications and multiple calendars
- Arranging travel and logistics
- Reporting on meeting outcomes and documenting travel
Grouping these segments made it easier to identify what customers were looking to accomplish and the products they used to help them. We saw that most customers were using similar products to accomplish their goals.
We considered the product solutions within each segment and avoided segments we felt were oversaturated or over-served with current solutions in the marketplace (e.g. travel arrangement and travel logistics served by products like Kayak, TripIt, etc.). We also moved away from Situations in which clear incumbent software solutions existed, making behavioral change unlikely (e.g. managing meeting notifications and multiple calendars served by Apple Calendar, Google Calendar, Outlook Calendar, etc.).
DEFINE & PRIORITIZE PROBLEMS
Prioritize Situational Segments by the largest amount of unmet needs
Next, we ranked the remaining Situational Segments by number of unmet needs in the customer’s workflow.
Once we had our prioritized list of Situational Segments, we decided to prioritize the Job Stories within each Segment. To do so, we mapped the Job Stories on a simple 2x2 matrix; the x axis represented the amount of pain felt in customers’ current workflow, and the y axis represented the anticipated cost of building a product to meet customers’ Desired Outcomes. This identified the Job Stories that would have the highest impact to customers and lowest cost to build.
Contextualize the Stories & Segments within the greater User Journey
Lastly—at the advice of our Director of Product Alex Jenkins—we stepped back to look at the big picture. We made sure we had the right problems in the right order without ignoring their impact to other moments along the User Journey (it can be easy to lose sight of the full User Journey when focusing on delivering a solution).
We wanted to be intentional about how and when the customer would transition between our new product and existing products in their Journey.
This work helped us define the key problems we needed to solve for our Minimum Valuable Product. Using Job Stories as the acceptance criteria for our MVP had a magical way of framing the problems as opportunities — making solutions easy to envision. The very phrasing of Job Stories invites those solutions.
PROTOTYPE & TEST SOLUTIONS
Design, prototype, and test
We spent the following sprints designing and prototyping in order to get feedback from our internal team and customers. After showing a functional mobile prototype to a handful of customers—and interviewing them one by one—we collected enough feedback to validate:
- The solution solved the pains we uncovered during research.
- The solution had the right foundation of features to be valuable to customers without too much behavior change.
Release, get feedback, measure, refine the roadmap
We’ve just released our MVP, and early feedback tells us we’re helping customers do their jobs better, faster, and easier than before.
Among other overwhelmingly positive responses, customers have told us, “This will revolutionize the way I do my job” and “I’ve been doing this for a long time, and this is the greatest f****** thing I’ve seen.”
We’ve still got work to do, and we’re getting more and more feedback everyday. We’re hopeful our focus on Jobs to be Done will lead to a product with a deeper connection to our customers and win big in the market.
Without a framework like Jobs to be Done, it would be difficult to sift through all of our research and define customer problems in a way that is testable and decoupled from specific solutions. We’re excited to continue to collect and catalog customer feedback using this framework. We are now focused on features that will add depth to our MVP to make it not a nice-to-have but a need-to-have product.