Project Management · 2026-05-09
Pretotyping, Prototyping, PoC or MVP? Choose the Right Validation Technique
Before you build an MVP, ask yourself: is an MVP even the right tool? From pretotyping to Pixar's storyboard method, discover four validation techniques that can save your project before it starts.
"If you are not embarrassed by the first version of your product, you've launched too late." — Reid Hoffman, founder of LinkedIn
The Evolution of Product Development
This is one of the most quoted principles in modern business and project management — and for good reason. The idea of starting small, learning quickly, and adapting has revolutionized how we approach product development. It sits at the heart of Lean Startup methodology, Agile philosophy, iterative development, and innovation practice worldwide.
Whenever you work on a project involving development, new business, new markets, or innovation — especially in an environment full of uncertainty and unknowns — it is key to ask yourself a few hard questions.
Especially if you are a business owner, or what we call a "Sponsor" in projects: the person ultimately accountable for the project idea and goal definition.
How do you validate an idea? How can you be sure your brilliant concept will succeed in the real world?
These are the questions we will answer across the next two articles. Let's start with the key concept — MVP.
What is an MVP?
An MVP — Minimum Viable Product — is the simplest version of a product that delivers enough value for early customers to use, while providing feedback for future development. It contains just the core features needed to solve the basic problem your product addresses. Nothing more.
The benefits of an MVP approach are well established:
• Validate your core assumptions with real users
• Minimize wasted resources on unwanted features
• Get to market faster
• Establish an early feedback loop with customers
• Reduce the risk of project failure
While MVPs offer tremendous benefits — and we will explore their potential downsides in our next article — even getting to the MVP stage requires significant investment. But what if you could validate your concept even earlier?
Tip #1: Know Exactly Why You're Building an MVP
Before rushing to build an MVP, ask yourself: what specific question am I trying to answer?
Different validation goals require fundamentally different approaches:
a) Testing a product idea — Will this concept work? How might it look and function?
b) Feasibility check — Can we technically build this? What would it cost?
c) User feedback — How will people interact with this product? What improvements would make it more valuable?
d) Market validation — Will people actually pay for this? At what price point?
These four goals may look similar, but they are not. A fitness app might be technically flawless — passing the feasibility check — but have a confusing interface that frustrates users, failing the user feedback test entirely. Meanwhile, users might love a streaming service's features during free trials, but refuse to pay the subscription price when asked — making the business unsustainable despite excellent UX.
Being crystal clear about your validation goal helps you choose the right technique — and might save you from building an MVP prematurely.
Pre-MVP Validation Techniques
Once you have defined your exact validation goal, ask yourself one more question: is an MVP actually the best technique for that goal? Are there other ways to validate — earlier, cheaper, faster?
The answer is yes. Let's explore four powerful techniques that can validate your concept before you ever reach MVP stage.
1. Pretotyping
Pretotyping was coined by Alberto Savoia, former Innovation Agitator at Google. It answers the most fundamental question of all:
"Would people actually use this if we built it?"
The beauty of pretotyping is its extreme simplicity. Instead of building anything, you create the illusion of a product to test market interest. Famous examples include:
The "fake door" test: Adding a button or link for a non-existent feature and tracking how many users click it. A software company might add a "Video Calls" button to their messaging app — when users click it, they see "Coming soon! Enter your email to be notified." This tells the company exactly how many users want that feature before writing a single line of code.
The "Mechanical Turk": Manually providing a service that will eventually be automated. Aardvark (later acquired by Google) tested their question-answering service by having humans manually route questions to appropriate experts — before building the automated algorithm. They validated the concept while learning how to build the technology.
Other techniques include the Pinocchio test, One-Night Stand, The Wizard of Oz, and more. Pretotyping costs almost nothing but can save you from investing in products nobody wants.
2. Prototyping
Prototyping creates a sample version of your product to visualize and test specific aspects of the solution. Unlike pretotyping — which tests market interest — prototyping tests design concepts and usability.
Prototypes range from simple paper sketches to interactive digital models. They help teams visualize solutions and gather feedback before committing to development. A mobile app prototype might simulate the entire user interface using a design tool like Figma, with no functional code behind it at all.
3. Maximum Virtual Product (The Pixar Method)
Pixar Animation Studios — the legendary company behind Toy Story, Finding Nemo, Up, and Inside Out — has revolutionized animation through both technical innovation and storytelling excellence. And their validation approach is one project managers can borrow directly.
Before expensive production begins, Pixar creates a complete virtual vision of the entire film: fully storyboarded, roughly animated scenes (even hand-drawn sketches), covering the whole movie from start to finish. This "Maximum Virtual Product" allows comprehensive review and refinement while changes are still cheap — before a single frame of costly rendering is produced.
Applied to other industries, this might mean creating detailed simulations or virtual walkthroughs of your entire product experience before building anything physical. The investment is in imagination, not infrastructure.
4. Proof of Concept (PoC)
The Proof of Concept is one I encounter frequently in real projects. It focuses specifically on technical validation — answering the question:
"Can we actually build this with our technology stack and resources?"
A PoC typically demonstrates that the most challenging technical aspects of your solution are feasible. Unlike a prototype focused on user experience, a PoC is often developed purely for internal stakeholders to prove technical viability. Before building a complex AI-powered application, for example, you might develop a small PoC that demonstrates the core algorithm works correctly with a limited dataset.
Proof of Concept vs Prototype vs MVP: The Key Differences
These terms often get confused, so let's make the distinctions clear. Proof of Concept vs Prototype: a PoC proves the solution can be built technically; a prototype shows how it will look and feel. Prototype vs MVP: a prototype typically has no working code behind it; an MVP is a real, functional product. Pretotyping vs MVP: pretotyping tests whether people want it before you build anything at all — it is the earliest and cheapest signal you can get. The earlier in this progression you can validate, the cheaper the mistake if you're wrong.
Tip #2: Your MVP Might Be Coming Too Late
These four techniques follow a logical progression of increasing investment and fidelity. Each step provides valuable validation while requiring less commitment than a full MVP.
Depending on what you are trying to validate, an MVP might already be overkill. Why build a working product to test market interest when a simple pretotype could answer that question? Why develop functional code when a prototype could validate your user interface?
Smart business leaders — and smart project managers — choose the right validation technique for their specific question, saving precious time and resources.
Remember: the goal isn't to build an MVP. The goal is to validate your concept in the most efficient way possible.
What's Next?
While these pre-MVP techniques can save you from building products nobody wants, the MVP approach isn't without its own challenges. In our next article, "Anti-MVP: When Minimum Is Too Minimal," we'll explore the potential pitfalls of MVP thinking and how to avoid them — including the infamous 90/90 Rule.