- Keep stripping away to get to the core value for your users
Start with a giant backlog of user outcomes by all means, but go through multiple rounds of prioritisation with all your stakeholders during the project - the more eyes you get at this stage, the better. Keep driving people back to the product vision, and make sure you get at the key idea that makes your product special. Ben Horowitz was (as usual) on the money when he wrote: ‘If you had a noisy car you might ask for a louder stereo, but you would probably be a lot happier with a quieter car’. If you can identify the key needs that will make your product compelling for your users, then you have started out right.
- Once you have got your MVP nailed, make sure people know it
The second step is to zoom out, and check that everyone agrees with what the MVP actually is. It is all too easy for the different people involved - from the team, to end user champions, to senior stakeholders - to have different conceptions of what will be built and released. An awesome way to keep everyone aligned is with interactive prototypes and straightforward spikes (a ‘spike’ being the simplest thing you can program that will convince you you are on the right track). People are visual creatures: showing them what you plan to build and release is going to be far more effective at keeping everyone up-to-date than words in a product vision document.
- Roadmapping will help you reassure people whose priorities didn’t make the cut
So, now what do you do with all the stories that didn’t make your MVP candidate? Some you may well want to use to develop your product in the future; consequently, it is important to show how these potentially useful stories and features will be iterated into the product after the MVP. A clear roadmap should explain how a series of development cycles - with regular releases - will continue to deliver valuable, working software to your users. This will go a long way to reassure those who might otherwise be inclined to recommend an old school, two-year development and release project cycle.
- Make sure senior business sponsors can sell your vision
You are going to need support to ensure your MVP reaches the escape velocity required to launch it quickly, and launch it well; it takes a lot of effort. Once the product is a living, breathing thing that people love, it will gain its own momentum. However, until it reaches that point, you will have to keep selling it over and over (and over) again. This will be easier if you can get senior sponsors on your side early, who really get what you are trying to do and will champion it with you.
- Deal with technical risk ASAP: make life easy for yourself and the team
Integration. A word to strike fear into the hearts of even the most seasoned product team. It’s difficult, time-consuming, costly and draining. But not always, if you focus on it upfront. Get documentation, get existing APIs, and spike your way through the unknowns. Starting out on a new product is challenging because the scope, user landscape and technology might all be in question. At this point, listen to your team - and allow them to test those technical risks before committing blindly to the features that could be affected by them.
- It may not do everything, but what it does, it does really well
An MVP, by its very nature, will not deliver all of the functionality that everyone wants. So as you approach your first release, make the quality’s high. Most of the end users will want the MVP to do more than it does. Their thresholds for inconvenience or outright failure will be lower than for a product with a full feature set. In other words, it is crucial that what is delivered works really, really damned well. Otherwise, you can go ahead and scrap those beautiful roadmaps - because you will have lost before you have even really begun.
- Go live! (But remember you have to support this thing)
So you have released your MVP, and it is a success! Congratulations. But there is one final tip that we learned from experience: get the support level right. As you go on developing this product for the next release, you must maintain that first iteration. Plus, it will be easier to decide between either a) working on the ‘crucial new feature’ or b) fixing that ‘urgent bug’ if you’ve agreed the priorities with key product stakeholders upfront.
Of course, all of the above breezes over the near-daily anxiety attacks you are suffering because you really believe in this product and the deadlines are looming and nobody seems to get the product vision (the senior people who wrote it included) and everyone seems to think it is going to be perfect when it goes live in just nine weeks...But then the fun lies in experiencing that terror first hand. Right?
