Product Strategy Services: How an External Team Can Shape Your Roadmap

• Poor product-market fit accounted for 43% of the startup shutdowns CB Insights analyzed in 2026, and Pendo's 2024 data show that 6.4% of features drive 80% of clicks.
• Product strategy work earns its fee by testing your riskiest assumption with a clickable prototype and an engineer in the room.
• If you've already tested your riskiest assumption with real users on proven technology, you can usually skip discovery and build.
• Judge a provider by what you'll hold at the end, and whether another team could start building from it without calling them.
• Stopping or building less after discovery is a good result, and GOV.UK's discovery guidance agrees.

Product strategy services go by several names, including product discovery services, product strategy consulting, and a product discovery workshop, and the label matters less than what gets tested.

Product discovery is the research and testing you do before building to determine whether an idea is worth building at all. The clearest checklist for it comes from Marty Cagan of the Silicon Valley Product Group, who names four big risks every product idea carries [1]:

• Value risk: whether customers will buy it or users will choose to use it.
• Usability risk: whether users can figure out how to use it.
• Feasibility risk: whether engineers can build it with the time, skills, and technology available.
• Business viability risk: whether the solution also works for the rest of your business.

In Marty Cagan's model, the lead engineer owns feasibility, and that's the risk I see skipped most often, because nobody who'll write the code is in the workshop. A prototype here means a clickable mock-up that looks real enough to test with users but contains no production code, which makes it different from an MVP, a working first version you can release. I cover that distinction in this article about MVP vs Proof of Concept, and our guide to MVP development companies shows where discovery fits when you're choosing a build partner.

In March 2026, CB Insights analyzed 431 venture-backed companies that had shut down since 2023 and found identifiable reasons for 385 of them [2]. Poor product-market fit was cited in 43% of those cases, with companies citing more than one reason, and two-thirds of the product-market-fit failures were early-stage companies that never found a market.

Running out of capital topped the list at 70%, but the report calls it "almost always the final cause of death, not the root problem," and in my experience that root problem is usually runway spent on a product the market didn't want.

Pendo's 2019 Feature Adoption Report, based on 615 customer subscriptions, found that 80% of features in the average software product are rarely or never used [3]. Its 2024 product benchmarks, drawn from 6,800 customers, found that 6.4% of features drive 80% of clicks [4], so the pattern held five years later.

Marty Cagan wrote in a 2013 SVPG essay that "at least half of our ideas are just not going to work" [5]. He offered it as a practitioner's estimate, and it fits what I see on our projects, where every feature cut at the prototype stage is code you never pay to build or maintain.

A good engagement ends with material a developer can build from, and this is how we run one at Milo:

After the sale, our first meeting is the kick-off call. Our project manager, the client, and someone from our sales team attend.

The first phase is workshops. Our designer works with the client, or with someone who represents them. The number of sessions depends on the project.

An engineer is in the room from the start. During client sessions, our technical lead reviews the designs from a technical perspective. They look for modules designed in a way that is complicated to build, because those raise costs. We want to catch that before anyone builds them.

We use Figma, Jira, and Confluence. We build the clickable prototype in Figma, keep documentation in Confluence, and create tasks in Jira as the work goes on. We work in Scrum sprints. The project manager runs this and walks the client, or the person responsible on the client's side, through the tools.

Jira holds the backlog, meaning the ordered list of work still to be done, and a sprint is a fixed working cycle of one month or less, as defined in the 2020 Scrum Guide [6].

I won't promise you a fixed week count, but I'll hold every engagement to one test:

On the Monday after discovery, a founder should be able to hand a clickable prototype, clear documentation, and a ready backlog to any developer and say, "Start building."

The UK government's guidance for its own digital services sets the same order, saying "you should not start building your service in discovery" [7] and testing the riskiest assumptions afterward with alpha prototypes that are "just complex enough to let you test different ideas, not production quality code" [8]. Testing after launch is covered in our MVP Testing Guide, and the user research side in our UX Design Services guide.

The clearest example I can share is an anonymous startup that built a car care booking platform for the Saudi market, and these are my notes from the engagement:

A two-sided platform serves two groups of users at once: drivers who book and businesses that sell. Its scheduling relies on FullCalendar, which shows bookable calendars in the browser, and Cronofy, which syncs those bookings with the calendars people already use.

The lesson I take from this project is about timing: the team only learned how much location work the client expected after the budget was set, so the conversation about the map happened under budget pressure. Putting that kind of trade on the table before anyone signs the scope is what a discovery phase is for.

No, and a provider who treats it as one is really selling you a build, as I've learned from being on both sides of that outcome:

If discovery ends with "don't build this," it has done its job. Stopping early saves the weeks of development we would have spent on something that wouldn't have worked.

Discovery can stop or simplify a single feature. Our designer builds the clickable prototype in Figma, and our technical lead participates in the workshops and reviews every design from a technical perspective. If a module is designed in a way that is complicated to build, we find it there, while it is still a screen in Figma. Then we either simplify it or take it out. A fancy widget that looks small in a design can take far more development time than planned, so we raise it early.

I have also seen what happens when discovery doesn't catch the problem. A client wanted a quick, cheap MVP and never mentioned that the product depended on a map and location integration. It came up after we had agreed on the scope. The client argued it was standard functionality, but it was core to the product and required its own time and budget. The project ran long, and we did what we could to limit the loss. If we had tested that one thing first, we would have had the honest conversation in week one instead of in the middle of the build.

GOV.UK's discovery guidance puts it the same way: "It's not a failure to stop at the end of the discovery phase if your research shows that's the best thing to do" [7]. Most engagements land somewhere between a full stop and a full build, usually with a module simplified or a feature moved to a later release.

Buy discovery when the cost of being wrong is high, and you don't yet have evidence that you're right. For the opposite case, this is what I tell founders:

Don't pay anyone for strategy if you can already name the one assumption that kills your idea, you've talked to real users, and your technology is proven. You don't need a discovery phase. You need to build. A workshop would only repeat your plan back to you, and you would pay for it.

Founders rarely admit to that last row on the right, but if you only want validation, a workshop will give it to you for a fee.

Yes, if it's open about its incentive to build more:

A development company has an incentive to recommend building more, and I don't pretend otherwise. We keep it in check by testing the one assumption that could kill the idea before we build anything around it. We would rather run a small proof of concept or a clickable prototype than start a large build on a guess. If a client decides to stop after the MVP, we hand over the code in accordance with the agreement we set at the start.

Engineers in discovery change the roadmap because our technical lead sits in the workshops and reviews every design. They find modules that are complicated to build and would drive up costs, and we simplify or remove them before the client sees them as promises. The roadmap that comes out of that already accounts for the cost of building each part.

That feasibility check, which Marty Cagan gives to the lead engineer [1], is what a build partner adds over a strategy-only consultancy that may have no engineer in the room. You can test any build partner for bias before you sign:

• Ask for a real example of a module that discovery removed or simplified.
• Ask which assumption they'd test first, and how, before any build is quoted.
• Agree in writing what you own, including the code, if you stop after discovery or after the MVP.

For the engagement models, see the Outsourced Product Development Guide. Our guide to web application development services covers the subsequent build phase.

Expect a few weeks, set by how much is still uncertain. GOV. The UK puts a typical government discovery at around 4 to 8 weeks [7], followed by a separate alpha of 6 to 8 weeks for prototypes [8], though a single commercial product usually needs much less time. In our MVP development companies guide, I recommend a paid discovery phase that typically lasts 2 to 4 weeks, with larger builds lasting longer.

Skipping discovery moves its cost into the build, where it's harder to see, and this is what happens when a project reaches us without discovery or full documentation:

Projects like that rarely come to us. When one does, we push for discovery to be mandatory and part of the project.

If a project arrives without full documentation, the most important thing is access to the code so that we can review it. That review is extra work, and the client pays for it. Every fix our developers report against what is currently in the code is also billed on top.

Neither the review nor those fixes add a single feature. A few weeks of discovery at the start usually costs less than that catch-up work.

Ask one question first, then listen closely to the answer:

"What exactly will I be holding at the end, and could another team build from it without calling you?"

A real answer is a clickable prototype in Figma, documentation in Confluence, and tasks in Jira, with an engineer in the room from the start who has already flagged the modules that are complicated and expensive to build. A weak answer is a slide deck.

When founders ask me how to tell a workshop from real strategy work, I put it this way:

If your discovery phase ends with a presentation, you bought a workshop. If it ends with a prototype, documentation, and a backlog a developer can start from, you bought strategy.

A success metric is a number you agree in advance that tells you whether a release worked, and GOV.UK asks teams to plan how they'll measure success during discovery [7]. The other questions worth asking are below, with a good answer and a warning sign for each.

Keep it where your team already works, and feed it with evidence from customers.

A roadmap gets used when it lives where the work happens, in the backlog and the sprints, and when an engineer helped write it, so it matches what the product costs to build. A roadmap ends up in a drawer when it lives in a slide deck.

At Milo, that place is the same set of tools discovery produced:

Our roadmap lives in Jira, where we create and track tasks as the work goes on. Documentation is stored in Confluence, and the clickable prototype or design system is in Figma and was created by our team. We work in Scrum sprints, and their length is adjusted to project needs; our project manager walks the client, or the person responsible on their side, through all of it.

An outcome-based roadmap lists the problems you're solving, rather than features, with delivery dates. 18F's product guide, written for US federal teams and archived in January 2025, calls a roadmap "a bridge between your strategic vision and your backlog of daily tasks" and warns that "a roadmap is not a promise: it is a prediction" [9]. A now/next/later layout suits a small team, with "now" holding the current sprints and "later" holding problems you've agreed to revisit.

On handover, 18F's partner guidance says that "a product that is dependent on our leadership and support will die when we walk away" [10]. In practice, the tools that hold your roadmap should sit in accounts you own from day one, so it doesn't depend on any vendor, including us. Teresa Torres, who coaches product teams, adds in her discovery guide that "good product discovery teams engage with customers at least weekly" [11], and a short roadmap review at each sprint boundary keeps the "now" column honest.

If you're unsure whether you need any of this, write down the one assumption that would kill your idea and how you'd test it. If you can't, a short discovery phase is probably worth paying for, and if you can, you may be ready to build.

What's the difference between product strategy and product discovery?

Product strategy is the decision about what to build and in what order, usually written up as a roadmap, and product discovery is the research and testing behind that decision, such as user interviews and a clickable prototype. Agencies often sell both as one engagement, so check what you'll hold at the end.

How long does a discovery phase take?

GOV.UK says around 4 to 8 weeks is typical for a government discovery, with a separate alpha of 6 to 8 weeks for prototyping. In comparison, a private engagement for a single product often runs 2 to 4 weeks and larger builds take longer. Agree a timebox with the provider before work starts, sized to the amount that is still uncertain.

Is a discovery phase worth it for an MVP?

Usually, if the MVP depends on an assumption you haven't tested or on a component nobody has priced. On a car care booking platform we built, the map was nearly dropped due to budget constraints before we agreed on a simpler version. If you've tested your riskiest assumption with real users using proven technology, you can skip discovery and go straight to building.

Can the discovery team be different from the build team?

Yes, and another team should be able to build from what discovery produces. A separate firm removes the incentive to recommend more building, but you lose the feasibility check from the engineers who'll do the work, so ask a strategy-only provider who will estimate the build.

1. Marty Cagan, Silicon Valley Product Group, "The Four Big Risks," 4 December 2017. Supports the four risks and the lead engineer's ownership of feasibility. https://www.svpg.com/four-big-risks/
2. CB Insights, "The top 9 reasons startups fail," 5 March 2026. Supports 431 shutdowns since 2023, 385 with identifiable reasons, 43% poor product-market fit, 70% ran out of capital, and the two-thirds early-stage finding. https://www.cbinsights.com/research/report/startup-failure-reasons-top/
3. Pendo, "The 2019 Feature Adoption Report," 2019. Supports 80% of features rarely or never used, across 615 subscriptions. https://www.pendo.io/resources/the-2019-feature-adoption-report/
4. Liz Fieno, Pendo, "Product benchmarks," 18 June 2024. Supports 6.4% of features driving 80% of clicks across 6,800 customers. https://www.pendo.io/pendo-blog/product-benchmarks/
5. Marty Cagan, Silicon Valley Product Group, "The Inconvenient Truth About Product," 17 March 2013. Supports "at least half of our ideas are just not going to work." https://www.svpg.com/the-inconvenient-truth-about-product/
6. Ken Schwaber and Jeff Sutherland, "The Scrum Guide," November 2020. Supports the definition of a sprint as a fixed-length event of one month or less. https://scrumguides.org/scrum-guide.html
7. GOV.UK Service Manual, "How the discovery phase works," updated 21 June 2021. Supports the 4 to 8 week duration, not building in discovery, stopping not being a failure, and planning how to measure success. https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works
8. GOV.UK Service Manual, "How the alpha phase works," updated 8 May 2019. Supports the 6 to 8 week alpha and prototypes that are not production code. https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works
9. 18F (GSA), Product Guide, "Craft a roadmap," archived 20 January 2025. Supports the roadmap as a bridge to the backlog and "not a promise." https://guides.18f.org/product/define/roadmap/
10. 18F (GSA), Product Guide, "Enable partners," archived 20 January 2025. Supports the handover principle. https://guides.18f.org/product/partners/
11. Teresa Torres, Product Talk, "Product Discovery Basics: Everything You Need to Know," 18 August 2021. Supports weekly customer contact. https://www.producttalk.org/product-discovery/