How product managers can use design thinking to run better discovery, validate assumptions, avoid building the wrong features, and align stakeholders.
Product managers sit at the intersection of business, technology, and user experience. Design thinking gives PMs a structured approach to the hardest part of their job: figuring out what to build. Not what is technically possible, not what stakeholders are requesting, but what will actually solve a real problem for real people in a way that sustains a business.
Most product failures are not engineering failures. The code compiles. The servers stay up. The features work as specified. The failure is that the features do not matter to users. They solve the wrong problem, or they solve the right problem in a way that does not fit how people actually work and think.
This is a PM-level failure, not a development-level failure. And it is remarkably common. A 2019 Pendo study found that 80% of features in the average software product are rarely or never used. That is an enormous amount of engineering time spent building things that do not matter.
Design thinking directly addresses this by front-loading research and empathy before committing to solutions. It forces PMs to answer "Are we solving the right problem?" before asking "Are we building the right features?" This sequencing seems obvious, but in practice most product teams skip it. The pressure to ship, the backlog of stakeholder requests, the urgency of competitive features, all of these push PMs toward building before understanding.
Before starting any discovery work, define the challenge explicitly. Write down: What problem are we exploring? Who are the target users? What does success look like? What constraints exist (timeline, budget, team capacity, technology stack, regulatory requirements)?
This prevents "research drift," the common pattern where discovery work expands endlessly without a clear focus because nobody defined what they were looking for. See the Initialize stage guide for a detailed framework.
A useful exercise: before starting research, write down your current hypothesis about the problem and solution. Be specific. "We believe [user type] struggles with [specific problem] because [reason], and solving it with [approach] would improve [metric] by [amount]." This hypothesis is probably wrong, but having it written down means you can test it deliberately rather than confirming it unconsciously.
Talk to users. Not just power users who fill out feedback surveys, but the silent majority who quietly struggle, the churned users who left without explanation, and the non-users who looked at your product and decided not to sign up.
Most PM teams have a severe sampling bias. They talk to users who proactively reach out (the loudest 5%) and generalize those opinions to the entire user base. Design thinking's empathy research corrects this by requiring deliberate outreach to underrepresented segments.
Use a mix of methods:
Create empathy maps and user profiles to synthesize what you learn into artifacts the team can reference throughout the project.
Synthesize your research into How Might We questions rather than jumping to feature specifications. This is where many PMs struggle because their training and tooling are optimized for writing specs, not for sitting with ambiguity.
A good HMW question is specific enough to guide ideation but broad enough to allow multiple solutions:
See the Define stage guide for the full problem statement framework.
Generate as many solutions as possible without evaluating them. This is psychologically difficult for PMs because their job usually involves evaluating and prioritizing. During ideation, the PM's job is to facilitate generation, not to filter.
After generation, evaluate using structured criteria:
This is where PMs add unique value: connecting user needs to business viability and technical feasibility. Designers can assess desirability, engineers can assess feasibility, but PMs are uniquely positioned to evaluate viability and strategic fit. See the Ideate stage guide for brainstorming techniques.
Build lightweight prototypes of your top ideas. For PMs, this often means:
The goal is to make the idea concrete enough to test, not to build the final product. If you are spending more than a few days on a prototype, you are investing too much before validation. See the Prototype stage guide and Rapid Prototyping for Beginners.
Put prototypes in front of real users. Watch how they interact. Ask what they expect to happen. Ask what confuses them. The goal is to learn, not to validate your idea.
The difference between learning and selling is subtle but critical. When you are selling, you guide users toward success and explain things when they get stuck. When you are learning, you watch what happens when users encounter your prototype with no guidance and no explanation. The unguided experience reveals the real usability and comprehension issues.
Explore different user testing methods and choose the one that matches your timeline and resources.
Design thinking and Agile are complementary, not competing. The practical integration model for PMs:
Run design thinking as a continuous discovery process that operates 1 to 2 sprints ahead of the delivery team. While engineers build sprint N's validated features, the PM and designer are researching and prototyping what will become sprint N+2's work.
The discovery output is not a traditional requirements document. It is a brief that includes: the user need (with evidence), the proposed solution (with prototype and test results), the success metrics, and the key risks. This gives the engineering team enough context to make good implementation decisions without prescribing technical details.
Many PMs, especially at startups and small companies, do not have a dedicated UX research team. This does not mean they cannot practice design thinking. It means they need to be more efficient with their time and more intentional about the methods they choose.
Practical approaches for solo PMs:
Related guides: design thinking non designers · design thinking leadership · design thinking startups
Design Thinker Labs Home · All Guides · How It Works · Pricing