Why a product design phase comes before the build budget

A product design phase is four to six weeks of structured work sitting between an approved idea and a committed build budget. It produces a validated prototype, a prioritised feature breakdown with ranged estimates, a technical architecture with integration risk resolved, and a release plan with cost scenarios attached. The output is not a set of design artifacts. It is a narrower cone of uncertainty, and a scope that can be cut without breaking. Teams that skip the phase rarely save the money. They move it into the build, where it gets spent on rework nobody planned for.

A build budget usually gets approved at the moment the team knows least about what it is buying. The number comes from a pitch deck, a board conversation, or a comparison against what the last product cost. It is defensible as an intention. It is almost never defensible as an estimate.

What follows tends to be familiar. Development starts, and somewhere around month three the questions that were postponed all arrive together: whether the data model holds up for the second customer, whether the integration everyone assumed was documented actually is, which items on the original feature list were requirements and which were preferences that nobody challenged. Scope then gets renegotiated under delivery pressure, which is the worst available condition for making those calls. The team is not choosing between options at that point. It is choosing between damage.

We spend most of our time in the stretch between zero and one, which across fifteen years has meant more than 220 products. The four to six weeks this article is about exist for one reason: to de-risk the product investment before it is committed. A budget usually gets set before anyone has done the work that would reveal what the product costs, which means the number and the product get described at different times by different people, and the gap between the two stays invisible until the build is already moving.

IT projects also do not fail the way other projects fail. A study of 11,011 projects across 23 project types, published in the Project Management Journal by Bent Flyvbjerg and colleagues, found that IT was the only category in the set with a Pareto tail parameter below one, at 0.92. In plain terms, the distribution of IT cost overruns has no finite mean, which means conventional forecasting does not work on it. The authors put it more bluntly than that: at the moment of the investment decision, the cost of an IT project is more unpredictable than for any other project type they studied, including the disposal and storage of nuclear waste. The risk is not that every build overruns. It is that the ones which go wrong go wrong without a ceiling.

The reflex is to treat a design phase as a delay. Four to six weeks before development means four to six weeks of burn with nothing shippable at the end, and for a company with runway measured in months that reads as an expense with no output. The argument here runs the other way. A design phase does not add time to a project, it relocates the least reversible decisions to the point where they are cheapest to make, and it converts a number somebody hoped for into a number somebody can defend.

What a product design phase actually is

A product design phase runs four to six weeks and sits between the decision to build and the first line of production code. It is not open-ended research and it is not a one-week design sprint. The work is deliberately bounded: explore the problem space, define the solution, validate it with the people who will use the product and the people funding it, then hand over a scope development can start on without renegotiating it.

Three people own it together. A product manager owns scope, priorities and alignment. A UX designer owns the experience, the information architecture and the visual direction. A software development lead owns architecture, feasibility and the estimates. The detail that matters is that they work as one unit rather than three streams that converge at the end. Engineering in the room from week one is what separates an estimate grounded in a technical approach from an estimate grounded in optimism. By the time you reach development, we have already done the hard thinking together.

The common arrangement is the opposite: design runs ahead, engineering reviews at the end, and the estimate arrives after the client has already approved a direction. A number produced at that point is not really an estimate. It is a negotiation with a foregone conclusion.

The phases overlap rather than run in sequence. Discovery immerses the team in the problem, the users, the business context and the technical landscape, and logs what is known against what still needs validating. Shaping defines the solution, with information architecture, flows, designs, technical architecture and a first feature breakdown taking shape in parallel. Validation and refinement stress-tests all of it: prototypes go in front of stakeholders and users, estimates firm up, assumptions either resolve or get escalated as known unknowns. Wrap-up consolidates everything into a prioritised, estimated scope and ends with the trio briefing the development team in person, because documents alone do not transfer context.

How long a product design phase takes and what it costs

A product design phase typically runs four to six weeks, and typically is doing real work in that sentence. Products with a single primary user journey and no regulatory surface land at the short end. Products with several user types, an existing system to integrate with, or a compliance requirement that shapes the architecture land at the long end, and occasionally past it. Anyone quoting a fixed duration before seeing the problem is quoting a preference rather than an estimate, which is an odd way to begin a piece of work whose purpose is producing honest estimates.

Cost follows the same logic. The way we think about it is proportional: a design phase usually costs somewhere in the region of a tenth of the build it precedes. That framing is more useful than a price, because it puts the decision in the right terms. The question is not whether four to six weeks of design is expensive in isolation. It is whether a tenth of the build budget is a reasonable price for knowing what the other nine tenths are buying.

What a product design phase delivers

A design phase is worth what its outputs are worth. Five of them do the work of making a budget decision defensible.

A prototype people can click through

A design phase prototype is an interactive walkthrough of the product's primary user journeys, built and tested before any production code exists. At minimum the phase delivers a clickable Figma prototype covering those journeys. Stakeholders, users and developers walk through the flows before production code exists, and that changes the character of the feedback. Reactions to a description are opinions. Reactions to something a person has just used are information.

Where the design system and tooling allow, we go further and generate a functional front-end prototype using AI-assisted design-to-code tools. When the thing in front of a stakeholder actually responds, usability problems, missing requirements and edge cases surface earlier than any other method we have tried.

Part of the point is to make objections cheap. Someone looks at a flow and says that is not how the work actually happens, and in week three that costs a conversation. The same objection in month five costs a sprint, and somebody has to explain the change to whoever signed the budget.

A feature breakdown you can price

A feature breakdown is a structured list of the product's features and capabilities, written at the level of detail where estimating, prioritising and planning each item becomes possible. Granularity is the whole point of it. Each item is written so both the client and the development team understand it, with technical context attached by the software development lead: the backend and frontend split, the integrations involved, the dependencies, the complexity flags. Estimates come as ranges with their assumptions stated. Priorities are marked. Known unknowns and research items are listed separately rather than buried inside line items that look confident.

The practical test is whether the breakdown survives contact with development. Ours feeds directly into Jira when the build starts, which means the scope conversation does not restart in sprint one.

A technical architecture that has been tested rather than assumed

The technical architecture produced in a design phase is a documented, tested account of how the product will be built: the stack, the system design, the integrations and the constraints it has to hold up under. The software development lead defines the stack and the reasoning behind it, the system architecture and infrastructure, the third-party integrations, the continuous delivery approach, and the non-functional requirements. That last item is where most of the trouble hides. Performance, security, scalability and reliability are constraints that shape an architecture, and when they arrive after the architecture is settled they force rework rather than adjustment.

Integrations get validated through targeted technical spikes inside the phase, not confirmed by reading documentation. By the end, each integration approach is either proven or explicitly flagged as an open risk. That distinction is the difference between a plan and a hope.

Alex Cristea, the software delivery lead on Audora, described the infrastructure there as designed around the project's quality attributes, scalability, reliability and security, after analysing a mix of on-premise and cloud resources and proposing what the team judged "the best fit given the current project context". That is the level at which the decision gets made: a stated approach, a stated reason, and a record of what was considered and set aside.

A release plan tied to a story map

A release plan sequences the scope into releases and states why that order, and it is anchored to a user story map so the trade-offs stay visible. The story map walks through the user journeys end to end, with scope items placed along each journey and grouped into releases by priority. It is built together with the client and it stays live in FigJam for the length of the engagement, which matters because it makes trade-offs tangible. Move a story into release two and the map shows exactly what release one becomes.

The release plan then sequences the work with a stated rationale for the order. Release one is scoped to deliver demonstrable value while validating the most important assumption, and later releases build on it without rework. Cost and timeline scenarios sit alongside it, so priority calls get made by the people who own the budget rather than inferred by the people writing the code.

Ranged estimates and the team shape to deliver them

A ranged estimate expresses development effort as three figures rather than one, optimistic, most likely and pessimistic, each with the assumptions behind it written down. The finalised feature breakdown is estimated that way. We use PERT to produce a weighted forecast instead of presenting a single number with false precision. Alongside the estimates comes a recommended team capacity, the roles, seniority and allocation sized to the release plan rather than lifted from a template.

That combination is what makes the output fundable. A range with stated assumptions can be interrogated by a board or an investor. A single number cannot.

None of this removes uncertainty. Estimates are approximations by definition and software delivery stays unpredictable, which is worth saying plainly rather than selling around. What the phase does is narrow the range. The cone of uncertainty, described by Steve McConnell and used at Construx, holds that an estimate made at initial concept can be out by a factor of four on the high side and a quarter on the low side, a total spread of sixteen to one, and that the range contracts only as real information accumulates. A design phase is a deliberate way of buying that information before the commitment rather than after it.

It is also the easiest line to cut from a plan, and the objection is a fair one: this is the only stage with nothing shippable at the end of it. The difficulty is that the stage with nothing to show is the one that determines whether everything after it can be planned at all.

How a product design phase set the scope for Audora

Audora came to us in November 2022 with a platform concept for automating cybersecurity audit workflows, the kind of problem where the compliance standards are dense, the work is document-heavy, and the users are auditors rather than people who enjoy learning software.

The design work came first and moved fast. Ideation sessions established what the platform was for and which specific pains it had to remove. From there the team defined proto-personas, mapped the user journey end to end, built low-fidelity wireframes and refined them into Figma prototypes, and set a visual style guide covering typography, colour and interface components. High-fidelity prototypes covered the core use cases. None of it was decoration. Each artifact narrowed the same question: what does the first release actually have to contain.

Running alongside that, a needs and benefits analysis produced the estimate. Not a number handed to the design team as a constraint, but a number that came out of the design work once the scope had been drawn and argued over. The first release then shipped on time and within the estimated budget, and went to Audora's first group of clients.

An estimate that holds is rarely luck. It is what happens when the thing being estimated has already been drawn, prototyped and cut down before anyone commits to building it.

What teams underestimate about product design

The decisions you defer are the expensive ones

Not all postponed decisions cost the same. Visual direction can be revisited in month four at manageable cost. The data model cannot. Neither can the tenancy assumption, the integration boundaries, or the question of whether the first customer's requirements were treated as configuration or written into the code. Those decisions sit underneath everything built on top of them, and revisiting them is not a change, it is a rebuild of the part that was already working.

A design phase does not make those decisions easier. It makes them earlier, at the point where the cost of being wrong is a conversation rather than a migration.

Building fast has made choosing slowly more expensive

The obvious conclusion to draw from AI-accelerated delivery is that design phases matter less now. If a working front end can be generated in an afternoon, why spend four weeks deciding what to generate.

The conclusion runs the other way. When production was the bottleneck, a bad scope decision was partly absorbed by how long everything took, because the slowness itself created checkpoints where someone noticed. Now the wrong product can be built quickly, convincingly and at scale, and it will look finished long before anyone discovers it solves the wrong problem. Speed of production has raised the share of total project risk sitting in one question: is this the right thing to build. That question has never been answerable by a coding tool. It is answered by the work of narrowing scope against real users, real constraints and a real budget, which is precisely the work of deciding what not to build.

The data points the same way. The 2025 DORA report, which surveyed nearly 5,000 technology professionals, found that AI adoption now correlates positively with software delivery throughput, reversing the previous year's finding. It also found that AI adoption continues to correlate negatively with delivery stability. The report's own framing of its central result is that AI functions as an amplifier, "magnifying an organization's existing strengths and weaknesses," and that the returns come from the surrounding system rather than the tools. Ninety percent of respondents reported using AI at work. Thirty percent reported little or no trust in the code it generates.

A prototype produced in two days is a fast artifact. A validated scope is a different thing, and the second one is what a budget rests on.

Handoff is a conversation, not a folder

A design phase can produce every artifact on the list and still fail at the last step. "Ready for development" needs an explicit definition: the first release scope estimated, designs at sufficient fidelity, the technical approach documented, integration requirements clear, known unknowns catalogued.

Even then, the documents are not the handover. The trio briefs the development team in person and walks through the story map, the design decisions, the architecture and the risks. Context does not survive being written down and emailed. It survives being explained and questioned.

The ambition is deliberately limited here. We are not trying to hand over a complete design system, because that grows over time. What we aim for is enough structure that your developers can build new screens and states without needing the designer back for every variation.

Four common mistakes in a product design phase

1. Treating product design as the part that produces screens

Design phases get scoped as visual work with some research attached, and they are evaluated on how the mockups look. The screens matter, but they are the visible output rather than the valuable one. A phase that produces beautiful designs and no estimable scope has moved the budget decision precisely nowhere.

2. Running product design without engineering in the room

When design finishes first and engineering reviews afterwards, two things happen. Feasibility problems surface late, and the estimate becomes a reaction to finished designs rather than an input that shaped them. The result is a scope priced under pressure to agree with work already approved by the client.

3. Estimating before the architecture is validated

An estimate built on an unvalidated integration is a guess wearing a number. The integrations that look simplest in documentation are frequently the ones that consume a sprint, and the only way to know is to test them inside the phase. Estimates that rest on validated architecture can be defended. Estimates that rest on assumed architecture get revised, and revisions to a build budget are rarely downward.

4. Buying a design phase that does not end in a fundable decision

This is the mistake underneath the other three. Plenty of discovery and design engagements conclude with a research summary, a journey map and a set of recommendations. Useful work, and it leaves the original problem untouched: the reader still cannot walk into a board meeting and say what the build costs, what the first release contains, and what happens if the second assumption turns out to be wrong. Worth asking any prospective partner directly what their phase ends with, and whether the estimate comes with its assumptions attached.

Where to start before committing a build budget

Most people reach the end of an article like this with the same question, which is what to do on Monday. Four things, in order.

Write down the number you are being asked to approve and what it assumes

Take the build budget currently in play and list what it implicitly assumes about scope, integrations, team size and timeline. The exercise takes an hour. It usually reveals that the number was anchored to something unrelated, a previous project, a funding round, a competitor's raise, rather than to the product being built.

Name the two assumptions that would change the scope if they were wrong

Every product has them. Whoever the users actually are, whichever integration is load-bearing, whatever the regulatory requirement turns out to demand. Two is enough. If a design phase cannot resolve or materially narrow those two, it is scoped wrong.

Ask who owns the estimate and what it rests on

This applies internally and to any partner. An estimate owned by whoever sold the work behaves differently from an estimate owned by the person who will architect the system. Ask what technical validation sits behind it, whether the assumptions are written down, and whether it is a range or a single number.

Decide what release one has to prove, not what it has to contain

Feature lists expand under discussion and shrink under deadline. A release defined by what it proves holds its shape, because scope items can then be tested against it: does this help demonstrate the thing we need to demonstrate. This is also the fastest route to a realistic view of what a first build costs.

None of these four require hiring anyone, us included. They do tend to make the shape of the design phase obvious, and occasionally they reveal that the budget on the table was approved for a product nobody has fully described yet.

Thinking slow is a hard thing to sell

The Flyvbjerg study does not stop at measuring the risk. It proposes what drives it, and both mechanisms are grounded in the data rather than borrowed from the existing literature. The first is bespokeness, meaning every project treated as a unique endeavour instead of assembled from parts that already exist and already work. The second the authors call think-fast decision-making. IT projects in the study run at a mean duration of 3.2 years against 6.9 years for every other project type, and rather than making them safer, that compression appears to mean they get, in the researchers' words, "rushed through planning and delivery without proper preparation." The antidotes they propose are modularity and thinking slow.

Thinking slow is an awkward thing to sell. It has no visible output. It arrives before the part everyone is excited about. Every instinct inside a funded company with a roadmap, a hiring plan and a board meeting in six weeks argues for starting the build and sorting the rest out in motion. The four to six weeks are not a slower start, though. They are the only stretch of the project where changing your mind is free.

Our own position on this is the one we put in front of clients: estimates are not delivery guarantees, and while we work to hit the dates we set, software development is unpredictable by nature. Some assumptions stay open at the end of a design phase, and the honest handling is to record them as known unknowns and price the risk rather than dress them up as settled. What the phase reliably does is narrower and more useful than a guarantee: it turns the budget conversation into a conversation about a described product rather than an imagined one, early enough that the answer can still change what happens next.

The money gets committed either way. A design phase does not decide whether you spend it. It decides whether you know what you are buying when you do.

Common questions about the product design phase

How long does a product design phase take?

Typically four to six weeks. Products with one primary user journey and no regulatory surface sit at the short end. Several user types, an existing system to integrate with, or a compliance requirement that shapes the architecture will push it to the long end or slightly past it. A fixed duration quoted before anyone has seen the problem is a preference rather than an estimate.

What does a product design phase deliver?

Five things that a budget decision depends on: an interactive prototype covering the primary user journeys, a feature breakdown at estimable granularity with priorities and assumptions attached, a technical architecture with integrations validated rather than assumed, a release plan tied to a user story map, and ranged development estimates with a recommended team shape. It ends with the team that did the work briefing the team that will build it.

How is a design phase different from a discovery workshop?

A discovery workshop is usually one to two days and produces alignment: shared understanding of the problem, the users, the rough scope and the priorities. A product design phase is four to six weeks and produces a fundable scope: designs, validated architecture, sequenced releases and estimates you can put in front of a board. The workshop is often how the design phase gets scoped.

Do we still need a design phase if we are using AI development tools?

More than before, in our view. AI tools have compressed the cost of producing software, which means a scope mistake now gets built quickly and convincingly rather than slowly and visibly. The 2025 DORA report found AI adoption correlating positively with delivery throughput and negatively with delivery stability, and described AI's role as amplifying an organisation's existing strengths and weaknesses. Speed helps a team that knows what it is building. It does not supply that knowledge.