I’m incredibly fortunate to have had the opportunity to forge a career in product management for close to 12 years. Even with the ups and downs it invariably brings, it's a perfect fit for my interests. Like many, I enjoy taking on customer problems we've discovered and pursuing valuable solutions. However, this behaviour is far from my initial product management experience specifying the desired functionality in Product Requirements Documents, handing over the work to an engineering team, and reviewing the output. At this point, I had yet to understand the value of storytelling.
Fortunately, within a year, or two, I went through a company transformation workshop led by Marty Cagan. Then, I saw the proverbial light and read Inspired from cover to cover. The experience taught me that an empowered multi-discipline product development team with co-located members would outperform others when they can articulate the vision, customer problems and desired outcomes.
Fast forward a few years, I found myself stuck on how best to onboard, share and retain knowledge as team members rotated. When well organised, the structure of Sprints and the temporary nature of User Stories don't have a negative impact. We were well-versed in decomposing the problem, enhancing the product, and shipping frequently. We even established a pattern of release twice a week. Problems only arose when we needed to refer to something we'd learnt three or more months ago, which had since become assumed knowledge. As our work covered bulk data collection and ingestion, the typical answer to this problem was creating yet another page on the wiki to retain requirements in technical documentation for troubleshooting at a later time. Unfortunately, this documentation was only an artefact to help capture the development requirements for engineers and quality assurance. It said nothing about the customer or the intended purpose of the dataset. At the time, I felt this was a massive gap in my "product toolkit" and the team's knowledge.
As I see it, one of the many benefits of the web, especially social networks, is the serendipity of learning something helpful but unexpected. A personal example of this was coming across Karthik Raman's article, Why I started writing Product Narratives in 2017. Karthik recommends structuring your narratives in prose to describe the end-to-end experience of my product in a very conversational tone.
I adopted this idea and used the concept to construct a brief narrative for each User Story. By doing so, I can better outline the context of the problem and the outcome. Writing Product Narratives has helped me focus my mind, identify the core ideas worth solving, and shelve others to ship early. In addition, I’d recommend working through a process of seeking peer feedback to ensure the narrative team meets the objectives.
We use these narratives as the North Star to keep us honest while building out a significant change to the product. Then, when the product needs to go through a substantial change cycle, I start another narrative referencing the former to provide the background information and describe the desired solution our user sees. Working in this manner has made it easier to retain the big picture without writing gruelling specifications that colleagues seldom read in their totality.
I've carried on happily for several years, working in this fashion. It's been an excellent vehicle for writing high-level requirements in an accessible format before working through the details with UX Designers and Engineers. However, I sometimes pitch projects to our founders in light of reoccurring feedback from customers. While these aren't entire pivots and fit our product strategy, they take our roadmap in an unexpected direction. I noted that I wasn’t getting to the point quickly when communicating these opportunities upwards. After some reflection, I realised my storytelling wasn't hitting the mark. Fortunately, I watched a ProductTank talk by Harriet Patience-Davies that helped immensely.
Harriet gave a fascinating talk at ProductTank in November 2021, Driving a shared product vision and goal setting. Her presentation on storytelling introduced me to the logline concept. In Hollywood, loglines help sell a movie within a succinate sentence giving the reader a high-level summary.
When <flawed hero at start of the story> is forced to <call to adventure>, they have to <achieve or overcome something> or risk <losing everything>.
However, she points out we could adjust this structure for a product development team to read as follows.
A <company/team/product> must/needs to/wants to <take action> to <fix a problem/win new audience/reach objectives> or risk <the stakes>.
So why is this important? The trickiest thing about being a Product Manager is bringing everyone on the journey. The product narrative is a brilliant vehicle to communicate the ambition and relevant detail to product team members, who can then build upon this information to figure out the UI/UX and deliver working software that solves the problem definition. However, the logline format allows Product Managers to encapsulate the problem briefly and desired conclusion to capture the audience's attention. However, the people outside the product development team would gain the most from a logline format as you sell your team's solution to their problem.