, I head the team responsible for product strategy, product management, and product analytics for a platform with over 500 million registered users. In other words, I've been through my fair share of product planning exercises, and I've come out the other side with lessons learned about how to build a product roadmap—lessons I'd like to share with you now.
How should we prioritize product features?
We often ask ourselves questions, like:
Should we build this?
When should we build this?
How should we build this?
Debates tend to get so caught up in the should, that when and how are neglected. However, if teams work backwards a bit and envision future success, questions about should and when are quickly resolved. In other words, if a team can answer the question, "If we are successful, will we have this feature in X years?," then the conversation should shift toward priority and implementation of the feature.
Most teams fall into the trap of trying to find a single formula to rank all of their product ideas. Unfortunately, this pits features that move metrics, like engagement and revenue, against customer requests and delight features. Over time, teams that do this inevitably focus exclusively on metrics, and their relationship with their customers suffers. If this does happen, however, identify the issues early and use a
about in 2009, avoids that trap by taking 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 are features designed to move a key business metric, typically growth, engagement, or revenue. These features pay the bills. Ultimately, a product without justification will lose its funding.
Customer Requests are features requested by customers. They rarely move metrics, but are critical towards building a long term relationship with your customers based on listening and responding.
Delight are features that aren't requested by customers, but when they see them, they are surprised & inspired by them. They are critical towards building a strong emotional attachment with your customers—delight inspires passion and loyalty.
Categorizing features into these buckets forces product teams to face abstraction head-on and 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?
Realistically, a single feature won't be a metric mover, a customer request, and a delighter. Metric movers rarely delight. Customer requests don't move metrics by much. And delight feature by nature are not requested. However, great products are built on product prioritization that encompasses all three.
We've found this technique to be indispensable. Try it and let me know how it goes!
Time to start your own 3 bucket planning: copy this doc.
Since I wrote the blog post, I've had a lot of people reach out with practical questions on applying the philosophy. This doc is actually a guide ready for you to copy and use!
Copy this doc
on your desktop to get started.
The goal of the doc is to enable you to see where your team is focused by classifying each of your roadmap items, and identifying which of the three buckets need attention. It also enables going bucket by bucket and addressing the unique needs of metrics movers, customer requests, and customer delight issues.