agentsclimarketplace

Ent mvp review

Skill kalyvask/entrepreneurship-lessons/.claude/skills/ent-mvp-review

PMF framework spine + supporting methodologies (Lean Startup, Customer Development, RDI, Mom Test, Disruption, Market Type) and 24 Claude Code skills, from curious mind to PMF.

Install
npx -y skills add kalyvask/entrepreneurship-lessons --skill ent-mvp-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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).

SKILL.md

5.0 KB, as published. Nobody here has run it

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."

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.