"Do I need a prototype?" "Should I build an MVP?" "How do I convince investors?" "How do I validate my idea before spending months developing it?" At first glance, these appear to be unrelated problems, each requiring its own answer. In reality, they all stem from the same underlying challenge: how do you help someone understand your idea before you've built the product?
That "someone" could be an investor deciding whether your business deserves funding. It could be a potential customer deciding whether your solution is valuable. It could be a technical co-founder evaluating whether the product is feasible to build. Or, surprisingly often, it could be you. Many founders don't realise that they themselves haven't fully understood their own idea until they try to represent it outside their head.
This is why I rarely answer the question exactly as it is asked. When a founder says, "I need a prototype," I mentally translate that statement into something more useful.
You don't need a prototype. You need someone to understand, evaluate or believe in your idea. The prototype is only one possible way of achieving that.
That shift in thinking changes everything. Instead of debating whether you need a prototype or an MVP, you start asking a much more productive question.
What decision am I trying to help someone make, and what is the smallest artifact that helps them make it?
Once you answer that question, choosing the right approach becomes surprisingly straightforward.
Why Explaining an Idea Is Harder Than It Looks
One recurring observation has stayed with me throughout my career. Even when I felt I had explained an idea clearly, I often discovered that different people had walked away with completely different interpretations. Initially, I assumed I needed to communicate better. Over time, however, I realised the problem wasn't simply about communication skills. It was something much more fundamental.
Whenever we explain something verbally, we leave gaps. Those gaps are unavoidable because language is an abstraction. We describe the important parts and assume the listener will infer the rest. Unfortunately, everyone fills those missing pieces using their own experiences, assumptions and mental models. As a result, two intelligent people can listen to the exact same explanation and imagine two very different products.
A simple analogy helped me understand why this happens. Imagine a children's connect-the-dots puzzle. If the dots are placed far apart, every person will draw slightly different curves while connecting them. The final pictures will resemble one another, but they won't be identical because each person has interpreted the missing spaces differently.
Now imagine another puzzle where the dots are placed only a few millimetres apart. There is very little left to interpret. Almost everyone reconstructs the same picture because there are far fewer opportunities to make assumptions.
This is precisely the difference between telling someone about an idea and showing it to them. A visual artifact—whether it is a sketch on a whiteboard, a simple wireframe, a clickable prototype or even a rough AI-generated concept—dramatically reduces the number of assumptions other people need to make. It doesn't make your explanation more persuasive. It makes it more precise.
A Prototype Is Not a Smaller Version of the Product
One of the biggest misconceptions I see among founders is the belief that a prototype is simply an incomplete product. That mindset often leads people to ask whether they should skip directly to building an MVP instead.
I think that framing misses the real purpose of a prototype.
A prototype is not a development milestone. It is a decision-making tool.
Its purpose is to reduce uncertainty before expensive commitments are made. Sometimes that uncertainty exists in the minds of investors who are trying to understand the business opportunity. Sometimes it exists in the minds of users who are deciding whether the product solves a meaningful problem. Sometimes it exists within the development team, who need clarity before writing a single line of code.
And sometimes the greatest uncertainty belongs to the founder.
Ideas have an interesting characteristic. The moment they are born, they begin to feel personal. We become emotionally invested in them long before they have earned that investment. We naturally start looking for evidence that confirms our thinking instead of evidence that challenges it.
Creating a prototype changes that dynamic. The idea is no longer trapped inside your imagination. It becomes something tangible that can be questioned, criticised and improved. Quite often, founders discover weaknesses in their own thinking simply because they were forced to represent the idea visually for the first time.
That's an incredibly inexpensive lesson compared to discovering the same flaw after months of development.
Do You Need a Prototype or an MVP?
This is probably the most common question founders ask, but I don't think it has a universal answer. The answer depends entirely on the decision you're trying to support.
If your goal is simply to help investors understand your vision, a well-constructed clickable prototype may be more than enough. Investors aren't always evaluating your engineering capability. More often, they're trying to understand the opportunity, the problem you're solving and the clarity of your thinking.
If your objective is to validate a user journey, static screens or a clickable flow may provide all the evidence you need. Users can often tell you whether a process makes sense long before any production code has been written.
On the other hand, if you're trying to demonstrate technical feasibility, scalability or your team's execution capability, then a working MVP may become necessary because those questions simply cannot be answered using a prototype alone.
Notice what changed.
We didn't begin by asking whether you needed an MVP.
We first identified the decision that needed to be made, and only then selected the smallest artifact capable of supporting that decision.
The DICE Framework
Over the years, I've found that the decision is usually much simpler than founders make it. Before asking whether you need a prototype, an MVP or something in between, work through these four questions. They help you focus on the outcome you're trying to achieve rather than the artifact you think you need.
-
D — Define the decision.
What decision are you trying to help someone make? Is it to secure funding, validate an idea, gain user feedback, align your team or test technical feasibility? -
I — Identify the decision-maker.
Who needs to make that decision? An investor, a customer, a developer, a co-founder or perhaps even you. -
C — Clarify the uncertainty.
What information is preventing that decision from being made? Until you can clearly articulate the uncertainty, you'll almost always build more than you need. -
E — Execute the smallest artifact.
Create the simplest artifact that removes the uncertainty. It could be a sketch, a whiteboard drawing, AI-generated screens, a clickable prototype or a working MVP. The artifact isn't the goal; it's simply the quickest way to provide the missing evidence.
Start with the decision, not the deliverable. The right artifact usually becomes obvious once you've worked through the DICE framework.
Learning Before You Start Building
A few years ago, I worked with founders building a procurement platform for Resident Welfare Associations. The product brought together multiple vendors selling hardware, sanitary and maintenance supplies through a single platform. Like most early-stage startups, they faced a familiar challenge. They needed to explain their vision to different stakeholders while simultaneously validating whether they were heading in the right direction.
Some conversations were supported using simple static screens. Others used clickable prototypes. As the product matured, parts of the experience were demonstrated using an early MVP. Looking back, I don't think the interesting lesson was which artifact was shown to whom. The important lesson was that they never relied solely on verbal explanations. Every significant conversation was anchored around something people could see, question and react to.
That allowed the founders to receive meaningful feedback long before substantial development costs had been incurred. Users questioned workflows. Stakeholders highlighted assumptions. Conversations became more concrete because everyone was discussing the same thing instead of imagining different versions of the product.
This is one of the biggest advantages of prototyping. It transforms opinions into observations. Instead of asking people what they think about an abstract idea, you're asking them to react to something tangible. The quality of feedback improves dramatically because people are no longer responding to imagination; they're responding to an experience.
The Earlier You Learn, the Less You Spend
Every change made during product development carries a cost. The later that change happens, the more expensive it becomes. Changing a sketch takes minutes. Changing a clickable prototype may take a few hours. Changing production software could involve redesign, engineering effort, testing, deployment and customer communication.
This is why I see prototypes as a form of failure prevention rather than merely a design activity. Their purpose is not to make the product look attractive. Their purpose is to expose mistakes while they are still inexpensive to fix.
Sometimes those mistakes are usability issues. Sometimes they reveal gaps in the business model. Sometimes they expose incorrect assumptions about user behaviour. Occasionally they reveal something even more fundamental—that the problem isn't important enough for anyone to care about.
Founders often worry that discovering these things early means the prototype has failed.
In reality, the opposite is true.
A prototype that prevents you from building the wrong product is far more valuable than a product that teaches you the same lesson six months later.
The goal isn't to prove your idea is right. The goal is to discover whether it deserves further investment. Every assumption you validate before development reduces risk. Every incorrect assumption you uncover saves money. That is why the question should never be, "Should I build a prototype?" The better question is, "How cheaply can I discover whether I'm heading in the right direction?"
One Principle Solves Most Early-Stage Questions
Over time, I've found that many of the questions founders ask have the same underlying answer.
- How do I explain my startup idea? Create the smallest artifact that allows someone else to understand what you're building.
- How do I validate my product idea? Create something that users can react to before investing heavily in development.
- Do I need a prototype? Only if it helps remove an important uncertainty.
- Do I need an MVP? Only if the uncertainty you're trying to remove requires working software rather than a simulation.
Notice that none of these answers prescribe a specific deliverable. They all begin by identifying the decision that needs to be made. Once that becomes clear, choosing between a sketch, a wireframe, a clickable prototype or an MVP becomes much easier because each serves a different purpose.
AI dismantling the Barrier
One significant change over the past few years has nothing to do with the purpose of prototypes. It has everything to do with how easily they can be created.
On two recent engagements, founders arrived with AI-generated product concepts before any design work had even begun. These weren't polished deliverables, nor were they intended to be. They were conversation starters. They illustrated workflows, surfaced assumptions and helped us discuss the product at a level that would previously have required days of design effort.
That shift is important because it removes one of the biggest historical barriers to prototyping. Founders no longer need specialised design skills to externalise an idea. They can generate rough concepts, refine them through discussion and arrive at a much clearer understanding before investing in detailed design or engineering.
The principle hasn't changed.
Only the cost of creating an artifact has.
As a result, there are fewer reasons than ever to delay learning.
Final Thoughts
Founders often believe they need to build before they can communicate. In my experience, the opposite is usually true. You need to communicate effectively before you can decide what deserves to be built. A prototype is simply one of the fastest ways to achieve that because it reduces ambiguity, improves feedback and allows everyone—including the founder—to make better-informed decisions.
So the next time you find yourself asking whether you need a prototype or an MVP, pause for a moment and ask a different question.
What is the smallest artifact I can create that helps the next person make the next important decision?
More often than not, the answer to that question will save you both time and money while giving your idea its best chance of succeeding.
