Two sides of one coin, per Dan Olsen: problem space is the customer problem, need, or benefit a product should address; solution space is the specific feature or design that meets it. Good strategy work states the problem space first and only then moves to solution space.
The clearest tool for forcing this order is the agile user story template — As a [type of customer], I want to [do X] so I can [enjoy benefit Y] — which requires naming the customer and the benefit before any feature is proposed.
The named failure mode is solution pollution: proposing a specific feature without grounding it in a customer problem first. Olsen's response technique surfaces the hidden problem statement: "I hear you saying we should build feature X — can you help me understand how's that going to benefit the customer, how is that going to create value for the customer?"
Apply: when a stakeholder or teammate pitches a feature, ask the solution-pollution question before debating the feature itself. Related to Solution Discovery vs. Problem Discovery and Customer Requests as Clues, Not Specs.
A phrasing rule for keeping problem-space and performance-space statements visibly distinct on a slide or grid: problem-space statements start with a verb (e.g., 'save time'), while performance statements use comparative adjectives (faster, cheaper, nicer, safer). The comparative phrasing can double as an internal slogan — see Uber's Series A Positioning (Three-Dimension Case Study)'s 'faster and cheaper than a limo, but nicer and safer than a taxi cab.'
Apply: When rewriting a benefits slide, phrase needs as verb-led statements and competitive strengths as comparative adjectives, so the two framings don't blur together.
Dan Olsen ("Dan Olsen on How to Prioritize Customer Needs") frames this as the central discipline of product management: a PM's job is to "define who's the customer and what are their problems" before any solution is proposed. He cites that 80-90% of new products fail, largely because teams either (a) start from a solution instead of a problem, or (b) validate a real problem that nonetheless isn't a good opportunity (see Importance vs. Satisfaction (Opportunity) Framework). Mode (a) is a pure problem/solution-space conflation; mode (b) is a prioritization failure that occurs even when the problem space was correctly identified — see Three Failure Modes for New Products Despite Good Process.
He operationalizes the distinction with the user story "so I can" clause (see User Story 'So I Can' Template): "so I can enjoy benefit Y" is the problem-space core of a story, while "I want to do X" is solution space bleeding in. A related failure mode is Solution Pollution — smuggling a specific solution into what's presented as a problem statement.
Owning the problem space is also positioned as the PM's core source of influence — see PM Motto: With Great Responsibility Comes Power.
Olsen breaks problem-space work into two discrete steps rather than one: first get clear on exactly what the problem is (using tools like Onion Model (Problem-Layer Peeling) or Benefit Ladder to make it specific), then separately validate that it's a real problem by talking to customers — a defined problem is not automatically a validated one. Skipping straight from "we defined a problem" to building a solution, without the validation step, is a recurring cause behind new-product failures: "you're throwing spaghetti at the wall and seeing what sticks and hoping something sticks."
The concrete output of problem-space work is a cleaned-up, deduplicated, laddered list of customer benefits/needs for a market — this list, not a feature list, is the PM's core "definition" deliverable. It's also the required input to the Importance vs. Satisfaction (Opportunity) Framework prioritization exercise: needs can't be plotted or scored on that grid until they've first been distilled into this list.