Product Wedge Review · for people ready to fund a build
Turn insider knowledge into a buildable product decision.
You know the workflow. In one working session and a written call you learn whether it is a product worth building — the v1 boundary, the trust model, and what it takes to ship it. The review is the only thing you commit to before you know the number.
A v1 runs as a fixed-scope sprint or a monthly mandate with a senior product team on it; the review tells you which, and the number, before you decide.
§ 01 — What the review decides
What a wedge review actually decides.
- The v1 surface — the single screen or loop that has to exist first
- Data and integration feasibility, named honestly, not assumed
- Where AI can be trusted in the workflow, and where a human must stay in the loop
- A build / fix-first / don't-build call, with the reasoning behind it
How it runs. A working session against your real workflow, sample data, and constraints — not a generic questionnaire. What comes back is a written call: the product boundary, the trust model for where AI drafts and a human decides, and a named next step. If a build follows, it runs as an Embedded AI Product Build.
§ 02 — Fit
Who qualifies, and who this review is not for.
Who qualifies
- A workflow you know from the inside
- An owner with decision authority
- Sample data or systems we can look at
- A budget for a multi-month build already in view — this is a v1, not a demo
- You will own the product
Not the fit
- A demo budget
- "Show us what AI can do"
- A team that wants to spec and staff it themselves
Prefer Sprinter to co-own it? That is a Studio partner incubation.
FAQ
Questions before a build.
What happens if the wedge isn't ready?
We say so, in writing, with the two or three things that would make it ready — a named owner, a data sample, a quantified cost. An honest "not yet" is a normal outcome, not a sales failure.
Who runs the review?
The same senior judgment that owns build architecture — not a junior analyst reading from a template. The review is scoped, run, and written by the person who would own the build if you proceed.
Does this commit me to a build?
No. The review's job is to produce a clear decision — build, fix-first, or don't-build — not to sell a foregone conclusion. Any follow-on scope is a separate decision and proposal.
What if my workflow doesn't have a technical owner yet?
That's normal for domain insiders. You don't need to spec the product or know the stack — you need to know the pain: who hurts, what it costs, and what would count as fixed. The review does the technical translation.
Next step
Bring the workflow you know best.
Bring the workflow, owner, data, and proof line. The review turns that into a build, fix-first, or don’t-build call.