Minimally Viable... Project?

This post originally appeared July 5, 2011 on BetterProjects.net


As I’m checking through my news feed, I ran across this great post from 37signals about what happens to user experience in a minimally viable product. This started me thinking… what would constitute a minimally viable project? Before we dig into that idea, what is a minimally viable product?
MVP, if you aren’t familiar, is an idea from the Lean Startup scene. In a nutshell, it means to do as little as possible so you can learn if you did the right thing or not. 
The first thing that comes to my mind about running a minimally viable project (I’ll refer to it as MVP from here on out, so don’t confuse it with MVP from the quote) is scarcity. This isn’t with a ‘do more with less’ management BS, but just an acknowledgement that the resources and ideas you do have are precious and should in no way be taken for granted. Lean Startups usually have very little money, and thus very little time, to create their product and get just enough customers to survive until the next round of funding comes in or until you get enough paying customers to sustain your company.

Sometimes projects start out with a surplus of resources, all of which are the wrong kind. When you’re trying to figure out what needs to be done, projects often suffer from a too many hands in the cookie jar syndrome. The opening in the jar, our project funnel, can only support so many people reaching into it at one time before fighting begins. In this situation, cookies may be in plentiful supply, if the jar is large enough, but cookie access is scarce. The more hands trying to access, the more scarce will be cookies outside the jar due to hands getting in each other’s way.

Starting an MVP requires having the minimum number of right resources to get the project off the ground. Any more or less of the wrong kind of resource and you are failing either the 'minimum’ or the 'viable’ part.

Another part of the Lean Startup process is a focus on using the tools you have available. Because of funding restraints, these usually end up being free, open-source software that the startup can acquire with little to no cost and can modify in any way they please. You don’t necessarily have the tool that is perfect for just what you’re trying to build, but you have tools that are good enough to get the job done now.

How many times have we waiting around to start a project because some piece of infrastructure or specific resources were unavailable? How frustrated did that make you? Yes, as I pointed out in the prior section, resource scarcity is a reality, but when you’re in an MVP situation, you do not let yourself be hindered by the lack of that exactly perfect resource. You do without, knowing that at some point you will likely have to scrap much of what you’ve done anyway. Why would you end up tossing what you’ve done away? That’s where we come to point #3 in the Lean startup.

Lean startups are all about iteration. The idea is to release quickly and often, get your customer’s feedback on what you’ve done and then make it better at such a rapid pace that before they can get bored with what you’re doing and move on. You constantly engage them with just enough progress that they stick around.

One of the things that often frustrates me is walking into a requirements review session knowing that its going to be two weeks until I see the revised document from the analyst. Yes, watching someone who is not computer savvy (or using a bad requirements management tool) attempt to update a document in real time during a meeting can be the definition of painful. When you’re with an analyst who can fly through the changes, its amazing how seeing the final revision take shape in front of your eyes changes your entire outlook on the project.

Does your organization practice MVP? Do you think its something that sounds nice but is best left to the realm of the lean startup? Let us know in the comments.
Mastodon