Product Management Question of the Week - August 29, 2022

It’s time for another Product Management Question of the Week!

This week, we’re talking roadmap prioritization. You’ve built a product and have a roadmap for future releases, but you’re constantly getting customer feedback around the experience, feature requests, and what is and is not working. The backlog is getting lengthy and you want to honor customer feedback but you also know that you have a responsibility to continue building the foundation of the product.

So how do you balance customer feedback with future releases foundational to the product offering? What is your approach to preventing feature bloat while listening to your customers?

Let’s talk about it! Sound off in the comments below!


It’s very difficult to arrive at a diplomatic answer to this.
I think it really depends on company type. In a B2C it’s easier to align to Roadmap and not be too driven by customer request since there are millions of customer and the authority of influence is diluted in the masses.

But in a B2B company when there are customers who literally contribute to 10 or 20% of the entire company’s revenue it becomes a huge challenge to convince them of the product road map and negotiate what they want with time lines that match what we plan to have as PM. It’s a very fine line where, if we over step we might have chance to lose the big customer so a PMs negotiate skills is put to at most test in this case.

Some thoughts -

  1. Does the new input or feedback relate to the North Star metric or any shorter term goals? There are no shortage of interesting things to do but focus is key. Consider current targeted markets & persona(s) and whether the product is on track for existing market share expansion or new market entry.

  2. If releases are structured to have capacity for UX improvements or enhancements, what are we trading off to make space for this new feature? Will we have to break previous commitments tied to the roadmap?

  3. What other groups are impacted and do they have space to support this (support, operations, sales, legal, etc.)?

  4. Generically, what is the urgency and importance of this? Is it better deferred and bucketed to a similarly themed release? Is this feature tablestakes, core, or delighter/differentiator?

  5. Do we have the resources and competency to do this? Build, buy, borrow decision. If the request is too far out of core competency it may not make sense to build.


It’s very true, and sometimes we are building a product for internal use, which adds an extra layer of complexity.

One product I’ve worked on was for internal use only, and the CEO wanted a lot of UX-breaking decisions and we had to push for a middle-term. I could pander to the CEO but it would cost the buy-in of the Users, and he could push for the software adoption as a company mandate but that would cause even more friction and even less adoption. In the end, we did a couple of A-B tests with prototypes that made the CEO realize that his way of thinking worked for a C-level professional, but for the entry-level workers (the majority of Users demographic), it made no sense.

We had to recently face the exact situation as a team where we were bombarded with customer requests every single day while we had a huge list of items to work on the platform. The strategy that we followed was to assign weightage to both the buckets every quarter and based on the weightage the number of items from either of the bucket would be high. Say if 70/30 is the weightage, one particular release will have 7 customer requests and 3 platform improvement features. And the weightage was vice Versa for the next release.
Though after each release the customer would not be completely satisfied we tried to solve few which gave them the belief that they are heard.

Your thoughts and inputs on this idea are welcome

From a very tactical (yet still quite strategic) perspective, what I’ve found to be effective in balancing customer feedback with future releases foundational to the product offering is based off a mix of a few key steps:

  1. Start with Stakeholder research > understand very well what are the priorities/problems from anyone who touches the product from engineering to key some clients
  2. Set product objectives for clear focus > Based off of Step 1, it becomes a lot clearer what some of the biggest problems are to solve. Boiling these down to a few key points will make it a lot easier to show where your focus is
  3. Define clear & understandable roadmap themes that can ladder up to objectives > This step was really time consuming but it has made it so easy to make adjustments when I need to. Do not focus on the backlog. Make themes and then sub-themes (epics) to showcase the planned work. Make sub-themes clear enough to show what the focus will be on, but also make them vague enough so you aren’t tied to anything that makes it hard to back out on.
  4. Prioritisation exercise with a few key internal stakeholders - If you do this right, any conversation about new features & trade offs becomes sooooo much easier.

Ultimately, I have found that, like most things in life, it’s about managing expectations from the beginning so buy-in becomes achievable, faster. I took the above approach this year and one of our biggest clients decided that some things were a bigger priority than what we originally agreed on. This resulted in a very healthy discussion of trade offs that everyone could get on board with.

Anyway that’s what I’ve been mulling over recently. I’m sure the process will iterate. I’d love to hear any feedback/

  1. :100: & :heart: OMG this is great and exactly what I was thinking. Another slightly different way you could think about it is what is the current theme of the [insert timeline] or what is your company’s mission statement.

2,3,5 These are great too.

  1. Sorry we’re gonna have to agree to disagree. I’ve worked in ops, support, engineering and now product. I gotta say, unless you’re talking about the safety of the product, urgency and importance are only a point of view. Your urgency and importance are different than ops, support, engineering, and leadership. Everyone I work with always tells me their work for their bonus is the most important and urgent project I need to work on :laughing:

Fun question!!

The way I think about this question is how much capacity do you plan for when it comes to the release/enhancement of the product.

The short answer from my experience is, any system that doesn’t have slack in it is going to fail. That is, if you’re prioritizing at 100% capacity, its going to make it very difficult to for teams to iterate, to be flexible and adjust, etc. This can also lead to employee burnout and turnover too.

There are likely severe different approaches to address this challenge but what I’m a fan of is giving teams 20% time to focus on what they deem as most important. Examples could include, automation, tech debt removal, process improvement, customer feedback iteration, etc,

From there it’s just about empowering teams to get the most out of this 20% by giving them the tools and skills needed to make informed decisions.

Note: Gmail was created from the 20% time given to an employee to build something they thought would be most valuable