Verified against Claude · 2026-08-06
Cut a feature wishlist down to the MVP that actually tests your riskiest assumption
Reduces a full feature wishlist to the smallest version that tests one specific assumption, with a visible cut list naming what got left out and which assumption it would have tested instead.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are helping scope an MVP down to the smallest thing that tests one specific assumption — not the smallest version of the full product vision, which is a different and much larger exercise. CONTEXT Full feature wishlist: AI-assisted triage form, multi-clinic dashboard, patient wait-time SMS updates, staff analytics reporting, role-based permissions, EHR integration Riskiest assumption to test: That front-desk staff will trust an AI triage recommendation enough to act on it without a nurse double-checking every case Who will use this test version: Front-desk staff at one pilot urgent care clinic How long you can run the test before needing a real answer: 4 weeks HYPOTHESIS RESTATEMENT Restate That front-desk staff will trust an AI triage recommendation enough to act on it without a nurse double-checking every case as one testable hypothesis, specific enough that a pass and a fail would look visibly different. INCLUSION From AI-assisted triage form, multi-clinic dashboard, patient wait-time SMS updates, staff analytics reporting, role-based permissions, EHR integration, select only the features Front-desk staff at one pilot urgent care clinic needs to genuinely put that hypothesis to the test — not features that would help test a different, less risky assumption, and not features that make the product feel more complete but aren't load-bearing for this specific test. CUT LIST List every feature you cut, next to the assumption it would actually test instead — so each cut is a visible decision with a stated reason, not a feature quietly dropped and forgotten until someone asks where it went. PASS/FAIL DEFINITION Define, in advance and specific to 4 weeks, what a pass and a fail look like — specific enough that you and a skeptical cofounder would agree on the result afterward without arguing about what counts. OUTPUT FORMAT Three sections: Included (with the assumption each feature tests), Cut (with the assumption each cut feature would have tested instead), Pass/Fail Definition.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
This grounds MVP scoping in Lean Startup's actual definition — an MVP exists to test one hypothesis, it is not a stripped-down version of the entire roadmap — a distinction most feature-cutting exercises collapse by asking 'what's the smallest version of everything' instead of 'what's the smallest thing that tests the one thing I'm actually unsure about.' The paired cut-list format, where every removed feature sits next to the assumption it would have tested, is what stops scope creep in reverse: without a written reason, a cut feature has a way of quietly getting re-added mid-build because nobody remembers why it left, or because it's easy to justify as 'just one more thing' in isolation once the team is already deep in the build. Defining pass/fail before building, scaled explicitly to {{test_duration}}, removes the after-the-fact wiggle room that lets a team call a weak result a win because the bar was never actually written down — a fail metric defined for a 4-week test needs to be reachable in 4 weeks, and a metric borrowed from a longer or shorter test window quietly changes what the test is actually measuring without anyone noticing until the result comes in ambiguous. Anchoring inclusion to a single named user (not 'users' generally) also forces every feature decision through one concrete lens instead of an abstract audience, which is what keeps the cut list honest — it's much easier to rationalize keeping an unnecessary feature for 'users' in general than for one specific front-desk staffer at one specific pilot clinic whose actual week you're trying to picture.
What you get back
Hypothesis: Front-desk staff will act on an AI triage recommendation without a nurse double-checking every case first.
Included: AI-assisted triage form (the core test), patient wait-time SMS updates (needed to see if staff override the AI recommendation when a patient complains, which would signal distrust).
Cut: Multi-clinic dashboard (tests a scaling assumption, not this one) — staff analytics reporting, role-based permissions (test later-stage operational assumptions) — EHR integration (tests adoption friction, not trust in the recommendation itself).
Pass/fail: Pass if staff act on at least 8 of 10 AI triage recommendations without pulling in a nurse to re-check within the 4-week window. Fail if a nurse re-checks the majority regardless, or staff quietly revert to their old manual process before the window closes.
Verified against
Claude Sonnet 5 · 2026-08-06
Gemini 3 Pro · 2026-07-30
Changelog
- 2026-08-06 — Initial publish, verified against Claude Sonnet 5 and Gemini 3 Pro.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
