The MVP — Minimum Viable Product — is the most talked-about and least-followed piece of startup advice. Everyone knows they should build one. Almost nobody actually builds the *minimum*. Most build the MDP: the Maximum Developer’s Pleasure — every feature they think is cool, polished to their standards, released six months later than necessary.
Let’s fix that.
—
## What “Minimum” Actually Means
An MVP is not a terrible version of your full vision. It’s the **smallest thing you can build that delivers the core value and generates real learning.**
The key question: **What is the one thing this product must do to be worth trying?**
Not the ten things. Not the five things. The ONE thing that solves the core problem.
For a project management tool: “Create a task and mark it complete.” Not “Create a task with dependencies, subtasks, labels, assignments, due dates, recurring schedules, and Gantt chart views.”
For an invoicing tool: “Generate an invoice and send it to a client.” Not “Generate an invoice with 12 templates, multi-currency support, recurring billing, late payment reminders, and integrated time tracking.”
The MVP does the ONE essential thing well enough that a real user can get real value from it. Everything else is a future version.
—
## Why Shipping Fast Matters More Than Shipping Pretty
Every day your product isn’t in front of real users, you’re building on assumptions. And assumptions are comfortable liars.
You assume people want Feature X. You assume the onboarding flow makes sense. You assume the pricing feels fair. You assume the core problem is what you think it is.
The only way to test assumptions is to put the product in someone’s hands. Real users do things you never expected. They ignore the features you’re proud of and love the thing you threw together in 20 minutes. They get stuck in onboarding steps you thought were obvious. They tell you the problem you solve isn’t actually the problem they care about.
This feedback is infinitely more valuable than six more months of solo building. The sooner you ship, the sooner you learn. The sooner you learn, the more likely your product succeeds.
**Ship fast, even if it’s messy.** Not broken. Not dangerous. Not embarrassing. But messy? Yes. Incomplete? Yes. Missing features you want? Absolutely. If you’re not slightly embarrassed by your MVP, you launched too late.
—
## How to Cut Scope (When Everything Feels Essential)
The hardest part of building an MVP is cutting features. Every feature feels essential when you’re the builder. Here’s how to cut ruthlessly:
**The “Will they pay without it?” test.** For each feature, ask: “Would my target customer still pay for this product if it didn’t have this feature?” If yes, cut it. If you’re not sure, cut it and see.
**The manual replacement test.** Can the missing feature be replaced by a manual process? Instead of building an automated email system, can you manually send emails for the first 50 customers? Instead of a search feature, can users scroll a short list? Manual processes don’t scale — but your MVP isn’t supposed to scale. It’s supposed to learn.
**The “launch blocker” filter.** Categories features into three buckets:
– **Must have:** The product literally doesn’t make sense without it. The core value proposition depends on it.
– **Should have:** Improves the experience significantly but the core works without it.
– **Nice to have:** Would be cool. Users might eventually want it. Not relevant for v1.
Ship with “must have” only. Add “should have” based on user feedback. Add “nice to have” only if data supports it.
**Time-box it.** Give yourself 2-4 weeks for the MVP. Whatever you can build in that time is your MVP. This constraint forces prioritization better than any framework.
—
## MVP Formats That Don’t Require Code
Sometimes the best MVP isn’t software at all. Before building, consider:
**A landing page with a signup form.** Does anyone even want this? If you can’t get signups from a description of the product, building it won’t help.
**A spreadsheet.** Many early-stage products can be simulated with a spreadsheet and manual effort. An expense tracker? Spreadsheet. A content calendar? Spreadsheet. A matching service? Spreadsheet and emails. It’s ugly, but it validates demand with zero development time.
**A concierge MVP.** You personally do what the software would do, for a handful of early customers. This gives you deep understanding of the workflow, edge cases, and actual customer experience before writing a line of code.
**A Wizard of Oz MVP.** The customer sees what looks like an automated product, but behind the scenes you’re doing everything manually. The customer gets value, you learn what they actually need, and you only automate what’s proven to matter.
These non-code MVPs feel wrong for developers. “I can build this in a weekend, why would I use a spreadsheet?” Because the goal isn’t to build — it’s to learn. If you can learn faster without code, code can wait.
—
## 🔨 Your Action Item: Define and Ship Your MVP in 2 Weeks
1. **Write down every feature you think your product needs.** All of them. Get it out of your head.
2. **Circle the ONE feature** that represents the core value — the single thing that solves the main problem.
3. **Put a deadline on the calendar:** 2 weeks from today.
4. **Build only the circled feature** and the minimum infrastructure to support it (authentication, basic UI, payment if it’s a paid product).
5. **Ship it.** Put it in front of 5 real potential users. Not friends. People in your target audience.
6. **Document what you learn.** What did they love? What confused them? What did they ask for that you hadn’t built? This is your roadmap for v2.
The goal isn’t a beautiful product. It’s a learning machine. Ship the minimum, learn the maximum, and then build what the market tells you it wants.
—
**CTA Tip:** The MVP is the hardest concept for developers to embrace because it requires shipping work you’re not proud of. Reframe it: the MVP isn’t your product. It’s a research experiment with a working prototype. Your real product is what comes after — informed by real-world feedback instead of assumptions. Build the critical features to deliver value. Ship fast, even if it’s messy. You can always make it beautiful later, but you can’t un-waste months building the wrong thing.
—
*Next up: What happens when the data says your current direction isn’t working? Sometimes you pivot. Sometimes you shut down. The hardest question is knowing which one. Let’s talk about pivoting.*
—
—