Michael Seibel - How to Plan an MVP

Don't fall in love with your MVP because early, low‑fidelity versions usually change dramatically after learning, so treating them as experiments prevents attachment and keeps you adaptable.

Cut your spec aggressively when needed to ship because getting anything into the world creates momentum and feedback that fuels progress, whereas trying to perfect everything encourages perpetual delay.

Write down your spec because a written plan prevents unconscious scope changes from every conversation and keeps a short sprint from drifting into a long project.

Time‑box your spec to only include features you can build within the launch window because forcing requirements to fit a fixed timeframe removes unnecessary scope and increases the chance you ship on time.

In regulated or hard‑tech domains you may need a slower, heavier MVP process because compliance and complex engineering block quick builds, but you can still start simply with a website or explanation to spark early conversations and referrals.

Build a lean MVP in weeks, not months, because lightweight artifacts (a landing page or spreadsheet) let you test core assumptions fast and start learning without long development cycles.

When the product doesn't help, iterate the solution rather than changing the customer or problem because failure usually indicates poor solution fit—the need and user are often valid but the tool is wrong.

Keep the problem and customer fixed but hold your solution loosely because the product you imagine often won’t match what customers actually want, so adapting the solution preserves focus while enabling learning.