In my articles about go to market, I always mention the importance of “customer stories.” These stories are a critical component of the knowledge that product management can provide to sales and marketing and sales engineers to help ensure sales success.
But, if you’re like me, maybe you aren’t so comfortable with “storytelling.” It was a big challenge for me once. To help you get a better at it, I’d like to share some useful storytelling tools I learned recently.
We’ll cover a basic storytelling structure in this article. In the next article, we’ll talk about how you can use these stories in various situations, including the go to market scenarios as well as others.
I’ve never felt that that I was a good storyteller. My family didn’t tell stories. (Unlike my wife’s family, for whom everything – even a trip to the supermarket – turns into a story.)
But I’ve always known that stories were important as a way to engage with people. And to some degree, I found that stories about my product were easier for me to tell.
But I learned some techniques recently that have really helped me tell better stories. I always thought storytelling was complicated, but this approach makes it much simpler.
It’s an easy structure for telling a story. You slot in the information you know and end up with a pretty good story. It’s nice to have a tool like that!
As you know, stories have beginnings, middles, and ends. It’s a truism, but it’s not that helpful to know that on its own.
What I learned recently was what to put in the beginning, what to put in the middle, and what to put in the end, to make a decent, engaging story.
This structure works well for stories around products. It also works well for the stories you might tell in a job interview, or on your resume.
The way it roughly works is this:
That makes everything seem a little easier, right? “There was this problem. I did these things to solve it. And we had this result.”
That turns out to be a good way to tell a basic story. It’s not the only way to tell a story but if you don’t otherwise have another approach, it’ll serve you well.
How does it work in practice? I’ll go through each section, and using an example show how to make a good story.
I’m going to start with the problem section, then the results section. Problems and results are often the hardest for us technologists, because a good story has a lot of emotional depth in the beginning and end. I’ll give you some guidance on how to generate those emotions in your story.
Then I’ll cover the solution section. Unlike the other two sections, we technologists often go overboard here – it’s the area we’re most comfortable. In fact, we love the solution section, and our biggest challenge is not overdoing it! We like giving a lot (too much) data about what we did, and how it worked, and how cool it was. We’re not as good at setting the problem up in a compelling way, and we’re not as good at talking about the results in a compelling way.
Think about a problem you might be having in your organization. A typical one is “we are having trouble selling, we can’t get a repeatable sales model, and we don’t have any sales growth.” That’s a problem many companies have. In itself it’s not a very compelling beginning. “Sales not growing” is a business problem. For most people, a business problem is not emotionally engaging in itself.
How do we make it more compelling? How do we give this problem an emotional hook?
Well, imagine you are the sales manager in this situation. For you, there’s definitely some emotional heft to “sales is not growing.” You’re probably going to lose your job if you don’t turn things around. You’re certainly not going to be promoted. You’re not going go to Club, your team isn’t going to make quota. And so on.
In fact, if you’re in a “sales is not growing” situation, there are a lot of bad potential outcomes if it continues. The worst is, “We will go out of business if we don’t grow sales.” Another is “We’re losing market share to competitors,” particularly if they are growing and we are shrinking.
Let’s restart the story, making use of these more compelling potential outcomes.
“Our sales were tanking! We were losing market share to our competitors, and my job was on the line.”
It’s a little bit longer. But it has a lot more bite.
What are the lessons?
I took the basic problem statement, which was just a fact, and I made it into an engaging, compelling kickoff for my story.
The key here is to think about the outcomes if this bad situation continues to exist. How will it suck for you, for the customer, for the company? And then make that part of the problem section of the story.
This works for all kinds of stories, not just losing sales. You can find dire outcomes, you can create vertical takeoffs, and you can talk about the bad personal outcomes if the situation is not fixed.
Let’s move on.
Now to make the story sound good, you need to be sure to tie the results back to the problem. Our sales were tanking, we were losing market share, I implied I might be fired any day, and I implied that the company might go under.
So, in your result statement, you want something like this:
“As a result, we’ve have consistently growing sales every quarter, and all the sales people are making quota. Not only that, we’ve taken market share from our competitors, and because it was such a successful program, the Sales organization invited me to come to Club with them – and I got a promotion.”
That is an outstanding result. It’s emotionally engaging. It ties back to all the parts of the problem statement, plus a little more. Going to Club was a bonus and a very emotionally engaging act of recognition for having done a good job.
The point of that example is that you want to make sure that your results tie back to your original problem.
Of course, the corollary is that you should only put challenges in the problem that are solved in the results.
This is the part we love as technologists. We love to go into great detail about all the things we did, and how great they were, and how cool our product features are, and how smart we are.
So, there are two main points about the solution part of the story.
First, you don’t have to go into great detail in the solution. It’s often better to give just a sketch of what you did, rather than the full Monty. Most people find the details of the solution somewhat boring. You want to avoid boring people. A good way to think about this is that you are leaving room for questions. After you share the problem, solution, and results you might get a question like “Oh, the middle part – tell me more about how you did that. I’d like to understand that better.” This is great because it keeps the conversation going.
The second point is that sometimes, when you are solving the problem, you find out that the real problem is something different and more important. This makes a great story line! (It’s used all the time in big Hollywood blockbusters.)
Not only do you solve the original problem, but you solve additional problems as well. These are problems that wouldn’t have been uncovered if you hadn’t found them.
For example, I often tell a story about helping a sales engineering team with their demo. They asked me to help them with their agile demo because I am an agile expert. As I worked with them, I realized the problem wasn’t their agile demo, it was how they were demoing. They were doing a feature-function demo, and never directly addressing the prospect’s problems to show how our product solved them. Instead of giving them a new agile demo, I trained them on how to give a solution-oriented demo. As a result sales immediately jumped.
The goal of the solution section – the middle of the story – is to show that what you know, or what your product does, addresses the problem. And if you find a deeper underlying problem during the solution portion, it also shows how smart you are.
This structure has an obvious name – Problem-Solution-Result. You can abbreviate it PSR.
In the next article I will drill down further on the PSR format. There are several different ways you can use this structure. I’ll show you how to use it for your go-to-market storytelling activities. In particular.
In the meantime, here are three steps to work on your storytelling skills:
I learned this PSR technique at a great networking program in Silicon Valley called ProMatch. It’s a job search and skills program for professionals who are between jobs and who need to brush up on their job finding skills. The PSR technique is one of their fundamental building blocks for developing resumes and interview skills.
Your host and author, Nils Davis, is a long-time product manager, consultant, trainer, and coach. He is the author of The Secret Product Manager Handbook, many blog posts, a series of video trainings on product management, and the occasional grilled pizza.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.