3 Ways ‘Jobs-To-Be-Done’ Improves Application Development
The jobs-to-be-done (JTBD) theory of innovation isn’t new, but the framework has many lasting benefits for software development organizations. While JTBD is mostly associated with customer research efforts, there are methods of using it that can greatly improve conceiving, producing and delivering innovative products within the development process. This article is written for product managers, owners and designers to help generate ideas of how to use JTBD concepts to improve your research, process and product.
The JTBD theory is largely attributed to Harvard Professor of Economics Clayton Christiansen, though more development of practices and thought leadership has come from Tony Ulwick (founder of Strategyn, a consultancy), Alan Klement (author of “When Coffee & Kale Compete”), and others. While there are differences in the approach each proponent recommends, the theory is unanimously focused on discovering the underlying motivations that customers have when they invest into products or solutions.
Some of the practices that have come from JTBD over the years are used early in the process, during initial research, while others are used throughout the rest of the development process. Below are three methods that product teams can incorporate today to improve your own team’s product delivery.
The Big & Little Sell Concepts: Identifying the Opportunities
Understanding what to look for in research
While much of Clayton Christensen’s work focused on JTBD, he was, at the heart, a marketing guy. While he understood that a business’s success comes from sales, his realization that accounting for the circumstance around a product’s use is what would lock customers in to become repeat buyers. He called these two points of conversion the “big sell” and the “little sell”.
Let’s consider a customer deciding to buy a shiny red sports car from a dealership lot. The moment of the big sell is when they believe the product checks-off all of their requirements, and they are satisfied that they have done their research. They’ve compared brands, models, engine specs, considered what they can afford, and have even sat in a few. This one makes the most sense.
The little sell is the moment, maybe years later, when they are recounting all of the ways that this car was made that surpassed their expectations. This moment of reflection is exactly when they know they will buy another of the same car when the time comes. That feeling doesn’t come from a list of included features. It comes from the manufacturer having a deep and holistic understanding of exactly how the product would be used so that it can be designed to address every context of its use.
Within your software development organization, you have two resources that are directly exposed to evidence of the big and little sells: Your sales and support teams.
Your sales team frequently receive feedback from customers about what they are looking for and where they were impressed or disappointed, post-sale. Ask questions like “What do our customers really expect of us?” The responses and insights shared from your sales team will inform your choices for your customer’s big sell moments.
Learning about little Sell opportunities is different. For these observations, we must reach out to customer support. Since they take calls and emails on the circumstantial issues that arise in your customer’s day-to-day, support learns about the friction your product has when applied to real world situations. These insights, combined with results from your user research studies, can reveal opportunities and “usability bugs” — difficult-to-foresee problems with UI design. Resolving these should improve customer retention, and possibly help you discover use cases you weren’t previously aware of.
Doing the Right Thing: Measuring Twice Before You Cut Once
“Customers don’t want a ¼” drill bit. They want a ¼” hole.” — Theodore Levitt
Paul Adams, SVP of Product at Intercom, observed that JTBD is hard to understand. This most likely is due to JTBD’s focus on understanding the context of the product’s use, rather than just the intent of the product. It can feel immeasurably difficult to understand every situation that a drill bit can be used, not to mention the desired end result. And even among the leading experts on JTBD, there is considerable dissent about what constitutes an “end result”.
Tony Ulwick uses Levitt’s quote to argue that the end result should be to create a ¼” hole, and to look for ways to improve the drill bit or process. But Alan Klement points out that the user’s end result may be to hang something on a wall; a challenge solved by solutions like 3M’s Command strips. In these use cases, 3M’s product obviates the need to create a ¼” hole altogether.
If you’re in the drill bit business, it might be attractive to think that you can address evolving customer needs by focusing your R&D on the drill bit itself. The wiser objective would be to identify all of the contexts in which your product may be at a distinct advantage or disadvantage. You may find that some of your assumptions about the application of your product were inaccurate and turn out to be holes in your understanding of your product’s total addressable market. So how deep do you dig in your client’s workflow before you land on the most fruitful end result to focus on?
Don’t just ask customers what they want. Observe them until you understand the context and intent behind what they say they want.
I remember an expression I learned early in my career in the user experience field. It encouraged user researchers to “Ask your interviewee ‘why’ over and over again, until it gets awkward. Then, ask it one more time.” Usually, this is the point where your interviewee understands that you’re not actually asking about drill bits, and starts talking about their underlying motivations. Now, you’re on to something.
You may not always have opportunities to do user research, but remember that the layers of context around your product’s use are many, and just being aware of that can help you prioritize your development. But even better is to conduct more rigorous research focused not on the product in question but on the contexts of its use.
Doing the Thing Right: Communicate the Job Faithfully
Job stories can help retain the motivations for a product’s vision from the start of concept all the way to delivery.
Alan Klement also identified weaknesses of user stories, which identify the roles and actions taken to achieve an expected outcome. For some time, Klement recommended the use of job stories as an improvement because this method focuses on context and intent rather than role and the action (as found in user stories).
Job stories can help carry JTBD insights from research to delivery without becoming muddied by the evolving nature of features. This is because they:
- … are based on contextual inquiry research
- … can be written by designers
- … ensure that developers output product that is faithful to the research and design
- … and user testing can validate the product’s efficacy at addressing that same context and intent
Another reason to use job stories is to help align “adjacent” development efforts. Too often, we see how product vision starts to fragment when pods naturally start focusing on producing the features within their user stories. Before you know it, two pods have produced work that isn’t quite aligned with the overall vision, or each other.
Because job stories always include context, pods are reminded that their output is about more than just the feature they’re working on during that sprint. Keeping that context means a pod working on, for instance, a customer credit card payment process will more likely have a similar look and feel as the pod that produces the account transactions screens. The scope of user stories is too narrow to promote a holistic approach to feature development. Job stories are by nature rooted in a wider scope — the context of the product’s use.
Closing
While the best thought leadership on JTBD has been focused on creating practical methods to use it, as I’ve written about here, the greatest benefit JTBD offers is still in presenting a different lens through which to conduct research and manage development. Clayton Christensen’s “How to hire a milkshake” video, where he shares his experience assessing milkshake sales for McDonalds is an excellent starting point for reinforcing the value JTBD can offer your own innovative process. I hope you will keep these concepts and the three methods I’ve shared in mind next time you’re asked to assess the real needs of your users.
As a last remark, I would like to mention the continued value of user personas. Some JTBD methods, including Alan Klement’s job stories, suggest that their methods obviate personas. But personas still help align a development team with the environment and economy that their products are used in. Personas help create visions of the people and organizations your products serve. It may be time to reconsider what is necessary or beneficial in a user persona, but they are still a valuable resource that your team should continue to use.
References:
- https://www.christenseninstitute.org/jobs-to-be-done/ — The late Clayton Christensen’s non-profit think tank
- https://www.youtube.com/watch?v=VmbSpTJXozk — Clayton Christensen video “How to Hire a Milkshake”
- http://www.Jtbd.info — Alan Klement’s observations on Jobs to be Done
- https://strategyn.com/ — Tony Ulwick’s JTBD consultancy
- https://vimeo.com/275265188 — Paul Adam’s video “The End of Navel Gazing”
