Anyone who has ever worked on a software product knows that the following is always true:
You will always have more features, ideas, and ways to improve the product than you will have time/budget for.
The following is also true:
No matter how many winsome MVP diagrams you encounter of happy stick figures riding skateboards that turn into scooters, that turn into cars, and so on; You will still find it exceedingly hard to make product choices.
Throughout the course of building any custom product you will inevitably have to say “No” to a seemingly countless number of great and obvious ideas. The truth is that building awesome, lean MVPs is difficult. The general concept of MVP thinking seems to make sense, but it is exceptionally hard to practice when the rubber meets the road. We need concrete practices to do it well. Here are some I have been learning.
#1 Don’t build what you don’t understand.
This might seem obvious, but I highly encourage you to be absolutely ruthless about this. If you really pay attention to it I think you’ll find that your features and stories will include things you only partially understand.
For instance, I was on a team building a multi-tenant application that launched promotional/engagement websites. In the administrative panel for the application we built fields for Launch Date and Allow Enrollment to control when the website would be available and if users would be able to fill out a form to create their own account. It seemed to make sense that these would be features of spinning up a website. The only problem is that we didn’t understand the full lifecycle of a site yet or how this overlapped with theming and content tools that we would develop later. We should have asked ourselves if we really understood the purpose of those fields. After a short reflection we would have realized that we didn’t, and accordingly should have tabled the “features” of spinning up the platform until we were clearer on what we needed to accomplish. To add insult to injury, the validation for these fields proved to be complicated and it felt like the goalposts were moving on us. This is the smoking gun that we didn’t understand it in the first place.
#2 Don’t be afraid to Concierge.
Can certain features you’re considering be done manually? Can you utilize a 3rd party tool to provide the feature in the background. For example: your application was originally conceived of as being able to email users directly and run basic campaigns. While it’s not ideal, you might actually be able to get away with exporting the list of users and sending periodic blasts from a tool like Mail Chimp or Constant Contact. What was originally probably months of dev work, can now be handled with a manual process and a SaaS subscription ($50–100/month). Keep in mind that this is a matter of scale. Certain features only make sense at scale. Which brings us to…
#3 Do the back of the napkin math.
This is especially important when considering the manual workarounds and concierge tradeoffs. You should do some rough math (don’t spend too much time on the math, you’ve got more important things to focus on) and compare the cost of developing a feature to the cost of handling it manually. It’s not hard to find things that can be handled with reasonable manual work for now. The feature won’t make business sense until you scale. If you are planning a small and quiet launch, you likely have features in your application that don’t make sense until you have hundreds of clients. When you just have 3 or 4, you can quickly use napkin math to see that certain features may take months to develop, but only really pay you back once you have a large user base/clients. A manual process that only needs to be done once a month for each client probably doesn’t warrant building feature sets that will take weeks. But if you are successful, you’ll know when the time is right.
Don’t kid yourself; you will face the temptation every day to either build things you don’t actually understand or don’t actually need (or wince sometimes both). Be disciplined about this. Saying no will often feel like you are building painfully simple things. That’s ok. Build it. Use it. Learn from it. Then plan the next features.
I have found these practices to be a reliable way to get us out of the circular conversations about whether or not a particular feature needs to be in the MVP or not. Too often, it’s easy to convince ourselves we need something (i.e. imagining a scenario in which we regret not building a particular feature). Imagining a possible future where you regret not building something is not a high enough standard for including it in a product. Following these concrete practices helps bring product decisions into sharp focus and should improve decision making.
