Why I use Product Narrative and Loglines to aid my storytelling

Matthew Akino-Wittering

I feel incredibly fortunate that I've 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 that valuable solution. 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 hadn't yet understood the value of storytelling.

Luckily, this wasn't my experience for long. Within a year or two at Ask.com, 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 instilled in me that an empowered multi-discipline product development team with co-located members will outperform others when they can articulate the vision, customer problems and desired outcomes.

Fast forward a few years, I continually 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 failed 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 and 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 even used the concept to construct a brief narrative for each User Story. By doing so, I've found that I can better outline the context of the problem and the desired outcome. From my experience, I've found that writing Product Narratives has helped me focus my mind and identify the core ideas worth solving and shelve those for reexamination later. As I work through this process, I collaborate with others and seek feedback for peers and the product development team.

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 begin describing desired changes seen by our user. 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 like this quite happy for several years working in this fashion. It's been an excellent vehicle for writing up high-level requirements in an accessible format before working through the details with UX Designers and Engineers. However, I sometimes find myself pitching 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'm increasingly finding that I struggle to communicate these unwelcome projects upwards. After a bit of reflection, I realised that my storytelling wasn't hitting the mark for this audience.

Enter Harriet Patience-Davies. Harriet did a fascinating talk at the Driving a shared product vision and goal setting ProductTank in November 2021. 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. For example.

When <flawed hero at start of the story> is forced to <call to adventure> he/she has to <achieve or overcome something> or risk <losing everything>.

However, we could adjust this structure to read as follows for a product development team.

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? In my humble opinion-the trickiest bit about being a Product Manager is bringing everyone along with you. But as you find yourself talking to the different roles inside and outside your business. It will also be necessary to communicate accordingly at various stages. I believe 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 and desired conclusion in a pithy statement to capture the audience's attention. However, the people outside the product development team stand to gain the most from a logline format as you sell your team's solution to their problem.