Rai Notes

Product Discovery

4 min read

Product discovery is the process of deciding what to build before committing to how to build it. Its purpose is to reduce risk: will customers want it (value risk), can they use it (usability risk), can we build it (feasibility risk), and does it work for the business (viability risk)?

Continuous Discovery

Teresa Torres’s framework centres on building a regular cadence of customer contact into product work.

Weekly customer touchpoints — at minimum, talk to one customer per week. Not big formal research projects; small, frequent conversations that keep the team grounded in reality.

Opportunity Solution Trees (OSTs) — a visual tool linking:

  1. Desired outcome (the metric you want to move)
  2. Opportunities (customer needs, pain points, desires)
  3. Solutions (ideas to address opportunities)
  4. Experiments (tests to validate solutions)

The tree forces you to explore multiple opportunities before jumping to solutions, and multiple solutions before committing to one.

Key principles:

  • Co-create with the cross-functional trio (PM, designer, engineer)
  • Compare and contrast opportunities rather than evaluating them in isolation
  • Test assumptions, not ideas — find the riskiest assumption and design the smallest test

Dual-Track Agile

Coined by Marty Cagan (SVPG). Two parallel tracks running simultaneously:

Discovery track — small team (PM, designer, tech lead) validating ideas through prototypes, experiments, and customer conversations. Output: validated backlog items.

Delivery track — the full engineering team building, testing, and deploying validated items. Output: working software.

Discovery stays 1–2 sprints ahead of delivery. This ensures the team is always building things that have been validated, while continuously exploring what comes next.

Not a waterfall: discovery and delivery overlap. Engineers participate in discovery; PMs participate in delivery. The distinction is about focus, not handoff.

Jobs to Be Done (JTBD)

Framework by Clayton Christensen. Customers don’t buy products — they “hire” them to do a job.

The milkshake example: McDonald’s wanted to sell more milkshakes. Demographics didn’t help. When they studied the job, they found morning commuters “hired” milkshakes to make a long drive less boring and keep them full until lunch. The competition wasn’t other milkshakes — it was bananas, bagels, and boredom.

Three types of jobs:

  • Functional — the practical task (get fed during commute)
  • Social — how it makes you look to others (professional, modern)
  • Emotional — how it makes you feel (satisfied, confident)

Application to product work:

  • Interview around the job: “When did you last [try to accomplish X]? Walk me through what happened.”
  • Identify struggling moments: when do users switch products or use workarounds?
  • Design for the job, not the demographic

Story Mapping

Jeff Patton’s technique for visualising the user’s journey and planning releases.

Structure:

  1. Activities (top row) — big things the user does (e.g. “Onboard”, “Create Invoice”, “Send Invoice”)
  2. Tasks (rows below) — steps within each activity, ordered by priority from top to bottom
  3. Release slices — horizontal lines cutting across the map, defining what goes in each release

Benefits:

  • Shows the whole user experience, not just a flat backlog
  • Makes it obvious when a release is missing a critical step
  • Facilitates conversation about “what’s the thinnest slice that delivers value?”

Impact Mapping

Gojko Adzic’s strategic planning technique. A mind map with four levels:

Goal → Actors → Impacts → Deliverables

  • Goal: the measurable business objective (e.g. “increase trial-to-paid conversion by 20%”)
  • Actors: who can help or hinder the goal (users, admins, partners)
  • Impacts: what behaviour changes we need from each actor
  • Deliverables: what we can build to cause those behaviour changes

Why it works: it connects features to business outcomes through a chain of reasoning. If you can’t trace a feature back to a goal through actors and impacts, question whether it should exist.

Anti-Patterns

Building what’s shouted loudest — the most vocal customer or stakeholder gets their feature. This optimises for noise, not value.

Big-bang requirements — spending months on requirements before building anything. By the time you ship, the market has moved.

No validation — going straight from idea to development. “We know what customers want” is the most expensive assumption in product development.

Discovery as a phase — treating discovery as something that happens before development rather than alongside it. Discovery never stops.

Ignoring feasibility — discovery that doesn’t include engineers wastes time on ideas that are technically impractical or wildly expensive.

Graph View

Backlinks