Delivering solutions to stakeholders is our job – a combined effort between Salesforce Admins, Business Analysts, and Architects. Despite working hard to gather requirements, design, and then implement, it’s too often the case that what we build doesn’t quite address the stakeholders’ needs. As a result, solutions can end up underutilized or unused altogether.
Salesforce has recently incorporated new tools into its certification paths with the intention of helping Salesforce professionals better understand stakeholders’ needs. These include the UX Designer certification (released in 2021) and the Strategy Designer certification (announced at TrailheaDX in May 2022). They draw on ideas from the Product Management, Design Thinking, and Lean communities, and include tools like Relationship Design, UX Research, Empathic Interviews, Inclusive Design, and Journey Mapping.
Collectively, these tools help us to understand our stakeholders so we can deliver real solutions that address their problems and help them achieve their goals. This article will explore one of these tools, Jobs To Be Done, as well as how admins, business analysts (BAs), and architects can incorporate it into their Discovery Process.
Note: Throughout this article, I will use the general term “stakeholders” to refer to all people impacted by a Salesforce solution, including organizational leadership, managers, end users, power users, etc.
Jobs To Be Done: What Is It?
Jobs To Be Done (JTBD) is a framework for understanding customers and the problems they want to solve. The concepts in JTBD can be a little bit abstract, but the essence is this: Customers have particular problems they’re looking to solve, so they ‘hire’ a solution for a particular ‘job’. The most famous JTBD case study involves milkshake sales at McDonald’s.
McDonald’s had a product (the milkshake) that it viewed as a dessert or treat product, which was mostly purchased for children. However, when a research team (led by HBS professor, Clayton Christensen) investigated why McDonald’s customers were buying milkshakes, they found that many were not purchasing milkshakes for their intended purpose (dessert/treat for kids). Instead, adults were purchasing milkshakes because they could conveniently eat/drink them for breakfast as they drove to work.
So, customers were ‘hiring’ the milkshake for the job of ‘convenient breakfast food to eat during the drive to work’. JTBD was the framework that grew out of this and other similar product research initiatives.
As Salesforce implementers, we’re often focused on the solution space (the functionality, design, and technical implementation of our solutions). JTBD helps us to focus on our stakeholder’s problem space. At the end of the day, our stakeholders are mostly interested in their problems (and the extent to which we can solve them) – they’re not particularly interested in the specifications of our solutions.
Note: In the JTBD world, “solution space” and “problem space” are often referred to as the supply-side and the demand-side, respectively.
Understand the Problem Before Defining the Solution
Great admins and architects have a knack for understanding their stakeholders’ motives as well as their problems. They intuitively understand which solutions their stakeholders would like (and which they wouldn’t) – seemingly by feel. They know how to ask the right questions to gain a deep understanding of their stakeholders’ tastes and preferences, and they know how to build trust.
Jobs to be Done is a great framework as it brings to the forefront many of the considerations these great admins and architects appear to do as a natural matter of course. JTBD gives us a common vocabulary for discussing stakeholders’ problems, needs, and motivations, while providing a solid framework that enables us to improve our skills.
To illustrate how JTBD can be used to give structure to the discovery process of stakeholder needs, I’m going to use one of the tools within JTBD: Job Stories. I’ll also compare Job Stories to User Stories to illustrate how the former can help us understand a stakeholder’s problem, while the latter can help to define a solution.
Comparing a User Story to a JTBD Job Story
Before digging into the comparison, I’d like to make one point clear: the purpose of this comparison is not to imply that Job Stories are better than User Stories (or vice versa). The purpose is to illustrate that they are different tools used for different purposes.
|User Stories||Job Stories|
|Purpose||The purpose of user stories is to describe functionality in a way that is accessible to everyone, from end users to Salesforce team members.||The purpose of Job Stories is to understand the stakeholder’s problem, when and where they occur, and their motivations for solving them.|
|Format||As a [role], I want to [action], so I can [achieve an outcome].||When [context/situation], I want to [motivation], so I can [achieve an outcome].|
|Example||As a salesperson, I want to view Opportunity notes, so I can quickly prepare for sales meetings.||When I’m on a sales call with a prospective client to finalize a scope of work after many rounds of negotiations (often right at the deadline), I want to quickly summarize their concerns from prior calls so that we can confidently address them in an organized manner.|
Additional Considerations: User Stories
Trailhead has a great definition of User Stories: “User stories are simple descriptions of a feature told from the user’s point of view.”
The User Stories format allows us to communicate how a feature should function (via the “I want to” phrase), and also helps to establish acceptance criteria (via the “so I can” phrase). While they are not entirely descriptive of the implementation (good user stories are at a high enough level that they don’t dictate a particular implementation), they are concerned with defining a solution.
Additional Considerations: Job Stories
With Job Stories, you’ll notice there is a lot of detail about the context – this is by design. One of the useful things about Job Stories is that they clearly communicate when the problem occurs, and potentially what conditions trigger the problem.
Job Stories may provide intangible, social/emotional information. In the example above, information like “many rounds of negotiations” and “right at the deadline” communicate the time-sensitive and stressful nature of this situation. These details would be out of place in a user story, but they provide the team with useful information as they begin to brainstorm solutions.
Implementation teams do not build features based directly on Job Stories (as they would with User Stories, Functional Requirements, or Specs). Job Stories do not provide enough detail about functionality or acceptance criteria. The purpose of Job Stories is to understand stakeholders’ problems and motivations, and begin to hypothesize potential solutions.
Additional resources about Job Stories:
- Trailhead: Craft Job Statements
- Alan Klement: 5 Tips for Writing a Job Story and Replacing User Stories with Job Stories
- This second article argues that Job Stories are a superior tool to User Stories – a framing that isn’t useful for our purposes, but the article has some excellent insights about how to think about Job Stories.
Getting Started With JTBD
JTBD is a large body of knowledge. Here are a few thoughts on how you can begin to incorporate JTBD into your daily work as a Salesforce professional.
Clarify Your Goals for a Discovery Initiative
It is important to collectively define the goal of a Discovery initiative. Is the goal to:
- Understand the problem space?
- Define the scope of a project?
- Begin brainstorming functional solutions?
These goals are not necessarily good or bad, but it is important to make sure that everyone is clear on the objective of the Discovery. Furthermore, being clear about this objective will help to ensure that the group is using the right tools in the Discovery. For instance, if the goal of your Discovery initiative is to deeply understand stakeholders’ challenges, then User Stories would not be an appropriate tool.
Get Better at Interviews
JTBD requires empathic interviews with stakeholders. Trailhead has some good resources on stakeholder/user interviews:
JTBD comes from the product management world, which is focused on building marketable solutions/products and growing a customer/user base. While JTBD is a useful framework for Salesforce initiatives, it is important to acknowledge that many Salesforce initiatives have a different objective than product management.
The goal in many Salesforce initiatives is adoption by the existing user base, not growth of the user base. This means that you may need to adjust some of the JTBD concepts for your particular needs. It is also important to note that, even within the JTBD community, there are differing (sometimes sharply conflicting) opinions about the lessons of JTBD, even disagreement about what JTBD is and is not.
The resources below will provide a good starting point for learning about the main ideas and thinkers in the JTBD space:
- Competing Against Luck: A book by Clayton Christensen, Taddy Hall, Karen Dillon, and David S. Duncan.
- JobsToBeDone.org: A website by JTBD practitioners, Bob Moesta and Chris Spiek.
- ReWired Group resources page: A consulting practice founded by Bob Moesta and Greg Engle.
- The Circuit Breaker: A podcast by Bob Moesta and Greg Engle.
- AnthonyUlwick.com: A JTBD practitioner.
- JTBD.info: A website managed by JTBD practitioner Alan Klement.
- Modern Product Discovery: A talk by Teresa Torres (I’m a big fan) where she puts JTBD in context of other Product Management frameworks.
- The Next Normal Demands a focus on Jobs To Be Done: An article by Michael Maoz, SVP Innovation Strategy, Salesforce.