It is tempting to measure a project by how soon the first screen appears. But the most expensive mistakes are made before that — when a team starts building something nobody fully agreed on. The first stage exists to make those mistakes on paper, where they are cheap.
§ 01Four stages, two before the build
- 01DiscoverUnderstand the business, the problem and what success looks like.
- 02DefineAgree the features, architecture, technology and scope before code.
- 03DesignShape the flows and interface so the product is clear before it is built.
- 04DevelopBuild with maintainable technology, reviewing and demoing as we go.
This note is about the first two. They are short compared with the build, and they are where a project quietly succeeds or fails.
§ 02Discover: the questions you will be asked
Discovery is mostly conversation. Expect questions that feel more like business than technology — because that is where the requirements actually come from.
- Who is this for, and what are they trying to get done?
- What happens today without this product — and what does that cost you?
- What does success look like six months after launch?
- What are the fixed constraints: budget, deadline, existing systems, regulations?
- Who decides, and who needs to be kept informed?
§ 03Define: turning answers into a plan
Definition turns those conversations into decisions. The goal is a shared, written picture of what will be built first — and, just as important, what will not.
- A feature list split into must-have for launch and later.
- A technical outline: how the parts fit together and which technology fits the job.
- Scope and milestones you can hold the team to.
- The open questions that still need an answer, each with an owner.
A good plan says no to things on purpose, instead of by accident later.
§ 04Three traps worth avoiding
- Treating every feature as a must-have. If everything is essential, nothing can be scheduled — and the first release slips.
- Skipping the people who do the work. A manager describes how a process should run; the person doing it every day knows how it actually runs.
- Agreeing on words instead of examples. “Simple reporting” means something different to everyone until someone sketches the actual report.
Each of these is cheap to fix in a conversation and expensive to fix in code.
§ 05How to prepare as a client
- Gather the documents, spreadsheets and tools you use today — especially the ugly ones.
- Name one person who can make decisions and answer questions quickly.
- Write down what must be true on launch day, and what can wait.
- Be open about budget and deadlines; they shape the plan more than any single feature.
§ 06What you should walk away with
By the end of definition you should be able to explain the project to a colleague in two minutes, point at the first release on a list, and know what each milestone delivers. If you cannot, the plan is not finished yet — and it is far cheaper to keep talking than to start building.
