If you want to be a bad product manager, try to deliver as many features as possible. The more features you have, the more likely you are to have the things that any individual customer cares about. Customers expect products to keep getting better, and the way a product keeps getting better is by adding more features. Plus, adding a whole bunch of smaller features will be just as good — if not better — than adding that one big important enhancement. More is always better, right?
If you want to be a good product manager, try to deliver the fewest features which will provide the most value. Customers buy products because of the needs that the product fulfills and the problems the product solves. Features in and of themselves are useless — they exist to fill a need. Customers will find product features valuable only if those features satisfy a need and if the act of filling that need is something which is valuable to the customer.
Unfortunately, product managers often approach this problem the wrong way. They will create a long list of desired features and then get estimates from engineering on how much effort each requires. The most important features may take the most amount of effort, so, in the hopes of getting more features more quickly, a product manager will forgo the most time-consuming — and often the most valuable — enhancements to the product. Instead of a few valuable features, the product gets a larger number of less consequential additions.
Rather than simply counting the number of features or the amount of enhancements, product managers should evaluate the ratio of value to effort and focus on obtaining the most value for the customer with a given amount of effort. Product management is not about delivering the most — it is about delivering the least. As Marty Cagan of Silicon Valley Product group writes in Great Products by Design (which has been quoted here before and will likely be quoted here again):
The job of the product manager is to identify the minimal possible product that meets the objectives and provides the desired user experience — minimizing time to market, user and implementation complexity.
Instead of adding more features, product managers need to make sure they have the right features in their product and consider removing features when appropriate. By creating a product that provides the most value for the least amount of effort, a product manager will produce a product which is easier to sell, support, and maintain, and ultimately deliver more value to the customers and to the organization.
26 thoughts on “Deliver customer value, not product features”
Great post, Jeff – very accurate and true. So many folks fall in to the feature trap. Everyone from executives to developers to support personnel.
It’s key to always ask, “what problem is this solving?” and “is it the right problem based on our market?”
Value based is necessary across the enterprise as you move into the late mainstream market. Earlier markets are controlled be geeks that focus on features and the control they grant, or economic buyers focused on solutions. Late market users just want to get their work done, and if that involves your software fine, but don’t get in the way of their work–eliminate feature bloat, which includes things like all those customizations we build into our applications.
Value based works really well as a project management and product management paradigm. Delivering a minimum marketable feature (MMF) means that you get an iteration out there, you get feedback quicker, you learn quicker, and your users learn your product, become experts, and become loyal quicker. Subsequent iterations of MMFs means that you also have more frequent cash inflows and a more level cash flow with less of a need for an infusion of investor monies.
With value based, risk will be more focused. You might find one MMF blowing the schedule, but most of them should involve minimal risk.
Hi Jeff, I am a amid follower of your blog. Being a learning product manager myself , I can really relate to the things being shared by you. And believe me I try to practice most of this while doing the product.
Excellent post. We had this saying that release planning was more about what things not to do than what things to do.
Coincidentally, I just blogged about an article on Business Week where they talked to Chris Hacker at J&J.
Check it out at
You bring up an excellent point. The success of iPod and iPhone reinforces the need to focus on the experience you want to create, and build a system that gets you there.
I recently blogged about the need to Design for User “Delight”
pls send me this types of topics by maill. sweet kiss.
Hello. I just recently discovered your blog and upon reading the few posts, I’m quite sure that I will be coming back for more tips. Whilst my work is in pre-sales, I am currently working on “launching” an existing product but for a new market.
I agree with this particular post because even if the product is full of features, they may not really address the client’s needs and issues. It is far better to tell them how your product solves their problems instead of bombarding them with features and functions that they may never use ever.
Nice message Jeff 🙂 I rode your coat tails once again since your post inspired me to write one of my own on this topic. I appreciate the inspiration!
The information which i got from this website is wonderful. Its very useful for new company developlement and the up coming stars. Very recently came to know about this website. Thanks to google.
Great and very true post! I translated it to Arabic and posted it in my blog if this is ok?
This is the link to the translated post:
Great write up!!
Remove a feature? Wow! Cant think fo any IT or physical product where we actually have seen a product lose a feature. Most of times we have had that happen in our IT products the users end up punishing us!!
Adobe removed a ton of features from Photoshop when it created a version specifically for the late mainstream market. They gave this product a new name. The features removed where those that served the technical enthusiasts. Removing the features required that smart defaults substitute for customization controls. The same capabilities were delivered. Customization controls were eliminated.
I think that the realization in technology is once a feature of a mass produced product has been implemented the costs are minimal to keep it in.
For strategic reasons product features are redistributed or repackaged to drive different market segments as you mentioned.
And then on the other hand in custom projects where there the maintenance costs of features and the removal of risdual bugs and design flaws can still be a high cost features may be removed that are not working so well. I have removed functionality from custom products only to have customer complaints. Our judgemenet was that the cost of the features was higher than the overall benefit.
What I couldnt think of was a mass produced market product in the same segment that has lost a feature. And if it happened why? The Ipod nano will no longer have podcast or playlist playback ability? The ford focus will no longer offer an FM radio option.
On the other hand this is really only interesting for established product offerings. In the mobile phone industry for example nobody really even thinks of a model or funcions. The AZ3423 will have Mp3 and the TH234TF Flip will not. The exception being Apple but probably only because they are so new to the game.
The cell phone industry is about churn. The software industry, even SaaS is about retention.
In an existing category, you have choices in regards to how you will fight price-based competition in the late market. You should make those choices before you enter the late market.
If you are going to sublimate your interface, you should build in the model-view controller pattern facilitation as early as possible. If you are going to move to mass customization, then you need a view-population pattern facilitating architecture. If you are going to die by price competition, then you need to have a discontinous technology coming down you pipeline before you consume 50% of your market cap. Late market, the price-based competition and consumer/non-geek market is a deaveraged market on the B2B side, and one-to-one marketing is about deaveraging even the most average market around.
As for Ford, they have probably moved to XM radio or some such. If I have to pay extra to hear music in my car, I won’t. Somewhere under the decision to remove FM radio is a strategy.
Cell phones companies are pushing texting as a way for them to make money, so I get a lot of free text messages to get me used to them. Your feature set serves multiple strategy constituents.
Over time features become commodities. If those features are playing gates, as in to be in the market you must provide that feature, then leave it in. Otherwise, it is not providing value, revenune, or profit, so it is time to take it out.
Taking things out means having a technical architecture that lets you get that done.
Another example was Macromedia. They had a framework that spanned all their applications. When they M&Aed, they took the application catelog of that company and put it on their platform. This led to the demise of features, but always improved the product.
There is no such thing as an established offering. A market is a fixed commodity that is consumed by sales. It is also a deaveraged market with certain known structural divisions, each having their own definition of fitness. As your market is consumed, your offering must change.
Tick, tick, tick….
Great information and well said – good to read the similar thoughts!
Free CreativeCommons ebook that provides another perspective on this Product Management question:
â€Working through Screens: 100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Workâ€
View / Download online book: http://www.FlashbulbInteraction.com/WTS.html
Very curious to hear any thoughts that you might have on this project.
Jacob, where is your blog for this book. That would be a better place to leave comments.
There has been a cultural divide between the techies and the art-based application developers. As a techie, I’ve said for a long time that the requirements elicitation process is broken, but it is broken as a matter of the indifference of engineering efficency as the core value and the political filters of organizations.
The key is recognizing functional cultures. You can do concepting all day under the execuitive sponsor paradigm and working through screens will be the end result of working through the indifference of that economic sponsor.
Until we recognize the individual or at least the functional unit as a unit of meaning and encode that meaning and its relevance of work, we will continue to produce average functionality that leaves hidden costs in its wake. It’s not a matter of whether there is joy in work, but in the cold hard truth about the cost structure inherent in averaged functionality.
I like what I’ve read so far, but if you want further comments, provide a blog for that. This isn’t my blog. It just seems that centralized comments would be more focused.
you are doing exellent as every term is given so meaningfully.
thank you !!
Comments are closed.