Written Narratives

I have started replying to some emails with “send me the prompt, please.” The problem is not that they used an LLM. The thing is that they skipped the thinking.

LLMs did not invent this. Slide decks got there first. One of the key roles of a leadership team is to make clear decisions¹ and unlock decision making  on other levels. The topics are complex. They need data and the intricate relationships among them. Yet many leadership teams synchronize through presentations². Bullet points then, prompts now.

Spoiler alert: This article is advocacy for more long(er)-form writing in organizations. Not less talking, quite the contrary. My conviction is that writing is thinking³. That is why I am against leading through presentations. It is also why I am against outsourcing the writing to an LLM. The same idea now powers spec-driven development ⁴. Instead of driving people, you are instructing an agent. The thinking still has to happen. In writing⁵.

What is Wrong with a Slide Deck?

Let’s start with the older shortcut. 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.

Writing in the Age of AI

Back to the “send me the prompt” email. There is nothing wrong with using LLMs for brainstorming, drafting, or reviewing your writing. Just don’t delegate the whole writing process to it. Please, be mindful of the reader. People can tell when the whole text was whisked up by an LLM. Bryan Cantrill calls it your intellectual fly being open . And be kind to yourself. Letting an LLM generate long text from a short prompt prevents you from thinking.

Every sentence is yours

Every sentence in the document should be your voice. It should not feel awkward to stand behind it. If your honest answer would be “Just ignore it, AI wrote it”, delete it. Or rewrite it.

Writing is thinking

Hopefully, this whole article helped to establish the idea that writing is actual thinking²³. Deep thinking. Writing about a topic improves your understanding of it, similar to teaching it. Producing long text or code is now trivial. The thinking that goes in⁴ is real value here.

High Signal-to-Noise Ratio

Antoine de Saint-Exupéry²⁴ wrote that perfection is reached “not when there is nothing more to add, but when there is nothing left to take away”. Longer is not better.

Be in your readers’ shoes

Your piece is written by one or maybe couple of people. It will be read by dozens. Answer their questions before they ask. A bit more context levels everyone up. Spending a bit more time making your document extra clear is a one-time cost that benefits many.

If somebody wrote it, read it

Somebody weighed every sentence in their doc. Running it through an LLM for a summary is almost rude. Especially the lazy “summarize this for me” prompt⁴. If everything is LLM-written, nobody reads it. If everything is LLM-summarized, nobody writes it.

Please, try not to be a meat proxy  between an LLM and your readers.