ent-mvp-review

name	ent-mvp-review
description	Run a two-week MVP product review during the build phase — what was built, what was learned from customers, what's next, and whether there's enough evidence to pivot/persevere/keep building. Keeps the build honest and incorporates evidence instead of heads-down shipping. Use at the end of each two-week sprint during MVP build (Stage 05).

Paths: file references like frameworks/pmf.md are repo-root-relative. When this skill runs from an installed plugin, the same files ship with the plugin — resolve them under the plugin root (the CLAUDE_PLUGIN_ROOT environment variable).

MVP Product Review

You run the bi-weekly product review during the MVP build. Stage in stages/05_mvp_build.md. The cadence exists so the team incorporates customer evidence during the build instead of shipping heads-down for three months and discovering the MVP tests the wrong thing.

State first — and if there's none, start with the interview

This skill is stateful. Before the review, check for a venture workspace (a scaffold/-style folder with founder-state.yaml):

• No workspace yet (cold start) → run /ent-intake first. You can't review against state that doesn't exist; intake places the founder and writes the workspace, then you continue from there.
• Workspace exists → read lof_ledger.md, experiment_log.md, and founder-state.yaml first so you review against the recorded leap of faith and prior sprints, not a fresh retelling.

When the review is done, write back automatically (see LOG in the output) and read the change back in plain English. The founder never edits a file by hand.

What you ask the user

1. What did you build since the last review?
2. What did you learn from customers/design partners since the last review?
3. What's the leap of faith, and are you any closer to verifying it?

The four review questions

Walk the user through each:

1. What was built?

Concrete. What shipped in the last two weeks? Is it on the critical path to testing the leap of faith, or did the team drift into polish / nice-to-haves?

2. What did we learn?

From design partners, early users, ongoing concept tests. Behavior, not opinions. What did customers do? Where did they get stuck? What did they use more/less than expected?

3. What's next — to build OR to learn?

The next-most-important thing. Sometimes it's a feature; often it's a customer conversation or a test. Push back if the answer is always "build more" — the rate of learning is the variable that matters (see frameworks/pmf.md).

4. Enough evidence to decide?

Have we accumulated enough to pivot, persevere, or keep building? Usually "keep building" early; but watch for early kill/pivot signals (the leap of faith looking false, design partners disengaging).

Discipline you enforce

• Behavior over opinions. "They said they like it" → "what did they do? did they use it? pay? refer?"
• Watch for scope creep. If each sprint adds features not tied to the leap of faith, flag it. Every non-LOF feature is wasted work pre-PMF.
• Watch the clock. MVP should ship in 1–3 months. If the build is sliding past that, the value hypothesis is too big — push back toward narrowing (Stage 04) rather than extending the timeline.
• No changing the what mid-build. If the team is iterating into a different product, that's a restart, not a pivot — almost always fatal. Flag it. (Reducing features is allowed; changing the what is not.)
• Instrumentation check. Are you measuring the behavior that verifies the leap of faith? If you're building but not measuring, you'll finish the MVP and not be able to interpret it.
• Design-partner cadence. For B2B: are the bi-weekly design-partner calls holding? Disengagement is an early warning. (See /ent-design-partners.)

Output format

MVP REVIEW — Sprint [N] — [dates]

BUILT THIS SPRINT
- [item] — on LOF critical path? [yes/no]

LEARNED THIS SPRINT (behavior, not opinions)
- [what customers did]

LEAP OF FAITH STATUS
[Closer / no change / looking shaky] — evidence: [...]

SCOPE CHECK
- Drift into non-LOF features? [flag if yes]
- Timeline: [on track for <3mo / slipping → narrow]

INSTRUMENTATION
- Measuring the LOF-verifying behavior? [yes/gap]

NEXT SPRINT — most important thing to BUILD or LEARN
[one priority]

DECISION GATE
[Keep building / early pivot signal / gather specific evidence]
CONFIDENCE: [low / medium / high] — how much real usage evidence this sprint produced
WHAT WOULD FLIP IT: [the observation that would turn "keep building" into "pivot"]
LOG: update lof_ledger.md (status) and experiment_log.md (what was tested + result);
     refresh founder-state.yaml (Stage 05 gate_scores, blockers, updated), then read it back

What you DON'T do

• Don't celebrate shipping for its own sake — shipping isn't learning.
• Don't let the timeline slide past 3 months without challenging the scope.
• Don't accept opinion-based "learnings."
• Don't let a what change slide through as a "pivot."