Define

You have a problem statement. Now you’re going to solve it, as a team.

Define is where the solution gets built collaboratively. PM and PD lead, but PE must be in the room from the start, not as a resource estimate at the end. Engineers see constraints and possibilities that PMs and designers miss. The best solutions come from the full triangle in discussion, not from one role handing off to the next.

This is where the team’s brainpower is concentrated: PM, PD, and PE together. What gets decided here determines everything that follows. A weak Define produces a weak Build regardless of how hard everyone works. An impeccable Define makes Build fast, focused, and almost automatic.

Running the Define Session

What’s expected: A structured call with PM, PD, and PE, plus any other stakeholders whose input shapes the solution. Marketing if there’s a go-to-market angle. Operations if there’s a workflow implication. Client-side if the feature directly affects them. PM decides who needs to be in the room; the default is not just the core trio. It runs in two parts: 45 minutes of silent writing, then open discussion. The engineer gives the green light before the session ends. Nothing moves to Build without it.

What good looks like: Everyone enters having read the problem statement. The 45 minutes produce a shared document that covers the solution from every angle (product, design, engineering, and any relevant business or operational perspective), written independently and in parallel before anyone anchors on a single direction. The discussion that follows is high-quality because everyone has already thought it through. The engineer ends the session by confirming the definition is implementable, the structure is sound, and there’s nothing missing that would block Build.

How to get there:

Part 1 — 45 minutes, everyone types, no one talks. Each person writes their thinking into a shared doc simultaneously. PM writes the proposed solution, user flows, edge cases, and open questions. PD writes design considerations, UX decisions, and constraints. PE writes implementation approach, risks, technical decisions, and anything that’s unclear or underspecified. No discussion during this phase. The goal is independent thinking before group influence.

Part 2 — Discussion. Go through what everyone wrote. Surface disagreements, fill gaps, make decisions. If someone reframes the problem, don’t rush past it. A slightly different problem often has a much simpler solution. Be innovative. If the first solution looks like a month, challenge it: what would make it a week? What assumption makes it feel big?

Engineer green light. Before the session ends, the engineer explicitly signs off: the definition is complete, implementable, and has no gaps that would cause problems in Build. If the engineer can’t give the green light, the session continues or a follow-up is scheduled. PM does not move the item to Build without it.

Leadership probes the solution. After the engineer green light, leadership reviews the definition doc, not as a sign-off, but as a probe. In Discover, leadership challenged the problem. Here, leadership challenges the solution: does it actually solve the sharpened problem? Is the scope right? What assumption in the solution could be wrong? What’s been missed? The team should expect questions, not just approval. Nothing moves to Build until this is done.

The definition doc produced in this session is what gets fed to AI for implementation. Its quality is the ceiling on how well Build goes.

Tools:

Second-order thinking — before committing to a solution, ask what it leads to. “This solves the problem” is first order. “And then what happens?” is second order. Catches unintended consequences early.
Inversion — ask what would make this solution fail. What could go wrong? What assumption would need to be false? Surfaces blind spots before build.
Decision matrix — if there are multiple strong solution candidates, score them against criteria that matter (complexity, user impact, engineering effort, maintainability). Useful when the team is genuinely split.

Engineering Judgment in Define

The engineer’s job in Define is not just to say “here’s how we’ll build it.” It’s to find the most elegant solution — the one that solves the problem with the least code, the least complexity, and the fewest things that can go wrong.

Find the elegant solution. The first idea is rarely the best one. Before committing to an approach, ask: is there a simpler version of this that solves 90% of the problem? Could a configuration change replace a feature? Could a third-party service replace three weeks of custom work? The best solution often involves building less than you expected.

Build vs buy vs open source. Before writing any custom code, evaluate all three options. The default should not be “we’ll build it” — building means owning it indefinitely. The question is not “can we build this?” but “should we?”

Buy: a paid service or API that does this already. Faster to ship, someone else maintains it, costs money. Often the right call for non-core functionality.
Open source: an existing library or tool that solves it. Free, but you own the integration and upgrades. Prefer well-maintained libraries with wide adoption over niche ones.
Build: custom code that you write and own. Only justified when the problem is core to what we do, no existing solution fits, or the constraints of external tools would limit us in ways that matter.

If something can be bought or open-sourced, the conversation about building it should be short.

Choose boring technology. Novelty is a cost. A new framework, a new database, a new architectural pattern all carry the same hidden tax: unknown failure modes, less community knowledge, steeper learning curves, and more debugging in the future. Proven tools have known failure modes, large communities, and years of battle-testing. When a boring technology solves the problem, use it. When something new is genuinely needed, make that case explicitly and get alignment before committing.

Code is liability. Every line of code written is maintenance burden, future surface area for bugs, and weight the team carries forward. Less code is better. This means:

Use proven libraries rather than building the same thing from scratch. Validation with Zod rather than hand-rolled type-checking. Established ORMs over raw query builders. Well-maintained UI component libraries over custom implementations of common patterns.
Lean on the framework. Most frameworks solve common problems well. Fight the framework only when you have a clear reason.
If a library already exists and is well-maintained, the burden of proof is on building your own.

Define performance expectations. Before Build starts, agree on what “fast enough” looks like for this item. A response time target for an API, a page load budget, a query execution ceiling. Performance requirements set in Define get built in from the start. Performance problems discovered in production get patched in under pressure. The engineer should flag which parts of the solution are likely to be performance-sensitive and propose how they’ll be monitored after launch.

All of these decisions — build/buy/open source, technology choices, performance targets — belong in the definition doc under the engineer’s section. They are not afterthoughts to sort out in Build.

The Definition Doc

What’s expected: A complete, precise description of what is being built and why, written well enough that it can be handed directly to AI to implement.

PM owns the what and the why. Engineer owns the how. PM must understand the solution deeply: every user flow, every edge case, every decision about what’s in scope and what’s not, and the reasoning behind each of them. What the engineer builds, and why it needs to work that way. PM does not need to own the technical implementation approach, the data model, the API design, the architecture. That belongs to the engineer. But PM should understand the solution well enough to explain it to anyone, and to catch it when the implementation drifts from the intent.

What good looks like: The doc is readable in two layers. The PM layer (what are we building, for whom, what happens in each user flow, what are the edge cases, what’s out of scope) is complete and unambiguous. The engineer layer (data model implications, API contracts, technical decisions) is owned and written by the engineer. Both layers exist in the same doc. Together they leave nothing open to interpretation.

The definition doc is not a spec in the traditional sense. It is a prompt brief. Its quality directly determines the quality of what gets built. Ambiguous language in the doc produces ambiguous code. Missing edge cases produce bugs.

How to get there:

PM writes:

The story: one sentence on what we’re building and for whom
The user flow from entry to completion, step by step
Every edge case: what happens when data is missing, when the user takes an unexpected path, when the operation fails
What is explicitly out of scope and why
Design decisions and the reasoning behind them

Engineer writes:

Build vs buy vs open source decision, with reasoning
Technology choices and why (boring over novel unless there’s a clear case)
Key libraries and tools being used, and what they’re replacing
Data model changes or implications
API contracts: endpoints, payloads, expected responses
Technical approach and any constraints that shape the solution
Performance expectations: what fast enough looks like, and how it will be monitored

Review it together and refine until nothing is ambiguous. If PM can’t explain a user flow clearly, that’s a gap. If the engineer isn’t sure how to handle a case PM described, that’s a gap. Fill both before moving on.

Tools:

Issue trees — useful for mapping out all the sub-problems the solution needs to address. Ensures completeness.
Abstraction laddering — check that each part of the solution is solving the right level of the problem. Not too narrow, not too broad.

Success Metrics

What’s expected: Before anything moves to Build, the team has agreed on how they’ll know it worked. Not after Launch. Now.

What good looks like: One primary metric with a specific target and a timeframe. The metric is something you can actually measure, and the instrumentation to measure it exists or will be built as part of this work. Everyone on the team can answer “how will we know this succeeded?” without looking at a doc.

Bad: “We’ll see if users engage more.”

Good: “Cart save rate above 40% within 2 weeks of launch, measured by sessions where a cart is restored vs. sessions where a user reaches payment and abandons.”

How to get there:

Go back to the problem statement. What was the cost of inaction? Success is the inverse of that. If the problem was “60% of shoppers abandon at payment because their cart empties,” success is a measurable reduction in that abandonment rate.

Define three things:

Primary metric — the one number that tells you if it worked
Target — a specific value with a timeframe (“40% within 2 weeks”)
How it’s measured — what event, what query, what dashboard

Secondary metrics (guardrails) are worth noting too: things that shouldn’t get worse as a result of this change.

Tools:

Second-order thinking — make sure the metric you’re optimising for doesn’t create a worse outcome somewhere else.

Scope Decisions

What’s expected: Every Define session produces an explicit list of what is not being built, alongside what is.

What good looks like: The out-of-scope list is as specific as the in-scope list. Not “we’re not doing the advanced stuff.” We are not handling multi-device sync in this release, because it requires a separate auth flow and adds two weeks. That’s a separate problem to solve later.

Scope decisions are not failures. They are how you ship. Every item added to scope is a tradeoff against every other item. Making that explicit keeps the team aligned and prevents “I thought we were including X” conversations during Build.

How to get there:

For everything that came up in the Define session but didn’t make it into the solution, write it down with a one-line reason. These become the out-of-scope section of the definition doc. They’re also the starting point for future discovery.

Ask: if a user needs this and we’re not building it, what will they do? If the answer is “they’ll be stuck” or “they’ll ask us for it immediately,” reconsider whether it’s actually out of scope.

Sizing

What’s expected: Every item on the roadmap has a size before it moves to Build.

What good looks like: The team agrees on the size without long debate. Significant disagreement means the solution isn’t defined well enough yet.

How to get there: Use the three categories:

Sand — less than one person sprint. No design required, no release plan. Just do it.
Pebble — one to two person sprints. Needs a story, a size, a release plan.
Rock — more than two person sprints. Needs leadership sign-off before it’s committed. If it looks like a month, stop: can open source solve part of it? Can we ship a smaller version that validates the approach first?

A person sprint is one engineer for one sprint. If you can’t agree on size, the definition isn’t tight enough. Go back.

This size is the initiative’s PS (person sprints) on the story map: the same sand, pebble, and rock you set at quarterly planning, now firmed up against a real solution rather than a rough signal.

Tools:

Impact-effort matrix — plot candidates by impact and effort before committing. High impact, low effort moves first. High effort, unclear impact goes back to Discover.

The Release Plan

What’s expected: Every pebble and rock has a release plan with concrete milestones before it goes on the roadmap.

What good looks like: Each milestone is specific enough that you’ll know when you’ve hit it. “Backend complete” is a milestone. “Good progress” is not. Update the plan throughout Build so it’s always accurate.

How to get there: Map the stages of development between Define and Launch. What gets built first? What’s the demo milestone? What constitutes done? Set dates that are honest, not optimistic.

Release Notes Draft

Write the announcement before you build. Every release uses this format:

Release: [Feature Name]

Before: [Old behavior — what the problem was]
After: [New behavior — what's different now]

[Screenshot or demo video — added at Launch]

If you can write both clearly, you understand what you’re building. If you can’t, the story isn’t clear enough yet.

This isn’t just a communications task. Writing Before/After is a forcing function for alignment: it makes the value of the feature concrete and surfaces gaps in the definition before a single line of code is written. If the Before/After doesn’t feel compelling, reconsider whether the problem is worth solving.

Deployment vs. release. These are different things. Deployment is code going to production. Release is when the feature is live and users can see or use it. The announcement goes out at release, not deployment.

What needs an announcement:

User-facing changes: anything the patient, doctor, nurse, or admin will see or interact with differently
Ops workflow changes
Payment or billing changes
New features

Pure backend refactors, infrastructure changes, and minor bug fixes that restore expected behavior don’t need announcements.

Leave the draft here and update it throughout Build. Screenshots and final copy come at Launch. The substance should be solid now.

The Output

Nothing moves to Build until these exist: the definition doc, the size, the release plan with milestones, and the release notes draft.

Together they fill in the initiative on the story map: the definition doc is its solution statement, alongside its release plan, release notes draft, PS, and DRI. Quarterly planning opened the initiative and Discover sharpened its problem; Define is where the rest of its fields get written.

Next: Build