We build lots of features for GSN.com. We do that with a surprisingly small number of folks. Our users play tens of millions of games on a daily basis. Our team consists of one designer, a product manager, four developers, two QA folks and a couple of Ops people. There’s a lot to manage and improve for those ten folks. That means we often have to make trade offs in order to get stuff out to production.
During a recent feature discussion session, we were debating whether we should go quick and dirty or build something “the right way.” I reiterated that the team was responsible for the end deliverable and that they have to stand by the decisions they make. I explained that they were empowered and required to do what they think is best for the business. Sometimes quick and dirty is the best way; sometimes it isn’t. One of the developers on the team had this to say, “I am trying to figure out when we do MVP and when we don’t.” That comment was innocent enough, but it really struck me.
The engineering team here at GSN had associated MVP with quick and dirty. Unfortunately, I suspect this isn’t unique just to our team. I suspect this comes from a deep seeded misconception that the basic principle of an MVP is about saving time. Additionally, there is a related misconception that a hacking something together saves time. Neither of these are really true.
The idea behind building a minimum viable product is to ensure that you and your team focus on the right things. It is a big waste of time to build something that people don’t find valuable. Building an MVP is a way to create a product that has just enough features to be able to tell if users will ultimately find enough value in your product to use it. If you spend six months building the most awesome and complete piece of software the world has ever seed, but users don’t really have a need for it, you have wasted six months. However, if you spend one month to build just enough of a product to get users’ feedback and subsequently determine that your users have no need for an integrated cheese making schedule, you have saved significant energy and money.
An MVP is about features, not speed to market. You build an MVP because you can never be sure what your users want or need until you get something in their hands. You do not build an MVP because you are pressed for time. Determining what features go into your MVP is not done by looking at a schedule and seeing who is available to do the work. Feature sets are determined by looking critically at the plan and deciding if each individual feature is truly required to gauge the product’s value.
Hacking something together is all about saving time (in the short term). To say that you have hacked something together says nothing of the features set. It does not mean that you have left things out or that you have determined that a specific feature isn’t really necessary after all. A hack is all about short term turnaround on delivery.
Hacks typically come at the cost of long term maintainability. In our conversation a few weeks ago, the discussion centered around whether we added a few if statements to existing pages (the hack), or took the time to break things down into more manageable and interchangeable chunks (the “right” way). We had a short window for delivery and we knew that the interchangeable chunks approach, while not an overly complicated task, would take more time. Both solutions however would provide the same feature set. Our decision was not “MVP or no MVP.” It was “hack or no hack.”
In the end, we decided to go the “right” way. We had enough time and we knew that the investment in cleaning things up now would pay off the next time around. More important than what we ended up implementing, however was coming to a consensus on how we wanted to build software. We want to build small and test things out before we put too much time and effort into a product, but we also want to invest in our future now. Sure, there may be times when we decide that a hack and the “right” way are the same thing. We may do things quick and dirty in order to get stuff our the door, but we will come back to them quickly and clean them up. Our rule can now be summarized as: MVP always; hack it as a last resort.