guest blogger product management

How to Communicate Product Priorities to Management

Guest Post by: Tiago Resmini (Mentee, Session 10, The Product Mentor) [Paired with Mentor, Erdem Ay]

A common thing in product management is business leaders (like the head of product or the CTO) not having clear sight of every problem happening with a product or one specific part of a product.

That happens because they are not include on the day-to-day routines of each squad that manages that product (obviously), so in many cases the most important channel they have to access that kind of information is through direct or indirect communication with the team, usually docs and presentations written by the PM.

That leaves a great responsibility for the PM, especially because these leaders are usually the ones who will make budget allocation decisions and should have all the information available to make those decisions.

This article will be a case study on how to structure qualitative and quantitative evidence in a way that management understand the priorities of your product clearly.

In this case, I will show what was the process I used to structure and present information when I was sure that management was not aware of the problems inside my product and managed to reallocate resources to that product.

The Problem

The feeling of underinvestment is very common in product teams. They are very focused in understanding and solving customer problems (which is a good thing), and usually have an extensive list of problems and opportunities they can tackle. It is normal that the large number of alternatives on these lists lead to this feeling of “we could do more with more resources, so we should ask for it”.

On the management side, however, things are harder since every team will have a long list of opportunities and they have to decide which ones, considering them all together, are the best. Communication and alignment play a huge role here, both for management and for PMs, since bad decisions can be made if the PM does not communicate correctly and frustration can be created if decisions are not well aligned by management.

So as a PM, your responsibility is not to ask for resources when you think you have to many things to do, you have to consider a whole new complex system to make sure your request is actually something management is not aware of. To guide that thought, here is a list of situations where that is probably the case:

  1. Market Timing is crucial: Some investments in product are not so sensitive to market timing as others. If you are sure you will lose a lot of potential value by not investing is something right away because you will not launch on time to capture that value, you should consider making that clear to your Head of Product;
  2. Your team is drowned: Sometimes the squad is managing a heavy operation product and/or has a huge load of tech debts and bugs to be corrected. In that case, if you are underinvested, you will have very low velocity to deliver things that create value and bringing more people will also bring economy of scale, usually doubling or tripling value creation speed;
  3. Your opportunities are very big: Regardless of being lean, delivering and validating product value incrementally, sometimes in more mature products, to deliver huge value (after validating and idea) you will need huge investments. In these cases, it may also make sense for you to get more resources so that you can deliver that faster, since the investment is too high but you are sure that it will bring ROI;
  4. You know the trade-offs: In some cases, because management did a good job aligning decisions, you will know why resources are allocated as they are and feel that new information (either because it is actually new or because you failed to communicate it earlier) could change that decision.

In my case, I felt I failed to communicate all the opportunities we were missing in the current situation and the amount of work they required to be delivered. On top of that, the squad was also drowned into tech debts and value creation speed was an issue for us. So it was a combination of situations 2, 3 and 4.

How to present

If you are facing one or more of these situations, that might be also the case to stop and organize information so that you can present it clearly to management, then ask for more resources.

I organized my presentation in 3 main topics:

  1. Opportunities, problems and root causes
  2. Bets you have to solve those problems
  3. Team allocation scenarios

Opportunities, problems and root causes

First, you start by presenting the motivation behind: show which of the situations described above your team is facing and more importantly, why that is happening. You should be able to answer the “5 whys” of every problem you are presenting to make sure that not only they understand the value created by solving those problems but also that they can trust you to solve them.

Create a detailed opportunity tree for every problem you want to address (remember the 4 situations above – not every problem will make sense to have more resources allocated) and show deep understanding of each one of them. Bring quantitative and qualitative data to prove the problem is crucial and that you knowledge about it is enough to solve it.

My tips here are to

  1. Try your best to estimate how much money is involved in these problems. I know sometimes it is hard to do, it is not a direct correlation etc. But sometimes you can make some assumptions (which you will need to show when presenting) and reach a rough estimation that already helps a lot to communicate how big the problem is. It is very hard to compare problems with different metrics (for example: comparing if improving retention for feature X is more important than improving adoption for feature Y), and money is the common language for every business.
  2. Communicate qualitative data in different ways that can support your quantitative data and your root cause analysis. Presenting only qualitative data usually is not enough to convince someone, but a common mistakes I see people doing (me included) is to neglect all of that data. Sometimes just grouping similar feedback that came from surveys, support tickets or even interviews is already a good way to support your quantitative analysis. Bringing specific quotes from customers is also a great way of materialize and prove a point you are trying to make with data.


Next, your objective is to make sure they trust you to solve the problems you just presented. Don’t be the kind of person that only brings problems and no solutions.

That doesn’t mean (at all) that you will be compromised with a solution or that you are throwing everything you know about product management in the trash.

What you are doing is presenting the hypothesis you are most confident with at the moment (that’s why I call them bets), which will give your audience a sense of what needs to be built to solve those problems. That leads to a better understanding of the size (cost) of the solution and usually make people feel more confident on your plans, since you are now showing that not only you know the problem deeply, but you also understand how to solve it and already has some alternatives designed.

Team allocation scenarios

Your final goal is to get the approval you need to reallocate resources.

I have often seen people presenting problems and solutions in a great way but still struggle to get the resources anyway, since they don’t push the final step of the process.

Think of that as a salesperson calling you, validating that you have a problem you need to solve and that the product they are selling you will solve that problem. And then stop right there. Or even in a self-service model: how many times have you searched a product at Google, found what you wanted at a fair price, didn’t buy and forgot about it?

The point is that we usually need that final push to take action: the salesperson has to send you the proposal on your email, the e-commerce has to create an ad-campaign to retarget you on your social media so that you take that final step and finish your purchase.

This final step step of the presentation is the same: you are building an actionable proposal of resource allocation (and even better if you can argue where is that resource coming from) and just asking them to sign your proposal.

Just as if you are selling a product, you need to show the consequences of doing nothing (recap of the first part of the presentation), present different scenarios of new resource allocation and how those consequences would be different in these scenarios. In my case, for example, I built 4 scenarios:

  • Actual allocation – the situation we were at the moment of the presentation
  • Ideal allocation – how many developers, PMs and UX designers we should have if resources were not scarce
  • Realistic allocation 1 – an intermediate scenario between actual and ideal allocation, which would be possible to make and solve part of the problems
  • Realistic allocation 2 – a different variation of an intermediate scenario

That way, you will make clear what are the consequences of sticking with the situation you have at the moment and also show that you have your feet on the ground by showing that you can put aside some of the problems you presented to reach a possible deal with management.

Extra tips

Although this is already a tough process that drains a lot of your energy, that are still some learnings I had along the way that may be useful since they can invalidate the whole process.

Make the right people listen

None of this will matter if you do not present it to the right people. And that means not only the decision makers (manager/head of product/CTO) but also a lot of people around that, if not convinced, will argue in other forums that your request is not valid.

For example, if your plan will need reallocation of developers from other squad to yours, the leaders of that squad may not buy your plan and argue back. Or if your bets have dependencies on other squads and they do not agree with your plan. Or if someone else in the company is trying to solve the same problems… There are a number of reasons I can quote, but there is no silver bullet here: you can to think about how to communicate with each stakeholder, probably in distinguished moments each, and then finally present to the decision maker.

Validate your presentation over and over again

This tip serves for almost every important presentation you will give, and this one is not different. You can to be overprepared in these kinds of proposals: slides should be impeccable, your speech should be crystal clear and most important, you need to anticipate most of the questions people will have for you.

And the best way to that, in my opinion, is to show and present to other people, with different jobs, who are familiar with your context: your leader, other PMs, the tech-leader and the UX designer of your squad, your mentor… Use the time you have to prepare to gather feedbacks from people with different points of view, since each one will probably show some flaws on your presentation and/or prepare you to a tough question that might come up.

Final thoughts

I believe the best advice I can give after spending ca. 1 month elaborating a presentation and getting mentored about it (even in the subsequent months we were still talking about it) is to think about asking for more resources as something that will benefit the company, not your team. This will make you feel empathy for your managers and put you in their feet.

It is very common for a PM to think that his/her product is very important and that there are too many problems not addressed by any initiative. By doing this, not only will you have a better plan to present, but also a better chance to get it approved, as I did with the help of everyone involved 🙂


About Tiago Resmini


Tiago is a Control and Automation Engineer acting as Product Manager at RD Station, a platform that offers a Marketing Automation tool and a CRM to help SMBs grow. He joined RD Station as his first PM job in 2016 and has been in charge of serving Reporting and Analytics tools for more than 10,000 customers since then.




More About The Product Mentor

TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

%d bloggers like this: