Product and interface
MVP
The smallest thing that can be built to test the assumption most likely to kill the business — not the smallest sellable version of the eventual product.
Also called Minimum viable product
The definition turns on the word viable, which names a hypothesis rather than a feature set. The right question is which assumption, if wrong, ends the project — and what is the cheapest honest test of that one assumption. Sometimes it is software. Often it is a landing page, a spreadsheet operated by hand, or twenty conversations.
An MVP that tests nothing is just a small product with a flattering name, and it costs the same as a small product.
Teams build a quarter of the roadmap, ship it, and learn nothing — because the risky assumption was demand, and every feature they cut was on the supply side. Name the assumption first; the scope follows from it rather than the other way round.
A definition is free. Being answerable for the figure it produces is the part that is bought, and this term is a working part of the engagements below.
- From idea to a product that exists
- Find the assumption that kills it, and test that one first.
- Your product has a meaning. You are too close to say it
- The name is not the work. The invariant is the work, and the name is what it compresses to.
- Custom software development and AI engineering for Dubai
- A probabilistic component is only safe inside a deterministic boundary.
The definitions are the easy part. Whether the figure on your dashboard was computed this way is a different question, and usually the more expensive one.