In spring 2024 we faced a simple question: is there a market for a retrofittable e-bike battery system? Instead of consulting for months, we gave ourselves eight weeks to get an answer. That exercise became ohmbike — and the approach is now our default MVP method.

What an MVP actually is

An MVP is not a stripped-down end product. It is a learning tool. Its only purpose is to validate a hypothesis the team cannot answer internally. Anything that does not contribute to that answer gets cut.

Why eight weeks is the right window

Four weeks is too short for a real product with a checkout flow. Twelve weeks is too long — the team starts polishing instead of validating. Eight weeks is the sharp cut in which a small team can ship working software against real users.

Our eight-week plan

  1. Week 1 — Focus. One sentence: what must be provable by the end?
  2. Weeks 2–3 — Architecture and brand core. Tech choices, one core scenario built.
  3. Weeks 4–5 — Build. Only the core scenario. No side features.
  4. Week 6 — Closed launch. 50–100 testers, real orders.
  5. Weeks 7–8 — Measure, learn, decide. Analyse, then pick: continue, pivot, kill.

What ohmbike taught us

The original hypothesis was partly wrong. We assumed private customers were the audience. The first paying customers came from B2B — delivery services. Pure market research would not have told us that.

When an MVP makes no sense

When you have no real hypothesis. If you already have 100 paying users and want to scale, you don’t need an MVP — you need expansion.

What to take from this

Set a hard time window. Define upfront what must be provable. Cut everything that does not contribute to the answer. Plan at least two weeks for evaluation — otherwise the whole sprint is just motion.

Sources

  1. Eric Ries — The Lean Startup (2011)theleanstartup.com
  2. First Round — Why You Should Ship Nowreview.firstround.com