Discovery Overview¶

Discovery is the continuous work of understanding problems worth solving, validating solutions before committing engineering effort, and ensuring we're building the right thing — not just building the thing right.

This is the discovery track. It runs in parallel with the delivery track. Discovery is not sprint-bound. It has its own rhythm, its own participants, and its own artifacts. The two tracks converge at Thursday backlog grooming, where validated opportunities become dev-ready stories.

For the detailed how-to, see the Discovery Playbook.

Philosophy¶

We are an empowered product team. The PM discovers and validates problems worth solving. Design explores solutions worth building. Engineering advises on feasibility and cost. No one hands finished specs over the wall. The team collaborates to find solutions that are:

Quality	Question	Owner
Valuable	Will users choose to use this?	PM
Usable	Can users figure out how to use this?	Design
Feasible	Can we build this with our time, skills, and technology?	Engineering
Viable	Does this work for the business?	PM

All four qualities are addressed during discovery — not after the sprint review.

Principles¶

1. Fall in love with the problem, not the solution¶

The PM's job is to deeply understand the problem space — who has this problem, how painful it is, what they're doing today, and what a better outcome looks like. Solutions come second. If you can't articulate the problem clearly, you're not ready to explore solutions.

2. Outcomes over output¶

Success is not "we shipped the feature." Success is "students are discovering pathways they wouldn't have found on their own" or "advisors can identify at-risk students before they disengage." Measure whether you moved the needle, not whether you completed the ticket.

3. Most ideas won't work¶

At least half of product ideas will not deliver the expected value. The purpose of discovery is to find this out before committing engineering time. Cheap experiments beat expensive builds.

4. Prototype to learn, not to ship¶

Prototypes are disposable. Their purpose is to test assumptions quickly and cheaply. A prototype that proves an idea won't work is a success — it saved the team from building the wrong thing.

5. Engineers and designers are partners, not resources¶

Engineers participate in discovery — especially for feasibility assessment, technical constraints, and identifying opportunities the PM might not see. Designers participate in delivery — they're available during the sprint to answer questions, refine details, and respond to implementation realities.

How the Tracks Connect¶

Discovery                                    Delivery

Validated opportunity --> Thursday Grooming --> Sprint Backlog
                               ^
                          Dev-ready stories
                          with acceptance criteria,
                          designs, and validation evidence

Thursday backlog grooming is the primary handoff point. The PM brings stories that have gone through discovery — problem validated, solution explored, prototype tested (where applicable), and acceptance criteria written.

Four Convergence Points Per Sprint¶

Day	Convergence	What Happens
Day 5 (Tuesday, Week 2)	Feasibility check-in	Engineering informs what's buildable. PM/design adjusts solution direction based on technical constraints.
Day 7 (Thursday, Week 2)	Backlog grooming	Validated stories enter the delivery pipeline. Devs provide t-shirt sizing. PM gets signal on capacity.
Day 9 (Monday, close)	Acceptance verification	PM confirms completed stories meet discovery intent. Validates that what was built matches what was validated.
Day 10 (Tuesday, ceremonies)	Sprint review + planning	Stakeholder feedback flows back to discovery. Team aligns on next sprint from the refined backlog.

What Should Happen at Grooming¶

Good grooming looks like this

PM: "We've been hearing from students that [problem]. We tested [prototype] with 5 users and [results]. Here's the story with acceptance criteria. What do you think about the approach, and how would you estimate it?"
Dev: "That makes sense. Have you considered [alternative]? It would be simpler to build and might solve the same problem."
Designer: "The prototype tested well for [scenario] but users struggled with [edge case]. I've updated the design to address that."

These are anti-patterns

PM brings an idea that hasn't been validated: "I think we should build X." Based on what evidence?
PM brings a fully specified solution with no room for engineering input: "Build exactly this."
A stakeholder request goes directly into the sprint backlog without discovery: "Chris said we need this by next week."

What Good Looks Like¶

Discovery is working well when:

The team can articulate why they're building what they're building — and the answer isn't "because a stakeholder asked for it"
Most stories entering the sprint have been through some form of validation
Surprises at sprint review are rare — stakeholders have seen prototypes and given feedback before engineering starts
The PM is talking to users every week, not just before planning
Engineers feel informed about context and have space to suggest alternatives
The backlog has a healthy pipeline of validated opportunities, not a graveyard of unvalidated feature requests

Discovery needs attention when:

Stories enter the sprint with vague acceptance criteria or no designs
The team frequently builds things that don't get used or don't solve the problem
Stakeholder requests bypass discovery and go directly into the sprint
The PM spends most of their time in Jira and meetings, not with users
Usability issues are discovered after launch, not during prototyping
Engineers are surprised by complexity at grooming because feasibility wasn't checked