§ CAPABILITY

Product and Technical Discovery Sprint

A short, bounded piece of work that turns an intention into a scope both sides can hold. Cheaper than the first month of building the wrong thing, and it ends with a decision including the decision not to proceed.

Who
Founder holds the engineering leadership seat; the delivery team executes underneath it.
Request a call How the work runs

What you're seeing

There is a build brief and no stated decision behind it.
Usually means Somebody asked for a thing rather than for an outcome. Without the commercial question underneath, nothing in the scope can be prioritised and every trade-off becomes a matter of taste.
Two people describe the same project and the descriptions differ.
Usually means The disagreement exists now and will surface during the build, at the point where changing direction is expensive. It is far cheaper to find in a workshop.
Nobody has checked whether an existing contract or a data residency rule constrains this.
Usually means Constraints reshape a scope more than requirements do, and they surface late by default because nobody owns finding them. This is the most common cause of a mid-build re-plan.
The estimate has a single number on it.
Usually means The assumptions were not stated, so the number cannot be checked and cannot be updated when something changes. A range with its assumptions written down is more honest and more useful.

What is actually being decided

The first question is not what to build. It is what commercial decision this build is meant to enable.

A brief with no decision behind it produces a scope nobody can prioritise, because every trade-off — this feature or that one, this quarter or next — has no criterion to be resolved against. It gets resolved by seniority or by whoever cares most, and both produce a plan that fragments the first time it meets a constraint.

Establishing the decision usually takes one workshop and it frequently changes the shape of the request. Two people who both wanted the thing turn out to have wanted it for incompatible reasons, and that disagreement is much cheaper here than in month three.

Constraints before requirements

Requirements are what a client knows and will tell you. Constraints are what nobody thinks to mention.

A data residency clause in an enterprise contract. An integration agreement with a twelve-month notice period. A compliance obligation that rules out an architecture. A commitment made to a customer last quarter that nobody wrote down. Each of these reshapes a scope more than any individual requirement does, and each surfaces by default at the worst possible moment, because no one owns hunting for them.

So the constraints register is built before the requirements are refined, and it is where most of the surprises in this work live.

Prototype the risk, then delete it

Whichever assumption would be most expensive to be wrong about gets tested with something built to be thrown away.

The deletion is deliberate and it matters. A prototype that is kept and extended becomes the foundation by accident, carrying every shortcut taken while the question was still open — and those shortcuts were correct decisions for a prototype and wrong ones for a system. Building it to be discarded also removes the pressure to make it good, which is what keeps it fast.

It can end in no

A discovery that structurally cannot reach a no-go recommendation is a proposal wearing a different name, and everyone in the room can tell.

That is why it is paid work with its own deliverable rather than a free pre-sales exercise. The willingness to conclude that this should not be built, or should be bought instead, or should wait two quarters, is the only thing that makes the go recommendation worth anything.

Where it sits

This capability sits under Software Development, where anything beyond a well-specified change starts here, and under CTO Consulting, where a fixed-scope sprint needs a scope that can honestly be fixed.

Two neighbours pick it up. Architecture Review is the deeper version of the technical half where the question is whether an existing system can carry the plan. And Backend & API is usually where the prototype’s real successor gets built, with the contract written first this time.

How the work runs

  1. Establish what is being decided

    The commercial question underneath the request. A build brief with no decision behind it produces a scope nobody can prioritise.

  2. Find the constraints early

    Integrations, data residency, compliance obligations, existing contracts. These reshape scope more than requirements do and they surface late by default.

  3. Prototype the risky part

    Whichever assumption would be most expensive to be wrong about, tested with something thrown away afterwards.

  4. Scope and cost

    A plan in phases with effort ranges and their assumptions stated, including what it would take to stop after phase one.

What arrives

  • A written scope with phases and effort ranges
  • A constraints register covering compliance, data and integrations
  • A throwaway prototype of the riskiest assumption
  • A recommendation, including no-go where that is the answer

What it costs your team

Two workshops and a review, roughly a day of stakeholder time in total.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • It can end in a recommendation not to build

    Costs It is paid work that sometimes concludes there is no engagement after it.

    A discovery that structurally cannot reach no-go is a proposal with a different name, and everybody in the room knows it. The willingness to conclude against our own interest is the only thing that makes the recommendation worth anything, and it is why the deliverable is scoped and paid rather than free.

  • The riskiest assumption gets prototyped, and the prototype is thrown away

    Costs It spends part of a short engagement building something that will be deleted.

    The point is to learn whether the assumption holds, not to start the build. A prototype kept and extended becomes the foundation by accident, carrying decisions made while the question was still open. Deleting it deliberately is what keeps the learning and discards the shortcuts.

  • Constraints are hunted before requirements are refined

    Costs It front-loads unglamorous investigation into contracts, obligations and existing systems.

    Requirements are what the client already knows and will tell you. Constraints are what nobody thinks to mention — the data residency clause, the integration contract with a notice period, the compliance obligation that rules out an architecture. They reshape scope far more than requirements do, and finding them after the build starts is where re-plans come from.

Frequently Asked Questions

A short, bounded, paid engagement that turns an intention into a scope both sides can hold to — by establishing what commercial decision is being made, finding the constraints, testing the riskiest assumption, and producing a phased plan with effort ranges. It ends in a recommendation, which can be not to proceed.
It is paid work with its own deliverable and it can end in a no-go. That is the test: a discovery that structurally cannot conclude against the provider's interest is a proposal with a different name, and it should be priced as one — that is, free.
Then it is short, and the value is in the constraints rather than the requirements. Data residency, an existing integration contract, a compliance obligation, a commitment made to a customer last quarter — these reshape a scope more than the feature list does, and they are the things nobody thinks to mention.
Yes, entirely — the scope, the constraints register, the prototype and the recommendation, whether or not anything follows. A discovery whose output is only usable by the provider who wrote it has not produced a scope, it has produced a quote.
Typically one to two weeks, and around a day of stakeholder time in total across two workshops and a review. Longer than that usually means the decision underneath was not clear, which is itself the finding worth reporting.

Sources

Page reviewed