Stakeholder management is one of the hardest parts of a Product Manager’s job, especially when they are at the executive level. But with the right presentation, you can align executives to your vision. Here are five best practices that Google Product Leader, Ravikumar Gampala, has learned on the before, during, and after of executive presentations.
Ravikumar Gampala is a product professional with unique product expertise in building corporate applications. His proven leadership and capacity for solving complex business problems led him to Google, where he is currently a Group Product Manager. Ravikumar develops the product vision, strategy, and roadmap for Cloud Resource Life Cycle Management. During his 15 years at Google, he defined the Monetization product strategy in Emerging Markets, directing hundreds of Engineers and Product Managers to commercialize Google Search in emerging markets.
Ravi set the strategic vision for Search Ads & Sales Productivity, providing direction for 120+ Engineers, Product Managers, and UX Designers via roadmap planning and prioritization. Prior to this, he was a Group Product Manager at Oracle. He led a 20 person multi-disciplinary team to build system upgrade tools for Siebel Enterprise, launched a highly profitable business analytics product and enterprise reporting products—growing product revenue by 400% over 3 years.
5 Practices for Executive Presentations
I have organized a couple of stories split into either what to do before or during your presentation. The structure I will use for telling the stories will be the STAR-L format. First I’ll explain to you the situation. That is what ‘S’ stands for. And task and/or action is what was done or what was expected of the presenter. ‘R’ stands for the result which is what really happened. And finally, when we look back, what do we learn from their experience? So that is what I’m calling the STAR-L format. So without further ado, let’s get into the first story.
You might be interested in Storytelling in Product Management
1. Socialize the deck with “key players”
The first practice that I’m referring to here is socializing the deck with some “key” players. This means that your stakeholders are the beneficiaries of your product. If they have the opportunity to be present during your presentation, make sure that you share the deck with them ahead of time. Ensure that the decision-makers provide their feedback. You should hear their perspective so that they feel that they’re being heard and you feel that you heard them. These are two very important bidirectional communication aspects.
Check out: Communication Secrets for Product Leaders
The story that I’m sharing with you today is my own experience. When I was the product manager for sales revenue at Datamark, I inherited a product with lots of issues. So the first problem was that the data was incorrect at times. Therefore, people used to call it untrustworthy data. The second and another big problem was that the data was still when they were accessing it. This is more of a perception because users might feel that when they’re looking at the data, they’re looking at it as of a certain date or timestamp, but the reality does not match with the user’s expectation. That is what we can refer to as data staleness or the staleness of the data, or lack of freshness.
But then the task at hand for me was to basically come back with a proposal; how do we rebuild the revenue Datamark so that the data is fresh and so the metrics are reliable and trustworthy? Very simple to explain. Of course, I’m not trying to trivialize the difficulty involved in actually fixing these problems. So that basically defines the situation.
Since I’m very familiar with the problems because I’ve spoken to my stakeholders, I thought that there is no reason for me to revamp the known facts again with them. This is just my perspective. I’m not saying I’m right or wrong. Second, it’s their problem that I’m solving. So they should be on my side because we’re all trying to get the same problem solved. That was my thinking at the time.
We then walked into the presentation. Now, as soon as I started talking about the problems and not the solutions, my partners felt that I’m representing the problems in the wrong order. Specifically. I was talking about data freshness as a problem. And by no means was I saying that it was the main problem, or it was the fundamental problem. My sales and finance stakeholders started jumping in and saying that I need to fix the untrustworthiness aspect of the data first because that is a higher priority. And that I am presenting the problem in the wrong order. So I told them that this is just the list of problems, and I’m stating them here before we get to the solution part.
And of course, I’m always going to focus on what is the bigger and more important problem to fix, but that did not really go well as more and more people started picking on the fact that the issues are presented in a wrong order from their perspective. So there was nothing for me to argue. And soon enough, I was piled on by a lot of people who are saying the same thing from their perspective in a different way. As one might call it, I experienced the “pile on” effect for the first time. It was not pretty. So on one hand I was asking myself ‘why am I doing all this?’ I’m trying to build a product for the benefit of my stakeholders and they’re not on my side. But regardless of how I felt at that time, the presentation was partly successful and partly unsuccessful. I didn’t come out as a successful person from that presentation, but we still managed to go through the problem and the solutions which was a good thing.
Looking back, the learning from the experience is to get input and buy-in from your stakeholders because they are the ones who will support you when you’re presenting. That way, the executives will feel that you have the full support of your stakeholders. You’re not just representing their problems, but also capturing the priorities, the importance, and the value to stakeholders in the right order. So that is what I’d say is the biggest takeaway from this story: get feedback from your stakeholders prior to your presentation.
You might be interested in: Why Communication is Key in Product Management with Checkr’s PM
2. Collaborate to avoid obvious errors
The second story of the day is actually an interesting experience that one of my coworkers had gone through while I was watching along with the executives during one of the presentations.
The situation was that my coworker, another product manager, was presenting a so-called Budget Recommender to the sales and executives team. What this product is supposed to do is to look at an advertiser, their spending behavior in the past, their preferences, what would they like to achieve through the through campaigns and use a secret sauce to make a recommendation to them saying “This is how you should be splitting your budget dollars into search and into display.” So what the product is supposed to do is very straightforward and easy to explain. There was no confusion about it. My friend did a good job setting the context.
But as soon as he started talking about the product and its features, one of the executives asked for the link to the product to play around with. And my coworker has prominently displayed the data version of the product to play around with. Needless to say, some of the people in the room started playing with the product while my coworker started talking about the product features. So that was the situation.
What my coworker was seeking as part of the presentation was approval for a beta launch to the large advertisers. He was trying to make a case about why it makes sense in order to launch it for the benefit of large advertisers. But as soon he started talking beyond the second slide where he highlighted some of the key features of the product, one of the executives played around and used a search-only advertiser as an example to look up what the budget recommender would say.
Since the executive already knows, coming from the search advertising space, the expectation was that the product would automatically say $0 for display and all for search because that is the ground reality. Because the advertiser never believed in display advertising. They never expressed interest nor would run any campaign in display advertising. And it is very clear from their goals as well, that they wouldn’t want to put any money whatsoever on the display side of advertising. But interestingly, the product recommended a 50/50 split between search and display advertising.
As soon as that happened, the senior executor raised his hand and said “I looked up this X customer number, customer X, who is known to be a search-only advertiser. How come your recommender is saying to split 50/50 between this planned search?” My coworker was speechless for a moment. He was caught off guard because it was totally unexpected. And everyone in that room knew that the product did not do the right thing because it did not match the ground reality. So there was a pretty awkward silence for a few moments. And then my friend backed up quickly and abruptly closed the presentation saying that he would have to do some more homework along with his tech leads and then come back with a revised proposal. Until then he excused himself and the team and actually left the room.
This was a classic case of a problem that could have been prevented or could have been caught before if my friend sought help from one of the other product managers or the tech lead to do some spot checks right now. An extra pair of eyes to review and catch any obvious errors would’ve done the trick. And he could either have tweaked the product or bought some time to come back at a later time when the product did the right thing to match with the ground reality. Again, to reiterate. get some help before the presentation. Not from yourself because you would be so close to the product and the presentation that sometimes it is very hard to see the problem yourself. There is a reason I’m calling here very clearly an extra pair of eyes to review and catch any errors as a key takeaway.
3. Make sure you can explain the math!
I’m sure that a lot of you can relate to explaining the calculations of numbers, be it revenue impact, cost reduction or productivity impact. As part of your presentations, making a case on how your product would bring about that impact.
In this third story, I have done a presentation where my product was supposed to improve the sales productivity, such that in a 40 hour week, my product would cut down two hours of daytime in doing some unnecessary things that a salesperson could product clearly use to spend time with either a customer or pursuing an opportunity, which is seen as a more valuable investment for their time. So again, the situation was that I was presenting a case to sales and executives saying that my product would save two hours of a salesperson’s time on a weekly basis.
While explaining the numbers, the task at hand for me was to quantify what is the benefit, not just in terms of the number of hours, but to translate them into headcount, which is commonly used language that everyone was talking about at the time. So, that is what I was expected to do as part of this presentation. And what I did was to actually show the calculation of how two hours saving on a weekly basis for a 10,000 person sales team would result in 20,000 hours of savings. But what I did not do at that time was to show the math and how it would translate to 500 people headcount as the value or the impact.
So one of my executives caught me and said “Ravi, can you explain to me, how did you translate the 20,000 hours that you’re talking about as savings for the salesperson’s time equals to 500 people headcount?” It’s a very simple calculation and I knew this all along, but at that moment, under the scrutiny of very senior people, I blanked out because I did not really anticipate this question, and I was not prepared to explain how 20,000 hours of savings for sales would translate to 500 people as a headcount.
The math was very simple. When you divide 20,000 with 40, which is the hours in a week for a given headcount, you would get the actual number in terms of headcount, as I said, which was 500. So all I needed to do was to divide 20,000 with 40, and you get the answer. But at that moment, it didn’t occur to me. I looked like an idiot. And my coworkers and executives were not doubting what I showed them. They knew that there was a very clear way to explain it, but then, because I was not prepared to explain in a very simple way, I couldn’t explain the numbers properly.
So walking away from the experience now, if only I rehearsed very quickly how to explain a two-hour savings for a salesperson for a 10,000 people salespeople organization would equate to a 500 headcount. I would just present the math exactly as I did it. It’s very simple in hindsight to explain this. But the key takeaway here is that when you’re showing numbers, especially if they’re very simple, it’s very important for you to practice or rehearse. Find ways to explain any calculations in a simple manner. How exactly are you going to explain the numbers in a way that other people would understand?
4. Be enthusiastic to answer any questions
So my next story is very easy to relate to for most of the people here as well as for the product management community. Sometimes when being asked a lot of questions, we see it as a bad thing. It’s seen as if people don’t trust or believe you, or that you are having a tough time explaining what you’re trying to convey or communicate to your audience. But depending on the topic and the depth of it, sometimes it might require a lot of questions inherently as part of the topic. So as a general rule, it is better to expect. Being asked questions is a good thing, and it is a way to sense that your audience is engaging with you. They’re interested in the topic and they want the answers to difficult questions that they may have, and therefore they’re bringing up these questions.
So sometime back, one of my coworkers was presenting various levers that product owners can use to gain resource efficiency in their life cycle. What specifically we are talking about is when compute, storage and network are the infrastructure resources, which are used by every product, there are some levels that the product is providing that could be used by the product owners so that the resources are more efficiently used. This allows them to pack more workload with the same given resources. And the presentation was about how exactly the product owners get such benefits. And it was presented in a how-to style. So number one, do this. Second, do this, and these are the steps to do it and the amount of benefit you get from number two would be so and so… So that is the nature of the presentation and the situation was exactly, as I explained so far.
The audience was a lot of executives as well as the product owners. By product owners, we mean the likes of Google advertising, Google search, YouTube. These are all major enterprise-scale products that would need huge amounts of resources in geographically dispersed data centers in the form of abstract compute storage, and network, including main memory and SSD.
The task at hand for my coworker was to simply stick to the format and say, the first lever is to recompile your code, the production service so that it uses a smaller memory footprint and uses less amount of computation. And therefore this is how you benefit and the quantity, the magnitude of the benefit is so and so. And so on, so forth for level number two, level number three, et cetera. He did a fine job explaining all the levers.
Read next: Product Leadership Skills: Influence Without Authority
Because the topic is so involved, you can tell that this is not a very simple conversation. So people naturally had a lot of questions. And of course, my coworker also did a fantastic job by pointing out a link where there is a lot of Q&A or rather answers to commonly asked questions. The problem here was that people were looking at it for the first time. So it wouldn’t prevent them from asking a lot of clarifying questions and therefore they had to become part of that presentation.
So initially my friend was enthusiastic about supporting some of the questions, thinking that it is a way to sense the interest in the presentation and that the audience was engaged with him. But then he started getting annoyed very quickly because the number of questions started going up quite drastically, and he was being interrupted frequently. It could be sometimes in a case where you have been interrupted, but then you should have been prepared with a positive attitude that there may be a lot of questions and be prepared for other questions.
So far, we talked about the situation, the task, or the action expected of my friend. And the results, in this case, were the immense amount of questions and the frequent interruptions during the presentation. My friend had a dozen levers that he could talk about. But with all the interruptions, even getting through six of them would be a fairly good success, but he was nowhere close to that. It took an hour and he was hardly able to cover about six or sound slides. There was still a lot more to go.
Now, looking back, there are definitely a couple of learnings. The first was to send the slide deck ahead of time, along with the link to commonly asked questions and answers. But then again, you cannot expect that people would look at the link and be prepared before the presentation. People may have been busy with a lot of other things, so you cannot expect that. So what is a more important lesson from this experience is that you should solicit questions. You should put on a smiling face to answer them and be receptive to being asked and being interrupted. And this is one of the reasons that you should be prepared for twice the amount of time that you would need to talk for the overall presentation because half the time might be needed for the Q&A.
5. Keep it simple
So this last one is a cliche. A lot of people might tell you this, you might probably know this already, but I have a specific meaning behind it. Keep it simple. Let me just walk you through this story today.
One of my UX researchers was presenting the key findings from emerging markets on consumer research. The stakeholders, in this case, were UX, Engineers, Sales, Operations, and Executives. So that was the topic. The pre-work done by the UX team and product management was the research with small and medium-sized businesses in emerging markets about the expectation they have on search, how it would work and what their experiences are. The presentation was about a synthesized version of the key findings, not the laundry list of the research that we have done. So that is what the situation was.
Check this out: Why UX is Essential for PMs
The task at hand was to actually go through the research findings which were five or six different findings that had to be reviewed with the executives in a 30-minute presentation. And this was hardly enough time to go through any details, but just enough to cover the key findings in a summary format and then for any questions for half of the time. So in other words, in a 30 minutes presentation, we should have expected 15 minutes for Q&A and 15 minutes for going through the key findings. But my coworker started going off the script and thought that it was important to set the stage for us by talking about the use cases that we collected or rather the interviews that we captured in the emerging markets.
People had a lot of questions and by the time we reached half the allocated time, my coworker was still on slide number one, and we had not even covered the gist of the findings or the major findings that we uncovered from the emerging markets. So as a result, the half an hour felt like a complete waste of time because we couldn’t even get to what the key findings are.
The key learning from this is that as a presenter, you have to assess the key messages that you would like to communicate in a given amount of time. And in this particular case, the UX researcher had to present the findings which would have needed about 10 to 15 minutes of time. So he would’ve been better off kicking off the presentation with the key findings. Maybe even an executive summary of ‘we should have positioned the product in this manner because X, Y, and Z’ as the findings are the reasons. That would have captured the major part of the presentation and in five minutes, he could have covered the main goal of the presentation.
But when it comes to keeping it simple, what I meant was that based on the amount of time that you have and the specific message that you want to give, you have to get to the point as quickly as you can, and as succinctly as possible. Because first, you cover that aspect, then you are free to talk about any other tangential topics or the Q&A that people might have. So keeping it simple is about tailoring or making your presentation very targeted for a specific purpose: the audience, and the amount of time that we have. For example, in this case, the up-leveling, would’ve been a key takeaway because the executives were looking for what exactly we found in six months of research and you can’t go about talking about every nitty-gritty detail.
Having fewer slides and uploading the presentation beforehand would’ve been the right format. If we had more time to present, or if we had a workshop-style forum, it would have allowed my coworker to talk about a lot more in detail of the research that we have done and then get to the findings towards the end. But that was not the case here. To convey the main themes, it is not necessary that you need to hit the whole content. But it is more about hitting the key themes and getting them sooner than later as part of your presentation. So that concludes my fifth story of the day.