Feature prioritization is one an essential responsibility of Product Management. All the work you do– customer development, internal horse-trading, market research, etc.–culminates with a list of prioritized features for the development team to build.
And yet, if prioritization is so important, why is it so difficult to do? Why is there so much confusion around it? Look at some of the most popular Product Management forums in LinkedIn or Quora. You’ll see that creating a roadmap and prioritizing features continues to be a big issue for Product Managers.
In many cases, the struggle to prioritize features is just a symptom of something bigger. The real problem is usually a lack of strategic vision or direction. In other words, feature prioritization without a product strategy is like mapping a route without a destination.
Before Jumping Into Feature Prioritization, Ask Yourself:
- Are you prioritizing features without a solid strategy and prioritization criteria?
- Are you only listening to the loudest stakeholder, biggest customer, or squeaky wheel?
- Are you just chasing after the features of the competition (feature parity)?
- Are you trying to chase the latest trend in your industry?
If you answer yes to any of the above questions, then your prioritization will not only be difficult, but it’ll be highly ineffective. Here is the simple rule: Your feature prioritization should flow from your overall product strategy.
Your company’s strategy will inform your high-level roadmap, which tells you what type of functionality you need to build in the short- and mid-term to satisfy your customer’s needs as well as other internal company needs.
There’s no point in prioritizing features unless you have a clear strategy and an agreement on the customer business problem you plan to solve. So before jumping into reorganizing individual features within your Product Management tool, take a minute to revisit your overall strategy and long-term roadmap. If you are short on customer insights or strategic alignment, then your time is better spent there.
Recommended podcast episode: You Can’t Outsource strategy
That’s not to say your strategy needs to be set in stone for all of eternity. Depending on the maturity of your company, it’s not rare for strategies to adjust or “pivot” (to use the Lean jargon) based on new customer insights or market changes. But you do need to have an agreed-upon strategy at all times, which remains consistent for at least six months.
The Bottom Line
By the way, getting here is a lot of work, and that’s where a big part of the value of Product Managers lies. If you’d like some great resources on developing and executing a customer-driven strategy, I highly recommend these other articles I’ve written on this topic.
- How to Use a Scorecard to Prioritize Features
- How to Build an IoT Roadmap
- How to Use Design Thinking to Build Better IoT Products
Photo by Peter Reed
10 Comments
Hi,
I completely agree about the importance of strategy when it comes to prioritization, but I don’t think it’s the only factor. Ultimately, you also need to know which features your users want the most. What are their priorities?
Methods like Kano/Agile/etc. always seem to forget that you’re building this product and the features it includes for your customers. So you need to listen to what they want.
Take this relatively simple approach… Each customer is given a number of points. They can spend those points on the features they want the most. The key here is they don’t have enough points for every single feature. After they’ve finished, you’ll have an idea of your customers’ priorities.
You can take this even further and segment the data based on customer value, industry, etc.
Thanks,
Joe, from Receptive.ioThanks for your input Joe. I’m glad you enjoyed the article.
Oh, no! Not the score card approach. I’m scared 🙂
Seriously, you’re dead on about the importance of prioritizing according to product strategy. I go even further: prioritize mostly in terms of your product’s unique value proposition. There are infinitely many problems we can solve with our products, and still infinitely many that have potential as a business. When we choose a unique value proposition for our product, we’re by definition scoping the set of problems we plan to solve and their relative priority.
As far as the score card approach, check out this excerpt from my blog entry, 5 Ways Companies Make Product Decisions:
“For example, a member of the team may maintain a spreadsheet with candidate market problems to solve, or with all the proposed enhancements to the product, and rate them on various criteria. They base product decisions on the items with the highest ratings. Some more sophisticated product managers analyze customer preferences using Kano analysis, rating features in terms of the extent to which they evoke surprise and delight, satisfaction, dissatisfaction, indifference, or an erosion of overall perceived value.”
As I noted in the “pros and cons” commentary, this approach can lead to products with incoherent and scattered value propositions.
Oh, yes! The scorecard is coming back with a vengeance! =)
I agree with your comment Roger. I think that a good approach is to use the scorecard as a tool for a “second-pass prioritization”. I don’t think one should go over the complete backlog and prioritize against the scorecard. That would result in the issue you are pointing out.
Instead, my approach is to look at the long term strategy, get voice of customer to validate what you should the focus of the next release. And only after that, you should use the scorecard to prioritize only the features for the next one or two releases. That way you focus on the immediate impact, without sacrificing the long-term direction. What do you think?
Other than that, I guess you’ll have to wait to read my post, which is coming out on Feb 17th =) I look forward to your feedback as well.
BTW, I love Kano as well, but I think it’s harder to implement if you are starting from scratch in terms of prioritization framework within your company.
Thanks Roger!
DanielDaniel, I didn’t intend to portray Kano analysis in a positive light. In the blog entry I cited, I pointed out that the spreadsheet approach and Kano analysis are examples of “left brain” product management methods. These methods have pros and cons. The main con is that they risk getting so far in the weeds that product teams neglect a singular and relentless focus on supporting the unique value proposition.
It barely matters how much a potential feature surprises, delights, satisfies, or has revenue potential in and of itself. What matters is that it helps provide the value promised in the unique value proposition.
Looking forward to your spreadsheet!
Completely agree Roger!
I think that frameworks like Kano, scorecards, Agile, Lean, etc, they are just that. They are frameworks and tools to help Product Managers accomplish a goal. They in themselves are not the goal or provide an ultimate solution. I see many folks new to PM focusing too much on those areas as if “mastering” Kano or Agile would automagically produce a great product that meets the proposed value and sell like pancakes. I wish it were that easy!In a recent talk at ProductTank, Rich Mironov made a comment. He said something like: “well, building a startup is easy, right? Just have a cool idea, grab a copy of The Lean Startup and off you go…”. =)
What experience has taught me is that learning all those frameworks (and many more) give us a good toolbox to pull from in any situation. We need to mix and match techniques and approaches depending on our company’s culture, place in the adoption curve, maturity of our process, personal style, etc. Product Managers along with our teams are responsible for delivering that value, delight and profit. Regardless of how we ultimately get there. What do you think?
Thanks for a great discussion Roger. I always appreciate your insights!
Daniel
Most successful product managers are, in fact, very left brained — and for good reason. In addition to the leadership and communications skills required to be effective at the job, analytical skills are a close 3rd.
In my experience, the way to avoid getting stuck in the weeds using a scorecard approach to prioritization is to… well, avoid getting stuck in the weeds. I use and recommend a scorecard approach for the large theme-level initiatives (and then separately within a chosen initiative, to prioritize individual features).
It does all start with product strategy and corporate goals, but given these, prioritizing the major initiatives which help achieve those goals most with the least cost is the only rational way to go, IMO.
Bruce, I think it’s selling exceptional product managers short to pigeonhole them as “very left brained”. Speaking as a very left-brained product manager, I see great value in some of the right-brained approaches of Al Ries and Seth Godin, and I strive to “channel” them to add to my instinctively analytical approaches.
I would say the best product managers are able to operate in whichever hemisphere is optimal for the situation, and to nimbly switch between them.
They have their place, but scorecards force us into fundamentally linear and limited thinking, whether or not you restrict them to “theme-level initiatives” beyond the product’s singular value proposition.
We need to complement scorecards with more right-brained methods, such as composing competitive mindshare maps.
Hi Daniel,
I think product strategy, or lack thereof, is one of the biggest challenges to Product Managers for a whole range of reasons. So many problems can be traced back to this.
One way that we help with prioritizing is to map out what the customer is doing. Not just with your product, but what are they actually trying to achieve in their jobs and what steps do they take to get there. We’ll go sit with a few customers and try to build a picture (a process) of what they do and the goals for their jobs. Then we can see where your product fits into the process.
This is always an interesting exercise because people are so surprised when they see how little impact their product actually has. When looked at in the context of the product strategy, or even the company/sales/marketing strategies, you start to see opportunities open up. You can ask questions like “how much easier will this feature make the user’s life?” “how will it support them reaching their goals?”
Hi Craig,
You bring up great points. I do like the idea of mapping out what the customer is doing. Some UX folks call it “journey mapping”, but regardless of the name, I think it’s a great tool for stepping back and seeing the overall problem your users are looking to solve, as opposed to thinking that our application is the center of it all. And like you said, often times, we realize that our product is just a small fraction of the overall puzzle. Even worse, sometimes we realize that our product is not essential and the user could throw it away in no time. Journey mapping is a great exercise for reality-check, finding out where our real value is and making sure we are fulfilling the benefits we promised.Thank your reading,
Daniel
