Discovery

Discovery is the work we do to decide what to build. Its job is to make sure that what reaches the roadmap is valuable, viable and feasible, and that we understand the problem well enough to solve the right one.

Principles

Open and shared. Anyone can propose work, and proposals get better when product, design and engineering all bring their insight to them.

Aligned. Every proposal connects to our vision, strategy and current business priorities. A problem that cannot be connected to those is probably not ours to solve right now.

Evidenced. Good discovery balances evidence with judgement. A proposal does not need every question answered, but it should show thoughtful use of what we know.

Rapid. Reviews and decisions are time-boxed. We value iteration, adaptability and learning over exhaustive planning.

Disciplined. We capture decisions, keep the focus on valuable outcomes, and resist designing the whole solution before the problem is agreed.

Discovery never stops

Discovery is not a phase that ends when design begins. It runs alongside design and implementation, and what we learn feeds back: problems get broken into smaller, independent ones, assumptions get tested, and priorities shift. Operation is discovery too; support trends and usage data are some of the richest evidence we have.

Who does it

Plan discovery with people who bring different perspectives. A good starting point is a trio of a product manager, a user experience designer and a software engineer. Extend it with whoever the problem needs: a test engineer to think about risk and testability early, a business analyst, or colleagues from editorial, customer experience or customer support who see the problem first hand.

What we are trying to learn

• Who does the problem affect, and how widely?
• Is the stated problem the real problem? What assumptions are built into it?
• What value would solving it create, for users, customers and AM?
• What risks and dependencies come with solving it?
• Are the solution ideas on the table viable?

How we learn it

Choose activities by what you need to know, not by habit. Some give qualitative insight: user interviews, usability testing, customer visits, stakeholder workshops. Some give numbers: usage analytics, A/B tests, surveys. Some help sort what you already know: journey mapping, assumption mapping, competitor analysis, support feedback, root cause analysis, opportunity solution trees.

Technical discovery sits alongside: time-boxed investigations and spikes that evaluate existing and new technologies, break the outcome into components, surface technical assumptions and risks, and give a rough order of magnitude for effort. This is what the feasibility step of validation draws on.

What comes out

Findings are saved centrally and shared with stakeholders. They inform the proposal, then the canonical objective document, and later the requirements and design. Discovery that produces no record produces no value for the next person.

For the theory behind this approach, read Continuous Discovery Habits by Teresa Torres.