MVP Scoping skill for Codex

An MVP is scoped well when it tests the single assumption most likely to kill the product, serves one clearly named user through one complete flow, fits a fixed time box, and comes with written criteria for what result means continue, change direction, or stop. “Minimum” refers to effort; “viable” means a real user can get real value from it.

Name the riskiest assumption

List assumptions in four categories and pick the one that is both most uncertain and most fatal if wrong:

Category	Question	Example
Value	Will they want it badly enough to change behaviour?	Ops leads will replace their spreadsheet
Usability	Can they figure out how to use it?	Admins can set up rules without help
Feasibility	Can we build it with our team, stack and data?	We can parse their scheduling exports reliably
Viability	Does it work for the business (cost, legal, channels)?	Inference cost stays under $2 per user per month

The MVP exists to test that one assumption. If the riskiest assumption is value, a landing page, concierge service or prototype may test it faster than code. Use $product-discovery for those cheaper tests.

Scope rules

1. One user, one job. Name the segment narrowly (“ops leads at 20-80 person agencies”). Every feature request from other segments goes on the cut list.
2. One end-to-end flow. The user must be able to start, finish and get the value once, even if crude. A polished first half of a flow tests nothing.
3. Fake what you can. Replace automation with manual work behind the scenes (concierge, Wizard of Oz), integrations with CSV upload, settings with sensible hard-coded defaults, admin UIs with scripts the team runs.
4. Fixed time, variable scope. Set the time box first (commonly 4-8 weeks for a small team), then cut scope to fit. Never extend the box to fit scope.
5. Quality bar holds for what ships. Fewer features, not broken features. Security, data protection and correctness of what is in scope are not cut.

Cut techniques

Ask	Typical cut
Is it needed for the first user to get value once?	Settings, roles, notifications, theming
Can a person do it manually for the first 20 customers?	Billing (invoice by hand), onboarding (call), reports (export)
Can a default replace a choice?	Time zone pickers, formatting options, templates
Does only a later segment need it?	SSO, audit logs, multi-workspace
Can we narrow input variety?	One file format, one integration, one language
Is it a “what if” edge case for a rare scenario?	Handle with a clear error and manual follow-up

Write each cut down with the reason and the trigger that would bring it back (“Add roles when 3+ customers ask for read-only members”).

Check against the codebase

When a repo exists, read AGENTS.md, the data model and the modules the flow touches before committing to scope:

• Which parts of the flow already exist and can be reused?
• Which new tables, endpoints or integrations does the flow need?
• What is the riskiest technical piece? Schedule it first or spike it in week 1.

Produce a rough size per flow step (small / medium / large) and flag anything large for the team to estimate properly; do not present your sizing as a commitment.

Success and kill criteria

Decide before building, write them in the scope doc, and get the owner to agree:

Measured over: 4 weeks after the 20th user onboards
Continue if: >= 8 of 20 pilot accounts use it in 3 of 4 weeks AND >= 3 agree to pay $X
Change direction if: usage is high but nobody will pay, or one step drives most drop-off
Stop if: < 4 of 20 use it after week 2 despite onboarding calls

Use counts or rates you can actually observe at MVP scale (often 10-50 users), not statistically significant conversion targets that need thousands of visitors.

Workflow

- [ ] 1. List assumptions; pick the riskiest; confirm with the user
- [ ] 2. Decide whether code is the cheapest test of it
- [ ] 3. Name the user, the job and the one end-to-end flow
- [ ] 4. Set the time box
- [ ] 5. List everything wanted; mark in / faked / cut with reasons
- [ ] 6. Check the codebase; size each step; spike the riskiest piece first
- [ ] 7. Write success, change and stop criteria with the owner
- [ ] 8. Produce the scope doc; review cuts with stakeholders

Scope doc template

# MVP: <name>
Riskiest assumption: <one sentence>
User: <narrow segment> | Job: <what they are trying to get done>
Time box: <start> - <end> (<n> weeks, <team>)

## The flow
1. <step> - in (real) | faked (<how>) - size S/M/L
## In scope
## Faked / manual (and who does the manual work)
## Cut (reason, trigger to revisit)
## Success / change / stop criteria
## Technical risks and week-1 spike
## Not cut: quality, security and data obligations that still apply

Gotchas

• Scope creep usually arrives as “small” additions for a second segment. Point to the named user and the cut list.
• A Wizard of Oz MVP needs a person with time to do the manual work; budget that time explicitly or the experiment collapses.
• MVPs that collect personal data still need consent, secure storage and deletion paths; cutting compliance is not a scope option.
• Teams often build the impressive part (AI, automation) and fake the boring part that actually carries the value test. Check the riskiest assumption is the real one.
• “MVP” is not a licence for unmaintainable code in the parts that will survive; mark throwaway code as throwaway in the repo.

Verification

Confirm one named user can complete the flow end to end, each in-scope item is needed for that flow, every cut has a reason and a revisit trigger, the time box was set before scope, and the success and stop criteria use numbers observable with the expected number of users.