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.
Most of your effort as a PM belongs here. What gets decided in Define 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. 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 — PM's product thinking, PD's design thinking, PE's engineering thinking — 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.
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.
The Definition Doc
What's expected: A complete, precise description of what is being built, written well enough that it can be handed directly to AI to implement.
What good looks like: Someone reads the doc and can implement the feature with minimal clarifying questions. Edge cases are covered. The data model implications are described. API contracts are defined. Out-of-scope is explicit. There is no ambiguity about what "done" means.
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 in the doc produce bugs.
How to get there:
Start with the story — one sentence on what you're building and for whom. Then build out:
- 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
- Data model changes or implications
- API contracts: endpoints, payloads, expected responses
- Design decisions and why
- What is explicitly out of scope and why
Review it together — PM and engineer — and refine until nothing is ambiguous. If the engineer says "I'm not sure how to handle X," that's a gap. Fill it 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.
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. If there's significant disagreement, it 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.
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. The plan is updated throughout Build and is 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 release notes before you build. If you can't describe what this does for whom and why it matters in plain language, the story isn't clear enough. If the notes feel thin, the value isn't compelling enough. Write the draft, leave it to be updated during Build.
The Output
Everything from Define lives in the Roadmap:
- The definition doc: complete, precise, prompt-ready
- The story: what we're building and for whom
- The size: sand, pebble, or rock
- The release plan with milestones
- The release notes draft
Nothing moves to Build until these exist.
Next: Build