Software development · Minimum Viable Product

Software Prototype vs. MVP?

David Schwartz Multi-Platform (Desktop+Mobile) Rapid Prototyping + Dev, Tool Dev

May 21st, 2015

If you've ever been involved in a software startup, do you distinguish between creating a "proof-of-concept functional prototype" and creating an MVP? Why or why not?

EDIT: I'm assuming you'd create a static mockup first (eg., using notecards, PP, or Photoshop). Then you'd build a functional prototype to demonstrate proof-of-concept, effectively creating a more dynamic mockup.

Stephen Cataldo

May 22nd, 2015

Karen -- in my perspective, few startups actually aim towards mvp, as in viable -- but seems that you actually did, already, if you have a manual pilot that customers use and pay for, that is a great mvp, almost ideal.

I've also encountered "mvp" interpreted as less-than-desirable product, and it's wasting a lot of early startups time. A lot of the advice circling about the startup world seems dangerously over-preached: people latch on to terms, we ask questions like "prototype vs mvp" and wind up thinking there's a general good answer (though I think this question might have been asked more like a survey, which makes sense to me.) It's usually good to use your strong-suit early and pick projects that need your strong suit early, whatever works for other people: I might be coding an hour after I have an idea as a way to think about it; if you're hiring people who aren't partner-ish to build something for you, wait until you could practically do it waterfall style before coding. It seems really hard to iterate when you're hiring outside teams... a lot of the advice I hear seems to match funded startups with a CTO-type person who makes sure that the iterations can evolve with you, not wind up in the trash on each iteration; the advice also matches consumer toys, which are harder to survey than businesses that actually know what they need, so there's little choice but iterating. Most of the startups on FD seem to be trying to hire developers for projects, which is bad for iterating -- if you can't figure out what you want v1 to do, I don't know that I'd hire someone who couldn't see that through.

Ryan Nobrega Product, Technology, Operations

May 21st, 2015

Hi David, yes, I would use the following distinction: 

The goal of an MVP is to validate customer adoption while the goal of a Functional Prototype is to prove a capability and / or better articulate a concept.

To illustrate, an MVP may be lacking a critical capability (e.g., you may brute-force a critical tech component with a manual process until you can prove customer traction / justify the tech investment to prototype + fully develop) while a Functional Prototype may lack the key feature your customer is looking for (e.g., your key feature has a tech dependency which you need to isolate / prove you can develop before building out the rest of the MVP required for your initial release). 

Karl Schulmeisters Founder ExStreamVR

May 21st, 2015

of course there is a difference between a prototype and an MVP.  whether you build a mockup or not depends on a variety of factors

  • as Rob points out - your dev process.
    • If its just you and you lack dev skills - do a mockup
    • if its a relatively straightforward thing, start the MVP
    • if its more complex do some mockups
    • If its agile - part of your dev process is mockups
  • your financing
    • if you need to raise funds to build out the full MVP and market it- build the mockup
    • if you are self-financed and think you've got enough for an MVP - skip the mockup and save your $$
  • how well understood the user interactions with the product are
    • If its an incremental improvement or a new take on an existing idea - start an agile process for the MVP
    • if its a disruptive product - build at least a mockup of the UX and get feedback from users


Generally its a good idea to mockup at least statically your UX.  you can use something as simple as powerpoint.  And if you animate it, you can get user feedback in the form of questions of "will it be able to tell me X"...or "do Y".

that then helps with the dev cycle

Karen Leventhal

May 22nd, 2015

As a person newer to the tech field (a non technical founder), I've found these terms perplexing.   Here is what we did. 

1) notice a problem
2) do research
3) do lots of surveys
4) build a website that didn't have enough features to be considered an MVP.   
5) Stop using that website 5 months after it was built, because it had so little functionality that all is did was act as a glorified landing page
6) do a manual pilot, that allowed us to acquire initial customers and understand the problems involved at a granular level
7) go through an accelerator, do more customer validation interviews
8) come up with an mvp powerpoint deck 
9) do more surveys to pinpoint prioritized features


There seems to be a belief system, that you put up a basic, less than desirable product and keep doing iterations. Which is one way to do it.  It seems to me,  you can skip a lot of that, by doing customer validation manually or with interviews, so you know what people want ahead of time, before building anything. 

If I had to do it again, I would skip the thousands of dollars I spent building a interactive, half prototype and just put up a landing page and send out our powerpoint deck with mock ups. 

Ezra Smyser Web Developer at Squire

May 21st, 2015

I'd generally say that a proof-of-concept is about proving that the technology works, whereas an MVP has everything needed for at least a limited release. 

Rob G

May 21st, 2015

I think whether or not  you take the time and $$ to produce a dynamic prototype depends on what your skills are and what you are building.  I think (generalization here) that, for example, mobile apps where UI and UX take higher priority then i think building a functioning prototype makes sense IF you have the time and $$ resources.  Also, if you have the tech skills on your team certainly a prototype is more likely to make sense in terms of time and $$, but still most of the validation of product/market fit can and in IMHO should be done before any code is produced.  Again the approach to validating product/market fit can depend on what you are building, but if i can properly validate without taking the time and $$ to build (or pay someone else to build) a functioning prototype i will.  It's just faster and cheaper.  In my experience working with startups and incubators/accelerators, founders tend to stick within their comfort zones:  if the founder(s) is technical s/he starts cutting code and then goes out to validate product/market fit armed with a cool prototype. that's great. I think the "failure" rate is exacerbated by the fact that the majority of tech-only founding teams simply don't do product/market fit validation at all or not until they've spent months or years on development. I can't count the number of tech-only teams i've seen that are months into development without REALLY doing significant market/product validation.  Non technical founders, typically out if necessity, stick within their comfort zone and do product/market-fit validation before paying for development (and specs).  

Ryan Nobrega Product, Technology, Operations

May 21st, 2015

Hi David, wrt "wouldn't a dynamic mockup help reduce risk" - I'm a big fan of dynamic / interactive prototypes. Whether using a tool like axure or low-fi pencil + notecards, there's much you just can't get right from a static design when it comes to a great user experience that delivers on the core value proposition.

Wrt reducing risk, it helps with time to market (i.e., finding the issues after the paint is dry) and product concept / ideation by short circuiting the dev / iteration process for those issues and ideas you just don't see until you are interacting with the product.


Kathy Keating Techie that loves solving wicked problems

May 21st, 2015

When I build a POC, my goal is to convey the concept/idea of what is possible.  I typically don't build functional POCs.  While it might look to the casual user like something is really going on, behind the scenes everything is hardcoded to produce only what is necessary to convey the concept.  Very little of my POCs will actually be repurposed (reused) later. 

When I build an MVP, my plan is to build only the base set of functions that deliver only what a user would need to enable them to start to achieve the function of the product.  

My analogy to distinguish between the two concepts is to think about building the next great mode of transportation. 
  • A POC might look like this really cool vehicle similar to a car that would be all shiny on the exterior, have all these fake bells and whistles on it to convey what I'm envisioning.  When you look under the covers, nothing is there.  
  • However my MVP might be a fully functional hover-board that the user can stand on.
This is how I think about the difference between POC and MVP.  And I make sure my teams/business owners are all on the same page about what we're producing and why we're producing it. And what we'll be able to do (or not do) with it later.

Jackson Powell UI/UX Designer & Front End Developer

May 21st, 2015

How does one prove product/market fit without acquiring customers? From what I read above it seems like people are saying one can acquire and activate customers with an interactive powerpoint file, thus the distinction between a functional prototype and MVP.

For me, a functional prototype and MVP are the same thing since they both have the same objectives:
  • Test customer adoption
  • Rate customer satisfaction
A powerpoint, paper, or UXPin prototype is great for figuring out how the functional prototype/MVP will well, function. It can also be used to test business model hypothesis and customer assumptions, however until you actually get a user to give you something you haven't proved product/market fit in my humble opinion.

Rob G

May 21st, 2015

i do distinguish, but lately i've tended to skip developing prototypes in software opting instead for powerpoint or other mockup tool.  PPT is easier to build and modify.  After we prove product/market fit then we move to a software MVP (or even rev1).