Demystifying Task Analysis of the JTBD Strategy
When I first waded into the JTBD pool a decade ago, I found myself conflicted. I was enamored with this theoretical approach to making disruptive strategies into executable roadmaps to solve customers’ needs, but I was simultaneously confused by the cottage industry terms that cropped up around the JTBD community.
The ancestry of the JTBD theory can be directly traced back at least 25 years to Tony Ulwick’s book, Business Strategy Formulation, and later codified in Clayton Christensen’s The Innovator’s Solution. Before these, dozens of marketing and Human-Computer Interaction (HCI) works reference many forms of Task Analysis, which closely resemble Jobs processes.
JTBD Is a Framework – Not a Process
With the benefit of hindsight, I can admit having found JTBD during a period best described as my Agile purist phase – having been recently liberated from Waterfall’s Gantt charts and person-hours estimation without Fibonacci’s.
The Scrum process offered such a refreshing change that I became overly protective of anything threatening its sacred ceremonies. Focused as a blue period Van Gogh, I needed only my monochromatic process; I was innovating masterpieces. Through this lens, you might understand why product people telling me to switch from user stories to job stories would produce such a visceral reaction.
Product management newcomers to the JTBD discussion inevitably end up tumbling down Jobs rabbit holes on Twitter or Medium. They quickly find that the most popular JTBD articles do more navel-gazing about who coined which terms than they do about the value of JTBD itself – which is considerable when hired to the right job. Still, many product professionals report having been turned off by JTBD literature; the conversation among them has become campy at times.
Tony Ulwick summarized the goal of JTBD best when he said, “[T]he goal of the framework is to solve the frontend innovation problem and allow us to understand what the customer is trying to accomplish, figure out how to find, how to secure, and how to claim a unique and valued position in the marketplace.”
So, from the product manager’s perspective, to which software product Jobs is JTBD best suited? Let’s have a closer look.
Right Job: Bringing Business Units and Developers Together.
User researchers and task analysts have been vocal proponents of the idea of utilizing developer time for more user interaction. Frameworks built up within the Jobs Theory can do wonders to help teams better understand the value of the software they are crafting. Some of the best discovery work happens when designers and developers share a common product vision, and Jobs is a great tool to hire and make that happen.
Adequate Job: Progress as Working Software.
As any Agile purist will tell you, the primary measure of progress is working software. Jobs Theory is highly concerned with progress, but not necessarily the advancement of finished technology. JTBD is concerned with the progress of the customer toward their goal.
As long as your iterations produce releases that incrementally improve a customer’s journey toward their desired outcome, Jobs is an exemplary descriptor of the scene being played out. “Working software is the primary measure of progress,” but the key word here is “working.” If the software is assessed as working when it meets the customer’s need, the team will find value in ideas from Jobs. If by working, we are to infer defect-free, then we will simply be delivering a solution in search of a problem.
Wrong Job: Agile Software Delivery.
Jobs Theory is not designed to tell you how to organize teams or deliver early and continuously valuable software. The processes and functions around the project management of teams who are building software, are better served by hiring Scrum. You can substitute Scrum with Kanban, SAFe, or XP, but the functional management of teams is a well-defined space. And the writing, refining, delivering, and demonstrating of user stories is a well-defined, saturated market. JTBD isn’t competing to upset the status quo here.
Right Job: Motivate Your Team, and Trust Them.
Jobs Theory is a beautiful fit here. Nothing empowers a software product team more than alignment around solving a problem that they know they can deliver. Articulate the outcomes of a market need to allow a team to build empathy for the human beings at the other end of the experience. If you struggle to articulate a vision, then pulling up from your 2-week sprint cycle for a day to conduct user interviews to gain a deep-dive understanding of the need being addressed can be a powerful experience.
Wrong Job: Defining Requirements.
A Job is not the same thing as a user story. Job stories have been promoted as viable alternatives, but in my experience, most software teams utilizing Jira or a Jira-alternative still have backlogs full of user stories. The Job story template replaces the role with the circumstance but is mainly unchanged beyond that — corporate needs you to find the differences between this picture and this picture.
Right Job: Enhance Agility through Good Design.
One of the least discussed aspects of Agile software delivery is that it becomes a lot easier to maintain speed and flexibility when an excellent design is at the center of a team’s vision. When the need is understood profoundly, and the idea is clearly articulated, Jobs Theory can free a group to act as empowered agents of the customer’s desired outcomes. For this Job, JTBD can be an incredible force multiplier.
Wrong Job: Shortest Timescale to Market.
Jobs To Be Done is a rigorous, time-consuming, and scientific approach to understanding deep customer needs. Often the experience that they have with a product fills a very differently shaped hole in their lives from the form of the product itself. Jobs Theory is an operational art (more on this in a bit). JTBD is deeply rooted in a methodical and consultative approach to understanding markets based on needs, articulated through VOC and unarticulated in contextual clues. Jobs Theory is best applied occasionally for validation and product-market fit.
Right Job: Maximizing Work Not Done.
Simplicity and software are two words rarely used positively within the same sentence. One of the most common fundamental needs that our customers value is Ease of Use. When simplicity can be laser-focused on the right need driving the most important outcome, the team, the client, and the user will be in lockstep toward a valuable, viable outcome. JTBD can excel here, but it may be dangerous to go alone. An excellent team – building and shipping software – may need help understanding which features are unimportant for the outcome. Having a user-researcher alongside to guide and shepherd the experience as the product is built can be a wise addition to a team’s bench strength.
Right Job: Reflect and Adjust on Effectiveness Improvements.
When you have defined a user persona and given a face to the problem you’re solving, it’s incredible what can happen to a team’s sense of accountability! JTBD tends to shun the use of psychographic or demographic personas, but a persona that encapsulates a need can be a fantastic tool to help teams assess and align during regular retrospectives. For this Job, JTBD is a great tool to hire.
Wrong Job: Efficient and Effective Information.
If shipping code is the goal, then JTBD is going to be seen as an impediment. Don’t implement it to get unstuck or to accelerate your team’s velocity. Inherent to most JTBD systems is sophisticated research and qualitative feedback; this is true in theory, and even more so in practice. The consequence of this requires our coming to grips with a very real sense of frustration. It’s no small feat understanding, analyzing, clustering, and ideating solutions to address the customer’s job, efficiency, and effectiveness – especially against time-based metrics.
Simply put, Jobs Theory analyses will not produce solutions to be built. It articulates users’ needs that could potentially be met. By definition, the job is agnostic of the technology solution that may fulfill it. The need is stable. The job is stable. Technology will come and go over time.
Right Job: Self-Organizing Teams.
JTBD is a Discovery or even Pre-Discovery activity, and software teams are by and large functionally diversified toward Delivery. JTBD can be a particularly well-suited tool for helping correct imbalances in teams that are biased toward execution over research. Jobs Theory enhances agility by focusing on the need, and the articulation of the need is likely something that will be a guided research process. For this reason, a team that focuses on job details can enhance trust with customers and establish a functional foundation on which to build a roadmap.
Wrong Job: Maintain Pace Indefinitely.
JTBD theories tend to be applied in sporadic consultant-driven scenarios. JTBD is difficult to impose on software delivery teams indefinitely because the analytical rigor inherent to user research requires that time be spent away from keyboards. The impact on pace doesn’t disqualify JTBD for use by software teams, but JTBD involves the input of a mountain of what Christensen calls “passive data.”
Jared Spool offered a pithy take on the concept when he said, “Passive data is hard-to-get qualitative data that will go beyond the market data. Christensen doesn’t say it, but passive data is what designers would call ‘user research.’ He argues you need to get out of the building and talking with customers, to uncover the true jobs those customers need to do.” JTBD would be fired on day one if the sustainable pace of software delivery was the goal; it is a great tool to hire for ongoing discovery.
The Sweet Spot: JTBD is Operationalized Product Management.
JTBD isn’t Product Ops, but it is Operationalized Product Management. It helps us to decouple product strategy from the tactical technology solution we’re building. When teams have developed high empathy for the users’ needs of their software, they will be more flexible, autonomous, and creative.
Jobs Theory is often shorthanded as a strategic thinking lens. As we examine the jobs at which JTBD can excel and at which it is best deferred in favor of other tools, we see that teams will be bringing the strategy with them to work every day and elevating the tactical toward the higher purpose of needs and outcomes. This is the sweet spot. It’s not just hitting a target, and it isn’t just developing visionary doctrine. It’s the intersection where the problem and the solution are manifest.
Want to learn more? JTBD guru Tony Ulwick guests on the ITX Product Momentum Podcast, while ITX’s Sean Flaherty joins Tony on Strategyn’s recent webinar.
Resources
Jobs To Be Done: Theory to Practice, by Anthony W. Ulwick
Jobs-to-be-Done: A Framework for Customer Needs
Know the Two – Very – Different Interpretations of Jobs to be Done
The 2 Jobs-to-be-Done Interpretations - and Why It Matters
Jobs To Be Done: An Occasionally Useful UX Gimmick
Replacing The User Story With The Job Story
The Customer-Centered Innovation Map
Klement’s Fallacy Misleads The Jobs-to-be-Done Community
Alan Klement’s War On Jobs-To-Be-Done
Jobs-to-be-Done: How to Analyze the Market of Marketing
How Twitter Applied the “Jobs to Be Done” Approach to Strategy
A Practical Model for Jobs To Be Done (JTBD)
Use Cases, User Stories/Statements, and Jobs to Be Done
Designing features using Job Stories
How we accidentally invented Job Stories
Job Stories: A Viable Alternative to User Stories
Paul Gebel is Director of Product Management at ITX Corp. He earned his BFA and MBA degrees at Rochester Institute of Technology, where he currently serves as Adjunct Professor. A veteran of the United States Navy, Paul’s experience also includes extensive project and product management experience and consultancy. At ITX, he works closely with high-profile clients, leveraging technology to help solve business problems so they can move, touch, and inspire the world.
