Defining a Product Narrative

tl;dr: successful product-focused teams have a clear Product Narrative that defines who to build for, why to build for them, how to build it, and what to actually build. Moreover, a Narrative sets the direction for a team – a charter that unifies everyone together, identifying the target customers and their problems to be solved.

​

As a follow-up to my previous essay around why a vision is nothing without a strategy (which focused on how to build great products), I’ve gotten feedback that it would be interesting to talk about best practices on how to build a narrative. This also helps with the interview question: “ HMW: how might you improve X.” or "HMW you build Y." There’s no right answer here, and everything I’m going to share is based on personal experiences throughout my product management career (I recently helped orchestrate our team's product narrative at Dropbox during our offsite in March). It should nonetheless serve as a useful framework when needing to build your own teams’ long-term direction and ways to boost inspiration and morale for everyone involved.

Let’s begin by expanding the above diagram further:

The Who: Identifying The Customers

The life cycle of defining a Narrative always starts from who: the customer. Over and over companies that fail to define and empathize with their customers build the wrong products that don’t address any user needs. It involves building user personas and matching their specific use cases based on findings. Are going to serve older generations? Younger generations? Families? Individuals? Or, everyone? An example: Robinhood is clearly targeting demographics outside of Wall Street day traders (think uneducated investors, millenials), hence their mission to “..democratize access to the financial markets, and to inspire a new generation of investors.”

You can’t build any product without having customer empathy and knowing what kind of person you’ll build for. Full stop.

The Why: Understanding Their Problems

Next, it’s important to understand why it’s important to build for that defined customer segment. That generally gets answered by defining a clear problem statement (often called pain points or user needs) - in business terms, that’s market opportunity. There are effectively two tangible deliverables for this:

• User Journey: empathizing with the user experience by building a UX flow, doing user research and interviews is critical to knowing who you’re serving (example).
• Articulating Needs: after designing the user journey, you identify the bottlenecks, inefficiencies and gaps where there’s a potential opportunity to fill in or improve. We are not ideating or prioritizing here, but merely locating non-delightful experiences in customers today.

The best Product Managers out there think about this section the most. This is because it is debatably the hardest part of a product manager’s job; an example: there needs to be a damn good reason to convince Uber to invest millions of dollars into the future of flying cars. Here’s a potential user need for why: as congestion on roads and subways get worse, land commute is becoming more and more a traveler’s nightmare, giving rise to opportunities to disrupt the space above where demand is high (i.e. flying is now a norm) but supply is limited (i.e. the inefficiencies of airports).

This process requires the mindset of an analytical consultant integrated with product intuition. It presses the individual to the edge in terms of using data-backed reasoning with gut instinct, and generally results in a 2-year or more long bet in the industry’s future. Storytelling why Uber should lead the future of air transportation is hard, because if it flops, it ends up in a wasted 2-year effort - but if it succeeds, it can enable Uber to be the frontier of portable air travel for the next century. This is, after all, part of a Product Manager’s core competency: to influence the team through strong conviction that that is what we need to do.

The How: Deciding Where to Play & How to Win

Then, it’s critical to define how to address the customer problems - this involves many moving and constantly malleable pieces, and often requires a couple iterations before getting it right:

1. Mission: why our team exists / what’s our purpose in this company and the world? How do we make it a better place?
2. Insight: what about the world and our customers today can inform where we should play?
3. Strategy: how will we win? what problem scopes will we tackle?
4. Definitions: where will we play? who will we target first?
5. Vision: what is the big bold bet? (this can often be swapped in meaning with Mission)
6. Goals: KPIs (Key Performing Indicators) / success metrics; how will we measure impact?

Regardless how long the team lasts (a year, or 10 years..), the mission serves to define the purpose of why your team exists. For example: Google remains to organize the world’s information, and Facebook to make the world a more connected place.

Next is to ensure you are being informed of the world and your customers, related to the user problem you’ve identified. That involves gathering different kinds of insights: market insight, customer insight, competitive insight etc. For example: Microsoft Windows phones globally gets far less traction than Apple iOS (which itself is getting less traction than Google Android). We should therefore prioritize on building for iOS and Android first.

That then helps enable you to build your strategy: selecting which problem scopes to invest in based on understanding the customer problems today, prioritizing in order of what has the highest user impact. Example: Bird will focus purely on scooters in 2018, because there’s greater AMU: addressable market users, as well as a rising PMF: product market fit trend. Once it hits critical mass and we have a stable revenue stream, it’ll make sense to look into alternative last mile solutions like e-bikes, e-motos, et al.

For some companies, the strategy piece can take the longest to define. It also often encapsulates all of points 2.) and 4-6.), but for the purpose of this post, I’m breaking it down further to be helpful in explanation. The final steps involve scoping out what the big bold bet, or the vision, will be (e.g. SpaceX will enable humans to live on Mars), coupled with where to play, or the definitions (e.g. Didi targeting only users in China as it is far more lucrative domestically, or Strava focusing on Mobility surfaces like the phone or smartwatches as primary mediums for fitness tracking). Finally, there is the measurable component called goals (in the form of KPIs), which helps keep the overall strategy in check and ensures we can consistently measure impact (e.g. we will increase ads revenue by $1B, or we will measure whether we can increase DAU:MAU from 5% to 30% this year).

The What: Ideating What to Build
​
Lastly, it ends at what to actually build, which involves defining the actual product and the incremental steps it will take to launch it to the world. In this process, it is important to be cognizant of the following:

• Big Rocks: what are high-level initiatives we will build? (the forest v. the trees - was invented by Todd Jackson, previously VP of Product at Dropbox & Twitter)
• Roadmap: what are the incremental steps to take in order to build a product?
• OKRs (Objectives & Key Results): how will we track progress of our work?

Breaking down how to build a product can get very sophisticated, and requires constant iteration and collaboration with designers, engineers, marketing and more. First, it’s important what the big rocks are – the larger definitions of what’s going to be built, that isn’t easily defined as a single quarter or semester-long project; an example: Netflix must first build an experience where anyone can search, then stream, any movie at any time. That’s our MVP: minimal viable product. Let’s not build a chat system in-app for friends to talk about movies yet..

Next, we define the roadmap (often using Gantt charts defining what will get built and launched during when), which is effectively a reflection of the big rocks that will be built over the course of some timeline. The OKRs will help meet that roadmap’s timeline i.e. Objectives, that is tied to measurable trackers, i.e. Key Results, meant to influence progress by way of achieving ambitious targets (learn more about what OKRs are in John Doerr’s book: Measure What Matters, or this “Ode to OKRs” blog post by Tom Tunguz).

I love the below image because it represents well what big rocks can look like: the MVP big rock can be to first build a skateboard, but the OKRs are the actual steps like the board and wheels that will need to get fixed together. The roadmap is effectively steps 1.-5.), laid out over the course of a time frame:

Src: https://hackernoon.com/what-makes-a-great-product-manager-3c1d03b90356

All while defining these steps, we must be cognizant of other factors that can positively or negatively change what to build:

• GTM (go-to-market): Are you thinking of how to stage rollout your product, including A/B testing it? Branding? (e.g. test Snapchat in English-speaking countries like New Zealand before launching in the U.S.)
• Impact: Are you aware of the consequences of building your product? (e.g. Tesla auto-driving capabilities, if not well programmed, can result in casualties)
• Challenges/Risks: Are there any high costs, tradeoffs to make, or obstacles to the product (e.g. more Dropbox storage promotions for free users will result in higher data server maintenance, at the expense of increased CAC: customer acquisition costs).

​
These factors play a role in influencing how to build the product and can ultimately steer the direction of a product decision.

• • •

A Product Narrative is not to be confused with a Technical Strategy (generally led by a Tech Lead or Engineering Manager) – that focuses more on how an engineering team will achieve the tangible deliverable (e.g. building a new mobile app as required in the Product Narrative, will require investing in using the new language “Kotlin”, as well as adopting Android P). It focuses on the technical stack and platforms that will be built or leveraged in order to succeed.
​
Tying it all together, the criteria of a successful Narrative includes the following:

• Is easily communicable to everyone
• Tells a story why to build what for whom
• Is directly actionable how to do it 

Some other companies call this process a “Product Strategy”. Others call it simply the “Team Definition”. Regardless, they all serve the same purpose: building a thoughtful, clear and crisp charter for a team by way of a structured, analytical and strategic approach to solve a customer problem. It is also a means to de-risk failures and optimize on a team’s long-term success. 

read prev

Read Next