This blog first appeared as Steve Wunker's piece for Forbes
By Steve Wunker
Agile development has become the norm in software, yet it often overlooks a key challenge – how to objectively prioritize product roadmaps. Without this, the results of agile sprints can focus on the wrong features, developed for the wrong users, and executed in the wrong way. That’s a tremendously expensive waste.
Perhaps worse, firms prioritize product roadmaps using fuzzily-defined and often politicized methods which take considerable time and lead to development efforts spread thinly across use cases rather than in a concerted manner which satisfies key users in a complete fashion.
There is a better way. Jobs to be Done, developed by my mentor Clayton Christensen at Harvard Business School, creates strategic focus and coherent execution. Jobs to be Done is a method to understand what people are fundamentally trying to accomplish, rather than looking only at what they say they want, what they use today, and what pain points they’re experiencing in their current user journeys.
Jobs to be Done creates the needed focus in a way that avoids lock-in to features, so it is a natural fit with agile development. Here are four reasons why you should use it and four ways how:
Reason 1: Jobs to be Done creates a clean link between personas and use cases to features
Tech firms typically root product development in targeting personas and use cases for their products. That’s sensible, but jumping from those right into feature prioritization misses a key step. You have to know what these individuals are trying to get done in their use case context, on both a functional and emotional level. By embedding Jobs within the Jobs Atlas, you get a full sense of what features must accomplish, in what contexts, at what point of a journey, and in what ways to generate rapid user adoption.
Reason 2: Jobs enables prioritization of features while maintaining flexibility about how to execute them
A key principle of agile development is to maintain flexibility. Customer research is sometimes avoided because of fear that it will create undue lock-in to concepts. The Jobs methodology avoids these issues. By prioritizing Jobs to be Done, rather than features per se, you can keep the focus firmly on the customer, and you can stay flexible about how you execute on key Jobs. As you debate features and the UX around them, you can set them within the appropriate Jobs context and have a clear measure of what will and won’t constitute successful accomplishment of the focal Job.
Reason 3: Jobs ensures you have the right set of solutions for the right audiences, to accomplish the Job in full and avoid adoption obstacles
Software often struggles to gain adoption because it doesn’t accomplish a Job in full, or it doesn’t circumvent obstacles to embracing new features. Personas and use cases are not going to tell you the full set of things that a user needs to accomplish to be satisfied, and they don’t reveal key dependencies which may impede take-up. The Jobs Atlas is a tool to avoid these issues. It ensures that you don’t craft a user experience that is half-done and unsatisfactory, but rather something that encompasses the full prioritized Job while sidestepping major obstacles.
Reason 4: Jobs is a way to speed up the development process
Companies sometimes avoid user research because they fear it will slow their progress. Jobs does the reverse, in three ways:
How, then, can you get started down this fruitful path? Here are four steps to take:
Step 1: Build your Jobs Atlas
The process begins, obviously, with understanding users’ Jobs to be Done. But that’s not everything. To have the full picture, you need to combine Jobs in an easy-to-track manner with the reasons why certain users prioritize certain Jobs, their current approaches and their pain points, the metrics you’ll use to determine whether Jobs have been fulfilled successfully, the obstacles you’ll need to circumvent in order for users to adopt your new solutions, and a sense of the value and competitive advantage you have in addressing certain Jobs. Together, these components comprise the full Jobs Atlas. It’s called an Atlas because it lays out the landscape in full, but it doesn’t prescribe the exact route you’ll take to reach your destination. It is solution-agnostic.
Step 2: Prioritize by Segment
The Atlas enables you to segment your audience in ways specific to the software you’re developing (and which may be distinct from a broader, corporate-level segmentation that’s trying to accomplish a host of other objectives including marketing communications and pricing). By focusing on a confluence of Jobs Atlas variables (certain Jobs in given contexts, with solutions beating current approaches on specific metrics and avoiding particular barriers to adoption), you can create clear concentration for your sprints ahead.
Step 3: Group the priorities into Job-related bundles
Frequently, Jobs do not occur in isolation. A user, for instance, may need to estimate the costs of an action and obtain feedback from appropriate individuals in the company about that cost or cost options. Those are distinct Jobs, but they’re linked. Step 3 is about generating those linkages, so you can then develop features conscious of their full context, and possibly with an eye toward building complete solutions for users rather than unsatisfactory parts.
Step 4: Prioritize product roadmap
Now you can prioritize your product roadmap based on objective measures: the weight placed on a well-defined segment, the full set of Jobs relevant to that segment, the likelihood of the segment to adopt new solutions, technical feasibility, as well as value creation and competitive advantage. Your team can debate product roadmap priorities using apples-to-apples criteria, and it can develop features with the full context needed to have on-target execution.
Prioritizing the product roadmap is frequently one of the toughest parts of agile development. Using Jobs methods, you can remove much of the pain, delay, and imprecision that are so common in this area. Jobs won’t tell you what your features should be, but it will reveal who to develop for, in what context, and for what reasons in a manner that is clear, objective, and actionable.
This piece was written with my colleague Charlotte Desprat.