A product discovery sprint is a short, fixed piece of work that turns a problem, idea, or rough requirement into a written product direction: the user, the core workflow, the MVP boundary, and an honest assessment of what is technically feasible.

What it produces

  • A defined problem statement and the one user it is for.
  • The core workflow, described as the sequence a person actually goes through.
  • What to build first, and what to defer, with reasons.
  • Where on-chain behaviour is genuinely required and where it is not.
  • A feasibility assessment and the risks worth knowing before anyone writes code.

It is written down, and you keep it whether or not you build with me afterwards. That matters more than it sounds. A direction that lives only in a conversation cannot be reviewed, argued with, or handed to an engineer.

What it is not

  • A consultation call. Calls produce opinions. A sprint produces a document with specific decisions in it.
  • Market research or a competitive analysis. Useful work, but it is not what this is.
  • A guarantee of product-market fit. Nobody can sell you that honestly, and anyone who does is selling you something else.
  • Design work. Interface clarity gets discussed because it affects scope. A production design system is a separate purchase.
  • A pitch deck. If you need investor materials, that is a different engagement.

What the days actually look like

A sprint runs three to seven days depending on how much is already decided. The shape is consistent, and it is deliberately front-loaded on understanding rather than on producing documents.

  • Days one and two: understand the situation. What the product is for, who the user is, what they do today instead, and what has already been tried and abandoned.
  • Day three: map the alternatives. Including the ones that do not involve software, because some of those are cheaper and better.
  • Day four: define the user and the workflow. One user, one action, described as a sequence rather than as a feature list.
  • Days five to seven: scope, assess, write it down. The version one boundary, the technical unknowns, the risks, and a recommendation.

How to judge the document you get back

A useful direction document has three properties. It names a single user rather than a market segment. It contains at least one decision you disagree with, because a document nobody can argue with was not making decisions. And it states plainly what it does not know, which is the part that tells you whether the author was honest with you.

If it reads like a proposal for the build that would follow it, you were sold a pitch rather than discovery. That is the failure mode worth watching for, and it is the reason the sprint is written to stand on its own whether or not you build with me afterwards.

When it is the wrong purchase

If you already know exactly what you are building and why, discovery is an expensive way to hear it back. Go build. The value here comes from genuine uncertainty about what the first version should be, or from a disagreement inside the team that nobody has resolved because there was nothing concrete to argue about.

When it pays for itself

It pays for itself the first time it stops you building a feature that would have taken weeks and changed nothing. In practice that happens often enough that I treat discovery as the default starting point rather than an upsell. My published starting point is $750 for three to seven days, which is a fraction of the smallest product build, and it is listed with the other engagements.

The full detail on what is included, what is not, and the questions I ask is on the product discovery sprint page.