A product design phase is a four to six week engagement in which a product manager, a UX designer and a software development lead turn a product idea into a scope that can be estimated and built. Those three roles run the work, but several decisions that shape the outcome belong to the client and are made before it starts: who holds decision authority, how much time domain and technical experts can give, how much of the technical role survives price negotiation and what "complete" is taken to mean. This article sets out what each role does, what each needs from the client and how to check readiness before signing.
Most buyers evaluate a product design phase by looking at the vendor. They compare portfolios, check who will be on the team and weigh one proposal's four weeks against another's six. That is reasonable, and it misses the part of the outcome that is settled on the buyer's side before the vendor has started work.
Consider a common negotiation. A proposal arrives with three roles on it: a product manager (PM), a UX designer and a technical lead which we refer to as a software development lead (SDL). The total is higher than expected, and the technical role looks like the easiest line to trim, since nothing is being built yet. The SDL's time is reduced to a few days, the price comes down and everyone signs.
Four weeks later the phase delivers a prototype, a feature breakdown and an estimate. The prototype looks right. The estimate is where the saving shows up, because without someone researching integrations, running quick experiments on the uncertain parts and pressure-testing each flow while it was being designed, the numbers rest on assumptions nobody had time to check. Feasibility then gets discovered in the first development sprints, which is precisely what the phase was paid to prevent.
The playbook our PMs work from lists this among four failure modes to deal with before a product design phase begins. The other three are similar in kind. A decision-maker who was never part of the sales conversation arrives with different expectations. A proposal promises "full product design" and the client reads it literally. A four-week phase is sold against expectations of exhaustive coverage. Two of the four start with how agencies, ourselves included, sell the work, and all four are resolved or left open before the kick-off meeting.
None of this moves responsibility for the result away from the vendor. It does mean a buyer has more influence over a product design phase than the usual evaluation suggests, and most of that influence is exercised in the weeks before it begins.
A product design phase is the short, intensive engagement that runs before development and moves a product from an idea or a problem space to a scope that is validated, estimated and ready to build. By the end it should have produced a user story map, a feature breakdown estimated by a technical lead, a release plan, a prototype of the primary user journeys, design system foundations, technical architecture documentation and a recommended team shape for the build.
Why that is a different job from interface design is covered in product design in software development is not UI/UX design. This article is about the conditions the phase needs in order to do that job.
A product design phase is delivered by three people working as a single unit, not as three parallel streams that converge at the end. The overlap between them is deliberate. The PM should hold opinions about user flows, the UX designer should notice when a direction implies more complexity than the timeline allows and the SDL should raise technical constraints before anyone asks.
The product manager is the person accountable for how the phase runs and for what it decides to focus on. That covers the feature breakdown, the user story map, the release strategy, the weekly plan for the phase itself and the summary that budget holders will eventually read.
A large part of the job is facilitation under time pressure. Most products cannot be designed in full within four to six weeks, so the PM decides, with the client, which journeys get depth and which get deferred. When the role is thin, scope grows without anyone negotiating it, and the PM drifts into doing design or technical work instead of steering the whole.
What the PM needs from the client is short: fast decisions and an honest picture of who actually makes them.
The UX designer is responsible for the structure and feel of the product: information architecture, user flows, screens, visual direction and the prototype stakeholders react to. Design system foundations sit here too, because a prototype built on a real component system is closer to something a development team can use, a point explored further in what your design system must enforce.
The common failure is polish arriving too early. A designer working alone can produce beautiful first screens while the full flow is still undefined, or design in a direction the SDL has not yet checked. The UX designer needs access to real users where possible, not only to internal stakeholders, and feedback sessions framed around a specific question rather than a general impression.
The software development lead is the team's reality check. The SDL defines the technical architecture, recommends a stack, documents integration analysis, estimates the feature breakdown and recommends the team capacity for development.
The timing of that work is what makes it valuable. An SDL engaged from the first discovery session can investigate an uncertain integration while the flow that depends on it is still being drawn. With agentic coding tools, a timeboxed spike on a third-party API or a performance-sensitive feature can produce a working answer within hours, inside the same week the question came up. An SDL brought in at the end can only estimate what has already been decided, and the estimate inherits every assumption nobody tested.
The SDL needs the client's technical stakeholders, access to existing systems and a clear account of any technical decisions already taken.
The three roles resolve disagreements between themselves before anything reaches the client. When the ideal experience needs technical complexity the timeline cannot absorb, the client should receive a recommendation with its reasoning, or a small set of options with clear trade-offs, never an unresolved debate.
The client keeps four kinds of decision: business priorities, investment, scope confirmation and brand and product direction. Those cannot be delegated to the vendor, which is why the rest of this article is about the client's side of the table.
Each of the following is cheaper to settle before the contract is signed than during the first week of discovery.
The decision-maker is the person with final authority over scope, priorities and budget. In some organisations that is one person. In others it is two or three, split by topic.
The risk is not that this person is unknown. It is that the phase is shaped with a champion while someone more senior, absent from the sessions, overrules the direction at the final presentation. A useful warning sign is a decision-maker who has not attended a single session by the end of discovery. For corporate innovation teams the gap is structural, since the person commissioning the phase is often not the person who approves the build, and naming both before kick-off costs one conversation.
A product design phase needs three kinds of people on the client side. The decision-maker is one. Domain experts who know the processes, users and business rules are the second. Technical stakeholders who know the existing systems and constraints are the third.
Their availability is usually the first thing to slip, because discovery sessions compete with everyone's day job. When sessions are chased rather than scheduled, decisions arrive late and the timeline absorbs the delay. Blocking the first two weeks of calendars before the kick-off is one of the cheapest interventions available to a buyer, and section five sets out how much time that involves.
The technical role is the easiest to cut and the most expensive to lose, for the reasons set out in the opening. A proposal that includes an SDL for a few days across a four-week phase is, in practice, a design engagement with an estimate attached at the end.
Two questions settle this quickly: how many days the SDL has on the phase, and whether they start in discovery or join for the estimate. If the budget genuinely cannot carry a full allocation, the better trade is to narrow the scope of the phase rather than thin the role, since a smaller scope estimated properly is worth more than a larger one estimated on assumption. The same logic applies to requests for a more junior UX designer.
A shared definition of complete is an explicit agreement, in named deliverables and named journeys, about what the phase will cover in depth and what it will defer. Without one, words like "full product design" or "complete scope" carry whatever meaning each side brought to the table.
Because most products cannot be designed in full within one phase, the usual approach is to go deep on the main user flow and two or three selected journeys, and to place everything else on a roadmap with the sequencing explained. That is not a compromise forced by the timeline. It is how product thinking works when time is finite: if the phase runs short, the decisions that matter most have been explored fully rather than everything having been touched lightly. Being able to decide what not to build starts here.
Technical context is everything about the current environment that constrains the new product: any required or preferred stack, existing systems and codebases, known integrations and third-party services, infrastructure limits and technical decisions already made.
Most of it is known to someone on the client side and written down nowhere. When it surfaces in week three, it can invalidate an architecture and the estimate built on it. Previous discovery or research work belongs in the same handover, since it lets the phase spend less time in discovery and more in shaping.
A calendar that matches the timeline means four to six weeks in which the decision-maker, the domain experts and the technical stakeholders are actually available.
Holidays, board cycles and competing launches compress a phase without anyone deciding to compress it. A four-week phase that crosses a holiday period is closer to a three-week phase with four weeks of expectations. The fix is to map the calendar before kick-off and, if time is lost later, renegotiate what the phase covers rather than expect the same output in less time.
"AI can do this" is a reasonable expectation to bring to a product design phase, and it shapes how a buyer approaches the collaboration well before kick-off. It tends to take one of three forms: an expectation that the phase should be shorter or cheaper, a proposal to trim the roles whose output looks automatable, or a prototype or specification generated before the first meeting.
The first half of the expectation is correct. The playbook our PMs work from assumes AI throughout the phase: discovery interviews synthesized in minutes rather than days, first drafts of a story map or feature breakdown generated before a session so the room has something to react to, functional front-end prototypes built on the design system instead of static screens and technical spikes on an uncertain integration completed in hours. The pace and depth expected of the phase already account for it.
What AI compresses is production. What it does not compress is the set of things the phase exists to settle. A generated story map, in the playbook's own framing, will not be right; its value is that it gives the client and the team something concrete to disagree with. The same holds for a feature breakdown expanded by a model or a release sequence proposed by one. Each is a draft that still needs someone with authority to accept, reject or reorder it, and someone technical to confirm it can be built at the estimated cost.
That moves the constraint. When synthesis and prototyping get faster, the slowest part of a product design phase becomes the client side: how quickly a decision-maker can confirm priorities, how soon domain experts are available to correct a wrong assumption and whether the technical context arrives on day one. None of the six items in the previous section gets easier with better tooling. Several matter more, because a faster team reaches the point of needing a decision sooner.
It also changes the case for trimming the SDL, though not in the direction the expectation suggests. Agentic coding tools make the technical role faster, not optional. The SDL is the person who turns a generated proof of concept into a judgement about feasibility and cost, and the one whose name sits against the estimate.
A prototype built before the phase starts is useful input, and it belongs in the day-one handover alongside any previous research. It shows what the product could look like. On its own it does not establish which journeys matter most, what the build will cost or which assumptions have been tested, and that is the work the phase is for.
A product design phase typically runs four to six weeks of active client work, with four as the baseline. It moves through four overlapping stages: discovery, shaping, validation and refinement, then wrap-up and handoff. The stages shift in emphasis rather than starting and stopping cleanly, and their weight changes with context. A client who has already done substantial discovery needs less of it. A client with many stakeholders or a layered approval process needs more time in validation.
The client's time is concentrated at the start, before there is anything to look at.
| Stage | Client sessions | Approximate core team time per week |
|---|---|---|
| Discovery | 2 to 3 sessions a week, 2 to 3 hours each | 4 to 9 hours |
| Shaping, validation and refinement | 2 recurring sessions a week, 1 to 2 hours each | 2 to 4 hours |
| Wrap-up and handoff | A final presentation and a handoff session with the development team | Varies |
On top of this sit a weekly status update, ad hoc technical deep-dives and asynchronous feedback on the prototype between sessions.
On cost, the phase is priced by its duration and by the allocation of the three roles, which is why allocation is where buyers usually push. The previous section explains why that lever tends to cost more than it saves. A broader view of how estimates are built sits in how we estimate the cost of your digital product.
The output of a well-run phase is a plan a budget holder can act on. Estimates arrive as ranges with their assumptions stated, never as a single figure, because a single number implies a precision nobody has at this point and tends to be held to regardless. From those ranges the PM builds cost and timeline scenarios for different team configurations, so the investment decision is a choice between options rather than acceptance of one number.
For the first release, "ready for development" should be defined explicitly: estimated stories, designs at sufficient fidelity, the technical approach documented, integration requirements clear and known unknowns listed. Anything that is not ready gets flagged rather than quietly deferred into a development surprise.
What the phase does not give is a guarantee. Its outputs are the best understanding a team can reach in an intensive few weeks, not a fixed contract. Estimates move during development, and priorities shift with the market. A vendor presenting a product design phase as certainty is overselling it, and a buyer treating it that way will read every later change as a failure.
Documents also do not transfer context on their own. If the team that builds the product is not the team that designed it, a proper handoff session is part of the deliverable, for the same reasons that apply to any project handover.
These questions apply to any proposal, from any vendor. A proposal that cannot answer most of them is not wrong, but it is incomplete, and the gaps will surface during the phase rather than before it.