Problem Space Before Solution Space

How Jobs-to-Be-Done turns feature requests into product judgment

I first learned problem-solving from innovation legend Dr. Bob Basudur, when I took his “Creative Problem Solving” course as a young manufacturing engineer with Converse. Later, after learning about jobs-to-be-done methods, it was natural to bring those into my problem-solving world.

For those in product management or those in leadership, few concepts are as important as this distinction between solutions and problems, or if you prefer, between products and jobs.

Working with hundreds of product teams, I don’t see teams failing because they don’t understand some advanced concept. They fail because they don’t understand the basics. And nothing is more basic than keeping problems and solutions separate.

Let’s explore this fundamental tenet, upon which all innovation is built.

Feature Requests Cosplaying as Insight

Here is a sampling of what lands in a product manager’s inbox on any given week.

“We need better reporting.”

“Customers are asking for AI.”

“The enterprise team says we need this integration.”

“Competitor X just launched it, so we need a response.”

“Users keep saying the product needs to be easier.”

“Can we add a wizard?”

Each of these statements contains a certain kind of usefulness. They come from credible sources. I’m sure that they point toward something real, reflect genuine customer frustration, or flag a competitive risk that deserves attention.

But the worst thing to do, would be to go forth and build these. These statements provide the initial clue. These are expressed in solution-space language: language that describes what the product might do, not what the customer actually needs to accomplish.

Further, these suggestions don’t address a product team’s core problem. They do not suffer from a shortage of ideas. Not even close. But, they suffer from a shortage of problem clarity. A feature request may contain a valuable hint, but it is rarely the signal in finished form.

The Core Distinction: Problem Space vs. Solution Space

Solution space is the world of features and product attributes. It’s the vocabulary of what a product might become.

Problem space is different. It is the world of what customers are trying to accomplish, what makes that difficult, where current approaches break down, what slows customers down, what creates risk or rework, and how customers judge whether they have succeeded. It is the vocabulary of what the customer is trying to do.

Some examples…

A solution-space statement: “Build a dashboard.” A problem-space statement: “Identify service failures.”

A solution-space statement: “Add Slack integration.” A problem-space statement: “Resolve workflow exceptions.”

A solution-space statement: “Add a wizard.” A problem-space statement: “Complete an unfamiliar workflow.”

Solution space describes what the product might become. Problem space describes what the customer needs to accomplish. A roadmap item is not a customer problem. It is a set of possible responses to a customer problem.

Solution space is where product teams design answers. Problem space is where they learn which questions are worth answering.

Working in solution space is not bad, of course. Every product team must eventually get there. The danger is working there too soon, before the team has defined the problem well-enough.

If we’re good on this point, and you’re not interested in jobs-to-be-done, then – fair enough. But to take this one more level, towards making all the data to be more actionable. Then, take this next step with me.

Problem space benefits from a usable language. Product teams need a way to express customer need without smuggling the solution back into the statement. That is where Jobs-to-Be-Done enters the frame.

Jobs-to-Be-Done: The Language of Problem Space

A Job-to-Be-Done is the customer’s goal, objective, or problem to be solved. Not the product they want. Not the feature they asked for. The underlying thing they are trying to accomplish.

A JTBD describes what customers are trying to achieve. It does not prescribe the product, feature, workflow, or technology that should serve it. It gives product teams a stable anchor for discovery and keeps them from confusing a requested solution with the need underneath it.

A simple translation model helps PMs work with this in practice:

Request: “We need better reporting.”

Job: “Determine what corrective action to make.”

Evidence: “Managers spend hours assembling reports and still miss emerging issues.”

The request is what the customer asks for. The job is what they are trying to accomplish. The evidence is why the job matters enough to prioritize. Without all three, a roadmap commitment is built on incomplete information.

A few more translations to make this concrete:

Request: “We need an integration.” Job: “Move work across systems.”

Request: “We need AI summaries.” Job: “Interpret large amounts of information.”

If solution space is expressed in features, problem space is often best expressed as jobs.

JTBD is useful because it forces the team to ask, “What is the customer trying to accomplish?” before asking, “What should we build?” A good job statement keeps the team focused on customer progress, not product preference.

This matters because product organizations are constantly pulled back toward solution-space motion.

Why Solution Space Feels So Productive

Everybody in the product ecosystem wants something different. Customers want commitments. Sales wants deal support. Customer success wants churn risks addressed. Engineers want clear requirements. Design wants direction. Executives want differentiation. Marketing wants positioning. Competitors create anxiety. Quarterly planning creates pressure to have answers.

All of that pressure points in the same direction: produce something visible, produce it now, and make sure it can be described in a slide.

Solution space delivers. It creates prototypes and demos. It gives executives something they can point to. It makes the team feel like it is moving. It satisfies the need to show progress at an upcoming meeting.

Problem-space work looks different. It means interviewing customers, observing behavior, mapping jobs, clarifying context, understanding workarounds, defining success criteria, and testing whether a request reflects a broad market need or a narrow preference. Many executives, unfortunately, lose patience during this exploration.

But here’s why executives should think about this differently: a team can move very quickly and still move in the wrong direction! Product discovery appears to be not valuable because it delays building, something that looks more tangible. But, of course, it is valuable because it redirects building toward problems that matter.

Product leaders should be careful not to mistake visible product activity for validated product judgment. The trap is easiest to see in the kinds of requests product teams hear every week.

A Modern Request that all PMs are Hearing Right Now: “Customers Want AI”

Everyone in product management, right now, has this situation: Customers mention AI. Sales wants an AI story. Executives want an AI strategy. Competitors are launching AI features. The board asks what the company is doing about it.

The solution-space response follows quickly: chatbot, copilot, auto-generated summaries, predictive recommendations, natural-language search, workflow automation. The team starts scoping before anyone has asked the most important question.

That question is not: “What AI feature should we add?”

It is: “What job might AI help the customer accomplish better than existing approaches?”

The possible jobs are varied. Prepare for a customer call with less time and effort. Identify anomalies buried in a long report. Summarize messy notes without losing important detail. Decide what action to take next. Diagnose an issue without reading pages of documentation. Make sense of scattered customer feedback.

The wrong build is possible in every direction. A chatbot may be useless if the real job is preparing for a sales call from scattered account history. An AI summary may miss the mark if the real job is deciding which exception deserves immediate action. Natural-language search may help significantly if the real job is finding the right policy, precedent, or customer detail quickly.

“AI” is not a customer need. It is a possible solution to many different jobs. A product strategy that starts with “add AI” is not yet a strategy. It is a technology preference looking for a customer job.

The Product Leader’s Test

Product leaders do not need to personally conduct every discovery interview. But they do need to inspect the quality of thinking behind roadmap commitments. The question is not whether the team is building something. It is whether they earned the right to build it.

One question cuts through most of the noise: What do we understand about the customer’s job that we did not understand before?

This is a better test than “what are we building?” because it checks whether discovery produced actual learning, not just activity.

Weak rationale sounds familiar. “Customers asked for it.” “Sales says we need it.” “Competitors have it.” “It came up in several calls.” “We already know this is a pain point.” “The largest account wants it.” These statements may all be true. None of them constitutes product understanding.

Stronger rationale sounds different. “We know which customers have this job.” “We know when and where the job becomes difficult.” “We know what customers are trying to accomplish.” “We know what happens when they fail.” “We know what workarounds they use today.” “We know how costly or frequent the struggle is.” “We know how customers judge success.” “We considered multiple possible solutions.” “We can explain why this one is the best current response.”

Product leaders can sharpen this further with supporting questions: What customer job does this roadmap item serve? What evidence tells us this job matters? Where does the current experience break down? Is this a broad market job, a segment-specific job, or a single-customer request? What other solutions did we consider?

The goal is not to slow the team down with bureaucracy. It is to make sure the team has earned confidence before committing scarce engineering capacity to something that may solve the wrong problem.

When executives adopt the logic of jobs-to-be-done, product teams will learn to get in line. It could hardly be overstated how powerful this can be for improving a company systemically.

The Most Fundamental of All Fundamentals: Product Success Begins in Problem Space

In an era before jobs-to-be-done, problem-solving experts understood that before creating a solution, that there must be a well-defined problem. “A problem well-defined is half-solved” has been attributed to many, but seems most likely to be from Charles Kettering, GM’s head of research a century ago.

Inventors and innovators across the ages have understood this. But… we can take this one step further.

Jobs-to-be-done just gives us the practical language to navigate the common product management environment, full of solutions, and often with little patience for exploration.

Whether or not you’re a JTBD appreciator, you’ll build much better product strategies when you learn to discern problem from solution, and build your systems and methods from there.

If this landed for you, share it with a product manager or executive could benefit. To start a conversation, or explore training options, message me on LinkedIn, which you can do here: www.WScottBurleson.com