Solution Discovery vs. Problem Discovery

Cagan draws a line between two different things a team can contest during Discovery (Product Discovery Process):

Problem discovery — disputing whether the problem a stakeholder or leader handed down is even real or worth solving.
Solution discovery — accepting the problem as given, and spending discovery effort finding the best possible solution to it.

His advice: pick your battles. Once an empowered team has been handed a problem, the clock is already running ("the moment they give an empowered product team a problem to solve, the clock starts ticking") — so spend the available runway on solution discovery, and save disagreement about whether the problem itself is the right one for the next strategy cycle, not mid-sprint. Relatedly: "they don't buy the problem, they buy our solution" — customers pay for the solution's quality, not for whether the team also got to relitigate the problem statement.

Problem Space vs. Solution Space (Olsen)

Dan Olsen (Google talk on product strategy) frames this same split as problem space vs. solution space: problem space is the customer need/benefit, ideally captured as an Agile-style user story ('As a [user], I want [need], so that [benefit]'); solution space is the specific feature or design chosen to meet it. Olsen attributes over 80% of product failures to skipping problem space and jumping straight into solution space — designing before the need is established or validated. His Product Strategy Grid and the Kano Model it's built on are explicitly problem-space tools; the Lean Product Process is what solution space looks like once problem space is settled.

Из тем: The Product Operating Model