Written by
The Bit Laboratory
Filed under
Product Design
Rewrites are rarely caused by bad code. They are caused by a product whose shape was never agreed on, built quickly and faithfully by a team doing exactly what it was asked to do.
Ambiguity compounds
An unresolved question at the start of a project does not stay one question. It becomes a schema decision, then an interface pattern, then a permissions model, then six months of workarounds that everyone privately agrees are wrong. Resolving it early costs an afternoon. Resolving it late costs a quarter.
Definition is a deliverable
We treat the definition phase as real, funded work with real artifacts: the decision map, the domain model, the critical workflows drawn end to end, the non-negotiable constraints, and the measures that will tell us whether the thing worked. None of it is documentation for its own sake. Each artifact removes a class of future argument.
- /The three workflows that must feel effortless on day one
- /The data model that everything else has to respect
- /The integrations that are genuinely load bearing
- /The success measures the business will actually watch
Design and engineering in the same room
Separating design from engineering produces beautiful screens that cannot be built and robust systems nobody enjoys using. When both disciplines shape the definition together, the resulting product has fewer seams, because the experience and the architecture were negotiated as one system rather than handed across a wall.
Speed comes from clarity. Teams that skip definition are not moving faster, they are deferring the cost.
Test the riskiest assumption cheaply
Every project has one assumption that, if wrong, changes everything. Sometimes it is technical, an integration that may not expose the data everyone believes it does. Sometimes it is behavioural, a workflow change users may quietly refuse. Naming that assumption and testing it with a prototype, a spike, or five conversations is the highest return week of work available before a build starts.
Write down what version one will not do
A scope boundary that lives only in someone's head is not a boundary. Documented exclusions protect the timeline more effectively than any estimate, because they turn late additions into a visible decision rather than an assumed courtesy. They also make the roadmap honest: the excluded items are not gone, they are scheduled.
What good preparation looks like
You know a project is ready to build when a new engineer can describe the product in two minutes, when the riskiest assumption has been tested in some cheap way, and when the team can name what it is deliberately not doing in version one. That last one is the strongest predictor of a calm launch we have found.
Definition is not a delay before the real work. It is the part of the work that decides how much of everything after it has to be done twice.
