# PoC vs. MVP: We Won’t Agree

> A PoC validates a marketing or technical idea, while an MVP aims to acquire your first users.

- Author: Mathieu Eveillard
- Published: 2023-10-25
- Updated: 2026-07-08
- Tags: Product & Agility
- Canonical: https://www.mathieueveillard.com/articles/poc-vs-mvp/
- Translation (fr): https://www.mathieueveillard.com/fr/articles/poc-vs-mvp.md

![PoC vs. MVP: We Won’t Agree](https://www.mathieueveillard.com/articles/2023-10-25-poc-vs-mvp/poc-vs-mvp.webp)

Surprisingly, this is a passionate, even controversial, topic. But before we get to the heart of the matter, let’s agree on one thing: the minimal nature of the MVP. The idea is to get into production quickly in order to iterate—the very essence of Agile.

Hence my personal rule of thumb: **if you think your MVP is too small, it’s because it’s still too big**. Reid Hoffman, co-founder of LinkedIn, put it this way: “If you’re not embarrassed by the first version of your product, you’ve launched too late.” It’s hard to argue with that.

That said, I’ve noticed an almost universal confusion between PoC and MVP. Let’s clarify things, and to do so, as is often the case, we just need to listen to the words.

## PoC: Proof of Concept

A PoC is, in plain English, a demo. Its purpose is therefore to demonstrate the existence of a market (traction) or the technical feasibility of an approach, in other words, to validate an idea. Your goal is to determine whether it’s worth spending more time on the project, and once you’re convinced, to convince investors to back you. It’s common to conduct several PoCs over the course of a product’s lifecycle.

**A PoC is fast, messy, and intentional**. A few weeks of work at most; any longer, and it’s already something else. It’s “quick & dirty,” because you want to do as little as possible to get the most feedback. If mockups are enough to get feedback, go for it! Some vibe coding, why not? Or even better. But be careful: at this stage, the goal is to get answers, not to build an asset for your company. You don’t build on a PoC; you throw it away.

## MVP: Minimum Viable Product

The goal of the MVP is entirely different: it aims to acquire users. To do this, your product must enable users to accomplish a minimal Job To Be Done. The MVP must provide a service that, on its own, justifies adopting the product, or even outweighs the cost of switching if the user was previously using a competing service (an MVP is therefore, by its very nature, contextual: [it depends on the competition](https://www.mathieueveillard.com/articles/mvp)). But be careful: once users trust you, you won’t want to let them down; you’ll have to provide a real service, even if it isn’t perfect. You have a commitment to your users because you’re in production.

**The philosophy behind the MVP is therefore to do less, but to do it well, even very well**. Your product must be production-ready: it must handle security, errors, logs, redundancy, backups, monitoring, and so on effectively. The idea is to build user loyalty through a service that is not only useful but, if possible, enjoyable. Some even refer to it as the _Minimum Lovable Product_. Consequently, building an MVP requires months of work with a real team and adequate funding.

A best practice is to design a [“Walking Skeleton”](https://www.mathieueveillard.com/articles/walking-skeleton) as early as possible, by which I mean the technical foundations for modularity, architecture, testing, security, operations (CI/CD), and so on. This step is crucial for limiting technical debt and maintaining the ability to deliver quickly over the long term. After all, despite everything that’s just been said, the MVP remains a starting point, a foundation upon which you’ll iterate.

## Conclusion

You might not use the exact same words to describe these milestones in a product’s life cycle: 1. Validate an idea and 2. Acquire users. Nevertheless, these are very distinct goals, and confusing them could cost you dearly. Ask yourself the right question: What are you building?