Written Narratives

One of the key roles of the leadership team in the company is to make clear decisions¹ and unlock decision making  on other organizational levels. Topics are frequently complex and need data and intricate relationships among them to describe the problem-space. Yet, many leadership teams are using presentations² to synchronize teams and describe the problem.

Before you frown and move one, because you never use PowerPoint, this article is really advocacy for using writing more. It is even more relevant in the time of AI coding-agents and spec-driven development  is on the rise. It is basically the same thing, instead of driving people, you are instructing AI agent. But one still need to do thinking, writing, and thinking in writing.

Spoiler alert: In this article, I am trying to advocate for having more long(er)-form writing present in organizations. I am not saying that people should not talk or meet in person, quite the contrary. My conviction is that writing is thinking³, which also means that I am vehemently against leading through presentations. Clear writing is even more important as AI tools are becoming part of day-to-day life.

What is Wrong with a Slide Deck?

Many sessions, where some impactful decision⁴ should be made, start with a presentation. The presenter is trying to describe the problem, the context, the data, the relationships, and the possible solutions. The audience is trying to follow the presenter, understand the problem, and make a decision; frequently interrupting the presenter with questions, comments, or suggestions, breaking the flow of the presentation, sometimes even derailing it completely.

Presentation Format

A big part is played by the form of the presentation. They can vary in design, but they all will consist of short blocks of text, bullet points, and occasional diagrams. Even the “How to deliver a great presentation” guides would urge going way below 50 words per slide, with a focus on visual reinforcement of a primarily verbal message⁵. Some presenters would solve the situation by going the complete opposite direction and defaulting to covering slides with text. Nevertheless, presentation format almost always follows very hierarchical, single-path structure.

And as the presenter runs out of the slide’s real estate quickly, they are pressed to fill in all the missing information verbally. Not only is this going to give way too much unfair advantage to more skilled presenters⁶, but it is also going to increase cognitive load on the audience’s side. Thus, success of the presentation is going to depend more on completely irrelevant factors, rather than the actual content.

One of the very famous events related to over-use of presentations as a communication tool was the shuttle Columbia accident. Final investigation reports are freely available and contain fascinating reading about information flows, basically organization-wide “telephone game”⁷:

As information gets passed up an organization hierarchy, from people who do analysis to mid-level managers to high-level leadership, key explanations and supporting information is filtered out. In this context, it is easy to understand how a senior manager might read this PowerPoint slide and not realize that it addresses a life-threatening situation.

— Columbia Accident Investigation Board, Report volume 1 (2003), page 191. Also referred to as a CAIB report.

Similar sentiment can be seen in the follow-up report from the Return to Flight Task Group:

We also observed that instead of concise engineering reports, decisions and their associated rationale are often contained solely within Microsoft PowerPoint® charts or emails. The CAIB report (Vol. I, pp. 182 and 191) criticized the use of PowerPoint as an engineering tool, and other professional organizations have also noted the increased use of this presentation software as a substitute for technical reports and other meaningful documentation. PowerPoint (and similar products by other vendors), as a method to provide talking points and present limited data to assembled groups, has its place in the engineering community; however, these presentations should never be allowed to replace, or even supplement, formal documentation. [….] It appears that many young engineers do not understand the need for, or know how to prepare, formal engineering documents such as reports, white papers, or analyses.

— Final Report of the Return to Flight Task Group (2005), page 190.

Information Density and Premature Generalization

Information density of the slide is rather low. The typical speaking speed for a presentation or speech is 125 to 150 words per minute⁸. In contrast, the average adult reads at a rate of about 200 to 300 words per minute⁹ when reading for comprehension. Furthermore, if our target number of words on one slide is about 50, and a typical technical report on one page has 500 words, we have 10x information density just on the number of words. This becomes apparent when a slide deck is printed on paper. As Edward Tufte pointed out:

The resolution of printed-out slide decks is remarkably low, approaching dementia.

— Edward R. Tufte; The Cognitive Style of PowerPoint: Pitching Out Corrupts Within (2006), page 26.

The small real estate and use of bullet points in presentations leads to another issue – premature generalization, vagueness. An analysis in the Harvard Business Review¹⁰ called bullet lists typically too generic and leaving the critical relationships unspecified.

I’ve seen so many times slides calling for solution to be “highly scalable” or “highly available” without going into any details¹¹.

Improving Presentations

I strongly believe that for serious presentations, we need to replace slides with a written narrative. The rest of the article is going to discuss a couple of potential styles. Even though their structure can be slightly different, they all benefit from the simple fact of being composed of full sentences and paragraphs.

Sometimes, a combination of written narrative and presentation is in place. Distribute the written part first, and then host a Q&A session supported with slides for getting the audience up to speed.

This is one of those simple but hard transitions, so it needs not only support from the leadership, but rather a direct executive order¹².

---

RFC (Request For Comments)

RFC stands for Request for Comments, a practice which powers key technical decisions about the Internet to this day through IETF. The RFC system was created by Steve Crocker in 1969 for ARPANET’s Network Working Group to capture notes. An approach similar to RFC has been adopted by many companies and open-source communities¹³.

RFCs serve as “living documents” that outline proposed technical designs or plans, inviting review and feedback from stakeholders before implementation. The fundamental purpose of RFCs extends beyond simple documentation – they represent a vehicle for asynchronous discussion. This is a key building block for any distributed team to collaborate.

Furthermore, an RFC should not be viewed as a request for permission, but rather “here is where we wanna go, are we missing something?” (as we have discussed in Who should decide? ).

RFC Structure

Your first RFC should be a RFC template¹⁴. As said, RFCs are living documents, so the template may (and should) change, but having an agreed template is essential to get things moving.

Start with a Problem statement. RFC follows and executes on your strategy , so start with a diagnosis (why you are even writing this RFC). Ask for comments right away. I’ve seen the “what is a problem” to be challenging, even more than the actual solution. Provide enough Background and Context so that anybody new to the document will be equipped with sufficient context to understand why the change is necessary. It should link to prior RFCs, discussions, tickets, and relevant documentation to avoid repetition while ensuring complete understanding.

Abandoned Ideas – rather than deleting discarded hypotheses¹⁵, RFCs should document why certain ideas were abandoned. This prevents future teams from walking the same path and falling into known pitfalls. Not to mention that half a year down the line, even the authors alone will not remember what was considered (and doesn’t need to be reconsidered and discussed again).

And finally the Proposal Overview. A clear (high-level) statement of the proposed solution, outlining the “how” at a high level while reserving detailed implementation for subsequent sections. Followed with Implementation Details. Section laying out rough API¹⁶ changes, UI changes, and overview affected subsystems.

Language

It may feel weird and way too formal, but it is worth checking out RFC 2119  which established specific terms and their meaning. Like “MUST,” “SHOULD,” and “MAY” to indicate requirement implementation levels, with each term carrying specific meanings that modify based on the document’s authority level. This standardization ensures that technical requirements are interpreted consistently across teams. Also, a shared dictionary of commonly used terms and their meaning is very helpful.

As many of us are non-native English speakers, I would recommend Technical Writing and Professional Communication: For Nonnative Speakers of English by Thomas N. Huckin and Leslie A. Olsen.

RFC Lifecycle

There is no one size fits all, but typically an RFC would go through multiple stages:

flowchart LR
  D(Draft) --> PR(Problem Review) --> SR(Solution Review) --> I(Implementation) --> M(Maintenance) --> S(Sunset)

Where Maintenance and Sunset are frequently missed. But it is important not to leave old RFCs to linger.

RFC Templates

• HashiCorp’s RFC Template 
• Squarespace’s RFC Template 
  • The Power of “Yes, if”: Iterating on our RFC Process 
• Architecture Decision Record (ADR)  has a slightly different structure, but they are closely related to RFC.
• Rust RFC Template 
• Tensorflow RFC Template 

PRD (Product Requirements Document)

What is PRD?

A Product Requirements Document serves as a blueprint that outlines a product’s functional and non-functional requirements, including its purpose, features, functionality, and behavior. It should be able to answer Why and What questions. A PRD should serve as a bridge among developers, designers, and stakeholders around a common vision while defining project boundaries to prevent scope creep.

A PRD hugely overlaps with an RFC or an ADR, it just has a different purpose, hence a slightly different structure. The idea of leveraging writing and feedback gathering is the same.

PRD Structure

The PRD’s main goal is to align all the involved parties. This is also reflected in its structure, the three main sections are – Problem Alignment, Solution Alignment, Launch (Plan) Alignment. Given the fact, that PRD should be read by people across the organization, it might be good to start with an Executive Summary¹⁷ for more complex PRDs.

In the Problem Alignment section we describe the problem at hand in a couple of sentences: why should the company care, why do customers care? Provide evidence supporting these claims. We should be able to tie the requirements to User Stories and Personas, which describe the target users¹⁸ in detail, including specific scenarios illustrating product interaction. We list Goals (short), showing must-have product behavior, with concrete measurable (== metrics) as well as unmeasurable (== feelings) goals. Also include a list of Non-Goals; similar to strategies and RFCs, listing what is not going to be addressed is very valuable. Explain why these are non-goals.

Having this section drafted is a great moment to ask for comments to validate that problem understanding is shared.

Solution Alignment is about defining the solution perimeter. The PRD/Product Manager is ideally the one who is in control of the scope, and others don’t need to figure it out. List the key features that are going to build up the solution. Again, be clear on the features’ scope, so teams can stay focused on delivery. Link out to detailed descriptions, RFCs, etc. Cover the common edge cases. Show the key flows, ideally how the end-to-end experience is going to look for the user. Include other parts (in less detail) of the product to highlight the context of the PRD/feature.

Launch Plan is not needed for smaller projects, but should be included for bigger initiatives. Do we need to have a pilot or beta release? If yes, what are going to be the criteria for moving to the next stage¹⁹?

Interaction Checklist

Good practice, especially in larger organizations, is to have an operational checklist, which covers potential for non-everyday interactions with other departments. Example of such a checklist:

Question	Department	Example Action
Do we need new/specific insights?	Data Science / Analytics	Work with person to figure what and how needs to be logged to produce such report.
Would this have impact on sales enablement?	Sales	Work with person.
Is this impacting our current marketing message? Can this impact our future messaging?	Marketing	Work with person.
Does this impact any shared KPI?	Impacted departments	Work with person on adjusting the goals.
Do we need to update training or support materials?	Customer Success / Support	Work with person on updates.
Do we need GTM plan?	Product Marketing	Work with person in advance, as these may need a lot of time.
Does it impact any channel partners?	Channel	Work with person on rollout plan.
Anything risky about this (e.g. new attack/reputation vector, GDPR, SOC2, etc. impact)?	Risk / Compliance	Work with person.
Any potential legal ramifications?	Legal	Work with person.

PRD Lifecycle

As usual, PRD goes through multiple stages:

flowchart LR
  D(Draft) --> PR(Problem Review) --> SR(Solution Review) --> LR(Launch Review) --> L(Launched) --> M(Maintenance) --> S(Sunset)

Every stage can (and should) introduce changes and updates. Ideally these are captured via some version control system. But even if you have it, it might be beneficial to keep a manual changelog section to highlight key changes for people who are not tracking it closely. The changelog doesn’t need to be detailed; it is really about prompting the reader to re-read sections, which they might have already read in the past.

PRDs Templates

Links to good PRD templates and other resources:

• Asana’s Product Brief Template 
• Figma’s PRD Template 
• Intercom’s Job Story Template 
• Product Hunt’s PRD Template 
• Shopify’s Product Marketing Brief Template 

---

Writing-First Culture and Written Narratives in the Wild

Several prominent technology companies have embraced a writing-first approach, recognizing the value of clear written communication for decision-making and knowledge sharing. Notable examples include Amazon, Basecamp, GitLab, Stripe, and Automattic.

Before diving into specific company examples, it’s worth starting with Edward Tufte  – a pioneer in information design and one of the earliest and most influential critics of presentation format and software²⁰.

Amazon’s Six-Page Narratives

Amazon is perhaps the most famous example of a writing-first culture. Jeff Bezos banned PowerPoint presentations in executive meetings, replacing them with six-page narrative documents. These documents begin with an executive summary and follow a clear structure that forces authors to think deeply about their proposals. The first 20-30 minutes of each meeting are spent in silence as attendees read the document, ensuring everyone has the same context before discussion begins.

He believes that a 6-pager is long enough to cover complex topics in detail, but short enough to maintain focus and clarity. This approach has become so fundamental to Amazon’s culture that it’s often cited as a key factor in their ability to make high-quality decisions at scale.

37signals

Basecamp/37signals has built their entire company culture around written communication . Their approach emphasizes long-form writing through tools like their own Basecamp product and HEY email platform. Jason Fried and David Heinemeier Hansson, the company’s founders, have consistently advocated for writing as a superior form of communication, particularly for remote teams.

Major decisions, product strategies, and even company-wide announcements are typically shared as detailed written documents rather than presentations or meetings. This approach allows for asynchronous work and thoughtful responses, which is crucial for their globally distributed team.

GitLab’s Public Handbook

GitLab takes transparency and written communication to another level with their publicly available handbook – a massive collection of documentation that details everything from company values to specific procedures. This “handbook-first” approach means that any significant decision or process must be documented in writing before it’s implemented.

The handbook serves multiple purposes: it’s a single source of truth for the company’s operations, it forces clear thinking about processes and decisions, and it enables their fully remote team to work effectively across time zones. The public nature of the handbook also serves as a powerful recruitment and onboarding tool, giving potential employees unprecedented insight into how the company operates.