Problems first, please – an approach to ideation

I often come across situations where the conversation begins with a solution. Interestingly, every discussion starts off by describing the situation in which the job on hand has come to a standstill because of an unanswered “how.” My questioning, then, often begins with the “why” behind the standstill, to understand how it all started – almost like watching a movie in rewind. This got me thinking – Are our solutions aligned with the core functional problem being solved? On introspecting more, I realized that every time a successful project was delivered, there was immense clarity about the core functional problem.

What is a core functional problem?

A functional problem statement describes the problem without talking about a probable solution.

Some examples:

1. Problem: Control appliances at my house while being away from home
   Solution: Remote controls, smart switches, home automation hubs
2. Problem: Listen to music on the go
   Solution: Walkman, iPod, streaming services
3. Problem: Stay abreast with the world affairs from the comforts of home
   Solution: Newspapers, news channels, news apps

Intriguingly, the solutions above narrate the story of product evolution in each category. To understand this better, I started exploring frameworks and theories that could always help align the solution with the core functional problem – triggering a shift from being solution-first to problem-first! That is when I was first introduced to (and then, hooked to) the Jobs to be Done theory.     

What is Jobs to be Done (JTBD) theory?

As Professor Clayton M. Christensen, Harvard Business School, puts it:

“People don’t simply buy products or services; they ‘hire’ them to make progress in specific circumstances. This progress is the “job” they are trying to get done.”

To gain a better context of this definition, I would highly recommend watching this video by Professor Clayton about McDonald’s milkshake and the job it gets done. This will surely kindle your curiosity to learn more about this theory.

To put things in perspective, let us look at the example shown below:

What is the customer really buying?

In this image, the customer may have purchased a keypad lock for home safety to do away with the need to carry keys. However, the requirement was for a lock that was so uncomplicated that even a child could unlock it, with no fear of misplacing the keys.

The customer, thus, got the keypad lock to make progress in a specific situation if a child reaches home before anyone else.

Anthony Ulwick, a practitioner of JTBD for over 25 years, says the Jobs-to-be-Done theory provides a framework for:

• categorizing, defining, capturing, and organizing all your customer’s needs, and
• tying customer-defined performance metrics (in the form of desired outcome statements) to the Job-to-be-Done.

A common theme in the viewpoints above is the customer’s desire to make progress/get better at doing a job where there is dissatisfaction/a need to fill a gap. This results in elevating the existing experience.

This need for progress presents opportunities to discover problem areas which were not visible before and to innovate on ways to get the job done. The theory has various applications in areas like software development, enterprise consulting, product marketing, and innovation, to name a few.

Practitioners have also defined frameworks to:

• craft a job statement
• create a job map
• categorize job types based on social and emotional dimensions
• identify the desired outcome statements from a target user’s perspective and
• write job stories that highlight a situation applicable to a more extensive user base than just a single persona

It is highly recommended to follow these frameworks to start the journey of practicing the JTBD theory:

Source: “Giving Customers a Fair Hearing”, Anthony Ulwick; Lance Bettencourt, MIT SLOAN Management Review, Vol. 49, No.

Job Story framework

Source: “Intercom on Jobs to be done”

Who can use this theory?

This theory can be used by anyone looking to solve a problem. To qualify this statement in the software world:

• Leadership can use it to define growth strategies based on business outcomes
• Product marketers can use this theory to perform market segmentation, identifying points of differentiation, and points of parity
• Product research teams can conduct focused JTBD interviews to gain insights about the occupation of various users
• Product teams can use this theory to ensure the chosen solutions map to the identified problems – a better version of requirement traceability
• Product managers and product owners in articulating stories
• Quality teams in designing test scenarios that meet the objective of the job to be done
• Architects and developers to achieve tight alignment of their solution with the different jobs

Comparing problem-first vs. solution-first

Let me share an example from an enterprise landscape in the context of the RFP response team.

Consider a scenario where a business has asked for a proposal to create a new web portal for its employees with a set of features. In the solution-first world (you might see this happening on freelancing websites where people are immediately responding with quotes), you would imagine the following:

• An entire team ramping up to create this new web portal
• Analysts and architects aligned to understand the requirements and prepare a solution for the same
• PM assigned to determine the cost, team, and schedule for the proposal
• Submit the response

In contrast, in the jobs-to-be-done world, this is how things will unfold:

• A core team reads through the proposal and prepares an interview questionnaire to discuss the jobs behind the selected features
• Interviews the business to get the required insights
• Frames statements for the jobs to be done and desired outcome
• Ranks statements and prepares a prioritized roadmap
• Evaluates various solutions for different jobs
• Selects a solution and submits a proposal that tightly aligns with the roadmap created for the ranked jobs to be done

Some key differences in the two approaches show a clear preference towards:

• Outcomes over output – Building a web portal is just an output whereas the expected outcome is to get the job done through the web portal, effectively.
• Alternatives over the requested solution – Evaluating multiple solutions rather than a simple selection of the one mentioned in the request.
• Roadmap over short-term plan – Prioritizing what goes first while showing the evolution of the solution.

How did I apply this theory?

While I continue to learn about the usage of the theory, let me share an example of how I applied it in a B2B context:

Stated problem statement

• Achieving a single sign-on is not possible between applications because multiple identity providers exist

Clarification statement given

• To ensure that the user is not challenged whenever moving from one application to another

How did I apply JTBD?

1. Framing the problem statement from the user’s perspective - The problem statement came from a technology group, describing the situation from their perspective, and not from a user’s perspective.
2. Formulating an interview questionnaire – This was based on the JTBD framework to dig deeper into the problem. This provided insights about the following:
   a. The job to be done and the desired outcome such as:
   • Accessing sensitive information while communicating with a customer or a prospect
   • Reducing frictions while communicating with a customer or prospect
     b. Direction of improvement – Reduction
     c. Performance metric – Friction. Defining friction as steps performed to access sensitive information. E.g., entering login information each time when traversing from one system to another
     d. Verb - Access
     e. The object of control – Sensitive information
     f. Contextual clarifier – While communicating with a customer or prospect
     g. Considering that business wants to ensure access control over sensitive information, the software user when communicating with customer wants to eliminate barriers to get information faster.
3. Considering that multiple personas were impacted by this situation, I created job stories that address the job to be done while capturing the anxiety and motivation of the user. E.g., When talking to a prospect about similar projects done in the past,
   • the salesperson wants the ability to access past opportunity data quickly
   • the prospect wants to know the price quote of the project quickly
     
     

so, the prospect feels comfortable while discussing the opportunity

In this scenario above, whoever is using the B2B software would like to access information faster. 

Why is it important to learn more about a job to be done?

To summarize, the theory is important because:

• Defining the core functional problem or the job to be done allows finding contextual solutions – Example: “while being away from home,” “on the go,” etc.
• It does not talk about a persona to which the situation applies, implying my market segment is not restricted to a few personas, aka outcome-driven segmentation.
• Drilling deeper inside a job helps to uncover outcomes, thereby presenting the opportunity to find points of differentiation. Example: In the job to control appliances away from home, a potential outcome could be to maximize the number of devices that can be controlled from a single hub. The ability to control more devices than a competitor’s similar product becomes a candidate for point of differentiation.
• It has an immense number of applications across the product’s lifecycle. Example: A development project to upgrade the underlying platform can have outcomes like reducing the time taken to expand the product into new verticals or new geographies.
• It lends clarity to the entire product team. Example: If a customer, during an interaction with a prospect, could not log in to an e-commerce platform to create a quotation may seem another bug for the development team. However, in real-world, it means that the customer lost business and probably the prospect forever. If the development team is clear about the job to be done, the entire approach changes.

Most importantly, there is no mention of a solution while describing problem statements.

TLDR – Too Long Didn’t Read

Advantages of adopting a Problem first approach:

• The Jobs-to-be-done theory presents multiple opportunities to innovate at each stage of a product’s lifecycle.
• The theory can be applied by anyone while solving a problem. There are several applications in a software development environment – both B2B and B2C.
• Product teams can use it to ensure clarity across all disciplines like requirements, UX, development, and quality while building the software.
• Outcomes over output – the framework helps to define multiple desired outcome statements that align with the jobs to be done.
• Job stories help to cover broader scenarios that impact a larger user base than a single persona.