Product Wedge Review · first step
Turn insider knowledge into a buildable product decision.
You know the workflow. We pressure-test it into a scoped product decision — before either of us commits to a build. Commercial scope is set only after fit is established.
§ 01 — What the review 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 mandate or fixed sprint.
Bring
- A named workflow with an observable starting state
- An owner with real time and decision authority
- Sample data, documents, or systems the review can look at
- What's already been tried, and where it broke
Not the fit
- A team ready to spec, staff, and manage the build themselves
- "Show us what AI can do" with no workflow or owner named
- A free strategy session — this is a paid, working review
- A guarantee of outcome before the wedge has been pressure-tested
FAQ
Questions this pattern has to answer.
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
Score the wedge before you build.
Bring the workflow, owner, data, and proof line. The review turns that into a build, fix-first, or don’t-build call.