Breaking Out of the Solution Trap
By: Jim Fullmer
Tags: User Experience, User Experience Design, Human Needs, Problem Framing, Jobs To Be Done

Breaking Out of the Solution Trap

The outcome-driven Jobs to Be Done approach can help project teams stay focused on people problems, not their own solutions. Jim Fullmer Follow Feb 6, 2020 · 6 min read

In my experience across various companies, one of the most common traps I’ve seen project teams run into is falling in love with their solution and losing focus on the underlying problems they’re trying to help people solve. This trap can easily become a downward spiral as the team creates solutions to solve problems presented by solutions — with ever-diminishing returns for the people they’re trying to serve.



The best way I’ve found to avoid such traps is an outcome-driven approach to framing the problem space called Jobs to Be Done (JTBD). It’s based on helping people accomplish their goals in a better way, regardless of the types of solutions that you — or they — tend to favor.

Keep solutions out of problem framing

When you let solutions creep into your problem framing, it hampers your ability to think beyond the solution — and freezes you into current conditions. By contrast, a well-framed, solution-agnostic problem will not likely change much over time.

Let’s take a simple example from my own (very busy) family life. My wife loves her paper calendar because it’s easy, quick, and personal. I hate it because it’s hard to share with me, so I often have to ask her what’s coming up. The problem statement might be framed something like this:

Solution agnostic problem framing based upon your research insights is more likely to stand the test of time.

If the problem framing on the left were used, flipping from month to month would always be part of my solution, preventing me from exploring other ways to deliver that sense of schedule she’s trying to achieve. Key questions would go unasked, such as: Why must changes to events be done in writing — are there other ways she might be able to make changes? Given the opportunity, would she enjoy another way of personalizing events even more than her current practice of adding drawings or capital letters?



A simple comparison scorecard drives home the need and the desired solution. The paper calendar does well at all but one of the jobs. My wife’s phone calendar only does one of the jobs well (the one I care about). We’ve yet to find a good solution that meets both our needs.

Applying an experience scorecard to a set of Jobs To Be Done can provide valuable guidance for identifying attributes of a good solution.

If I were try to create a custom solution, it would have to help our family achieve all four outcomes in a way that meets or exceeds our expectations. To inspire my wife to change from the solution she’s habituated to, I’d have to create a solution that significantly exceeds her expectations … otherwise, why change what’s been working well for her?

Jobs to Be Done in action

When I join a team, one of the first things I try to do is to separate the problem space from the solution space. My first step is to talk with team members 1:1 to capture each person’s thoughts about the user or customer problems our team is trying to solve. I ask questions like:

Why does this solution exist?

What problems does it solve for folks?

How well does it do it?

How do you know?

Which other solutions do people consider, and why?

I also go through past research, translating prior insights and problems people experience into candidate “job statements” — brief descriptions of what people are trying to get done, rather than what they’re doing. This lets me get to the following outcomes more quickly and effortlessly:

Identify an early list of candidate jobs based on tribal knowledge and past learnings. Understand alignment across the team on the problems we’re solving for our users/customers. Understand how well the team separates the problem space from the solution space. Understand how well the team acts on research findings.

After putting together a list of candidate jobs and outcomes, the next step is usually to create a hypothesis asserting that the list of candidate jobs I currently have defines the entirety of the problem space (or experience domain) in which my product plays.



I can usually disprove this hypothesis pretty quickly by doing a little qualitative research. Usual approaches include one or both of the following:

Schedule some 1:1 interviews and observation sessions with people I think are the target users (“job executors” in Tony Ulwick’s framing) for the solution.

Survey customers who just used the product, asking “What were you trying to accomplish just now?” followed up by asking “Why?” a couple times … and then follow up with “How was your experience trying to get that done?”

After converging insights across as many participants as needed, I go back to the team and compare the candidate jobs found in previous conversations with learnings from the first round of research. Grounding the team with evidence-based insights versus tribal knowledge helps the team understand and adopt the jobs and contexts that matter to users.

How to make a statement

The Jobs to Be Done approach is all about framing your problem space and carefully crafting your “job statements” in a solution-agnostic way. Here’s an example of an outcome-driven job statement, based on my family’s scheduling problem:



“Minimize the effort required for my family to coordinate a shared schedule when certain family members feel left out of the loop.”



The desired outcome is often the directional metric that matters most to the people trying to get the job done. In this case, it’s “Minimize the effort.”



The rest of the job statement has four parts:

Who: “my family” Verb: “coordinate” Object of the verb: “a shared schedule” Context: “when certain family members feel left out of the loop”

Try to keep your outcome statements to a single job and context. If there are multiple contexts for the job, remove the context from the job statement. Instead, include the multiple contexts in a 1-pager defining the job, why it matters, when it matters, and so forth.



Because a job statement like this is solution agnostic, you can actually use it to gauge other solutions. It can be a main pivot for competitive analysis, helping you understand how competitors approach solving the problem.



When you frame your problems well, you should be able to see how the solutions vary in their approach to the problem, as well as the advantages or disadvantages when people are trying to achieve the job related to a directional metric for a job well done.

Good job

A well-defined problem, job, or outcome should:

Define a meaningful problem for your user or customer that is unlikely to change over time.

Be rooted in your customer or user insights.

Be measurable so that you can compare your solution to competitors’ and expectations.

Not mention solutions.

Enable your targeted customer or user to explain the value associated with a solution relative to the problem.

Once you have your set of problems, start exploring different and better ways to solve those problems. Is there something unique or differentiating in the way that your company can solve the problem? If a competitor came in with a better way to solve the problem, what would be the impact?



People developing solutions often put their heart and soul, or at least a lot of time and energy, into something they hope will succeed. But the very definition of success can become a barrier to actual success if not framed properly. Good problem-space framing tools like Jobs To Be Done can help you maintain your focus on your user base and their needs over the life of a product and beyond.