Petr SkodaA Minimum Viable Product is often mistaken for "a simplified but working version of the product." In reality, the whole point of an MVP is learning: getting the maximum amount of validated knowledge about customers for the least effort. An MVP is not a synonym for a low-quality or unfinished product. It's a deliberately limited version that includes only the features necessary to test the single most critical hypothesis. And in many cases, it doesn't need a single line of production code at all.
Five forms of MVP worth knowing
Concierge MVP: the service you eventually want to automate is delivered manually at first. The goal isn't to prove technical feasibility, but whether customers actually want it and are willing to pay for it. A classic example is a company that, before building an automated meal-planning platform, manually put together meal plans for its first customers itself.
Wizard of Oz MVP: unlike the Concierge approach, the customer doesn't know that the "automated" feature is actually being carried out by a human behind the scenes. This lets you test the experience of an apparently fully automated product before it's technically built, typically useful for AI assistants or chatbots, where responses can be simulated manually first and only replaced by a real model once interest is confirmed.
Landing Page MVP (smoke test): a simple page describing the intended product and its benefits, with a call to action: join a waitlist, pre-order, submit an inquiry. A customer's willingness to leave an email address or pre-order is a far stronger signal of interest than a positive answer in an interview. Saying "I like it" costs nothing, but leaving contact details is already a small commitment.
Single Feature MVP: a functionally limited version of the product that implements just one key feature: the one that directly addresses the most serious problem identified so far. Everything else gets built only once that single feature is proven to actually help people.
Video MVP: a demonstration of the intended functionality without any technical build at all. The best-known example remains Dropbox's original demo video: it pushed waitlist sign-ups from a few thousand to several hundred thousand overnight, before the product existed in any working form.
The trap called generative AI
Tools like Claude, Copilot, or Galileo AI can now generate a clickable prototype, or even working code, in hours instead of weeks. That's a huge advantage, but also a trap. The ease of building something that looks and behaves like a finished product today tempts teams to skip customer validation altogether. Development speed isn't a competitive advantage if the result is a well-built solution to the wrong problem. The second risk is quality: auto-generated code can carry security vulnerabilities or technical debt that becomes very expensive to ignore once a prototype is meant to turn into a live system connected to an ERP or production data.
How we approach it
Before we start building the final solution (whether that's an internal application, an AI assistant on top of company documents, or agentic process automation), we look for the cheapest form of MVP that can test the riskiest part of the assumption. For data-heavy or AI projects, that often means a clickable prototype or a limited single-feature pilot, rather than jumping straight into full integration with every system. It saves both sides time and money, and drastically reduces the risk of having to change direction a few months in.
Sources
- Ries, E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business.
- Maurya, A. (2012). Running Lean: Iterate from Plan A to a Plan That Works (2nd ed.). O'Reilly Media.
- Savoia, A. (2019). The Right It: Why So Many Ideas Fail and How to Make Sure Yours Succeed. HarperCollins.
