Here is the arithmetic nobody puts in the proposal. You sign a six-month product strategy engagement in early March. Procurement takes four weeks. Security review of the supplier takes three more. Your data protection impact assessment sits with legal for a fortnight. API credentials for the system you need to integrate with arrive in the second week of May.
Your six-month programme is now a four-month programme, and the agency that quoted it is about to discover that at the same time you do.
The six-month clock does not start when you sign. It starts when your organisation is genuinely ready to work, and on most enterprise engagements those two dates are six to ten weeks apart. This guide sets out what six months honestly buys you, where the time actually goes, what a credible plan looks like on paper, and how to tell in the first meeting whether a partner can hit the window or is simply agreeing to it.
Start with the ceiling, because a partner who will not tell you the ceiling is not being straight with you.
In six months, with a competent team and a decisive client, an enterprise product strategy engagement can realistically produce: a validated product direction supported by real user and stakeholder research, a tested prototype that has been in front of the people who will use the thing, the foundations of a design system rather than a set of one-off screens, a costed and sequenced roadmap your investment board can act on, and a defined MVP scope that an engineering team can pick up without inventing decisions.
If the scope has been chosen deliberately for the window, you can also get a thin slice of that MVP running in production with real users. Not the whole product. One journey, end to end, on real infrastructure.
Here is what six months does not deliver in an enterprise environment. A complete platform. A replatform of anything load-bearing. A product that depends on three enterprise integrations you do not already control. Full accessibility conformance across a large surface area. Anything requiring a data migration.
An agency that agrees to any of them inside six months is either planning to renegotiate in month four or has not understood what your environment does to a delivery schedule.
The useful conversation at the start of a procurement is not "can you do this in six months?" It is "what is the most valuable thing we can genuinely finish in six months, and what does that set up for the next six?" A partner who reframes the question that way in the first meeting is showing you how they will behave in month five.
This is the map most proposals leave out, because it starts before the contract does.
Period | What is happening | Ownership |
|---|---|---|
Weeks -8 to 0 | Procurement, supplier security review, DPIA, contracting, system access requests, stakeholder diary commitments | You, almost entirely |
Month 1 | Discovery running in parallel with technical feasibility spikes. User and stakeholder research, systems archaeology, constraint mapping | Shared |
Month 2 | Concept development, prototype build and testing with real users. First design system components established | Agency-led |
Month 3 | Design build-out across priority journeys. Roadmap first draft. Scope lock for the MVP slice | Shared |
Month 4 | MVP planning and build readiness, or first slice of build begins. Accessibility approach agreed and applied | Agency-led |
Month 5 | Build and iteration on the thin slice. Roadmap refined against what the build has taught you | Shared |
Month 6 | Production deployment of the slice, handover, documentation, roadmap for the next phase | Shared |
Look at the first row. On most enterprise engagements the client owns the largest single block of elapsed time, and it happens before anyone has done any work. This is the part you can influence most and typically influence least.
Everything in this list can be started while you are still shortlisting, and each one buys back days you would otherwise lose:
Begin supplier security review and vendor onboarding at shortlist stage rather than after selection
Open the data protection impact assessment early, with a placeholder supplier if your process allows
Identify and provisionally book your research participants now, particularly if they are customers or frontline staff
Confirm in writing who holds sign-off, and get their availability into diaries for the whole engagement
Request API credentials, sandbox access and documentation for every system in scope
Agree the decision calendar: what gets decided, by whom, at what cadence
Do those six things and a genuine six-month window becomes a five-month one rather than a four-month one. That single month is usually the difference between finishing with something in production and finishing with a deck.
The instinct under time pressure is to shorten discovery. It is the wrong lever, and it is the one that produces the expensive kind of failure, where the team builds the wrong thing efficiently.
You do not shorten discovery. You run it in parallel. Research, technical feasibility spikes and early concept work happen simultaneously rather than as sequential gates. The design team is sketching against what the research is finding while it is still finding it. Engineers are testing integration assumptions in week two rather than discovering them in month four. Discovery still takes four weeks of calendar time, but four weeks of three workstreams is not the same as four weeks of one.
Four other choices matter as much:
A small senior team over a large mixed one. Adding people to a short engagement slows it down, because coordination cost rises faster than capacity does. Four experienced practitioners will outrun eight mixed-seniority ones over six months, and they will consume far less of your time being managed.
Demonstrable output every two weeks. Not status reports. Something a stakeholder can look at and react to. In an enterprise environment the binding constraint is usually how quickly your organisation can form an opinion, and opinions form much faster in front of an artefact than in front of a summary.
Design system foundations from week three. Not month four. Components built as the design progresses rather than harvested afterwards, so the build phase inherits a system rather than a pile of screens. [internal link: discovery and prototyping → /discovery-prototyping]
MVP planning concurrent with design, not after it. If build scope is defined only once design finishes, you have lost a month to sequencing. The scope conversation should be running from month two, informed by design as it emerges. [internal link: product strategy → /product-strategy]
These are capacity and mobilisation signals specifically. They tell you about speed rather than quality, and a firm can be excellent and still be wrong for a six-month window.
A start date that is not week one. "We can begin in Q4" means your six months is really nine. Ask for a start date and a named team available on it, in writing.
Named people without allocation percentages. A lead who is on your programme at 20 per cent is a lead you will wait for. The number matters more than the name.
A plan built on sequential phase gates. If the proposal shows discovery finishing before design begins, and design finishing before build planning begins, the timeline has no slack in it anywhere. One delay in month one propagates to the end.
No questions about how you make decisions. This is the strongest single signal. An agency that quotes a six-month timeline without asking who signs off, how often your steering group meets, or how long your security review takes has not estimated your project. It has estimated a project.
No acknowledgement of domain ramp. In a regulated or technically unusual environment, a team new to your sector needs three to six weeks before it is genuinely productive. A proposal that shows full velocity from week one has either priced that ramp invisibly or ignored it.
A large team proposed for a short window. Sometimes a signal of confidence. More often a signal that the agency is solving for revenue rather than for the deadline.
No stated de-scoping order. More on this next, because it is the thing that separates a plan from a wish.
If what you actually need is a shortlist rather than a feasibility test, that is a different exercise. [internal link: best digital product agencies for enterprise clients → /insights/best-digital-product-agencies-for-enterprise-clients] and [internal link: digital product strategy consultants → /insights/digital-product-strategy-consultants] both cover partner comparison in more depth.
Ask every bidder for these six things. The ones who can produce them quickly have done this before.
A named team with allocation percentages and a confirmed start date. Not roles. People, and how much of them you get.
Stated mobilisation assumptions. How long they have assumed your procurement, security review and access provisioning will take, expressed in weeks. This forces the conversation that otherwise happens in month two.
A decision calendar. Which decisions are needed, by when, and from whom, mapped across the whole engagement. This is as much a commitment from you as from them.
Milestone deliverables rather than activity lists. "User research complete" is an activity. "Tested prototype and prioritised journey map, reviewed by the steering group" is a milestone with a shape you can inspect.
A documented de-scoping order. What comes out first if the window compresses, second, third. This is the tell. Every six-month enterprise programme loses time somewhere, and the difference between a good outcome and a bad one is whether the reduction was planned in advance or negotiated in a panic in month five.
A named re-baselining point. A date, usually at the end of discovery, where the plan is revisited against what has been learned and the remaining scope is confirmed or adjusted. A plan with no re-baselining point is a plan that intends to be wrong quietly.
On budget, the shape of the engagement drives the number more than the duration does. Our recent article on enterprise MVP agency pricing sets out the UK bands and the questions to put in the RFP itself.
Our process runs across four stages, Discover and Define, Create and Innovate, Launch, then Monitor and Optimise, and for a six-month window we compress the calendar rather than the rigour. Discovery runs in parallel with technical feasibility work from week one. Prototyping starts before research formally closes. Design system components are built as they are needed rather than retrofitted at the end.
We staff small and senior, because that is what a short window rewards, and we name the team in the proposal with their allocations. We also tell you in the first conversation what we think is not achievable in your window, which is usually the least comfortable part of the meeting and the most useful.
Go back to the two clocks. The first is elapsed time, and a good agency can manage that with parallel workstreams, senior staffing and an honest scope. The second is your organisation's decision throughput, and no agency can manage that for you.
A partner who moves at speed inside a business that decides fortnightly will simply spend more of the engagement waiting. Which means the most valuable preparation you can do before the work starts is not writing a tighter brief. It is naming who decides, agreeing how quickly, and clearing the path before week one.
If you have a six-month window and want an honest read on what fits inside it, book a scoping conversation with our team. We will tell you what we think is achievable, what we would leave until later, and where we think your timeline is most likely to slip.
We use cookies for analytics and marketing. No data is shared with third parties.