In my last article I talked about the importance of the one on one coaching sessions between a manager and her product manager. That technique is about providing an ongoing mechanism for helping the product manager to reach his or her potential.
In this article, I’d like to discuss my single favorite coaching tool for helping product managers become exceptional: the written narrative.
But first I need to admit that of all the various coaching techniques I have and use, this one gets more resistance than any other technique. In fact, with more than a few people I have had to essentially force them.
It’s not so much that people doubt the effectiveness; it’s just that it can often be painful. And I’ve found that the people that need this technique the most, are the ones that resist it the most.
Product Managers have to make arguments all the time. Not so much for minor things but once things become costly and risky – good examples are large features and projects, and especially significant new efforts – there will naturally be many people that will question and challenge the work. Usually it’s the executives from across the company, but often it starts with convincing your own team.
The technique I’m talking about is writing out a narrative explaining your argument and recommendation.
To be clear, I am not talking about a spec of any sort. A spec is not intended to be a persuasive piece – it’s just a document describing the details of what you want built.
Rather, I’m talking about a document that describes the vision of what you’re trying to achieve, why this will be valuable for your customers and for your business, and your strategy for achieving this vision. If this narrative is done well, the reader will be both inspired and convinced.
One company that has made this written narrative the core of how they operate and innovate is Amazon. They have embraced this technique more than any other company I know, and I don’t think it’s a coincidence that they are one of the world’s most consistently innovative companies.
Here’s the thing. It’s not hard for you as product manager, in some kick-off meeting, to show a PowerPoint presentation, wave your hands, toss out some data points, and sound enthusiastic and confident. And then watch as the meeting degenerates into design by committee, or just as bad, everyone gets frustrated and just turns to the highest paid person in the room.
When this happens, it’s clear to me that the product manager did not do the necessary homework. The PM doesn’t truly know the topic. The argument is weak. The PM has not sufficiently considered and addressed the various perspectives and constraints.
What the written narrative does is make this obvious.
Many people have written about how the written narrative is core to Amazon’s innovation process, including from Jeff Bezos himself.
Former Netscape engineer, and long-time Amazonian Brad Porter shared a must-read article discussing the written narrative, and its role in unusually effective meetings and the broader decision making culture at Amazon in The Beauty of Amazon’s 6-Pager.
In How Amazon Innovates, the quote “When I begin to write, I realize that my ‘thoughts’ are usually a jumble of half-baked, incoherent impulses strung together with gaping logical holes between them,” sums up my experience both with my own writing, and the effect of forcing product managers I coach to get their logic down on paper.
We’ve all seen product managers stand up and bluster, and pretend to know what they’re talking about, but with the written narrative, as long-time Amazonian Stephenie Landry explains, “you can’t hide behind complexity, you actually have to work through it.”
As Brad concludes in his article, “Speed and scale are weapons and Amazon has already told everyone its secret… if only they have the discipline to implement it.”
Despite Amazon’s 25-year record of consistent technology-powered innovation, most companies I know would do nearly anything to avoid having to write out this type of narrative analysis and recommendation. Yet it’s one of the most valuable things they could do to both move faster and make better decisions.
This is why I emphasized the one on one technique first. Very few PM’s have the discipline to do this written narrative and confront the glaring holes in their arguments alone. However, if the manager is good, she can coach the PM through this process.
You might use this narrative to kick off decision meetings like Amazon does, or even if you decide you want to do that PowerPoint presentation, I promise you that if you first do a good job on the written narrative, then your presentation will be very easy to create and will flow directly from narrative; the presentation will be much better for it; and your visible preparation on the material will leave your audience justifiably impressed.
I had to be convinced of this myself early in my career, and I’m just grateful that I had a manager that pushed me well outside my comfort zone to do this. I’ve been a convert ever since.
When I am working on a new keynote presentation, I force myself to write out a full narrative first, iterate until it’s logical and compelling, test the narrative with people I respect and know will tell me the truth, and only then do I create the actual presentation.
If you’ve never tried this technique before, on your next significant effort, I hope you’ll give the written narrative technique a try. Expect it to be uncomfortable. Be sure to incorporate the perspectives of the members of your team and key stakeholders. Spend the time to make it clear, concise and compelling. I’m confident you’ll be a much stronger product manager as a result.
UPDATE: After this article was posted, several people asked me about details and examples, and coincidentally this article was just posted which does a good job of answering many of the logistical questions around the narrative.