Introduction
User stories are very useful for marketers who want to ensure that their deliverables are customer-centric: they identify the audience, what the audience wants to get done, and why. You can read about user stories here, here, and here.
How do you get started writing user stories? Most people start with the deliverable and then reverse engineer a user story for that deliverable. That’s fine and does have the advantage of encouraging marketers to look at the customer’s point of view.
But how do you know when you have a complete set of user stories? Is there any framework that can help guide us in writing user stories in a B2B context? As it happens, there is such a framework, and it’s known as the Jobs to Be Done Framework.
Jobs-To-Be-Done Framework
The classic explanation of the jobs to be done theory comes from Harvard Business School marketing professor Theodore Levitt, who said, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”
Jobs to be done theory and the associated framework provide a way for organizations to analyze the role of key external customers, the types of jobs they’re trying to get done, and the detailed steps and outcomes they need to go through in order to both get the job done and to make a decision to purchase your product and service. This framework is particularly useful for business-to-business (B2B) companies.
A complete explanation of the jobs to be done theory and framework is beyond the scope of this article. However, here, with an example, is how one company might use this theory and framework to generate job stories as an alternative to the traditional approach of writing user stories to fit deliverables.
Identify the Personas
The jobs-to-be-done framework recommends identifying three personas. Here are the three personas in the context of an example cybersecurity firm:
The job executor – this is the person using the product or service to get the core functional job done. In the case of this cybersecurity firm, this is the cybersecurity engineer.
The product lifecycle support team – these are the people who support the product throughout its lifecycle. In the case of this cybersecurity firm, there are multiple roles, but one is the system administrator.
The financial buyer – this is the person responsible for making the financial purchase decision.
Identify the Jobs To Be Done
Once you have identified the personas, start thinking about the jobs to be done for each persona, the equivalents of the quarter-inch hole. These jobs can be broken down into five categories:
- The core functional job – in our example, protect against a cyberattack
- Related jobs – in our example, recover against a cyberattack
- Emotional jobs – These are statements that describe the way the job executor wants to be perceived or feel when executing the core functional job. In our example, the cybersecurity engineer wants to be appreciated for the job they do.
- Consumption chain jobs – installation, setup, maintenance, end-of-life activities.
- The purchase decision job – in our example, the decision to purchase your product or service versus alternatives.
The key is not to think about your product’s capabilities and features and tie those to jobs to be done. The key is to ignore your product’s capabilities and features and just focus on what the three personas listed above are trying to get done.
Identify the Outcomes
Lastly, for each of these personas and each of these core categories of jobs, there are one or more outcomes related to the various jobs to be done. For example, if one of the jobs to be done is to train people on how to use the administrative console of the cybersecurity software, what is the outcome that training achieves when it is successful? Perhaps the outcome is that every system administrator can demonstrate the ability to perform 100% of the top 10 most frequent operations, and 90% of some larger set of operations without needing to consult the manual.
How all the pieces fit together can be seen in the complete Jobs-to-be-Done Needs Framework from Strategyn, shown below:
Write “Job Stories”
For each of the outer-ring defined outcomes, you can write a user story for that persona and that job step. For example, if under the consumption chain job, the training job step, we might write a user story something like “As a cybersecurity software trainer, I want to have an easy way to assess new administrators after training to ensure that they can perform 100% of the top 10 most frequent operations, and 90% of some larger set of operations without consulting the manual.”
When you write these user stories, it is critical to check with existing and potential customers to ensure that you deeply understand the outcomes they’re trying to achieve and how they measure them. If you’re not familiar with this outcome-based approach, check out our article on Outcomes-Based Marketing.
Conclusion
Most organizations use the jobs-to-be-done framework to ensure that the product managers and the product team are building the right capabilities to satisfy all of the jobs to be done. But marketers can also use this approach to ensure that the right stories are being told through their marketing materials and marketing activities.
Unlike the standard approach to generating user stories, which generally involves either brainstorming or reverse engineering user stories to fit the content we’ve already planned (or sometimes executed), the jobs-to-be-done framework provides a comprehensive approach to generating all of the user stories that the customer might be thinking about and that need to be told. And it provides a framework to think about user stories in a structure, rather than as a random list of deliverables with user stories to be generated.
Have you tried any alternatives to user stories? What are your thoughts about the approach described above? We’d love to hear from you in the comments below.
