Why Docs Aren't Enough for a Knowledge Base
1 February 2025
Editorial note: This post is from the early days of HappyHQ. Some of the ideas and details have since evolved, but these initial thoughts shaped how we think, so we're preserving and sharing them as written.
But First, Why Docs Rock!
We're not anti-docs—seriously! Docs are incredible. One of the earliest and most famous examples, the Rosetta Stone (c. 196 BC), bridged multiple ancient languages to communicate a royal decree. Throughout history, documents like the Magna Carta and the Declaration of Independence have shaped nations. And while not every doc rewrites history, docs are everywhere today—from shopping lists to product specs, ways of working, employee handbooks, and even this blog post.
Nowadays, we have so many great tools for creating and managing docs—Microsoft Word, Google Docs, Notion, Confluence, Obsidian, and even Slack with its new canvas feature. Industry-specific tools would add even more to the list. Writing docs has never been easier. The tools are lightweight, intuitive, and built for seamless collaboration.
A well-written doc can be powerful. It can align teams, build shared understanding, and provide clarity and motivation. But docs have their limits—especially when they’re expected to single-handedly capture everything in your knowledge base. Relying on docs alone puts too much weight on a single format, making knowledge harder to maintain, find, and act on.
Docs Need Their Chat Moment.
Imagine if the only way we could communicate was through email. It has its place, but it’s slower, more formal, and structured by default—salutations, signatures, and formatting. Attaching files works, but it's a bit clunky and awkward. Every email has a defined audience, and looping others in means juggling CCs, replies, forwards and endless nested threads.
Email now feels dated and cumbersome for collaboration. The rise of real-time chat platforms has been a major driver of this shift. While not without its own challenges (more on that in a future post), chat offers a faster, lighter, and easier alternative to email. This shift hasn’t made email obsolete—it’s made it better. By absorbing quick conversations, brainstorming, and real-time collaboration, chat has allowed email to focus on what it does best: structured, intentional communication—often with external audiences. (Now, if only it could shake off all the outbound drip spam.)
The knowledge base needs its own renaissance—but that doesn’t mean abandoning docs. Instead, docs should be one character in an expanded cast. Just as chat helped redefine email’s role, the right complementary tools can make docs more valuable, not less. We’ll explore what that cast might look like a little later. But first, let’s unpack why relying on docs alone is inherently limiting for knowledge bases and the teams that depend on them.
We're Asking Too Much Of Docs.
We think of knowledge bases as the home for everything teams need to know. A single place where shared understanding lives. But today's knowledge bases are built exclusively on docs. And docs, like practically everything else in this world, aren't great at everything.
1. A huge chunk of knowledge never makes it into a doc at all. We have this foundational assumption that all of our knowledge is in our knowledge base. But the reality is, it's not all there. In fact, it's not even close to all there. Roadmaps live in product tools, designs in Figma, decisions in Slack, debates in meetings, ideas in people’s heads. Trying to force all of this into docs is awkward and time-consuming.
2. Docs take too long, so we avoid or rush them. Writing a doc is like writing an email—it takes time. We need to work through a series of decisions. What are we trying to say? What needs to be included? What can we leave out? How should it be structured? Should we use headings? A template? Because docs take time, we either don’t write them at all (and lose knowledge entirely) or we rush through them (and end up with messy, half-baked docs that no one trusts).
3. Docs become a dumping ground for everything. When a doc is the only option, everything becomes a doc—even when it shouldn’t be. Articles to read, raw notes, early ideas, random links—shoved into docs simply because there’s no good alternative. Docs aren’t built for quick thoughts, ongoing discussions, or evolving ideas. But when they're our only medium, things that shouldn't be docs become docs. And when everything becomes a doc, the value of docs deteriorates. It becomes harder to tell what’s important. The signal-to-noise ratio tanks.
4. More docs = worse shared understanding. The more docs we create, the harder it is to find what matters. People can’t tell what’s important, what’s outdated, or where to even start looking. We assume they'll navigate the doc hierarchy a certain way, but in reality they might:
1️⃣ Click a direct link to a doc and never see the surrounding context
2️⃣ Use search, where outdated and irrelevant docs clutter the results
3️⃣ Ignore updates because notifications are too granular
Eventually, the knowledge base turns into a black hole. Someone becomes the de facto knowledge whisperer—the only person on the team who can actually find things.
5. Docs don’t evolve naturally. As docs are drafted, collaboration happens naturally. People contribute and our thinking evolves. But docs tend to follow a linear path from draft to final. A "final" doc captures knowledge at a moment in time, but final feels awkward when applied to most knowledge. And when everything feels final, nothing gets updated. People hesitate to "mess up" someone else's work. So instead of editing, they create a separate version. Now there are two docs with the same purpose. Then another. And another. Instead of a single source of truth, we have a pile of conflicting and outdated docs that are predisposed to becoming stale.
6. Docs are one size fits all. Different people need different information. But docs don’t work that way—they’re one-size-fits-all, which usually means too much information for everyone. Take a product spec. Engineers need technical details. PMs need the big picture. Designers need UX considerations. Customer support needs to know what’s changing for users. Instead of building docs specific to each audience, the doc just gets longer. The more audiences a doc tries to inform, the harder it is for anyone to find what’s relevant to them.
7. Freeform text is one dimensional. We rely on docs for all kinds of information—product specs, announcements, and blog posts. We also use them for things that follow a clear pattern—Q&As, glossaries, step-by-step guides, decisions, risks, and goals. Docs make it easy to write things down, but hard to capture, connect, and organize what matters. We can format text, but text is still just text. That means our docs (and our teams) lack crucial context behind the knowledge being shared. When someone edits the Q1 Goals doc, we have no way of knowing whether they corrected a typo or added a new goal. We also can't easily pull goals from this doc and compare them to last year's. It's all just text.
8. Docs aren't designed for action. Docs are great for capturing knowledge, but bad at helping us use it. Once something is written in a doc, it's up to us to track it down and figure out what to do with it. Take a product roadmap. We document features, priorities, and timelines. But when someone needs a status update, they dig through the docs, ask around, or manually rewrite the same information in a different format. The knowledge exists—it’s just stuck in docs. Writing something down is just the start. Teams need better ways to use this knowledge.
A Knowledge Base Built For Today.
Docs aren’t bad—they just aren't enough on their own.
Most of the problems we've talked about start to disappear when docs are supported by the right cast of characters—each designed to handle a different piece of how teams capture, access, evolve, and use their knowledge.
So what else does a knowledge base need?
Memories. A lighter, faster way to capture and share knowledge without turning it into a doc. Whether it's notes, work from somewhere else in the stack, or something with a little more structure (like a 'Decision'), adding a Memory should feel as easy as sending a message.
Streams. Memories flow into Streams. A simple, familiar way to keep knowledge organized around a topic, project, or event. Streams make it easier to find, share, and add to the knowledge within a team, without running into the side effects of docs.
AI Digests. Imagine if adding to your knowledge base also meant your updates were written for you. Project summaries, weekly trackers, audience-specific updates—all ready to go. AI that works with your knowledge should feel a little magical.
Discussions. Teams need a place to ask questions, share ideas, and work through proposals. Not lost in chat. Not buried in docs. Discussions should have a proper home—one that works alongside Memories, Streams, and everything else in your knowledge base.
Pages. A knowledge base wouldn't be a knowledge base without docs. But the docs that are left should be treated like a scarce resource. Fewer docs means higher-quality docs. And when docs are used intentionally, the important ones stand out.
It's Time For A Rethink.
At the end of the day, this isn't about whether or not to use docs. Docs aren't going anywhere. But with AI opening up new ways to capture and use knowledge, relying solely on docs feels more limiting than ever.
Our teams want to move faster and produce higher quality outcomes—without having to do more work. Making this a reality means rethinking the knowledge base. Teams need more choice. More intentional tools that fit the way they actually work. Whether it’s personal notes, team projects, or company-wide initiatives, working with knowledge shouldn’t feel like a chore.
When knowledge flows freely, everything improves. Teams move faster, stay aligned, and focus on what matters. There's less noise. Fewer distractions. Smoother collaboration. All key ingredients for happy, healthy, high-performing teams.