Complete product discovery framework

Many product designers imagine their job will feel like detective work. A problem gets handed over, and it’s your job to investigate and solve it: talk to customers, find the gaps, and make sense of it all.

But that’s not the reality for most people. Most designers get handed a set of requirements from a PM, turn those into a prototype, and pass them on to a developer. There’s no space to question the problem. No time to dig deeper. No expectation to do anything beyond execution.

That’s why discovery is such a pivotal skill. It’s not just a way to improve your projects: it’s how you break out of that cycle and redefine your role.

Why discovery matters for your career

When you lead discovery, your value to the company changes fundamentally:

• You’re no longer just delivering designs
• You’re filling knowledge gaps, reducing risk, and making smarter decisions
• You’re shaping what gets built, not just how it looks

The alternative is stagnation. If you’re just turning PM requirements into screens, your role becomes about speed and efficiency. That’s a role that’s easy to replace, automate, or outsource. But if you’re the person who uncovers insights, shares them across the team, and helps others make smarter decisions: that’s not easily replaceable. That’s a role with strategic value.

What discovery really means

Discovery is about taking something vague and making it concrete. You’re not just responding to a task like “make this better.” You’re figuring out what’s broken, why it matters, and what’s stopping the team from fixing it.

Discovery is not just UX research. It’s a way of working that connects your team’s efforts to business goals. It helps you move faster, reduce waste, and make measurable progress. Research is one tool inside discovery, but discovery is about aligning the whole team around what matters and learning your way forward.

The discovery framework

This framework helps you capture the context, constraints, and opportunities surrounding a product problem before exploring solutions. It ensures your design work solves the right problem in a way that aligns with both user needs and business strategy.

Run it as a shared whiteboard. Encourage your team to contribute asynchronously, then use synchronous meetings to discuss what was added. Not everything needs to be filled in upfront.

1. Problem definition

What are we solving? Frame it from the user’s point of view. Don’t start with a solution: start with the problem. A strong problem statement names who is affected, what they can’t do, and what the consequence is. If you can’t write it down clearly, you’re not ready to design.

2. Who has this problem?

Who are the affected users? Include real user types, segments, or roles. Add context like behaviours, goals, and environment. Use real user types if known, not generic personas.

3. What’s the business opportunity or risk?

Why does this matter to the business? What outcome could be unlocked, or what risk avoided, if we solve this? Focus on business metrics, goals, or risks (e.g., churn, operational costs, ARR, NPS).

This connects your discovery work directly to business value: essential for getting buy-in and demonstrating impact.

4. How do we know it’s real?

What evidence supports this problem? Use both qualitative (e.g., interviews, support chats) and quantitative (e.g., dashboards, funnels) sources. Try to link this to observable patterns, complaints, or conversion data.

5. What’s been tried already?

What previous efforts have been made to solve this? Consider both partial solutions and workarounds. What didn’t work, and why? Understanding past failures prevents you from repeating mistakes.

6. How do competitors solve this?

Have other companies solved this problem well? What ideas can we borrow, adapt, or avoid? This isn’t about copying: it’s about learning from what works and finding opportunities to differentiate.

7. What assumptions do we have?

List key assumptions about why this is happening, what users want, what they’ll do if we solve it, and what kind of solution might be needed. Link each assumption back to a specific problem identified in section 1.

Assumptions are risky. Identifying them early helps you:

• Highlight gaps in knowledge
• Prioritize research opportunities
• Design experiments to validate or invalidate assumptions
• Avoid building solutions based on untested guesses

8. Desired outcomes

What behaviour change are we aiming for? Connect the problem to a measurable success signal. Think in terms of leading indicators: what user action would tell you the problem is solved? Then trace that forward to the product metric or business outcome it feeds into.

9. How might we solve the problem?

List ideas for potential solutions. For each one, tie it back to the specific problem it addresses. This is a space for early exploration: no need for validation yet. Keep ideas loosely held.

10. Hypotheses

The final step is forming hypotheses: one type to explore whether the problem is real (discovery hypothesis), and one to validate whether your solution will work (delivery hypothesis). Getting this distinction right is the difference between validating a direction and validating a design. The course covers both templates in depth, with worked examples from real projects.

Making discovery collaborative

Discovery shouldn’t be owned by an individual. It’s more effective when it’s collaborative. Try using a whiteboard for this and encouraging the whole team to collaborate.

People are much more likely to contribute to a shared whiteboard than a document. It feels lighter and more collaborative. With a little context and the right structure, it becomes an effective way to gather insights across departments and build momentum.

Breaking out of the requirements trap

Many designers get trapped in a cycle: requirements into blueprints, over and over again. It’s not what the role was meant to be, and designers know it. But it’s hard to escape once you start. It becomes what’s expected from you.

Your value gets measured by how fast you deliver designs to developers. But there’s a better way.

The common issue designers face: “My PM already does discovery.” If you’re leaving this entirely to a PM, start splitting up responsibilities now. But do it from an attitude of support and humility, not entitlement.

The benefits of discovery

When you use discovery to guide your work, you prevent several common problems:

• Prevents rushing to solutions: You won’t create solutions to problems nobody has
• Focuses on outcomes: You prioritise business impact and user behaviour over outputs
• Frames design as experiments: Release, analyse, iterate: not just build and hope
• Ensures problem understanding: You understand the problem before jumping into solutions
• Gathers knowledge in one place: All research, context, and assumptions are documented
• Identifies knowledge gaps: You know what you don’t know and can address it

Your job is to reduce risk

Designers often talk about solving user problems. But discovery goes further. You’re helping your team:

• Identify the right problems
• Understand the opportunity size
• Avoid investing in low-impact solutions
• De-risk work by breaking it into smaller, testable steps

This means asking questions like:

• Why is this worth solving?
• What happens if we don’t solve it?
• How will we know if it’s working?
• What’s the fastest way to learn something useful?

The answers help your team invest wisely. And they position you as someone who drives clarity, not just design.

Putting it into practice

You won’t have all the data you need available all the time. If there are critical gaps that you think the success of your design relies on, you need to gather more data: either in the form of user research or experiments designed to validate assumptions with minimum disruption.

Start with one project. Don’t wait for something complex before giving the framework a try. Even trivial design tasks benefit from discovery thinking. Next, get a cross-functional group of people involved. Encourage them to add to the whiteboard asynchronously and organise a meeting to discuss the stickies.

Your next steps

Discovery isn’t something you do once: it’s a way of working. Start incorporating it into your process:

1. Pick one project where you can practice discovery
2. Set up a whiteboard using this framework
3. Invite your team to contribute asynchronously
4. Schedule a meeting to discuss what was added
5. Use the insights to guide your design decisions

Remember: discovery is about reducing risk and building confidence before you build. It’s about shaping what gets built, not just how it looks.