Should startups build a minimum viable product and iterate, or build a complete high-quality product before going to market?

Fabien Pinckaers · Feb 12, 2025

Building the entire product suite up front was risky but is the reason Odoo works today

It delayed monetization and salable product, but designing the big picture at once means everything is smooth and integrated rather than a patchwork of separate software

Scope: risk: two years before anything could be sold; judgment made in hindsight

8:01 20VC: The $5BN Company Built from the Belgian Countryside | The Story of Odoo: The Company with No Plans to Sell, IPO & Their Billionaire Founder Who Does Not Care About Money with Fabien Pinckaers, Founder & CEO @ Odoo

Jason James · Aug 29, 2025

You cannot run an MVP approach on a breadth-first product; a broad, full-life-cycle product requires a full build before going to market

With a dozen surface areas it's very hard to get everything to a sufficient quality level, so shipping an MVP-quality broad product underdelivers

Scope: drawn from building Daisy v1; they should have delayed going to market by six months to raise quality

14:03 20Product: Why Most CPOs are Bad | Why You Do Not Need PMs in a World of AI | Why the Design Stage is Dead and How to Use Vibe Coding to Replace It | The Three Roles All Founders End Up Firing on Repeat with Jason James @ Tezi

Noah Desai Weiss · Jun 16, 2023

The right way to test a big new product idea is to build a deliberately rough, ugly, unpolished internal prototype first and see if colleagues find it genuinely exciting before investing in refinement, polish, scaling and performance work

It surfaces whether the idea could change how people work before you spend on making it good, and you can then progressively scale it and watch daily/weekly retention and depth of usage

Scope: described as Slack's own playbook

32:52 20Product: Slack CPO Noah Weiss on How to Master Product-Led-Growth, The Biggest Mistakes Founders Make When Scaling Into Enterprise & What Needs to Change with your Product, Team and Processes when Scaling From PLG to Enterprise

Max Levchin · Feb 5, 2025

The right MVP practice is to ship rough prototypes for signal, then pull the product down and rebuild it properly once the data shows traction

You need cheap customer feedback to learn whether a crazy idea has odds of success, but leaving the rough version live means someone will build a better version if you don't

29:44 20VC: Affirm Max Levchin on Why Grading Talent by Letter (A or B) is Total BS | How to Create a Culture of Post Mortems and Writing | Why You Should Only Study Failure Not Success & The Biggest Surprises Scaling to $18.7BN Market Cap

Jason James · Aug 29, 2025

Launching a new capability at an A-quality level lets you leave it alone for roughly a year and move on to the next capability, whereas scrappy MVP/beta launches mire the team in fixes and slow down the next needle-moving launch

Time spent repairing half-built features is time not spent building the differentiating next thing

3:37 Invest in a quality launch to avoid repeated rework

Jason James · Aug 29, 2025

When you already have clarity on what customers want you should just build the full thing in one swing; customer involvement should be inserted mid-development only where you lack certainty

Accumulated customer learning gives varying degrees of clarity, and there are many points in the development journey (design, vibe-coded prototype, limited release) to bring customers in when ambiguity exists

4:35 Build full when clarity exists test with customers only where uncertain

Jason James · Aug 29, 2025

Whether to build an MVP or a full product should be determined by the thesis you're trying to test and what must be true to validate or invalidate it

Testing whether AI can be a labor capacity addition rather than an efficiency tool for human recruiters requires covering the breadth of a full human role

15:54 Build choice determined by what the thesis must prove

Cem Kansu · Jun 20, 2025

Extensive iterative prototyping should sequence core utility first, then engaging design, then polish — validating the core interaction before investing in looks.

You avoid spending months of build time before knowing whether the thing works at all; you validate the core, then do the other steps.

9:24 Sequence core utility before design and polish when prototyping new features