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. Not as a resource estimate at the end. In the room, in the conversation, from the start. Engineers see constraints and possibilities that PMs and designers miss. The best solutions always come from the full triangle in the discussion, not from one role handing off to the next.
A call is better than a message. Written proposals have their place, but the Define discussion happens live. You want to pick everyone's brain in real time, build on each other's thinking, and land somewhere none of you would have reached alone. You are not looking for the first solution that works. You are looking for the most elegant one.
The Define Discussion
Start by reading the problem statement out loud. Make sure everyone agrees that's the problem. If someone reframes it, don't rush past that — sometimes reframing the problem is the whole work. A slightly different problem often has a much simpler solution.
Then open the floor. What would you build? What's the simplest thing that solves this? What are the constraints? What are we definitely not doing? What would a competitor do, and do we want to do the same?
The signal that Define is done: the team can describe the solution clearly, has an agreed size, and everyone believes it solves the problem from the statement.
Sizing
Before anything goes on the roadmap, size it. We use three categories:
Sand — less than one person sprint. Small tasks, bug fixes, minor improvements. No design required, no release plan needed, just do it.
Pebble — one to two person sprints. A meaningful feature with defined scope. Needs a story, a size, and a release plan.
Rock — more than two person sprints. Significant work. Needs leadership in the conversation before it gets committed. If it will take a month or more, stop and reconsider: is there an open source tool that solves this? Can the problem be reshaped into something smaller? Can we ship a smaller version that validates the approach first?
A person sprint is the effort of one engineer for one sprint. If you can't agree on size, that's a signal: the problem isn't defined well enough, or the solution isn't clear enough. Go back.
The point of sizing isn't precision. It's a forcing function for scope discipline. Small and fast ships first and learns first. Large and slow should be rare, justified, and approved.
Writing the Story
The story is what you're building and for whom. It should be short enough to say out loud in one sentence. "We're adding a reschedule flow for clinic coordinators who need to move a patient to a different slot without losing context." That's a story. "We're improving the scheduling module" is not.
A clear story does several things. It gives the engineer something to optimize for — not just requirements, but intent. It gives design a north star. It makes scope decisions easier: does this edge case serve the person in the story? If not, cut it.
The Release Plan
Every pebble and rock needs a release plan before it goes on the roadmap. The release plan has milestones: the stages of development between Define and Launch. Not the definition and not the release itself — the steps in between. What gets built first? What's the demo milestone? What constitutes done?
Milestones should be concrete enough that you'll know when you've hit them. "Backend complete" is a milestone. "Good progress" is not.
The release plan is a living document. It will be updated during Build as reality diverges from the plan. That's expected. The only unacceptable version is one that stops being updated — a plan that says one thing while the work says another.
Release Notes Draft
Write the release notes before you build. This sounds backwards and isn't.
Writing release notes forces clarity. You have to describe what this does, for whom, and why it matters — in plain language, to a customer. If you can't write the release notes, the story isn't clear enough. If the notes feel thin, the value isn't compelling enough. If they require two paragraphs of context before the feature makes sense, the scope is probably wrong.
The draft doesn't need to be polished. It needs to exist. You'll update it during Build and finalize at Launch.
The Output
Everything from Define lives in the Roadmap:
- 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