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:
- Metrics Movers. These are features that will move your target business & product metrics significantly. In most healthy product organizations, there are specific goals and strategies behind the decision to invest in a product or feature. Engagement. Growth. Revenue. Typically, very few features are actually metrics movers. Know which ones they are ahead of time, because in the end, the judgment of whether your product or roadmap succeeded or failed will rest on the evaluation of the metrics.
- Customer Requests. These are features that your customers are actively requesting. There is no mystery here. Listen to your customers, and know which features they want to see the most. You don’t necessarily want to implement every suggestion, but product professionals need to listen to direct requests carefully, with humility and deep consideration. Nothing irritates customer more that to see you roll out new features that exclude the ones that they have already identified and requested actively.
- Customer Delight. These are features that customers haven’t necessarily asked for, but literally delight them when they see them. Typically these are features that require several ingredients: listening to customers to understand their pain points, leveraging a knowledge of technology to know what might be possible, and innovative design to come up with an unexpectedly elegant & delightful experience.
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.)
Psychohistory 
Great post. From my PM experience, just about every feature I’ve seen falls into one of those categories.
Pingback: Toward a universal model for software product development
Pingback: LinkedIn for iPhone 3.0 is LIVE! « Psychohistory
Pingback: Quora
Just exactly on theme for me. Wanted to say thanks for posting. (Found you through Quora).
Pingback: Joining Greylock « Psychohistory
Pingback: Be a Great Product Leader « Psychohistory
Pingback: Be a Great Product Leader « Psychohistory
Pingback: Links: 12-31-2011 | Aaron Johnson
Pingback: 위대한 Product Leader 되기 | 파란 개발자 블로그
Pingback: User Acquisition, Virality & Mobile Distribution: Notes | Psychohistory
Realize I’m a few years late to the game reading this post, but good stuff, thanks.
I do think you need a 4th bucket, which includes many of the internal tools and features that you have to do to support the business — like a software connector into an accounting app so you can recognize revenue a certain way. These don’t usually fall into any of the first three buckets, but they often still fall on the desks of product managers as they require planning, development resources and prioritization. Yes, they are important, sometimes even critical. But they are usually not very delightful or metrics-moving and customers (external customers, anyway) probably don’t know they exist.
Was thinking we can call this 4th bucket the “honey bucket.” In part, because it is sort of the “honey do” list. But, really, with that name I had another type of honey bucket in mind:
http://www.honeybucket.com/
By the way, they also have great t-shirts, hats and interesting mugs at that site.
Awesome post. One I was starting out, I tried to focus on more metric mover features – specifically features that grew revenue since we were a startup. I realised that we also needed features that were user focused e.g. user experience that improved usability, retention and engagement. But didn’t necessarily increase revenue directly. I really like the bucket for customer requests and customer delight.
Pingback: Reading List: 24.8 - 30.8 | Путеводитель по галактике для пытливых стартаперов
Pingback: Worthwhile Reads 31.8.13 | סיפתח
Pingback: Issue 61 – Did You Pass The Sunday Funday Test? | Tech Leadership News
I like the bucketing approach, but I would suggest that these buckets may be different depending on your goals. I note that 2 out of 3 of the ones you suggest are focused on existing customers. That would make a lot of sense for a large, established business that needs to maintain or improve its renewal rate.
A business that is trying to ship a new product or enter a new market would have very different buckets, perhaps including “minimum to play.” A business in a competitive, commoditized space might have a bucket for “Differentiators.” In all cases, I the metrics-movers should be top of the heap, I think. (As you said, this is how your product will be judged in the end.)
I did a presentation at ProductCamp last year on how to prioritize based on business goals like these that you may find interesting. The slides are up on Slideshare here: http://www.slideshare.net/ProductCampBoston/prioritization-301-advanced-roadmapping-class-bruce-mccarthy
Hi Bruce,
I appreciate the link and the insight. Unfortunately, attempts to break down prioritization across a large number of framework-driven business goals (like differentiation) or combine them in a single heuristic (to generate a score) has not proven to me to be effective in practice. As I explain in my post, metrics-based features (revenue, engagement, growth) quickly dominate the decision making, largely because the higher confidence intrinsic in their design / generation.
You can replace customer with “potential customer”, and the issues you mention are easily covered. If your sales force needs a “differentiator”, that’s likely a metrics mover that will help them close deals. If it doesn’t lead to increased sales, represent a request from a customer, or delight customers, that differentiator is not likely worth building.
The system I’m using above is actually very well optimized for new, growth startups (not existing businesses, although you can use it there too.)
Adam
I like the idea of buckets, and balancing your buckets in a new release. It’s definitely one part of a prioritization toolkit, as well as giving you a good way to communicate about your decisions with other stakeholders. Your breakdown also reminds me of the four categories of Kano Analysis. What is missing – or, let me say, would be a nice addition – is a visualization. And, to beat my hobby horse for a moment, tool support. (Maybe Bruce’s Reqqs supports this – I’ll have to ask him.)
To me, visualization is either something that moves metrics, is requested by customers, or will delight them. Usually, it’s the latter, although LinkedIn had some success using visualization to move metrics in a few key cases. For example, if visualization gets people to engage and upgrade to a premium subscription, that’s a metrics mover (in my framework).
Tools is part of a concept I didn’t cover here, which is how to layer in infrastructure investment into your development efforts. There are a few approaches to this, but in general, I try to separate them from the product prioritization process.
This is a great post!! The three buckets encapsulates the product planning very well.
I have only thing to elaborate. -about your first bucket “Customer Requests” –
Oftentimes, the minority is very vocal than a vast silent majority. There is a need to temper the requests with a larger understanding of the needs of full spectrum of users. This brings to my next point: Most customers dont ‘actively’ requests for a particular feature. However, their clickstream behavior will scream of unknown and unreported problems. In fact, many of the new features that ought to be built comes from the data mining of clickstream behavior.
Hundreds of thousands, if not millions, of customers are requesting you what they want implicitly by the way they behave on site. In this era of big data, A product’s value and success is more and more tied with a Product Manager’s ability to analyze large volumes of data, and come up with new features, enhancements, identify bugs that never get reported, and more.
One may argue that the above notion is more applicable to web products, but I would say that we are facing the dawn of internet of things, and just about every product is going to generate large volumes of data. Gone are those days where a PM can survive only with focus groups, customer requests, UERs.
Pingback: 45 Articles and Books that will Make you a Great Product Manager | SoshiTech - Social Media Technology - Soshitech.com
Pingback: Boston’s Product Managers on Feature Prioritization & Internal Strife Angel Fund Me
Pingback: Product Manager Weekly Reading #2 | Product Manager HQ
Pingback: What does a product manager do? | Rupali's Blog
Adam,
This is super helpful and will be encouraging my team to think about these buckets when it comes time to prioritize. It’s easy to get caught up in the wrong reasons for supporting or not supporting a new feature / project where this provides an easy framework for understanding WHY the team has decided to move forward in a certain direction.
Pingback: Alexander Nizni: Career Site – Product Leadership, UX Design, Marketing Product Management Resources: Marketing, Usability and More
Pingback: 如何成为优秀的产品经理 —— Adam Nash | 笑点低
Pingback: How to Build Products People Love: Lessons from Kevin Hale | Learn Cool Things
Pingback: Decoding product feature prioritization | Exploratory Minds
Pingback: Prioritizing features - Zain Abiddin | Zain Abiddin
Pingback: Product Management “Best Practices” - Dmitry Bekinin
Pingback: [번역] Be a Good Product Leader. by Adam Nash - Ahn Changyeong
Pingback: Best Product Management Resources of All Time
Pingback: Best Product Management Resources Collection
Pingback: Product Leaders as Curators & Editors | Psychohistory
Pingback: Product Prioritization by the Numbers - Mind the Product