Definitions for Demos, MVPs and Full-builds to help you determine which one your startup needs
Word definitions are really, really important. When I ask the barista for my “large cold-brew, no milk and no sugar” each morning, 2-minutes later I’ll have exactly what I asked for. The reason that works isn’t because they are a barista or I am a cafe patron. It’s because both they and I hold the exact same definitions for every word spoken in my order — of which the word-order matters.
Coffee beverages have been around for a long time; tech startups have not. Many of the words that get used in tech to speak about marketing, sales, and product are newly minted. Merriam-Webster doesn’t even have definitions for many of them. Most likely, your customers and colleagues don’t either. For those that do, it’s a Hail Mary to assume that their definition closely mirrors yours.
In my line of work, I speak at length with roughly 10 entrepreneurs every week. They come to my company for help at turning their ideas into working software products. In our meetings, they say a lot of words about their idea. After that, I ask a lot of questions to ensure I understand — as much as possible — what they said. Essentially, I spend a majority of my working-hours making sure us and our clients know what the hell each other is talking about.
Demos, MVPs, and Full-products
A constant source mis-alignment and mis-understanding between my clients and I arises when the words Demo, MVP, and Full-product get used. That mis-alignment and mis-understanding is not because my clients have wrong definitions for each of these words. Instead, it’s because almost every client I interact with has a different definition for these words. As a result, these words are, respectfully, rendered useless.
So, a ritual that I’ve adopted in client discovery meetings is to proactively offer definitions for words and terms that, somewhat inevitably, end up getting used. This practice is tremendously useful, as ensuring that a common vocabulary is in place ensures that the most effective communication can take place. In short, the conversation becomes much more productive.
After seeing my own definitions for the words Demo, MVP, and Full-product — in the context of software development — lead to many productive conversations, I thought I’d share them. I hope you find them helpful. If not, I hope you feel reassured in your own definitions!
Demo
“A non-functional asset that’s developed to assist others in imagining a product or service’s value.”
The reason people invest in building Demos is to help other people imagine the value that their product or service would provide if it were to exist or be purchased. The intended audience of a Demo can be an investor, customer, or employee. However, at its core, a Demo is first and foremost a communication tool.
A non-functional asset simply means that the actual asset that is the Demo doesn’t do what it’s intended to demonstrate. For a product that’s already built and working, a recorded video of someone using the product is a useful Demo. The video is the non-functional asset that — hopefully — helps customers imagine how the product could provide them value.
For products that are still just ideas, a clickable design built in InVision is a useful Demo. The clickable design is the non-functional asset that helps investors imagine what this idea could look like once materialized into a functional product that offers value to customers.
What this means is that a Demo is anything you develop and use to help others imagine how a product or service is valuable; while not being the product itself. Whether it’s a video, clickable design, or crude sketches in a Moleskine notebook doesn’t actually matter.
Minimum Viable Product (MVP)
“A product or service that provides the perceived-minimum of functionality required to communicate value that drives adoption from a target audience.”
There is a very famous sketch that’s often referenced when on the topic of MVPs. I’ve included it here:
At the risk of seeming curt, a skateboard is as much an MVP for a car as is a bottle-rocket an MVP for the SpaceX Falcon 9. However, the attitude of “I have a big idea, for which I will build a cheap and seemingly incomparable analog” is rampant.
The reason people invest in building MVPs is to mitigate their own risk of over investing in the development of something that their target customer doesn’t perceive value in. A great MVP is, actually, very difficult to pull off. Doing so is entirely dependent on the principal knowing exactly what’s important to their customer and building only that to a minimum point of usefulness; at the start of a company, most founders don’t have the knowledge to knowingly accomplish such.
This leads to the inevitable realization that an MVP actually has very little to do with your product. It has everything to do with your customer. The quality or efficacy of an MVP is solely attributable to whether it communicates value that drives adoption from a target audience.
An MVP has nothing to do with:
1) How much — or little–you want to spend.
2) How fast you want to get to market.
3) What small-percentage of your big vision’s features are included in a preliminary build.
It’s very difficult for product people to accept this, as it’s essentially saying that their customer is more important than their product and idea. However, if SpaceX’s mission is to shuttle passengers from Earth to Mars, their MVP isn’t a prop-plane route from San Francisco to the Nevada desert. Instead — maybe — it’s a working space-craft that’s just safe and comfortable enough to convince the early adopters that it’s worth buying a ticket and risking everything on launch day.
Full-build
“A product or service that exceeds the customer’s minimum-expectation through value-add features and benefits.”
Once again, this definition ties itself back to the customer as opposed to the product. It also positions itself as the step which succeeds the MVP, as a Full-build is an enrichment of the features and benefits that initially met the customers minimum-expectation. That is fundamentally different from simply developing “more cool features.”
This brings up an important point; it’s somewhat impossible to know whether a product or service is fully-built/mature unless it has first driven adoption as an MVP. The reasoning is that, unless the customer’s minimum expectations have been identified, it’s unclear what value they’re actually deriving from the product. At which point, added features and benefits might actually detract from the customer’s perceived value of the product, as they become confronted with options and interfaces that are irrelevant to them.
What is fortunate about Full-built products is that they are easier to accomplish than an MVP; after you’ve nailed an MVP! How so? Once you have adoption of an MVP, customers will hopefully start suggesting how the product or service can get better. These suggestions and feedback get filtered into your product road-map — taking significant priority over ideas brainstormed with internal teams. At that point, your customer is saying “the product has met my minimum-expectations, but here is how it could exceed them.”
Final Thoughts
As progressive and open-minded as the startup world is, it can also be very dogmatic. There’s a strong bias towards adopting something a prominent venture capitalist says during a talk — or a clever Tweet from the hottest unicorn’s founder — as gold-plated guidance for any startup under the sun. Particularly when the blogosphere re-words, re-publishes, and repeats it to feed the content monster.
That said, I encourage you to see that there is no way to approach building a business. Instead, there are many ways, each of which is very personal to the opportunity that you’re planning to capitalize on — and you. The advice/guidance received along the journey you should scrutinize, personalize, and then internalize; never just accept, no matter the source.
Why is this relevant? Because a lot of the popular opinion that surrounds how to approach building startups originated from thought leaders who — mostly likely — never built your business and grew their own years ago. It’s an unpredictable combination of available technologies and talent, alongside customer expectations and ever-shifting economic realities that create the complex challenges founders must solve. In short, had Uber been founded in 2000, 2010, or 2020, success would have required a completely different approach and team.
I hope that this article gave you some helpful ideas on product development, as well as introduced word-definitions for Demo, MVP, or Full-product that will lead to more productive conversations. If you have any questions or suggestions, please leave a comment below.
Thank you!