When is a Product “Viable”? When it’s Finished

Why you need not worry about building an MVP.

An unfinished car at an assembly line — Image generated with AI by DALL-E.

Popular refrain says that you should launch a bare-bones “MVP”, or “Minimum Viable Product”, before the finished, fully-featured version. An MVP, the thinking goes, could get you valuable real-world feedback and allow you to make adjustments accordingly.

The problem is that in order for a product to be viable, it needs to be useful. The solution needs to be a good fit for the problem at hand. If a product is unfinished, it doesn’t fit. Once it fits, it is finished. There’s no stage inbetween.

People just won’t put up with half-finished work. Chances are that the feedback that you’ll get is exactly about the loose ends that you chose to leave unresolved.

So do not worry about building an MVP. “Viable” and “finished” make a distinction without a difference.

Stay informed of new posts?

If you change your mind, you can unsubscribe at any time. You will not be spammed, and we will keep your email address private.

Article index

Scrum: A Scrum Koan; A Daily Scrum Koan; Scrum and the Road to Enlightenment; The Developer who did Everything Right; The Pathway to Heaven is Paved with Thoughtful Questions; A Story Point Koan
Communication: A Developer’s Guide to Collaborative Communication; On The Law of Demeter and the Power of Nuanced Discourse; Marshall Rosenberg and the Angry Luthier
Security: A Lightweight Information Security Management System (Part I) ★; A Lightweight Information Security Management System (Part II) ★; A Lightweight Information Security Management System (Part III) ★
Project management: In Praise of the Messy Development Cycle; Lost in Translation? Build a Project Dictionary; Why the Project Trilemma Doesn’t Apply to Application Development; The Importance of Marrying the Right Project Management Tool; Zen and the Nature of Flow; The Nature of Flow; Stop Asking for Estimates; The Art of Creating More Value With Less Work; How to Achieve Flow in Software Development; A Student and her Tardy Teachers; Zen and the Contest of the Two Teams; A Game of Okaloa Flowlab; A Game of Prisoner’s Dilemma; How to Reduce Lead Times; Why Two is a Great Team Size; How to Turn Around a Stalled Development Process
Technology: A Return to Simplicity
Collaboration: An Inquiry into Liberating Structures (part I) ★; Zen and the Paradox of Liberating Structures; Exploring the 1-2-4-All Micropattern (An Inquiry into Liberating Structures, part II) ★; Scattered to the Four Winds; Exploring The Nine Whys (An Inquiry into Liberating Structures, part III) ★
Testing: Specification by Example for Reluctant Product Managers ★; Software Testing for Reluctant Product Managers ★; Why You Need a Staging System for Acceptance Testing, and How to Set It Up; Don’t Use Consumers (or Users) as Guinea Pigs; Beethoven, Obama, and the Perils of A/B-testing; Zen and the Art of Rubber Duck Debugging
Design: The Masterpiece; Design as an Emerging Property of User Needs; Zen and the Case of the Blue Roses
Legal: Dev Agencies, Drop the Fine Print! It’s Plain English That Reluctant Product Managers Need
Off-topic: My Festive Season’s Wishes to all Reluctant Product Managers
Business: Zen and the Art of Gambling; The Sunk Cost Fallacy in Software Development; How Cost of Delay Improves Investment Decisions; Zen and the Discovery of Cost of Delay; The Sorcerer and the CFO; Zen and the Nature of Ideas; Zen and the Confident CEO
Science: A Guide to Understanding Scientific Studies (part I) ★; A Guide to Understanding Scientific Studies (part II) ★; Beware the Man in the White Coat: A Guide to Understanding Scientific Studies (part III) ★; Zen and the Art of Listening; The Story of the Little Fact
Hiring: How to Find Great Developers
Contracting: How to Minimize Vendor Lock-In as a Reluctant Product Manager
Marketing: SEO (Mostly) Doesn’t Matter. Focus on the Audience Instead (Part I); SEO (Mostly) Doesn’t Matter. Focus on the Audience Instead (Part II); The Three Shoemakers
Philosophy: Zen and the Principles of Construction; Zen and the Lazy Workers’ Boss; Zen and the Three Door Problem; Zen and the Art of Decision-Making; Zen and the Overzealous Student; Zen and the Feelings of AI; Zen and the Complaining Students; Zen and the Quest for Truth; The Tradesman’s New Kimono; Zen and the Meaning of Why; Zen and the Art of Collaboration; Zen and the Nine Whys; Zen and the Perils of Micromanagement; Zen and the Nature of Quality
Books: The Books on the Reluctant Product Manager’s Bedside Table
Product management: When is a Product “Viable”? When it’s Finished
Risk management: Don’t be a data hoarder; Why the Risk Matrix is Broken – and What to use Instead
Domain modeling: Zen and the Shopkeeper’s Enigma