How to be product focused and promote customer centricity using Jobs to be Done (JTBD) Framework

Fundamental Characteristics

JTBD Framework is a way to determine and prioritize our roadmap and deliverables from the perspective or value proposition of what our customers need to accomplish, based on the outcomes and metrics they desire. This framework is deeply empathetic to the customer and has a number of fundamental characteristics.

• Customer Centric
  • The customers’ needs are the center of our decision making process.
• Solution Agnostic
  • We only think of the problem and not a specific solution. What are the jobs that our customers and stakeholders are trying to accomplish. At this point our thinking should not be tied to any specific solution. 
• The Jobs are Stable over Time 
  • Even though the environment and circumstances may change, the jobs are fairly stable. For instance, the need to maintain our customers’ trust and keep our infrastructure secure does not fundamentally change over time.
• Measurable Outcomes
  • The job stories or statements should be measurable with a clear definition of done. We should be able to see that we’ve made an improvement from the standpoint of the jobs being performed by our customers, end-users, and stakeholders.

Fundamental Elements

• Performer
  • These are groups of people who perform the job we are focusing on, in other words consumers of our solution(s)
• Job to be Done
  • The fundamental job or a problem to be solved. The job should have four above mentioned characteristics (Customer-centric, solution agnostic, stable over time, and possess measurable outcomes)
• Circumstances
  • Context around the job to be done. The details that shape quality and functionality requirements and expectations. For instance, cloud migration solutions for small startups will be very different from those that would work for very large global enterprises like Netflix or Twitter.
• Customer Needs and Outcomes
  • What is the overall objective or progress (e.g ability to get the job done faster, cheaper, etc) the customer wants to accomplish. Along with that the specific needs and success criteria can be identified. These needs can be framed around three categories:
    • Functional: Specific job to be done with clear start and end states
    • Emotional: How does our customer wants to feel when getting their job(s) done
    • Social: How our customer wants to be perceived as part of getting the job done.

Discovery Process

The discovery process is based on a few essential elements:

• Customer: Job Performers.
  • We must be very clear about who our product or service will be used by. There are generally three types of customers:
    • End user – core functional job executor.
    • Product Lifecycle Support team
    • Purchase Decision Maker: Typically a member of the leadership team who funds and sponsors our initiative.
• Progress: Making the job execution better is some way (taking into account customer needs and desired outcomes as well as gaps and inefficiencies in the existing process)
  • Get an entire job done without having to cobble together solutions.
  • Get a job done in many contexts with a single product.
  • Get multiple jobs done with a single solution.
  • Get a job done more cheaply.
• Barriers: Obstacles that prevent customers from optimally completing their jobs. In other words, what part of the job are our customers struggling with? Difficulty in obtain the required data, ineffective development practices, lack of automation, etc
• Compensating Behaviors: Things customers have to do to overcome lack of functionality or features in the existing solution.

These are some of the key components of the discovery process:

• Fully understand the core functional job to done by our customers (remember the core jobs are stable over time only the solution approaches change based on context / environment, etc)
  • Enumerate and document unmet needs (and or struggles) associated with each core functional job.
• Enumerate and fully understand the desired outcomes (i.e job to be done cheaper, faster, etc) tied to the core functional job to be done. 
  • These desired outcomes represent the metrics we’ll need to track and measure.
  • Once we come up with desired outcomes for the core functional job(s) we can rate them. Below are the ratings we can use
    • Important
      • Failure to satisfy a job has serious consequences.
      • We can ask our stakeholders how important is this job from them from 1-10
    • Unsatisfied
      • Existing solutions are insufficient in helping our customers / stakeholders to perform their jobs. 
      • We can ask our stakeholders how satisfied they are in their jobs from 1-10
    • Example: We can ask our customer to rate the level of importance of a specific outcome or an unmet need from 1 to 10, then ask their level of satisfaction with an existing solution. The formula is as follows: outcome importance + (outcome importance – existing outcome satisfaction). For example if the customer’s unmet need around their software release process is lack of an easy to use CI/CD platform. Let’s assume the level of importance is 8 out of 10 and the level of satisfaction with an existing solution is 3 out of 10. Let’s plug these numbers into our formula: 8 + (8 -3) = 13. Using this approach we can quantify and compare the features from the customer’s perspective. (Anything 10 and up is usually considered of high value)
• Enumerate and document related (or more narrowly scoped) jobs to the core functional job to be done. 

Here are some fundamental practices that will help us understand our customers needs and priorities:

• It’s important to observe our stakeholders doing their jobs. 
• We can utilize the past data that has already been collected and frame it around the jobs to be done framework and mindset.
• Pay special attention to workaround (compensating behaviors) job performers incorporate into the workflows to compensate for the lack of functionality or inefficiencies in their existing solutions.
• Make sure these findings are discussed cross-functionally. Having a perspective of just a single team is typically not enough to see the whole picture.

It is very important that we have a very thorough understanding of what our customer is trying to accomplish from a process perspective, indentpend of any existing solutions. One of the approaches we can take to gain this detailed process level insight is deconstructing or dissecting a job from beginning to end into a number of functional steps. By doing that we can get a complete view of all the points at which a customer might desire more help from a product or service at each step. In other words, to better determine where within the entire process flow is our customer being underserved. Then, with a job map in hand we analyze the biggest drawbacks of the existing solution and identify the metrics customers themselves use to measure success in executing a task.

The job map or the process typically contains some common set of well defined steps.

Solution Principles

To increase the chance that a product or capabilities we are developing will be valuable to our customers and that they will be willing to adapt them in place of their existing solutions we must strive to achieve the following: 

1) The solution should address the entire job as a single offering or platform including all software, processes and hardware required vs just some aspect of it. 

2) The solution should improve the existing process by at least 20 or 30% from the customer’s perspective. Small incremental improvements of 1-5% are typically not enough to motivate our customer to change their existing approach and to abandon the process they are very familiar with.

3) The solution should take into account not just the job itself but also aspects of its operation and maintenance (simplification of product consumption).

Coming up with a Job or Desired Outcome Statement

What is a job statement? Simply put it is a value proposition capturing customer needs and highlighting the benefits they want to obtain from a specific product or service, given the jobs they need to perform within their specific context. We can think of it as an Epic / Story in our roadmaps or release planning, but framed from the customer centric perspective of what our stakeholders must get done. 

Let’s look at an example:

Job statement = <verb> + <object of verb> + <contextual clarifier>

• Example: “Improve CI/CD framework used by our team”.
• Example: “Improve our team’s ability to perform root cause analysis”.

The job or desired outcome statements can be easily turned into ‘user stories’ by adding ‘As a <type of user>, I want to…’ at the beginning of the job statements.

E.g. As a software engineer, I want to create a clear and easy to use CI/CD capability for my team.

Job Altitude

Job altitude is a level of specificity associated with a job statement. This concept allows us to form job trees that start with aspirational or thematic jobs and then move down to more specific functional jobs. The high altitude jobs tend to answer the question of “why” our customers / stakeholders need to perform a certain job. The lower altitude jobs on the other hand tend to answer the question of how a particular job will be done. Let’s look at an example below:

Job Level	Example	Outcomes
Aspirational	Maintain a High Level of Security and Trust in our Server and Network Infrastructure	Improved Security Posture, Reduction in discovered vulnerabilities
Main	Keep server and network components’ software patched	Increase the percentage of infrastructure that is kept in compliance by running the latest qualified firmware / images
Functional	Automated patching of Linux and Windows servers in our on-prem data centers	Reduce the time, resource and toil associated with patching the on-prem server infrastructure

Measuring Value

• How do customers define progress or the level success of their jobs
• How do we measure customer’s progress towards the improvements in the jobs they perform?
  • How much our customers are using our solution(s) to get their done done
  • How well can our customer perform their jobs using our solution(s)
  • How much value can our customers derive by performing their jobs using our solution(s)

Conclusion

As TPM and Program managers must be product focused and prioritize programs in the direction that addresses the core needs of our customers. We need to understand what our customers do, what is important to them, and what their pain points are. Our measure of success should directly tie into addressing the needs of our customers and how well we have solved their problems.