In the way we run it, a product design phase ends with nine deliverables: a user story map, an estimated feature breakdown, a release plan, a prototype of the primary journeys, design system foundations, technical architecture documentation, a recommended team capacity, a cost and timeline projection and a summary for budget holders. Other companies structure the phase differently, so the list is a reference point rather than a standard. Each deliverable has a test a buyer can run before the final presentation, and the prototype, which gets the most attention in that meeting, says the least about whether development can start.
The final presentation of a product design phase tends to follow the same order. The prototype goes first, because it is the part everyone can react to. Stakeholders click through the main journeys, someone asks about a colour, someone else asks how a screen will behave on mobile and the meeting runs long on the deliverable that is easiest to judge and least able to say what happens next.
The documents that decide whether development can start often arrive afterwards, as links in a follow-up email: a feature breakdown, an architecture document, a release plan. They are harder to read in a meeting and easier to accept without reading at all, which is how a phase gets signed off on the strength of how its screens look.
Few buyers commission enough product design phases to build a reference for what a good feature breakdown looks like, or how an architecture that was tested differs from one that was only described. The vendor has that reference. The person paying for the work usually does not.
The nine deliverables and the tests that follow describe how we run a product design phase, an approach shaped by fifteen years and more than 220 projects and followed by our product managers, UX designers and software development leads on every engagement. That is good evidence the approach works for us and for the clients we build with. It is weaker evidence that it is the only way to run the phase, and other companies name their outputs differently, split them in other ways or leave some out on purpose. What tends to carry across vendors is the question behind each test: whether the output lets a development team start without reopening the scope. That question is worth asking of any proposal, and it is most useful in the week before the final presentation, while there is still time to fix what it turns up.
In our practice, a product design phase ends with nine deliverables, which fall into four groups by the decision each one supports.
Each group answers a different question for a different reader. Scope tells the development team what to build first. Design shows what the product should look and feel like. The technical group states how it will be built and by whom, and the decision group gives budget holders what they need to approve the next stage. Why the phase produces these at all is covered in why a product design phase comes before the build budget. This section is about checking them.
One signal applies to all nine. The deliverables should take shape throughout the phase and be finalised in its last week. A story map or architecture document that first appears in wrap-up was probably assembled from conversations nobody wrote down at the time.
Each check below is a question a buyer can put to the team before the final presentation. The standards behind them are the ones our own teams are held to. Another vendor may name these outputs differently or combine some of them, and the questions still apply.
A user story map lays out the product's user journeys from left to right and groups the work beneath them into releases. The technique comes from Jeff Patton, who set it out in User Story Mapping, published by O'Reilly in September 2014.
What to check: pick a release and follow one user from their first step to their last. Each release should still let that user finish what they came to do. The line between releases should read as a priority decision someone made, not an arbitrary cut.
Warning sign: a map nobody can read without the person who built it, or a release that leaves a gap in the middle of a journey.
The feature breakdown lists the product's features and capabilities at the level of detail where each can be estimated and prioritised, with technical context added by the software development lead.
What to check: open five rows at random. Each should make sense to someone on the client side and to a developer, and should carry an estimate (a range is fine), a priority and a place in a logical group. Known unknowns and research items belong in their own list, kept out of rows that look settled.
Warning sign: rows so general they could describe any product, such as "user management" or "dashboard".
The release plan sets out what gets built first, second and third, and why.
What to check: look for one sentence per release explaining the sequence, along the lines of "release one focuses on this area because it tests the core value proposition and removes the biggest risk". The plan should link back to the story map and the feature breakdown, and later releases should build on the first without reworking it.
Warning sign: releases defined by size or by calendar quarter instead of by what each one proves.
The prototype is an interactive version of the primary user journeys: clickable at minimum, ideally a functional front end built on the design system.
What to check: walk each primary journey end to end without help, then ask a developer whether they could build from it without guessing. Polish is a poor measure of this, and it is getting poorer. In a September 2026 talk, Figma's Designer Advocate Hugo Raymond argued that the more finished a prototype looks, the more authority teams give it, to the point of treating it as a specification. He also pointed out that AI tools can now connect flows, generate data and add states nobody explicitly defined. So the useful question is which parts of the prototype the team decided and which a tool filled in.
Warning sign: error states, empty states and edge cases that are either missing or present without anyone being able to say who decided how they behave.
Design system foundations are the visual and interaction patterns the product is built from: colours, typography, spacing, components and the guidelines for using them.
What to check: ask how a developer would build a screen nobody designed during the phase, such as a settings page or an error view. The answer should point to documented components and patterns, and the designer's calendar shouldn't come into it. The aim is deliberately limited to foundations, since a complete design system grows with the product.
Warning sign: a style guide with colours and fonts but no components, or components with no notes on when to use them.
The technical architecture documents how the product will be built: the stack, the system design, integration points, third-party services, data model foundations and the technical research behind each choice.
What to check: ask for the list of integrations and, for each one, whether it was validated during the phase or taken from the provider's documentation. Ask too whether the architecture supports the release plan, so the first release can work before everything else exists. Technical risks should be either mitigated or flagged by name.
Warning sign: a document written to complete the file, with nothing in it the development team will open twice.
The recommended team capacity sets out the roles, seniority and allocation development will need, sized to the release plan.
What to check: see whether the recommendation follows the releases, since different releases often need different team shapes. One composition carried unchanged from the first sprint to the last deserves a question.
Warning sign: a team that reads like a standard template, with no visible link to this particular product.
The cost and timeline projection turns the estimates and the team capacity into scenarios a budget holder can compare.
What to check: estimates should arrive as ranges with their assumptions stated, and there should be more than one scenario, usually built around different team configurations. How those ranges are built is covered in how we estimate the cost of your digital product.
Warning sign: a single figure. It implies a precision nobody has at this stage, and it tends to be held to whatever changes later.
The summary is the consolidated account of the phase for board members, budget holders and leaders who weren't in the day-to-day sessions.
What to check: it should tell one story: what the product is, who it's for, what gets built first and why, what it costs and how long it takes. It should use visuals from the prototype and the story map.
Warning sign: the outputs presented one after another as separate artefacts, leaving the reader to connect the prototype, the estimate and the release plan alone.
Ready for development is the point at which the first release can enter a development team's planning without anyone having to reopen the scope. We set five conditions for it. The first release needs estimated stories, designs at sufficient fidelity, a documented technical approach, clear integration requirements and a catalogue of known unknowns. Anything that misses a condition gets flagged at handoff, never quietly deferred until it surfaces as a surprise in the first sprints.
The last condition is the one buyers tend to read wrongly. A first release can be ready with open questions, provided those questions are named, owned and priced into the estimate as risk. What it can't have is open questions nobody has written down.
The idea extends well beyond our own practice. Microsoft's engineering playbook treats a user story as ready when it has enough detail for the team to estimate the work within a sprint. Its readiness checks include clear acceptance criteria and whether the story is blocked by work another team still has to deliver. The Scrum Guide sets no readiness checklist at all: it treats backlog items as ready for selection when the team can complete them within one sprint, and leaves the rest to ongoing refinement. Both definitions work at sprint level. A product design phase applies the same test to the whole first release before development starts.
Vendors use the two terms differently, and some use them interchangeably, so the useful distinction is by output. Nielsen Norman Group defines discovery as a preliminary phase that researches the problem space, frames the problems to be solved and gathers enough evidence and initial direction on what to do next. By NN/g's account, a discovery typically produces a problem statement, journey maps or service blueprints, user-needs statements, personas and high-level concepts or wireframes to explore in the next phase. It can also end with a decision not to move forward, for example when there turns out to be no real user need.
A product design phase starts where that leaves off. In the way we run it, discovery is the first of four overlapping stages inside the phase, followed by shaping, then validation and refinement, then wrap-up and handoff. A buyer who has already run a separate discovery shortens the phase without replacing it, because research findings still have to become a feature breakdown, an architecture and an estimate.
| Discovery | Product design phase | |
|---|---|---|
| Question it answers | Which problem is worth solving, and for whom? | What should be built first, how and at what cost? |
| Typical outputs | Problem statement, journey maps, personas, user-needs statements, high-level concepts | The nine deliverables above |
| Ends with | A direction, or a decision not to proceed | A scope that can be estimated, sequenced and funded |
The practical test follows from the table. If what you received at the end of a phase ends in a direction, you have a discovery, whatever the proposal called it.
At handoff, each deliverable moves to the place where the development team will actually use it. A deliverable with no obvious destination was probably produced for the file.
Documents alone don't transfer context, so the handoff includes a working session. The people who ran the phase walk the development team through the story map, the design decisions, the architecture and the known risks. That matters most when the team building the product isn't the one that designed it, for the same reasons that apply to any project handover.
A product design phase hands over the best understanding a team can reach in a few intensive weeks. Three things fall outside that, and a proposal that promises them is overselling.
A guarantee. Estimates arrive as ranges because development still uncovers things a design phase can't. They move as the build progresses, and priorities shift with the market. Our position, stated to clients in the same terms, is that estimates are not delivery guarantees. The outputs are a well-researched plan, not a fixed contract.
A complete design system. The phase delivers foundations: enough documented structure for developers to build new screens and states without the designer drawing every variation. A full design system grows with the product, and handing one over at this stage isn't the aim.
Certainty about every assumption. By the end of the phase most critical assumptions should be resolved. The ones that aren't get recorded as known unknowns and priced into the estimate as risk, which is more useful to a budget holder than a scope that pretends to be settled.
Most of the checks in this article take minutes. Opening five rows of a feature breakdown, asking which integrations were tested, reading the release plan for one sentence of reasoning per release: none of it needs technical training, and all of it is easier to act on before the final presentation than after it.
The timing matters more than it used to. When a prototype could only look finished after weeks of design work, its polish said something about the thinking behind it. AI tools have weakened that link. Google's 2025 DORA research points the same way: AI adoption now goes with higher delivery throughput but still with lower delivery stability, and its authors describe AI as amplifying whatever a team already has. That moves more of the evidence into the deliverables that look least impressive on a screen: the breakdown, the architecture and the list of what is still unknown.
The structure in this article is ours, and other teams will organise the same work differently. The question behind it travels: does what you received let a development team start without reopening the scope? If the answer is yes, the phase did its job, whatever it was called. If the answer is no, the week before the final presentation is the cheapest time to find out.