Writing · Architecture

MVP paralysis when the domain is too broad

Jan 2023 · 2 min read

I once spent months trying to define an MVP for a product idea in the assistive-AI space. Every candidate MVP I sketched kept expanding. To work at all, the smallest useful version needed depth in the target domain, depth in pedagogy, and depth in the AI stack itself. Three unrelated fields. No one person or small team could hold all three at competent depth.

I eventually concluded that keeping the whole thing as a philosophical exercise (paper designs, mind experiments, open questions) was the honest state of the project. Not shipping, but not pretending to be shipping either.

The general lesson: if your MVP requires expertise in three unrelated domains, you don't have an MVP problem. You have an objective problem.

"Domain-extensive MVP" is a signal that what you're calling a product is actually a category. Categories don't ship. Products ship. You get out of the trap by narrowing to one specific use case where one domain is enough, shipping that, then generalising from there.

This is directly relevant to the current wave of general-assistant products. "General" means every domain. No team has depth in every domain. So the products end up either shallow across the board, or accidentally deep in whatever the founder happened to know. Neither is a strategy.

A contrarian corollary is worth saying out loud: paper design and mind experiments are a legitimate pre-MVP stage. You don't have to be shipping to be making progress. The real failure mode isn't slowness. It's pretending to build when you're actually still scoping.

The honest categories of project status:

  • Scoping: still figuring out what problem you're solving. Paper designs are appropriate here.
  • Building: scope is clear, you're implementing. Deadlines and MVPs matter here.
  • Shipping: it's live, you're learning from users. Metrics matter here.

Mixing them is the disease. Building without having scoped produces the domain-extensive MVP. Shipping without having built produces demos that don't survive contact with reality. Scoping while claiming to build produces the year-long "MVP" that never ships.

Name the stage you're in. Then use the tools appropriate to it.

Drafted in January 2023
Updated for site in 2026