This passage presents a framework for categorizing product features for consumer software or internet products, aiming to guide product managers in making informed decisions about feature development. The framework classifies features into three buckets: Metrics Movers, Customer Requests, and Customer Delight. Metrics Movers are features directly impacting key business and product metrics, like engagement, growth, or revenue. Customer Requests address features explicitly desired by customers, emphasizing the importance of listening to and addressing their needs. Customer Delight features, while not explicitly requested, are designed to surprise and delight users through innovative solutions to their pain points.
This framework encourages product teams to be transparent about the motivation behind each feature, ensuring a balanced approach that prioritizes both business objectives and customer satisfaction. By strategically combining features from each bucket, product managers can achieve optimal results, delivering value to customers while driving key metrics and showcasing innovation. Conversely, the absence of a particular bucket indicates a potential weakness in customer feedback channels, product execution, or innovation capabilities, ultimately impacting both short-term and long-term success.
In the spirit of capturing some of the observations that I find myself repeating, I’m adding this one to the mix tonight. Unlike the previous two, this is really a piece of concrete advice for product managers of consumer software or consumer internet products. It’s also a more recent observation that I’ve formulated in the past few years.
This advice takes the form of a simple classification framework for the features that you are considering for a product, whether it’s a single “large scale” launch, or a series of product features that are planned out on a roadmap.
Place your feature concepts in one of three buckets:
Don’t get me wrong – there are some features that can fall in more than one bucket, but it’s a rare feature that actually falls in all three.
I’ve found that categorizing features into these buckets forces product teams to be intellectually honest with why they are implementing a certain feature. Is it because customers want it? Or is it because the company wants it (to move metrics)? Or is it just cool?
For large, monolithic releases of features, optimal success comes from packaging up items from each of these buckets. The customer requests ensure that your customers see that the time that they are investing in your products is rewarded by a provider who listens and delivers. Your metrics movers ensure that the business and strategy you are executing on will provide the resources to invest in future iterations. And your customer delight features highlight your ability to leverage expertise in technology & design to deliver innovative capabilities.
Conversely, if you find yourself without one of these buckets represented, it likely represents a serious hole in either your channels for customer feedback, your product execution, or your innovation capabilities. These holes will significantly impact both your short term and long term success in this area.
Most consumer internet companies don’t ship monolithic feature redesigns often – instead they release small iterations and additions frequently. (At LinkedIn, we release every week.) The logic above, however, can just as easily apply to a series of 1-2 week features executed over the course of a three month roadmap as a large monolithic release.
Take a moment and consider major product releases in the consumer space that you really respect as a product professional. I think you’ll find that these releases have all three of these buckets well represented. (iPhone 3.0 is not a bad recent example.)