Product Discovery Services: Stop Guessing What to Build

Product discovery is the structured research phase before a build, where you establish what to build and why rather than assuming it. Done properly it involves talking to real customers, taking apart the products they already use, proving the technical approach, and drawing the core flow, then writing all of it up as a specification a development team can work from. It is the difference between starting a build with a hypothesis and starting one with evidence.

Software product discovery services are a paid research phase run before a software build, usually two to three weeks, covering customer interviews, a competitor teardown, technical architecture and wireframes of the core flow, and ending in a written specification with a costed delivery plan. The word "software" matters because the same term is used in physical product and manufacturing contexts, where it means prototyping tooling and materials rather than researching users and scoping a build.

We quote a fixed fee up front against a fixed scope, and the number depends mainly on how many customer segments need interviewing and how complex the architecture is. Across the market a research-led discovery phase typically runs from around $8,000 to $40,000, with the top of that range reserved for regulated or multi-stakeholder products. It should always be a small fraction of the build it is protecting, and if it is not, the discovery has become the project. For what the build itself costs, see our guide on how much it costs to build an MVP.

Usually not. An MVP is already the cheap way to find out, and if you know your customer and can describe the core flow confidently, discovery is a three-week delay in front of a three-week build. It earns its place when the domain is unfamiliar or regulated, when an earlier attempt failed and nobody is sure which assumption broke, or when the MVP has to fit into systems that already exist. Where it does apply, the research usually shrinks the MVP rather than growing it, which is why the build that follows tends to cost less than one scoped blind.

Two to three weeks. Week one is interviews and the competitor teardown, week two is architecture and wireframes, and the remaining time turns all of it into the written specification. A discovery phase that runs longer than a month tends to be producing documentation rather than decisions, and at that point you would learn more by building something small and watching what happens.

Consulting is our opinion, given quickly. In a free 30 to 45 minute call we help define scope, estimate a budget, recommend a stack and sketch a roadmap, all based on your description of the idea. Discovery is where we go and find the answers instead: we interview your actual customers, use your competitors’ products, prove the architecture, and draw the flow, then hand you a written specification. Most founders should take the free call. Discovery earns its fee in narrower cases: when the problem genuinely is not understood yet, when the domain is complex or regulated, or when someone needs a documented plan.

They settle different kinds of doubt. Discovery answers questions about people and scope: who the customer is, what they need, what to build first and what it will cost. A proof of concept answers a technical question: whether a specific thing can be built at the accuracy, speed or cost you need. Discovery produces a specification, a proof of concept produces a measurement. If discovery surfaces a technical risk that nobody can settle on paper, the honest next step is a short proof of concept before the build rather than during it.

A written product discovery report covering what the interviews found, the competitive picture, what to build first, wireframes of the core flow, the architecture and stack with their risks, and a costed delivery plan. Alongside it you keep the interview recordings and transcripts, the wireframe files and the architecture diagram in editable formats. It is written so that any competent development team, including one that is not us, can return a firm quote from it without running their own discovery.

No, and the document is deliberately built so you do not have to. Everything is yours with no licence back to us. Plenty of clients take the specification to their own team or put it out to several agencies, which is a legitimate reason to buy discovery in the first place, because it lets everyone quote against the same scope. If you do build with us, the discovery work goes straight into the build and the estimate is already done.

Either, and often both. If you have users or a waiting list we will talk to them, and if you do not, we recruit to your criteria so the conversations are with people who genuinely have the problem. What we avoid is interviewing your network, because friends and investors answer a different question than customers do, and their enthusiasm is the most common reason a founder builds the wrong thing feeling encouraged.

It can, but it usually should not for a first version. The value of discovery is that it changes what you build, and it can only do that while the scope is still open. Running it in parallel with a build tends to produce findings nobody can act on without rework. The exception is a second phase, where discovery for the next release runs while the current one ships, which is a normal and healthy way to work.