MVPs: A quick intro to dispel fear
"Don't worry, you don't have to build an app"
The first time I taught my Startups course I had a lot of students email me or come up for a chat in the breaks. Their questions all reflected a certain fear: that this was going to be more than they could handle.
I had told them this was a practical course and they would actually launch a business in the next 12 weeks. And even though I'd told them "you don't need to code or actually build an app or manufacture a product" they had clearly been worrying about what was expected of them.
So the next time I ran the course I added a quick 'detour' in the early weeks to introduce the concept of Minimum Viable Products, often referred to as MVPs, and to dispel misconceptions about them.
Below is what you need to know about MVPs at this early stage in your journey.
Before we get to that, a quick massive announcement: Book One is now live!
The Startup Guide
An insider's guide to winning startup weekends and hackathons
(If you have a paid subscription to this newsletter I’ll send you a code to grab it for $0.)
Writing the full, end-to-end process of creating a startup from scratch is/was taking a long time. So I made a slight detour to publish the first part of the journey as its own book.
The Startup Guide is a reference guide to cut through the complexity and hand you activities, templates and examples to give you an advantage in any startup weekend or hackathon.
As a startup advisor, award-winning teacher, hackathon facilitator and startup weekend mentor, I wanted to boil things down to easy-to-grasp essentials. You can refer to this guide when you're stuck, use the printable templates and activity guides for each step in the journey, or fling it across the room when you're frustrated.
Go ahead. Click I want this!
Back to your regular program.
Here is what you need to know about MVPs at this early stage in your journey.
1. MVP is an ambiguous term
MVP means different things to different people, and sometimes to the same people in different contexts. MVP has been defined as a product, a feature set, a proof-of-concept, a process, and a mindset. Some people focus on the "Minimum" (or Minimal); some the "Product", and occasionally the "Viable".
So when someone says "MVP" to you, check your assumptions about what they actually mean.
2. Someone else's MVP might be useful or worthless for your context
One of the famous MVP examples is Dropbox, which started with just a video imitating the functionality that Dropbox would enable, i.e. syncing files via the cloud. Many people saw the video and said "yes, please make that and you can take my money", so Dropbox was made for real.
You might hear that and it will spark something wonderful in your brain that is totally applicable to your business. Or you might think: "yeah, but that wouldn't work for me because…"
The point is not to copy what someone else did but to learn from their process.
3. The goal of an MVP is to learn
Much of what you've done so far has been to learn: to learn the right things, in the right amount, in a lean way. For example, learning about problems through customer interviews; or learning whether you're on the right track by showing customers some rough sketches of solution ideas.
Maybe you've run some experiments by now, too. For example: "If we post [this value proposition] in [this marketing channel] we will get a positive response [measured by X]."
An MVP is similar. It's not about launching a rough, lite-version product to the public. It's part of the process of learning what you should launch to the public.
MVP example: Flux Sports Rental
One of my student groups was working on a way for people to rent their unused sporting equipment out to other people. They had found people who wanted to rent out some equipment, and some people who wanted to borrow some equipment. So far so good. The next big question was: can we actually make this work?
To test this, they set out to match a renter and a borrower, complete the whole renting / borrowing / returning process, and receive payment and pass it on to the renter. The learning goal was to validate that their customers and users would actually pay money in exchange for the value provided; find out if they could make it happen; learn what it took to make it happen; identify the unknowns in the process; and get customer and user feedback on the process and experience.
Their MVP was all completely manual. They sent text messages to the renter and borrower to set everything up. The team joined the renter and borrower when they met up, took 'before' photos of the sports equipment (from memory it was a surfboard), and took the cash from the borrower and passed the renter's share on to them. Then the next day they met up with the renter and borrower again for the return of the surfboard: checked the condition of the surfboard was OK, refunded the deposit to the renter.
In order to learn as much as possible from the experiment they interviewed the renter and borrower about the whole experience and what they might change.
The point of me telling you this now is to reduce your fear about coming up with and building 'solutions' in the near future. You can put your enthusiasm and mental energy into learning more about your customers and their problems.
Have fun with it!