Skip to content

Guide to Product Planning: Three Feature Buckets

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:

  • 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.
  • 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 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.)

26 Comments Post a comment
  1. Great post. From my PM experience, just about every feature I’ve seen falls into one of those categories.

    August 9, 2009
  2. Just exactly on theme for me. Wanted to say thanks for posting. (Found you through Quora).

    December 4, 2010
  3. 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.

    October 3, 2012
  4. 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.

    August 30, 2013
  5. 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

    September 3, 2013
    • 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

      September 21, 2013
  6. 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.)

    September 21, 2013
    • 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.

      September 21, 2013
  7. Karthik Venkateswaran #

    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.

    December 13, 2013
  8. Ryan Dodds #

    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.

    August 11, 2014

Trackbacks & Pingbacks

  1. Toward a universal model for software product development
  2. LinkedIn for iPhone 3.0 is LIVE! « Psychohistory
  3. Quora
  4. Joining Greylock « Psychohistory
  5. Be a Great Product Leader « Psychohistory
  6. Be a Great Product Leader « Psychohistory
  7. Links: 12-31-2011 | Aaron Johnson
  8. 위대한 Product Leader 되기 | 파란 개발자 블로그
  9. User Acquisition, Virality & Mobile Distribution: Notes | Psychohistory
  10. Reading List: 24.8 - 30.8 | Путеводитель по галактике для пытливых стартаперов
  11. Worthwhile Reads 31.8.13 | סיפתח
  12. Issue 61 – Did You Pass The Sunday Funday Test? | Tech Leadership News
  13. 45 Articles and Books that will Make you a Great Product Manager | SoshiTech - Social Media Technology - Soshitech.com
  14. Boston’s Product Managers on Feature Prioritization & Internal Strife Angel Fund Me
  15. Product Manager Weekly Reading #2 | Product Manager HQ
  16. What does a product manager do? | Rupali's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 10,993 other followers

%d bloggers like this: