Minimum Viable Product
As a CTO, I try to focus more on the technology than the latest craze in entrepreneurship, but one of the things that has really resonated with me is the notion of the Minimum Viable Product. You can read more about it at that link, but here is the key part – “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
I think most software developers hear this and think “Oh, they want me to make a crappy slapped-together product”. That’s not really the case.
I just now realized this is a play on “You go”. Much better than Nova.
This hits a nerve with devs because they are almost always under some time pressure and often feel like they are being forced to cut corners in order to get the product out the door. However, I would make the case that the MVP is not software in the conventional sense that we are used to thinking about software.
I’m going to try an analogy. Let’s say you are hired to build a set for a 50’s era sitcom, set in bland, boring suburbia. The company wants you to build the house that will be used in the opening credits – showing the kids coming home from school, etc. This house is just shown in an exterior shot; all the real stuff will be done on a sound stage.
I’m so glad I don’t have to wear a tie to dinner.
In this case, what is your objective? Is your goal to build a house to code? Do you want this house to be able to last for 50 years? Should it be waterproof? Should it have a 200 AMP circuit installed?
The thing to realize here is that you aren’t building a house. You are building a “house”. In other words, you are building something that looks house-ish for a very specific purpose – to look like a house on camera. All of the requirement for a real house (code, longevity, etc.) are irrelevant. The only thing that is relevant is whether it looks like a house on camera. Now, there are some real house things you may want to do. For example, you may need to build the front steps to code because we are going to be doing a lot of shots of the kids bounding up the front steps. But that doesn’t translate to the rest of the house needing to be up to any code at all.
Now put yourself in the role of the studio hiring someone to build this facade. Which would you rather hire – a professional home builder, or someone who builds sets? Which one is more likely to be able to build the minimum thing I need?
The important thing to understand for devs building MVPs is that you are not building a house. You are building a set. The point of an MVP is not to be good software or elegant – it is to learn something quickly. You have to throw a lot of what you know about building software out the window, just like a professional home builder would have to ignore a lot of his training in order to build a movie set. Your software will be ugly behind the scenes, and that’s OK. In fact, it is wonderful. You will incur a lot of technical debt building the MVP, but that is fine. You won’t have to pay it back. This is what the “back” of your software should look like:
And don’t use those good 2x4s either. Do you think I’m made of money?
Here are some guideline I use when building MVPs:
If there is an existing library that does 90% of what you need to do for a particular function, figure out a way to adapt your product to use it.
1. Avoid writing libraries at all costs.
2. It is better to cut-and-paste code than get sucked into building a general purpose library.
3. Use the technology you are most familiar with. The people trying your software don’t care what language you use. You would be amazed by their lack of caring on this point.
4. You won’t need dependency injection. That helps with modularity and maintenance. You won’t be doing much of either of those things.
5. If you start to think “Wouldn’t it be cool if..” or “I bet the users would love to…”, then hit yourself in the head with a trout. The M is for minimum. You can do those things later once the users actually tell you they want those things.
6. Don’t create any kind of admin functionality for your software (unless that is what the users are going to use) Configure it with XML files or even just text files.
7. Don’t worry about documentation or comments. You aren’t passing this software on to someone else to maintain.
8. If you have extra time, spend it on metrics and data gathering, built into your MVP. Don’t spend it on making your software elegant.
9. Within reason, make sure your software works reliably. It is better to have something that is a little ugly that works, than something beautiful that crashes all the time.
10. Use iconfinder.com to find graphics. Don’t hire a designer, and for the love of God don’t do the artwork yourself.
But this leads me to a final guideline for any suits who happen to read this. Understand that the MVP is not a product, even though it looks like one. You might be able to convince people that a home on a movie set is real, but they won’t be happy living there. Plan to throw away your MVP and start over, building “real” software. On the plus side, all the stuff you learned will make this go a lot faster.
This is what happens if you try to move your MVP into production.
In software, we are very fortunate to be able to easily build MVPs. Imagine if the car industry could build a prototype car in a few weeks and let people try it out. They would love to be able to do that. An MVP is a fantastic tool for learning about your users, what they want and what they don’t. Just don’t mistake it for actual software, no matter how much it may look like it.