This guide provides a comprehensive checklist for establishing the essential processes for a new Product Discovery team. Discovery and Delivery teams can operate separately, but their workflows must be tightly integrated.

A typical Discovery team includes product leads, managers, analysts, and UX designers. For technical tasks, team leads and architects join the effort. The team's primary goal is to validate and refine initiatives before they land in the product backlog for the Delivery team to implement.

Discovery answers the questions, 'What should we build?' and 'Should we build it at all?'
Delivery answers, 'How should we build it?'

The Discovery Process Checklist

Team Setup and Roles

Appoint a Discovery Master: This role, which can be filled by a Product Manager, Analyst, or Designer, leads the discovery process.
Ensure Agile Proficiency: The Discovery Master should be well-versed in Agile principles by reading the Scrum Guide, completing foundational training, and passing the Scrum Open assessment with a score of 85% or higher.

Sprint Framework & Ceremonies

Structure Work in Sprints: Organize work into 1 or 2-week sprints to validate and refine initiatives.
Define a Sprint Goal: Start each sprint by defining a clear goal. Prioritize tasks that contribute to this goal first, and don't take on more work than the team's average velocity.
Dedicate Time for Research: Allocate at least 30% of each sprint to clarifying problem and solution hypotheses.
Run Key Meetings: Conduct regular Sprint Planning, Daily Standups, Sprint Reviews (Demos), and Retrospectives to maintain alignment and continuous improvement.

Definitions and Criteria

Definition of Ready (DoR): Establish clear criteria for when a task is ready to be taken into a sprint.
Definition of Done (DoD): Define and adhere to strict quality criteria for completed initiatives. This DoD must be synchronized with the Delivery team's DoR.
Acceptance Criteria: Every task in your project management tool must have specific acceptance criteria or a clear description of the expected outcome.

Backlog and Roadmap Management

Prioritize with a Scoring Model: Use a framework like RICE to assign a confidence level to each backlog item, iteratively validating and adjusting its priority.
Maintain a Forward-Looking Roadmap: Keep a Discovery roadmap planned for at least two sprints ahead to ensure the Delivery team has a steady stream of validated work.
Keep Organized Backlogs: Manage the Discovery backlog (problems and solutions), the sprint backlog, and a separate backlog for retrospective action items in your project management tool.

Customer-Centric Approach

Utilize All Feedback Channels: The team must be proficient in gathering insights from all customer channels, including support, sales, app store reviews, and UX research.
Centralize Insights: Create a single repository for storing all hypotheses, problems, and customer requests to identify recurring themes.
Prioritize the Voice of the Customer: This should be a guiding principle both before and after a product launch.
Assign a VoC Champion: Designate a rotating role within the team each sprint to be responsible for analyzing customer feedback.

Understanding Discovery Sprints

Discovery sprints run in parallel with development sprints, aiming to produce well-researched, validated initiatives for the product backlog. They follow standard Scrum events but stay at least two sprints ahead of development to prevent bottlenecks. The process is rooted in Design Thinking: moving from a symptom to a spectrum of problems, and then to a spectrum of solutions.

Problems Solved by This Approach

Fills the gap in the Scrum guide on how validated items get into the product backlog.
Ensures that only justified initiatives make it into the backlog.
Involves developers early, reducing the risk of poorly defined tasks.
Keeps designers, analysts, and product managers fully engaged in meaningful work.
Promotes systematic evaluation of alternative solutions instead of settling for the first idea.
Feeds the backlog with high-priority items regularly, not just what's available.

Potential Side Effects and Solutions

Problem: Developers feel disconnected. Solution: Maintain an open calendar of Discovery events and invite developers to participate.
Problem: Lack of transparency between teams. Solution: Align schedules. Hold Delivery demos and stand-ups just before the Discovery team's corresponding events.
Problem: Development is waiting for tasks. Solution: The Discovery team must stay 1-2 sprints ahead of the Delivery team.

Discovery Definition of Done (DoD)

The output of a discovery sprint is either a validated problem (to be analyzed further) or a validated solution (ready for the delivery team). Therefore, the DoD has two parts.

DoD for a Problem

What problem are we solving?
What is the root cause of the problem?
How do we know this problem exists (data, feedback)?
Who experiences this problem, and how many of them are there?
How critical is the problem for them (blocker, annoyance)?
How will we measure success if we solve it?
Which other teams or product areas are affected?

DoD for a Solution

What is the proposed solution?
What alternative solutions have been considered (including doing nothing)?
Why is this the best solution for the user and the business?
How will we test that the solution works (e.g., A/B test, user testing)?
What are the success and failure metrics for the test?
How does this solution fit into the overall user journey?
Is this an MVP or the final version? What does the ideal state look like?
How will we inform users about this change?

Useful Resources

#agile #scrum