Rule 43: Life is Short
We had so many great submissions for The 42 Rules of Product Management, we just had to share the “extras” that we couldn’t cram into the book itself.
Rule 43: Life is Short
By Reena Kapoor; Founder and Chief Strategist, Conifer Consulting
Don’t Boil the Ocean!
Don’t boil the ocean. Easier said than done. Every product I worked on that failed can be attributed to the fact that we tried to do too much; as a result we forgot what was important. Worse we did not even see our competition coming! Don’t make this mistake. Feature creep, feature bloat and various other sins happen along the way. The “cost” of this is not simply in time and money but much more importantly in “focus lost”.
But this is hard to do. Embrace a lot of “nay-saying”. You have to say no to products and features and favorite ideas from one and all. Take a page from Apple’s philosophy of “Just Say No”.
Jobs’s primary role at Apple is to turn things down. “He’s a filter,” says the Mac engineer Hertzfeld. Every day, the CEO is presented with ideas for new products and new features within existing ones. The default answer is no. Every engineer who has gone over a product with him has a story about how quickly Jobs reaches for the DELETE key. “I’m as proud of the products that we have not done as the ones we have done,” Jobs told an interviewer in 2004.
One way you can do this successfully (of course assuming you’re not the all-powerful Steve jobs) is by creating two conditions 1) you’ve really done your homework and know your market and target users inside out; be prepared to speak to what your users value and why, and back it up with good data; note this data does not have to be quantitative numbers from primary research but can be well thought out conclusions from synthesis of industry trends, consumer interviews, etc. and 2) you show others the true “cost” of deviating from your laser-like focus. This is not easy but must be done if you are to bring the team with you and not fight them over every feature.
So what are the features and functions you should include and work on? Understanding your market, coming changes, user habits and needs yield the answer to the question: what is the most essential set of capabilities I need to provide my users? And be sure to develop the product that solves that important – even if it’s a small one – problem well. It solves it deeply and completely (to a user’s mind) and may well be regarded as a narrow set of features, for starters.
Note this approach does not preclude you from having a future plan for a “whole platform” that enables much broader set of capabilities. But be sure to solve a few problems well vs. offering a shallow “solution” for a larger set of problems – unless of course “shallow” is good enough. This latter point is very critical too. Don’t get lost in what YOU consider important – show users and ask for their opinion. Again, run a whole bunch of experiments – quickly and nimbly – and apply the learning. When I say “shallow” I mean shallow and useless to users – and not to you.
So the key stages of thinking to develop are:
- Define what’s most essential in terms of capabilities to your target users – whether they can articulate it or not. Demonstrate how you know this.
- Evaluate the following honestly
- can you offer capabilities to solve crucial user problem well (good enough for users) so that
- it’s unique (no one else does it this way),
- meaningful (users think it’s a substantial benefit),
- relevant (they can use it frequently enough) and
- valued (and they are willing to pay for it)?
- Develop your strategy so it gives you a leverage point i.e., build barriers to future switching, for future expansion and market capture.
Prioritize the building of capabilities mercilessly (SAY NO) by taking into account the above as well as timing/resources needs.