Jobs to be Done: From Research to Minimum Valuable Product

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 Valuable Product. 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:

1. Gain empathy: Review existing research, identify gaps, and fill gaps with targeted customer interviews.
2. Synthesize research: Write Job Stories and define Situational Segments.
3. Define & prioritize problems: Define key problem areas and prioritize areas with the highest benefit to customers within the context of their User Journey.
4. 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 the 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 similar 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 these clusters of Situational 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. We also noticed 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 the total 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:

1. The solution solved the pains we uncovered during research.
2. 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 have been 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.

Notes:

1. We’re a big fan of the Jobs to be Done framework and especially how the folks at Intercom have applied it to product design, marketing, and support…really everything they do.
2. To find out more about Job Stories, you can read Paul Adam’s first blog about them and Alan Klement’s post on his development of the framework.
3. At EverTrue, we make software that helps Educational Advancement professionals make progress in their work day. We’re building a platform and a suite of tools, which help Gift Officers, Prospect Researchers, Annual Fund Managers, and Alumni Relations Officers do their job faster and more efficiently than ever before. Interested? We’re always looking for great people to join our team.
4. Check out our design team on Dribbble.