1. Minimal Viable Product thinking can be a trap – there has recently been a huge movement toward creating a “minimum viable product” and then going out to market as quickly as possible. I would argue it is important to temper this trend. This has turned into a tendency to quickly roll out half-baked functionality because developers believe they are following the MVP mantra. Well thought out features that deliver value, even if they take a bit longer to come to market, will (in my opinion) deliver more ultimate value to the product and to the user experience. I am all for iterating something early on once it is in the hands of the customer, but I would argue that some companies have misconstrued this and roll out an untested, half written piece of functionality
2. Keep an eye on what really matters – Many good product managers fight with this all the time. How many times do people from different lines of business ask questions like “wouldn’t it be cool if it could do this?”. When I really boil it down, there are only 3 reasons why you should build any given feature in an early-stage start-up. Here they are:
- It will help make money – If you are a start-up working towards break-even, then this needs to be ever present in every decision you make. If it won’t help move the needle and get you closer to profitability, you may want to reconsider it. I come from a school of thought in which you want straightforward business models with a straightforward path to cash. There are few out there with unlimited runways and you always need to be concerned with this in your approach.
- It will improve the user experience – User experience has become such a core function to any product manager. Is this easy to use? Do people get pissed off when they have to use key features on the site? Will it cause people to abandon your site? UX can be a core competency and key differentiator. Always focus on this! Even if it is as simple as a nicely done pop-up or a cleanly designed button, it all matters when it comes to UX.
- It will improve efficiency and scalability – Will this feature allow you to do more with less, does it allow you to hold off hiring more people to do the same function, or does it make the people you have more effective? You should always consider this to stay lean and mean as possible
3. Create a vision for the product – it is important to not limp forward from one feature to the next. This can be an easy trap to fall into. Having a tight 6-week development cycle is important, but having a grasp on what you want this thing to look like in a year or 18 months is important. This isn’t to say that you should wireframe the thing to death and do work for something that may or may not be built. Rather, have a feeling for what you want the experience to evolve into.
4. Beware the “Frankenstein” product – Every product manager should ask them this question on a regular basis. This ties in with the above point about product vision, but I generally find this can be more of a tactical problem. Does each feature compliment the next, is it tied together in a comprehensive UX flow or does it feel tacked on? “Frankensteining” new features into a product can be fraught with danger for the long-term health of a product. A good product manager needs to fight the urge to quickly throw a button into the UI to satisfy a line of business, but rather should look for a way to re-orient the UI. Sometimes you have to go a step further and actually yank or pull old functionality out to keep things clean. Pulling the bolts out of Frank’s neck can be painful but is sometimes necessary. It forces you to step back and refocus on your goals for the UX.
5. Know your customer, and then start to segment – it is very difficult to create a one size fits all approach. As you get new and different user groups you need to make a critical decision. Either try to serve all people with a reduced product or split the product up into different lines. Each are faced with their own set of products, you begin to fragment your offering. There is an argument to be made creating upgrade paths are a logical and allows power users progress to a rich feature set of products.
In summary, the role of a product manager is never easy. They are constantly getting pulled in 50 directions by constant and evolving requests. That said, if you keep these 5 core principles in mind it will make it easier next time you embark on building a killer product.
September 7, 2011
I replaced MVP with Minimum Viable Perfect. The change P makes it all very different.
I also think you have missed the role of people in the project management. Empowering people is central to managing projects.
September 7, 2011
I think that is a fair point, but then again I could write several chapters on the role that people and business needs/wants play on product management.
September 7, 2011
I like the principles. How do I convince the people paying the bills that they should also like the principles? I have found that principles 2a and 4 almost always go hand in hand.
As for 1, I’ve recently been putting out MVPs to find out if a project will even begin to have traction, and what features are most interesting. Sometimes it works, sometimes it doesn’t. I don’t have enough data points for the MVP to tell if I can get better products out without spending time on dead features.
September 7, 2011
Well, I am an advocate of iterative development. I am a converted waterfall guy, that said I always have a tendency to look at my iterative product through a waterfall development sphere if that makes any sense. While I am not going through the full process of building out something to the nth degree, still try to keep that in the back of my mind.
Regarding your points around 2a and 4. I think you need to have conviction and confidence on why you would draw a line in the sand to get things done. At the end of the day it just comes down to making a logical case why and why not to do something. If you can justify it using sound principles I say do it. It is never an easy process, but I would prefer to have knockdown drag out arguments about direction as opposed to spending 6 months building something that I know in my heart of hearts will fail.
September 7, 2011
Once you stop thinking about an MVP as a product, and start thinking about it as a learning and validation process, it gets easier. Of course, this only is truly effective when you are innovating with a fair amount of ruthless freedom, not building a deliverable with predefined expectations of success.
September 9, 2011
The MVP is being touted to show development progress rather than customer acquisition progress. Iterating even before the product is a recipe for failure but at times after seeing something tangible also gets cycles running.
September 13, 2011
It’s the first one about Product Management that I’ve read where it’s specifically about a web based product. I possibly have the opportunity to move up in my company into the product manager role and we’re in the eCommerce space. I’d like to do as much research as possible on the role so that I’m completely ready. Any suggestions of books or sites I could checkout?
December 2, 2011
I think you’re mixing (a bit) between project management and product management. The vision of the product is different than the vision of the project. The vision of the project is created in the project charter and applies to the executing phase of the project (which you seem to think it’s the vision of the product). The vision for the product is created by the marketing department once the product is released. The line is thin, but there is a difference.
See this post we have published a long while ago on the project vision statement. It fully explains what the vision is for a project.