Best practices

Discovery is the work that decides what to build. Delivery is the work that builds it. A team that skips discovery ships what somebody asked for, and learns after the release whether it mattered. A team that runs discovery ships less, and more of what it ships gets used.

These pages follow the practice of empowered product teams, as described by Marty Cagan, Teresa Torres and Jeff Patton. Each page states the practice first and then shows how Roko Platform supports it.

Discovery and delivery

Discovery and delivery are two tracks of the same team's work. They run at the same time, every week. Discovery does not end when delivery starts.

Discovery track

Should we build it?

1. 1Interview customers
2. 2Map opportunities
3. 3Test assumptions
4. 4Prototype options

OutputEvidence and a chosen option

Chosen option, with evidence

Usage data, new questions

Delivery track

Are we building it right?

1. 1Open a change request
2. 2Implement
3. 3Review
4. 4Release and measure

OutputWorking software and usage data

Discovery work is throwaway by design. Most ideas fail a test, and a failed test is a success: it cost a day instead of a quarter. Delivery work is built to last, so it carries tests, reviews and the working model.

Four product risks

Cagan names four risks that every product idea carries. Discovery retires them with evidence before the team commits to delivery.

1Value risk

Will customers choose it and keep using it?

Owner

Product manager

Test

Interviews, fake doors, a manual version

2Usability risk

Can people work out how to use it?

Owner

Designer

Test

Prototype sessions with real users

3Feasibility risk

Can we build it with our time, skills and systems?

Owner

Engineers

Test

Spikes, technical prototypes, diagrams

4Viability risk

Does it work for the business: cost, legal, sales, support?

Owner

Product manager with stakeholders

Test

Reviews with the people who carry the risk

The whole team owns discovery, not only the product manager. A product manager, a designer and a tech lead work together from the first interview. Torres calls this group the product trio and builds her practice around it. An engineer who hears the customer describe the problem proposes better solutions, and spots feasibility risk early.

Continuous discovery

Torres defines continuous discovery as "at a minimum, weekly touchpoints with customers, by the team building the product, where they conduct small research activities in pursuit of a desired product outcome." Treat it as a habit, not a phase.

• Talk to customers every week. One or two interviews a week beat twenty once a quarter. Automate the recruiting so the habit survives busy weeks.
• Work toward one outcome. An outcome is a change in customer behavior that the team can influence, such as "suppliers finish registration in one sitting". It is not a feature list. The opportunity solution tree connects the outcome to what customers need.
• Compare options. For every target opportunity, generate at least three solutions and test them against each other. One idea gives you nothing to compare.
• Test assumptions, not whole ideas. Break an idea into the claims it depends on, and test the riskiest claim first with the smallest test. See Assumption mapping.
• Keep it small. A discovery activity takes hours or days. If a test needs a sprint, it is probably a build.

Principles

These rules come from the practice above. Apply them in every discovery activity.

Practices