Discover · Core

Frame the opportunity and what you need to learn

Before any research, agree why this work matters, what outcome you are aiming for and what you do not yet know. A clear frame stops discovery from drifting and tells you when it is finished.

About 1-2 daysEvergreenLast reviewed 5 November 2026

Who this applies to

Skills it builds: Discovery and research
PM types: All
Product types: All
Starting points: All
Ways of working: All
Experience: All
Size of organisation: All

Steps, by experience

Beginner (under 1 year)

Write down where the idea came from: a business goal, a user complaint, data, a leadership request or a new technology. Be honest if the source is a solution someone already wants.
Turn it into an outcome, not a feature. Ask: if this worked, what would change for users and for the organisation? Write one or two sentences.
List what you already know and what evidence supports it. Then list what you do not know.
Sort the unknowns into four risks: will people want it (value), can they use it (usability), can we build it (feasibility) and does it work for the business (viability).
Turn the biggest unknowns into three to five learning questions, for example 'Why do new customers stop using the product in week one?'
Agree a time box for discovery, who is in the core team and what decision you will make at the end. Share this one-page frame with your sponsor.

Intermediate (1 to 4 years)

Restate the request as a desired outcome with a measure you could track.
Map known facts, assumptions and unknowns against value, usability, feasibility and viability risk.
Write three to five learning questions and the evidence that would answer each.
Agree the time box, core team, sponsor and end-of-discovery decision.

Experienced (5+ years)

Tie the opportunity to company or product strategy and a measurable outcome; challenge solution-first requests openly.
Rank the four risks by severity and cost of being wrong, and plan discovery around the top two.
Set an explicit decision point and kill criteria up front, so stopping is a normal result rather than a failure.
Get the sponsor to agree the frame in writing before the team starts.

Who can do this

Owner: Product manager

Can be delegated to

User Researcher: Turn the unknowns into research questions and suggest the right methods
Data Analyst or Performance Analyst: Pull existing data that confirms or challenges what you think you know
Tech Lead: Flag early technical constraints and feasibility unknowns

Reviewed by: UX Designer, Delivery Manager

Tool examples

Confluence: Create a one-page opportunity frame with fixed headings: source, outcome, knowns, unknowns, risks, learning questions, time box.
Notion: Use a database of learning questions, each tagged with its risk type and linked to the research that answers it.
Miro: Run a 45-minute session where the team sorts sticky notes into knowns, assumptions and unknowns, then votes on the riskiest.
Claude: Paste the original request and ask for the outcome it implies, the hidden assumptions and five learning questions. Check the questions with your team.

Definition of done

Outcome written in one or two sentences, without naming a solution
Unknowns sorted by risk type, with the riskiest ones highlighted
Three to five learning questions agreed
Time box, team and end decision agreed with the sponsor

Common pitfalls

Treating a requested feature as the outcome
Starting research without agreeing what decision it will inform
No time box, so discovery runs on until it loses support

If you lead the team

What good looks like: Every piece of discovery starts with a written outcome, clear unknowns, a time box and the decision it will inform.