Product management is about making informed, strategic decisions and ensuring product aligns with organizational goals and customer needs. But a product manager’s duties don’t begin and end with building a product roadmap. Successful product managers know even the most foolproof product strategies can fall flat in the absence of one key element: Transparency.

True transparency in the context of product strategy is much more than hosting a quarterly company-wide product roadmap presentation. It is a mindset embedded into every step of the product development process and baked into product culture. When product teams fail to communicate early and often with cross-departmental teams about what they’re working on and why they lose out on the many benefits of a transparent product roadmapping process.

3 Benefits of a Transparent Feature Prioritization Process

1. Organizational Alignment

A transparent feature prioritization process fosters organizational alignment by getting everyone on the same page about where the product is going and why. This universal understanding reduces friction across teams by uniting everyone in support of a common goal.

2. Product Management Leadership

Product managers can position themselves as the strategic minds they are by sharing how roadmap initiatives are prioritized and outlining the various factors involved in roadmap decisions. Transparency into what matters and why also empowers others within the organization to share relevant product insight and suggestions.

3. Trust

Finally, transparency breeds trust and product managers need their teams to trust their ability to make solid decisions and lead product in the right direction.

How to adopt a more transparent feature prioritization process

So what are some ways you can democratize a transparent feature prioritization process to reduce friction and achieve organizational alignment?

Hear your teams, customers, and prospects out.

Customers, prospects, and internal teams all have a unique insight into the product. If you aren’t already engaging with these folks, you should be. Sales, for example, knows what prospects need and want from the product. Support may be keenly aware of pain points within the product that frequently causes friction. Engineering knows all about the inner workings of your product and where technical debt may be lurking.

Facilitating an ongoing dialogue with these groups of people plays a significant role in democratizing the product management process within your organization. Set aside time to sit down with different groups of people and listen to their feedback on the product. Remember not to take everything at face value, try and dig into their requests to determine the root problem behind them and size up how significant it is.

Help internal teams.

Help internal teams help you by telling them how they can supplement their qualitative feedback with quantitative data. Explain to them the types of data that can help you quantify the value of acting on requests. For example:

  • Support claims that customer satisfaction is plummeting because you haven’t acted on a popular feature request in your product feedback forum. Does NPS data of the accounts request the feature support this claim?
  • Sales swear they can triple their close rate if you simply build feature Y, can they make a real business case for it using data from closed-lost deals?

If you get internal teams into the habit of thinking more like a product manager when they bring your requests, they may even begin pulling the data before you ask for it.

Even if a request seems silly to you, do your best not to be dismissive of it. This does not mean you have to agree to build it, it simply means keeping an open mind as you investigate feedback and dig into the why behind a request. If you don’t understand at first, take time to ask questions until you do. If it’s still something you simply won’t build, demonstrate that you’ve recorded the input somewhere, but be honest about why you don’t think it will happen. Never set false expectations.

Explain your process.

You need to make it clear that you do more than just take inputs. You are the strategic brain behind the product; it is your job to drive your product toward its vision while making choices that support broader organization-wide objectives. If you are making prioritization decisions without your product vision in mind, consider rethinking your strategy.

Product decisions are made with several factors in mind such as; product vision, customer needs, business objectives, and technical requirements. There is no one-size-fits-all formula for prioritizing initiatives on a product roadmap, so it’s wise to have discussions with your team regarding your decision-making process.

How exactly you approach this is up to you, but one effective way is to group initiatives on your roadmap by strategic themes. For example:

  • “This quarter we’re really focused on getting more users to move from our free to premium accounts, so we’re looking for initiatives that support that”
  • “Right now we want to catch up on some technical debt cleanup, so we’re focused on improving product speed and efficiency while also tackling some commonly reported issues”
  • “We want to increase retention this quarter, so we’re focused on initiatives that help us achieve that”

When you provide context into your thought process and reasoning for product decisions, it will quickly become clear that your feature prioritization process is not a game of picking favorites; there is indeed a strategy behind it.

Be transparent about what features are already in the hopper and what other teams have requested already. This reinforces that you have truly listened to everyone and gives folks an opportunity to share more insight into particular requests. Plus, this gives your team a subtle reminder of the (always growing) volume of requests you’re working with at any given time.

Unveil your plans.

Don’t take feedback and run! Share your product roadmap with all relevant teams within your organization. Directly reach out to everyone who provided feedback that informed your roadmap and explains how they had an impact. Then, take time to present your roadmap to the rest of your team.

We recently wrote in-depth about the hows of delivering an effective roadmap presentation, so we won’t go into too much detail here.. But in general, you’ll want to be prepared to explain the why behind every initiative on your product roadmap. Why is it there in the first place? Why was it prioritized above other features?

And don’t forget to explain the whats as well. What results are you expecting from each initiative? What key business metrics can you tie to each initiative? In what way does this initiative support our product vision?

Finally, don’t forget to thank everyone for their input! If you have a formalized procedure for gathering feedback from internal teams, now is a good time to review it. Reinforce the fact that all feedback plays a significant role in the development of your product roadmap — even if it doesn’t get acted on immediately. And if something simply won’t get built ever, don’t pretend that it will. Instead, tap into the power of transparency and explain why not. Your team will appreciate the honesty.

Do you have any pro tips for adding transparent feature prioritization to your roadmapping process? If so, please share in the comments below!

Post Comments

Leave a Comment

Your email address will not be published.