Product strategy and discovery
Product strategy and discoveryto decide what to build first
Discovery answers three questions before you pay for development: is the problem real, what is the smallest version worth releasing, and what will it take? It can't promise that the product will succeed. It can make the expensive assumptions visible while they are still cheap to change.
What discovery produces
Documents you can use even if you build with someone else or not at all.
A problem statement with evidence
Who has the problem, what they do today and what it costs them, drawn from conversations with people who actually have it.
A scoped first release
A written list of what is in, what is out and why, with each feature tied to the assumption it tests.
Architecture options
Two or three technical routes, including buying rather than building, with their trade-offs in cost, speed and future change.
An estimate and a roadmap
A range based on the scoped list, and the order of work, with the riskiest parts brought forward so that you learn early.
When discovery is worth paying for
It isn't always needed, and we would rather tell you so.
Worth doing
The idea is new, the budget matters, several people disagree about scope, or investors need a plan that holds up to questions.
Probably not needed
You are replacing a well-understood internal process, the requirements already exist, or the job is a defined upgrade. Then go straight to a scoped quote.
What it can't do
Discovery doesn't prove that people will pay. Conversations reveal problems, not purchases. Only a real release, a pilot or a pre-sale tests that properly.
If you already have a team
We can run discovery with your product people and engineers, so that they own the conclusions and can carry them forward themselves.
The decisions it should settle
If any of these stay open at the end, the discovery hasn't finished.
Build, buy or adapt
Is an existing product close enough to use, perhaps with an integration, before you pay for custom software? It is often the most valuable question asked.
Who it is for first
Picking one user group for the first release, even if the eventual market is wider, because trying to serve everyone is the usual reason a first version grows.
What counts as success
Measures that you agree in advance and can actually collect, so the decision after launch isn't down to opinion.
What could stop it
Regulation, data licensing, app-store rules or third-party APIs that might block the idea. These are the checks worth making before anything is designed.
How a discovery runs
Its length is agreed at the start, according to how much is unknown. Each stage can change the next.
Write down the assumptions
We begin with a working session to list what must be true for the product to work, ranked by how damaging it would be if it were wrong.
Talk to real users
Your contacts and any people you can recruit are interviewed about what they do now, and not about whether they like the idea.
Test the risky part
A clickable prototype, a landing page or a small technical spike, depending on whether the main risk is demand, usability or feasibility.
Scope, estimate and present
You get the written scope, options and estimate, including our honest view if the evidence says to change course or stop.
How discovery is paid for
A fixed scope with a clear end, which leaves you free to go elsewhere afterwards.
We agree the questions and the length up front. Time is priced from $20/h in USD, invoiced in USD, GBP, EUR or INR. The output is written so that another team could work from it, and building with us afterwards isn't a condition.
We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment. Workshops and user interviews can take place in the shared hours, or by appointment for US teams. If the answer is to build, the work continues as MVP development or longer-running software product engineering.
Why we don't publish discovery examples
Most of our work is delivered under NDA, so many projects cannot be named.
Early product ideas are among the most confidential things anyone shares with us, so we show no examples of them. Ask us for an NDA before you share yours.
Questions about discovery
Asked by founders and internal sponsors.
Can't we just start building and learn as we go?
Will discovery tell us whether the product will succeed?
Do we have to find the users to interview?
How accurate is the estimate at the end?
Tell us the idea, and what worries you about it
A few lines are enough. We will tell you whether discovery makes sense, or whether you are ready to go straight to a quote.
We reply within one business day (IST).