Narrative As Context
Companies live and die by the stories they tell.
Startups begin with a story. When a founder wakes up and says “I am going to change the world,” the next thought is a story. We frame and re-frame problems and apply our best storytelling to connect opportunities to our vision of the future. We draw narrative arcs between our vision and the product we want to build in order to justify why our solution is the right one to invest in, work on, or purchase from. Few of us are trained in storytelling, but how we wield our narrative skills determines how well our companies grow. There’s more to narrative than convincing others to do things: the foundation of a solid story is the context we use to frame the story itself. In order to show our audience a new reality, we first have to start with the reality they live in today. While wielded broadly by some, many founders limit their use of narrative to pitching their company, effectively limiting the spread of context through their organization. This may not be an issue in early days, but becomes a force of alienation and team siloing as companies scale.
A narrative refers to a structured or organized account of events, observations, and assertions that contribute to a coherent and meaningful storyline.
As product leaders we are tasked with using narrative to translate company goals into the language of the teams who build the product. The distinction is one of function more so than personnel: early startups expect leaders to be doers and doers to lead initiatives when required. When the functions are kept close like this, strategic context is well known across the teams and on-the-ground realities are well understood by leaders. When we encounter new information we are able to quickly integrate it into our thinking and update our narrative as required. There’s an organic aspect to this type of work: every person adapts their activities to a rapidly changing reality to ensure the organism is healthy and growing.
Shared Context
When a company scales, team functions naturally begin to specialize. Engineers are hired to write code and expected to participate only in the activities that support that responsibility. Product managers and designers are hired to define the product and ensure the product gets built according to the needs of the company. A C-suite is hired to bring structure and experience as the scope of varying functions becomes too big for a single founder or founding team to handle. Context is no longer shared between all members of the organization: it’s no longer possible for a founder to know what everyone is doing on a daily basis, and early employees who may have been heavily involved in high-level discussions are now tasked with more in-depth functional duties. This specialization can result in growing pains: communication may fail, teams (especially early ones) may feel alienated, and we begin to lose our way. Without the shared context won from standing shoulder-to-shoulder in the trenches, we risk losing focus and momentum. Somewhat ironically, this fracturing of context is due to the success of the company in its earlier stages. Rapid growth created by strong early teams leads to changes that ultimately dismantle the cohesion that led to their success. As with so much else, what got us to this inflection point will not serve us in the next stage of our company’s development.
Narratives are fundamental to human communication and understanding, as they allow us to make sense of the world and connect with one another.
In our scaled organization, the gap between strategic and tactical thinking is one of context, not competency. An executive sponsor may see a product effort as part of a broader strategy, but an engineer may lack that vantage point. In contrast, an engineer will have a keen sense of what’s possible with the technology the sponsor may not. However, the engineer is unlikely to recommend a technological approach that may serve the broader effort if they’re not aware of it. The executive’s lack of context may lead them to over-promise or sell short the effort as a whole. Neither individual is at fault for the lack of communication, but the teams they represent are not in sync. Downstream we may see products that meet local requirements but, because the engineering team lacked broader context, are not extensible in the way executives assumed. Engineers may find themselves the target of executive ire for pushing out deadlines when accounting for changes that executives assume are “small” but require significant work to accomplish.
Fractured Context
We can diagnose this condition by interviewing representatives of different functions, whose relative vantage points lead to unique frustrations:
[Extreme generalizations follow. Any resemblance to real people or organizations is unintentional, except where it’s not]
Engineers: “Leadership is out of touch. They can’t make up their minds. They don’t know what they want.”
Executives: “Things move so slowly around here. Why does it take so long to build things? Our Engineering team is opaque and uncommunicative.”
Product: “It’s difficult to get anything done because things keep changing. We keep taking on product and tech debt instead of fixing our mistakes.”
Design: “The product doesn’t even look like it was made by the same company.”
Someone, probably/definitely: “how is it possible that we have this many meetings and people still aren’t getting anything done?”
It’s exhausting to be in an organization like this. There tends to be a sense of “if only [person] would just listen, we could make things work!” But the reality is that the company has fallen out of sync with itself. Keeping in mind that orgs that do this are scaling due to their own success, it’s doubly important to address this issue before the company gets swept away in a cycle of dysfunctional but profitable inefficiency. Rather than expending additional energy, the best solution is instilling effective narrative communication habits into organizations before they begin to scale. Pushing early teams to become storytellers means investing in the success of every team they lead down the line.
Narrative Context
In the context of product, a narrative is a tool for ensuring everyone involved in a product effort shares a common understanding of the product’s purpose and direction. Simply put, it’s a way of explaining why we should build something. But the narrative process is helpful simply because of the way it makes us think. That means it’s applicable to all functions within an organization, especially where developing context is concerned.
A narrative has a beginning, a middle, and an end, where the beginning introduces the setting, the middle lays out the facts and conflicts, and the conclusion resolves these conflicts and provides closure to the story.
We can express the product narrative structure like this:
Set the table: We see X.
Describe the problem: Y is the problem that causes X.
Justify the problem: It’s worth solving because of A, B, and C
Describe the solution: We think Z is the right solution
Justify the solution: Doing Z will result in Q, P, R, which the company values.
What’s lovely about this structure is its flexibility. We can tell our story in 50 slides to the whole company, type it into a single page for a press release, or share it as a reminder in a couple sentences in a meeting. We can re-tool for various audiences, speakers, or ceremonies. Over the course of a large product initiative we may tell the narrative hundreds of times for dozens of different audiences. We naturally become over-communicators of context, allowing each audience the chance to understand our justification for undertaking the work we’re doing.
A well-created product narrative is a bridge between worlds. It’s a consensus-building tool that forces the speaker to provide context that speaks to the audience, prompting conversation by allowing the audience to connect their experiences to the new information being presented. By forcing us to assert the facts on the ground, we implicitly open the floor for discussion of unconsidered details and nuance, giving the storyteller a (free!) source of feedback to evolve and perfect their strategy. Not only are we conveying information and building understanding, we’re creating a more convincing argument each time we tell the story.
Empathy enhances the storytelling experience and allows the audience to emotionally engage with the product narrative in a meaningful way.
Telling a story is an inherently vulnerable act. Good storytellers have to summon the courage to assert not only their understanding of the world but also their understanding of the relevant facts for the audience. Leaders may balk at the expectation, dismissing the required empathy as unnecessary. Do-ers may find themselves feeling out of their depth applying their tactical frameworks to a broader view of the world. But this is precisely the point: by forcing functions to see through each other’s eyes we take a step towards a shared understanding of the world. Done properly, well-crafted narrative thrusts us back into the early startup world we came from: context is shared as a matter of course, part of the process of getting work done.
Narrative Applied
Implemented early, using narrative as the expected communication device within an organization helps frame the way each function does its work. It forces teams to consider the work of others as they move forward, allowing us to fill the gap left by our scale and specialized team functions.
Here are some concrete examples of how we can apply narrative to our daily work:
Engineering:
Sprint kickoffs and demos done in narrative style ensure we are all in the same place ahead of taking on new work or evaluating work we’ve just done.
Many teams already use narrative structure to handle post mortem and root cause analysis ceremonies. Doing so allows us to level-set on what we knew going in, what we learned, and what we’re going to do to avert future incidents.
Writing sprint tickets with enough context for anyone to pick them up and work on them (and in consistent style!) allows teams to work more flexibly and avoid architecture/design traps that cost us time and cause frustration.
Product:
I can’t imagine doing a product kickoff without a solid narrative. Many PMs will start with a problem statement and call it a day, but a fully formed narrative keeps teams engaged in the ceremony, especially when they’re from non-product functions.
When writing requirements, I expect my PMs to start in narrative format before adding the level of detail required to start work. Doing so allows a broader audience to ingest the information without needing to understand the specifics of the project. As a leader reading documents from multiple PMs on a daily basis, I can attest to the value of having a simple, consistent way of summing up an effort without having to call a meeting to have a document interpreted for me.
Planning Workshops are just a way of constructing narratives collaboratively. If we start the session with proper context, we can spend the workshop focused on exploring the problem space or brainstorming solutions. Without this level of focus we risk getting bogged down in “table setting” questions about what we are and are not talking about in the room. The result: follow-up meetings and low engagement from teams that feel they don’t have anything to add.
Design:
Honestly, designers are where I stole all of this from. A user experience has a beginning, a middle, and an end. The best designers empathize with customers to understand where they are in space/time/emotions when they use a thing, then describe the thing they’re using, then show what the user accomplished. At its core, this is simply another way of constructing a product narrative.
Marketing/Sales:
Go-to-market teams rely on every team that touched the product before them in order to effectively sell and retain customers. The best way to rally these teams around a campaign is to tell a compelling story about how the product impacts the lives of customers who buy it. If we lead with the customer context, customer need, and how the product must impact their lives, we open the door for questions about what is and is not relevant.
Sales folks are great storytellers by necessity, but there’s an almost legendary tension between sales and product teams where requirements gathering is concerned. Sales asks for new features that are keeping us from closing deals, product asks for justification. Sales gets frustrated because their experience is their justification. The best way to communicate this experience is a good narrative that explains in what context our customers need something they don’t currently have. Product is then able to determine how large the problem and opportunity may be through some exploration.
Executive Teams:
Ever been to a boring all-hands and thought, “is the [executive] speaking a different language?” Execs, like everyone else, tend to speak from their own context. But if done effectively, telling a story contextualized for the entire audience can be the cheapest way to motivate and build consensus around the cross-team efforts execs are likely to speak on. It also means people will want to come and listen.
Conclusion
This is not an exhaustive list. It’s meant to illustrate that narrative is praxis, not methodology. By expecting our teams to contextualize their work and communicate with a simple “i see x and it means y so we should do z” structure, we instill as a daily habit the act of reaching across teams. It’s by no means a magic bullet; silos will still form around projects or functions if we let them. But with a team that wields narrative in their work, we don’t need to teach the base skill of considering our work in context with the work of others.
Presenting your argument as a narrative with a clear conflict and resolution structure makes it easier to identify gaps in logic and reasoning.
If contextualizing our narrative tells us where we are, the narrative itself tells us where we want to go. Context exposes the facts as we see them, leading directly into a narrative that exposes the future as we want to create it. We cannot hide how we see the world from our teammates when we lay out the facts as context. When we tell our story, we cannot hide from ourselves the process by which we reached our conclusions. It’s a unique opportunity to strengthen an argument by viewing it holistically while scaffolding out the broader product effort itself. With this approach we can create a complete thought and argument without having all the charts and visuals needed to make a presentation. It’s orders of magnitude more valuable than cobbling together artifacts and adding a talk track: a narrative is a durable framework for all downstream activities, not a disposable backdrop for a single ceremony.
There’s so much else we could discuss regarding narrative are defined by the stories we tell, and our products are defined by us. From the first story a founder tells about how they’ll change the world, their narrative vision will define the future of their company. Whether we mean to tell stories or not, we are; we might as well tell good ones.
Sam Gimbel, formerly VP of Product at Clover and co-founder of Clark (acquired 2019), is a product consultant for mid-stage startups. He is still writing his own personal narrative.