Understanding the Problem

The foundation of product management is understanding the problem — deeply grasping the customer’s needs and pain before deciding what to build. This post covers why problem-understanding comes first, product discovery (learning what to build), the discipline of problems over solutions, and how to actually understand problems (talking to customers). It’s the most important PM skill and the one that most prevents building the wrong thing. Get the problem right, and the rest of product management has a foundation.

Why the problem comes first

Good product management starts with deeply understanding the problem — not jumping to solutions — because building the wrong thing (however well) is the biggest product risk:

• Building the wrong thing is the biggest risk. The most common product failure isn’t poor execution — it’s building something nobody wants (solving a non-problem, or the wrong problem). A team can build brilliantly and still fail if it built the wrong thing. So the biggest risk is building the wrong thing, and avoiding it requires understanding the problem first. The wrong-thing risk dwarfs execution risk. Ship the wrong thing perfectly and you’ve still failed.
• You can’t solve a problem you don’t understand. To build the right thing, you must first understand the problem — the customer’s real need, pain, and situation. Building before understanding is guessing, and guessing usually builds the wrong thing. Deep problem-understanding is the prerequisite for building the right solution. Understand first, build second. No understanding, no right solution.
• The instinct to jump to solutions is the enemy. Both engineers and PMs are drawn to solutions (building is fun; problems are tedious to investigate) — so the natural instinct is to jump to solutions before understanding the problem. This instinct is the enemy of good product management: it leads to building solutions to poorly-understood (or wrong) problems. Resisting the jump-to-solution instinct — staying with the problem first — is a core PM discipline. Resist the urge to build before understanding. Slow down on the problem.

Product management starts with deeply understanding the problem because building the wrong thing (however well) is the biggest product risk, you can’t solve a problem you don’t understand, and the instinct to jump to solutions leads to building the wrong thing. Understanding the problem first is the foundational discipline. The activity of understanding what to build is product discovery.

Product discovery

Product discovery is the work of figuring out what to build — learning about customers, problems, and solutions before (and during) building, to ensure you build the right thing:

• Discovery vs delivery. Product work has two modes: discovery (figuring out what to build — is this the right thing? does it solve a real problem?) and delivery (actually building it). Discovery precedes and informs delivery — you discover what’s worth building, then build it. Skipping discovery (jumping straight to delivery) risks building the wrong thing. Discover what to build, then deliver it. Two modes; discovery comes first.
• Discovery reduces the risk of building the wrong thing. The purpose of discovery is risk reduction — validating (before heavy building) that the problem is real, customers want a solution, and your solution would work. It’s cheaper to learn something’s wrong in discovery (a conversation, a prototype) than to build the wrong thing and find out after. Discovery de-risks by learning before building. Learn cheaply before building expensively. Cheap learning beats expensive mistakes.
• It’s continuous, not one-time. Discovery isn’t a one-time upfront phase — it’s ongoing (continuously learning about customers/problems/solutions as you build and iterate). Good product teams do discovery continuously alongside delivery, constantly validating and learning. Discovery is a continuous practice, not a box to check. Always be learning. Continuous, not a phase.

Product discovery is the ongoing work of figuring out what to build — learning about customers, problems, and solutions to ensure you build the right thing — which precedes and informs delivery and reduces the risk of building the wrong thing (by learning cheaply before building expensively). Discovery is continuous. At its heart is a mindset: problems over solutions.

Problems over solutions

A defining PM mindset is falling in love with the problem, not the solution — staying focused on the problem rather than getting attached to a particular solution:

• Get attached to the problem, not your solution. It’s easy to fall in love with a solution (an idea you’re excited to build) — but the discipline is to stay attached to the problem (the customer need) and hold solutions loosely. If you love your solution, you’ll build it even if it’s wrong; if you love the problem, you’ll find whatever solution actually solves it. Fall in love with the problem. The problem is the constant; solutions are hypotheses.
• Understand the problem before proposing solutions. The discipline is to deeply understand the problem first, and only then consider solutions — rather than starting with a solution and rationalizing the problem. Problem-first thinking (understand the real need, then solve it) beats solution-first thinking (build the cool idea, hope there’s a problem). Problem first, solution second. Diagnose before prescribing.
• The “solution in search of a problem” trap. A classic failure is a solution in search of a problem — building something because it’s technically cool or you’re excited about it, without a real problem it solves. Problems-over-solutions thinking avoids this: start from real problems, not from solutions looking for a use. Don’t build solutions searching for problems. Start from the problem, not the tech.
• This is especially important for engineers. Engineers are especially prone to solution-love (building interesting technology is the fun part). The problems-over-solutions discipline is a key mindset shift for engineers moving toward product thinking: care about the problem and customer value, not just the cool solution. It’s the heart of product-minded engineering. Love the problem, engineer the solution. The hard shift for builders.

The problems-over-solutions mindset — falling in love with the problem (the customer need), not a particular solution — is a defining PM discipline: understand the problem deeply first, hold solutions loosely, and avoid the “solution in search of a problem” trap. It’s especially important (and hard) for engineers. Understanding problems requires actually learning about them.

How to understand problems

Understanding problems isn’t done from a desk — it requires learning directly about customers and their needs, chiefly by talking to them:

• Talk to customers (the highest-leverage activity). The single most important way to understand problems is talking to real customers/users — learning their needs, pain, context, and how they currently cope. Direct customer contact reveals the real problem (which is often different from what you assumed). Talking to customers is the highest-leverage discovery activity — it grounds you in reality rather than assumption. Talk to customers. Nothing beats direct contact.
• Watch what they do, not just what they say. People aren’t always accurate about their own needs (what they say vs what they do differ). So observe actual behavior (how they really work, where they struggle) alongside asking — behavior reveals real problems that stated preferences miss. Observe, don’t just ask. Watch behavior, not just words.
• Ask about problems, not solutions. When learning from customers, focus on their problems and needs (what’s hard, what they’re trying to do), not asking them to design solutions (customers are good at describing problems, less good at specifying solutions — “faster horses”). Understand the problem from them; design the solution yourself. Ask about problems, design solutions. Customers know their pain, not your product.
• Validate assumptions with evidence. Product understanding should rest on evidence (customer conversations, data, observation, experiments) rather than assumptions. The discipline is to validate what you believe about the problem (and later, solutions) with real evidence — replacing assumption with knowledge. Evidence over assumption. Test your beliefs against reality.

Understanding problems requires learning directly — talking to customers (the highest-leverage activity), observing behavior (not just stated preferences), asking about problems (not asking customers to design solutions), and validating assumptions with evidence. This grounds product decisions in reality. Deeply understanding the problem is the foundation of product management — and the best defense against building the wrong thing. Next: prioritization — deciding what to build among all the possibilities.

Key takeaways

• Product management starts with deeply understanding the problem because building the wrong thing (however well) is the biggest product risk (dwarfing execution risk), you can’t solve a problem you don’t understand, and the natural instinct to jump to solutions (building is more fun than investigating) leads to building the wrong thing.
• Product discovery is the ongoing work of figuring out what to build (learning about customers, problems, solutions) — it precedes and informs delivery and reduces the risk of building the wrong thing by learning cheaply (a conversation, a prototype) before building expensively; discovery is continuous, not a one-time upfront phase.
• The problems-over-solutions mindset — fall in love with the problem (the customer need), not a particular solution (hold solutions loosely) — means understanding the problem deeply first and avoiding the “solution in search of a problem” trap (building something cool without a real problem it solves); this is especially important and hard for solution-loving engineers.
• Understand problems by learning directly: talk to real customers (the highest-leverage discovery activity — it reveals the real problem, often different from assumptions), observe actual behavior (not just stated preferences, which can mislead), and ask about problems (not asking customers to design solutions — they know their pain, not your product).
• Ground product decisions in evidence (customer conversations, observation, data, experiments) rather than assumptions — validating beliefs against reality — because deeply understanding the problem is the foundation of product management and the best defense against building the wrong thing.

Further reading

• New product development / discovery (Wikipedia)
• Minimum viable product (Wikipedia)
• What product management is (previous post)