Start With A Make-Believe App
AKA, the Gospel of Product MVP
A frequently recommended book for all entrepreneurs is The Lean Startup by Eric Ries. It’s over 300 pages long.
It can, however, be summarised in four words: focus on your MVP.
If you already know what an MVP is, scroll to the end to see the three core things to keep in mind in order to focus on your MVP.
What is an MVP?
MVP stands for minimum viable product. It’s the simplest version of whatever you’re building, that’s still viable as a product.
Between my previous job at a digital agency in London, and working with an app development agency since starting Sound Off, I realised that even amongst the experts there’s a ton of confusion around what an MVP actually is.
Consider a mobile app. The MVP could be a set of Sharpie drawings, that you leaf through with potential users. Or it could be a super shiny clickable prototype built in Figma, like a glorified PowerPoint presentation with some more bells and whistles. Or it could be the first build of the app, coded and ready for beta testers to install. Or it could even be a landing page, which lays out the problem and has an email sign-up form.
There’s no right answer — it’s all about making the right trade-offs.
Sure, having a fully coded app means you can test it on real phones in as close-to-real scenario as possible, but it’s also expensive and time-consuming. Having a landing page is a cheap and fast to validate that you have potential users, but it doesn’t allow you to test the specifics of your solution.
The goal is to make sure that you are validating two hypotheses:
- there are users who have the problem that your product is solving
- those users would use ( / pay) for your product
This is called product-market fit. You want to prove that there is a non-negligible market for your product. Anything more you can learn from an MVP is an added bonus.
You can have different MVPs.
This often gets left out when discussing the early stages of a product lifecycle. But it’s so important to understand that I’ll type it out again, in bold.
You can have different MVPs.
Reading The Lean Startup and other entrepreneurship books might lead you into thinking that an MVP is one finished thing.
But we know that the whole point of an MVP is to learn that there exists a real problem and to establish product market fit. It’s not about finishing building something.
Focussing on what’s viable with the least effort, focusing on going lean is all about iterating faster, learning quicker, and having a short feedback loop. The quicker you can get a version of your product into the hands of real users, the quicker you can get feedback on it, and therefore the quicker you can improve it.
That’s where the benefit of MVP really comes into play. By figuring out how to invest as little time as possible to get something out the door, which is still a viable version of your product, you can get feedback quickly and get to the right product-market fit faster.
But I know what you’re thinking… what’s the most minimally viable version of the minimum viable product?
The answer: The concierge MVP. This is something I learnt about from taking part in a few Techstars Startup Weekends.
Here’s what it is…
The Concierge MVP
A concierge MVP is a version of your product where you manually guide your user through the solution to a problem.
Let’s take Airbnb as an example. Airbnb is fundamentally a matching problem: how do we match one set of users (who have spare rooms) with another set of users (who are looking for a room).
You can write lots of code to solve this problem, and display rooms nicely with photos, and filtering by price, and have a mobile app that syncs with a web app…
…or you can do it manually. People with rooms email you about their rooms. People looking for rooms email you with what they’re looking for. You, the startup founder, manually match them up.
To software developers, this might sound like sacrilege: it’s hugely inefficient and is begging to be improved in a ton of ways.
But doing this means you can quickly validate that (1) there are users, who have the problem you’re trying to solve, and that (2) your product solves that problem.
And in fact, this is what Airbnb did. Back in 2007, They set up a website, and successfully received bookings for rooms they listed, manually matching customers to rooms — all before they started building anything. They validated their assumption that certain people would be willing to pay to stay at someone’s house in lieu of a hotel. And the rest is history.
The First Sound Off MVP
As I wrote above, a product can have many different MVPs. The first MVP we made for Sound Off allowed us to test this assumption:
- Assumption: people will want to Sound Off
We knew we had a novel idea, and that the science-backed us.
But would people understand it? Would they find it valuable?
Early on in the process, before we committed to working on this idea, we ran a short test where friends made voice recordings about their day each day for a week. Afterward, we sent them a survey to fill out about the experience.
As we hoped, 75% of people felt calmer after doing so, and 100% saw the benefit of it and knew someone they would recommend it to. We learnt tons about the experience of sounding off, such as where people were most likely to do it, what time of day, what they talked about (in general) — and who our ideal users likely were.
We ran this test without building anything. People could just use their voice memos app on their phones like Rory did when he first started sounding off. This was the leanest version of our app imaginable, with no extra features, no special design, no branding — not even a name.
After this, we worked on other MVPs. We made tons of Sharpie drawings to block out the app flow and core features; we built clickable prototypes and tested them with users; this week, we’re even testing new daily audio content in the app — our MVP for that uses a Google drive folder where we manually drop in a new file each morning. All of these help us test and validate different assumptions, and learn more about who our ideal users are.
And we’re now working hard on app development, to get an MVP that’s a functional app which can be installed on your phone.
Dream Big, Start Small
Always keeping in mind that you’re working on a version of an MVP will serve you well.
This is something that goes beyond product development and the world of startups: it’s something to keep in mind with anything complex you’re working on.
- An MVP isn’t a finished thing. You can have different MVPs at different stages. These let you gain more and more confidence as you progress.
- A concierge MVP is a version of a product where you are manually doing the work that your product eventually will do.
- Label your assumptions explicitly, and work to validate them, starting with the riskiest assumptions first.
- Dream big… but start small.
What’s your favourite example of a startup starting lean?
Let me know in the comments.