PoC vs PoV vs MVP

PoC, PoV, and MVP get blurred constantly — people use them interchangeably in the same meeting and quietly mean different things. That’s where projects go sideways: an engineer thinks they’re proving something can work, while finance thinks they’re being shown it’s worth funding. Same demo, two different expectations, one disappointed room.

The fix is simple. For each term, remember what question it answers and who it’s aimed at. Get those two things right and you’ll always know which one you’re actually dealing with — and you’ll stop talking past the people around you.

One thing always comes before any of them, though: before you trial a new tool or piece of software in a PoC or PoV, it has to clear a security review (the previous module). A pilot that touches real data is still using the tool, so security signs off first — then you pilot.

The three questions

Each term lives at a different point in the journey from “interesting idea” to “real product,” and each one raises the bar.

PoC — can it work?

A Proof of Concept answers a single technical question: is this even possible? It’s deliberately scrappy and usually throwaway. Nobody should care if the code is ugly or the data is fake — the only job is to prove the core idea isn’t science fiction. A PoC is aimed at engineers and technical decision-makers, and its output is essentially “yes, this can be built” or “no, here’s the wall we hit.” Polishing a PoC is wasted effort; it exists to de-risk feasibility as cheaply as possible.

PoV — is it worth it?

A Proof of Value assumes the thing works and asks the next, sharper question: is it worth the money and effort? This is aimed at budget owners — the people who decide whether to fund the next phase. A PoV speaks their language: real numbers. Forty hours saved per month, a 15% lift in conversions, three fewer support staff needed. A vendor running a PoV isn’t trying to impress you with clever technology; they’re trying to prove a payoff big enough to justify the cheque.

MVP — are we building the right thing?

An MVP (Minimum Viable Product) is the first version that’s small but genuinely usable — something real users can actually use to get a job done. Its aim is learning: you put it in front of actual users to discover whether you’re building the right thing before you build all of it. The “minimum” part trips people up. An MVP isn’t a half-broken product; it’s a complete-enough product that does one thing properly, so the feedback you get is real.

When someone says “is this a PoC or a PoV?”, they’re really asking: are we testing whether it works, or whether it’s worth it?

Using them in the right order

The natural order is feasibility → value → learning. First prove it can work (PoC). Then prove it’s worth doing (PoV). Then build the smallest real thing and learn from users (MVP). Skipping steps is where money gets burned: build a full MVP before checking feasibility and you might discover halfway through that the core idea doesn’t work. Skip the PoV and you might build something that works beautifully but saves nobody any time.

A quick scenario

A vendor pitches an AI tool that reads invoices. The PoC is a rough script proving the model can pull the right fields from a scanned PDF. The PoV shows it would save your finance team forty hours a month — enough to fund it. The MVP is a basic but working tool that five people in finance use every day, so you learn what they actually need before rolling it out wider. Same project, three different conversations, three different audiences.

Spot the stage

Read each situation and decide for yourself — PoC, PoV, or MVP? Tap a card to flip it over and check your answer.

Sort the scenarios

Drag each statement into the bucket it belongs to — or tap a chip, then tap a bucket. Hit Check placement when you’re done.

How to use it

In meetings, listen for which question is really on the table. If people are debating whether something can be done, you’re in PoC territory — and a slick business case is premature. If they’re asking whether it’s worth it, bring numbers, not a tech demo. And if someone proudly shows an “MVP” that does ten things badly, it’s fair to ask, “What’s the one thing it needs to do well for us to learn from real users?” Naming the stage correctly is half the work of running it well.