#27 - 5 Ways to Keep the “V” in “MVP”

Wednesday was a dark day. The most demoralizing and embarrassing in recent memory.

My friends and I are building a new social app and I believe deep in my heart that it’s going to change the world.

Which made what happened Wednesday all the more painful.

We put out our first MVP of the app in mid-Jan. My co-founder and I (the other dev on this project) promised our team and testers a new-and-improved version of the app every week. And every week, like clockwork, we’d go back to them, hat in hand, and say we need another week to get things right.

This Wednesday was finally supposed to be the unveiling of a major upgrade to the app. The culmination of hundreds of hours of dev time.

We built it, our team and testers downloaded it, and…it didn’t work. None of it. Most users couldn’t even get into the app.

I felt sad, angry, defeated. More than anything, I felt embarrassed.

Embarrassed that a simple mobile app has given me so many headaches. Embarrassed that everyone’s learned to not hold their breath when we say, “new build coming this week! Prepare yourselves!”. Embarrassed that the first time my friends are seeing me perform as an engineer, it’s an ugly sight.

I know on some level that this is how it’s supposed to feel. Startups are hard. Growth hurts. Things worth doing are often difficult to do.

But no, we’ve made too many boneheaded mistakes to let ourselves shrug this off as “part of the process”. We need to change our approach to building and iterating.

We need to put the “V” back in MVP.

A Minimum Viable Product (MVP) is the simplest version of your product that still provides upside for your users. By cutting out the non-essentials (a beautiful UX, advanced features, scalable systems and processes, etc.) you can release quicker and get real feedback from real users ASAP.

Here’s the trouble with how we (and many others) have been doing MVPs. We don’t focus on the “viability” of it.

For the purpose of this rant, we can boil “viability” down to one question: Does the product work? The small set of features you’ve chosen to include in your MVP should just. work.

The whole point of an MVP is to figure out if the product you’re building really solves a problem. To that end, you want your users reacting to your features, not your bugs. So make sure the damn thing WORKS.

I know this sounds obvious — real wisdom always does — but it’s an easy rule to violate if you don’t know what tactics to deploy.

So here are some reminders I’m writing out for myself and my team so we don’t step on the same rake. The last one is the most controversial, but it’s the one I feel most strongly about.

You’re testing hypotheses, not features.

I’ll say it again: The point of an MVP isn’t to verify that your features work. They already should.

What you’re testing are your assumptions. Is the product you’re envisioning the right solution to the problem?

Ask yourself: what needs to be true for us to feel confident we’re building the right thing?

Once you’ve figured that out…

Boil your MVP down to the 1-2 features that test your hypotheses.

The core functionality of our app involves sharing and replying to videos. So those features need to be in the MVP.

But you know what doesn’t need to be in the MVP? Push notifications. Database security policies. Profile photos.

We could have omitted all of that and so much more. In fact…

An MVP doesn’t even need to work end to end.

Our first MVP was an alpha that we just tested with our own team.

We didn’t need to have signup/signout capabilities or a group invite system. We could have taken a “wizard of oz” approach and done some manual work behind the curtain so our team could play around with the 2 features that really mattered.

Once you’ve gone through a couple of feedback cycles and know what users like and don’t like

Write tests for the stuff you keep.

I used to think tests were a huge waste of time in the MVP stage.

Your app’s evolving quickly, which means you shouldn’t waste time writing tests for code you’re probably going to throw out.

But it’s a double edged sword. Your app’s evolving quickly, which also means there’s a lot of potential for you to break important things with each iteration.

Once you’ve decided you’re keeping a particular feature around, invest some time into writing tests for it before you begin working on the next iteration.

And finally, the most important foot-gun to avoid…

Don’t set needless deadlines.

Early in Jan, we set a launch date of Feb 26. This wasn’t a “soft” deadline either. For a while, this was the date we were promoting to waitlisted users and potential PR partners.

A self-imposed deadline can be helpful if you need a kick in the ass to work harder. But our team doesn’t need that and I assume yours doesn’t either. We’re already burning the midnight oil, deadline or not.

Maybe a self-imposed deadline will force you to whittle down the scope of your product. Maybe it will inspire you to work more efficiently.

Maybe.

But for us, all the deadlines have done is force us to cut corners and build an app we aren’t particularly proud of right now. A great app is going to take as long as it’s going to take.

My first manager at Boston Dynamics once told me, “take the time you think a task will take to complete. Double it. Then double it again.”

No exaggeration, that heuristic has never been wrong for me.

Anyone will tell you that building a startup is both a marathon and a sprint. That’s been true of our experience so far.

So if you’re already running as fast as you can with no plans of stopping, then holding a stopwatch at the same time isn’t going to get you to the finish line any faster.

Quick reminder - If you appreciate my writing, please reply to this email or “add to address book”. These positive signals help my emails land in your inbox.

If you don't want these emails, you can unsubscribe below. If you were sent this email and want more, you can subscribe here.

See you next week — Rayhan