Jobs to be Done: From Research to Minimum Valuable Product
How we used the JTBD framework to build minimum valuable products.
Happy Holidays! 🎄🎁🕯️☃️
I’m away with family, so this week’s post is a throw-back to a few years ago before I worked at Spotify. As a small Product & Design team working at a startup, we needed to figure out everything for ourselves. This article formerly published on Medium.com is a recap for how we turned conversations with customers into a product roadmap for what we needed to test and build — ultimately leading to a very successful product people are still using today.
I hope this time of year is restful for you and your family.
-Mat
I wrote this article and previously published it on Medium as a contribution to the JTBD.info group. I’m posting again here in a new series of posts I want to do around JTBD or “Outcome-Driven Innovation.” What people misunderstand, how to do it right, and how it can elevate your design practice.
Does your design/product team know your customers’ needs?
Do your designers and engineers understand your customers’ behaviours and motivations?
Here’s a story about how we used JTBD at EverTrue to align the team around value when building our MVP:
Why this matters
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 design 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:
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.
1. 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.
2. 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.).
3. 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.
4. 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 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:
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.
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.
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.
Check out our design team on Dribbble.
What did you think of this case-study, was it useful?
Hit reply, I would love to know.
-Mat