Build MVPs in 2 months…or better in 10 days
P.S. You can read my latest article now: What Exactly Is a Product?
Say you’re buying a new car. Would you simply go to a dealership, point at a shiny set of wheels, and say ”Sold!”? Of course not! You take the car for test drive first to make sure the investment you’re about to make is the right one. Building products is similar. You need to trial your ideas before going all in.
The best way to test products is with an MVP, or “Minimal Viable Product.” (Aside: Some people call MVPs ‘Minimum Feature Sets.’) MVPs give you the best possible initial ROI and validation that what you’re building is something customers actually want. Most of you likely know the term MVP like your ABC’s, but in case you don’t, here’s a definition: It’s the simplest product you can design, build, and release with the smallest possible time and money spent.
Simple doesn’t mean stupid, though. A broken, featureless site is not an MVP, it’s a badly built product. Rather, an MVP is a carefully constructed prototype and subset of your overarching product goal. It’s something you can build and release quickly to get a pulse on how your product resonates with the market at large.
Like tying cherry stems with your tongue, building an MVP is a lot easier said than done. Most people give in to temptation, adding features to their originally slim build. In doing so, they actually create a full product instead of an MVP. This is a huge pitfall; doing so means you might invest a ton of effort and income upfront, only to find your product is as palatable to the mass market as haggis.
“Like tying cherry stems with your tongue, building an MVP is a lot easier said than done.”
The best way to avoid this trap is simply to limit the time you give yourself to deliver your product. Three months to build isn’t bad, and two month is better, but neither is excellent. Instead, aim to build your product in ten days or, best of all, 72 hours! Building your product in three days is like surfing in the Pacific — invigorating and despite its challenges, incredibly fun.
To figure out what to complete in this short timeframe, boil your idea down to the bare necessities; find the smallest usable subset of your product that can be tested with ‘real customers.’ Check out this earlier article for strategies. Once your MVP is defined, build and launch it at cheetah speed. The earlier you can determine if you’re building a product people actually want to use (and pay for!), the better!
To keep you on track, here’s a short walkthrough of how to build an MVP the right way:
First, run a mini inception (more on that here) to get your team aligned on goals. Make sure everyone knows what you’re trying to achieve and how success will be measured.
“Define your MVP. Decide on the fundamental features and stick to them like fingers to super glue!”
Basics established, define your MVP. Decide on the fundamental features and stick to them like fingers to super glue! This doesn’t mean making to-do lists (good ideas stick in your head anyways). Instead, focus on executing. You either build something or you don’t. There’s no need to get bogged down in microscopic details.
However, don’t think you can just build in a mish-mash manner, however. You do need a structure. Define and manage your team’s priorities on a day-to-day basis by holding standup meeting every morning. A key ingredient in agile project management, standups are quick, informal team catch-ups that last 5–10 minutes max. With everyone standing (yes, literally) in the same space, have each team member talk quickly about their yesterday’s accomplishments and today’s goals. As you listen, look for where you can help your team collaborate, as this will foster greater productivity.
“Thorough your build, focus will be your kryptonite.”
Thorough your build, focus will be your kryptonite. Ward off distractions like they’re death. A great tool for doing this is stop limits. Build them into your plan so you don’t fritter away too much time on unimportant things. In addition, don’t let new ideas creep onto your features list unless they 100% block your initial MVP launch. If you do find a add-on feature you feel is mission critical, work it into your MVP only if you can move another less-important feature to the technical backlog.
Now that we know how to do MVPs right, let’s examine what not to do as well. I’ve found the following to hold true:
Don’t rewrite your MVP on new technology stacks unless you physically cannot launch your MVP without doing so.
Also for sake of simplicity, opt to hire 1–2 developers local to your country instead of a 30-person team from overseas. Mo’ people, mo’ problems, folks. A small group of local developers will get the job done and will do it well.
Once you have your team, keep them efficient and happy by defining your priorities and sticking to your plan. Frequently changing priorities wastes development time and reduces your team’s efficiency.
“Building an MVP requires you stop strategizing, zero in on tasks, and get your hands dirty.”
Last, did I mention stick to your original requirements? I might as well do so ten more times because it’s that damn important. Put on your blinders, and go. Building an MVP requires you stop strategizing, zero in on tasks, and get your hands dirty. The result doesn’t have to be perfect, but it does have to work, and buckling down is key.
Once the work is done, break out the champagne and ship your product! But don’t panic if only three folks use your MVP. Growing big usually takes a long, long time. It took 3 years for Airbnb to go from one listing to 50,000. Plus, clean exponential growth graphs — you know, those ones you see from other startups — are usually cleaned up. Growth actually slides up and down depending on seasonal effects and other factors.
Startup life is, and always will be a roller coaster. Your ideas may be regaled or rebuffed. You’ll be thrown for loops you didn’t see. Your company will float through highs and lows. But if you focus on building a lean, mean MVP, and you’ll be able to ensure that your ride is much more worthwhile.
If you enjoyed reading this, please login and click “Recommend” below.
This will help to share the story with others.
Follow me @matthiaswagner
Thanks to Victor Mathieux, Kate Larsen and Hannah Rothstein for helping with this.
