Focus On the Problem, Not the Solution
One of my friends is the product manager for a set of data feeds that integrate her product with 3rd party systems. (Without going into specifics, this data is something like personnel data feeds, or financial data, or regulatory results.) They collect data from their customers, which they send to several 3rd parties. This has to be done in a timely way, with very high security and reliability, and errors are very problematic.
Now, this friend was asked to present the status of the data feed component, as well as her future plans, to a group of product leaders and executives. (You’ve probably had to do a “program review” like this yourself, so you know that simply the mention of a program review can strike fear in a product manager’s heart.)
From one perspective her software area is boring and annoying. She has to constantly make changes to her software to keep up with changes from the partners. They all use a "standard" format, but of course they each have their own versions of the standard. They have their own schedules for uploading, and so on. And occasionally she gets bad data from her customers, and has to reupload good data. And of course, sometimes her software has bugs that create errors all on its own.
The Program Review Template
The program review template used in this company has a little section for two lines on the "business value" of each program. But in reality, people fill those in a rather pro-forma way. Meaning that they are not very compelling, nor are they engaging. In fact, people for the most part either just ignore that section, or they read it out verbatim when presenting. Basically, a waste of space and breath, in most cases.
So, my friend asked me how she could make her program review better. First of all, how can she make it less boring? Or seem less boring? And how can she get the audience excited about her program and what it does?
This is not an uncommon situation - product managers often find themselves in reviews like this, with a provided template that makes it hard to tell the story.
Why Are We Doing This?
As I often do, I recommended she go back to the problem, the customer problem, that her software is solving. Customers come to her company for a particular service, and her data feeds are a fundamental component of providing that service.
If these feeds - boring as they are - aren’t working, then her company can’t provide the solution their customers are paying for.
If my friend didn’t or couldn't keep up with the changes from the partners and keep the uploads flowing in a timely manner then the value her company offers their customers would go way down.
She nodded in agreement.
Key Questions
What problem is that customer facing? What are the implications if the problem isn't solved? What are the implications if the solution doesn't work right, or isn't timely? Why did they come to her company for help solving that problem? What is the component of the problem that her solution solves?
By putting a brief story about this into her slide deck, before getting to the numbers, it significantly increases the audience’s interest. A story like this engages the audience, helps them put themselves into the client's shoes. They can start to feel the pain of not having the solution, and therefore start to feel the relief that comes from having a solution.
Engage Emotions With a Story, Then Justify With Facts
Once the customer’s story is laid out, she can follow up with some compelling numbers. The story helps put the numbers into context. Because every one of her customers might have an update to the data feeds every week, the scope is huge. And since we are in an era of instant gratification and Internet everything, the customers' expectation of responsiveness is very high.
That's the environment in which she is managing a constant stream of enhancements, changes driven by regulations, changes driven by partners, and fixing of defects.
Having set up her presentation in that way, when she talks about the enhancements, changes, and defect fixes she’s planning, they become much more compelling. At the end of the presentation, the audience will understand why this boring and annoying component of the business needs the daily attention of a product manager.
Important Considerations
This way of presenting the information about the “boring” data feeds might strike some in the audience as a diversion from “just the facts, ma’am” style of presenting. So I also advised my friend to be prepared for - and actually to pre-handle - potential objections.
“Pre-handling objections” is a powerful tool for persuasion. You put yourself in your audience’s shoes and try to understand what parts of your presentation will make them uncomfortable or will seem wrong to them. (You have to do this if you’re writing an article as well!)
The audience members might not even recognize consciously what’s making them uncomfortable. But they feel it happening during your presentation, so it reflects on you and your project or program.
But by raising and addressing the concerns yourself, you alleviate this discomfort, leaving them feeling much better about you and your program.
Some Concerns You Might Have
In this article I’m trying to persuade you to try a new way of giving a business presentation. You probably have some concerns. There are parts of this idea that make you uncomfortable. So, in a bit of a meta-level twist, in this section I’m going to “pre-handle your objections.”
I’ve come up with a few of the objections (or questions) you might have as you read this, and provided answers below:
- You have a template, you need to use it
- They don't allow me to put my own slides in
- They always ask about just the facts
- I don't have any stories
Objection: "Just use the template, darn it!"
What if you have a template, and you have to use it? And to make it even more challenging, what if you're only allowed that one slide? The eye-chart with all the data in it. What do you do then?
My recommendation is that you say something like the following:
“As I get started on my report on our progress, I just want to make sure everyone is level set on the background of this project. Really, the reason we're doing this is because of (here's where you tell a brief story about a user or client or someone who is impacted negatively if you don't do your thing).”
The idea is that you set everyone up to be thinking about your user and their problem. As you go through your report, talking about the numbers and user stories and things, relate those back to a) the story you opened with, and b) the company's strategy and objectives.
Objection: "Just tell us the facts please, no stories"
This is a little harder. I don't think people mostly mean this. What they mean is "tell us meaningful things." So, what is meaningful about the work you're doing? One thing that's meaningful is the number of customers you're affecting. Or the number of employees who are benefiting from your work, or how they are benefiting.
It's useful to know how fast the dev team is going, but you want to make sure the progress is in the right direction. It's very easy to end up going fast in the wrong direction, and that's something you want to show that you are not doing. In fact, if you present your information in that way, it puts other teams on notice that they have to become good at saying why they're working in the right direction, too. Everyone wins, in this case.
Objection: "I don't have any stories"
Where have I heard that before? Oh yeah, that's something I used to say all the time. And the fact is that there are always stories. Any project you're working on is there for a reason, whether it's a new product, or a feature, or a module, or an internal project. Something isn't working well for someone, and you are going to give them an alternative that's better than their current choices. This is true for any type of project - if it weren't true then it wouldn't have been OK'd, or it would be part of the plan.
You can depend on there being a story - you just have to find it. And usually this is not so hard. Think about what the user's or customer's life would be like without the thing you're building, and then how much better it will be with the thing you're building. That gap is the basis of a story.
(Conversely, if there is no gap, there might not be any reason to do this project! That's good information too.)
How You Can Start Being More Persuasive Today
You can use the same guidelines I gave my friend to make any presentations (or any content in general) more compelling and engaging. These techniques work even if you are constrained within a defined framework, and/or with a defined presentation template.
Tell a story: Even if you are the product manager for a "boring" feature or component, you can still create a persuasive and compelling story about the feature. The feature is there for a reason. It's solving a problem - an important problem - for someone. Tell that person's story and show what would happen if you didn't have the feature. To find it, you have to put yourself into your customers' shoes, understand their problems and pain, and their joy and relief at having their pain relieved.
Make the data meaningful and relatable: Put your numbers into context - how many customers do they represent, how often, and what does that scale mean?
Pre-handle objections: Put yourself in your customers’ shoes, empathize with their thinking, understand what they will question and what will make them uncomfortable, and address those issues during your presentation.
Feeling stuck? Go back: If you find that you can’t tell a good story about what you’re working on, you might have to revisit whether the project should exist at all.
I’m happy to report that my friend took my advice and applied it with great success. After her most recent presentation, several of the managers actually came up to her and complimented on her on making the data feeds project much more interesting and compelling. A wonderful side effect is that she has started to build a reputation as an excellent presenter.
By applying the ideas above, you too can build a reputation as a better, and eventually, an excellent presenter.
