© Illustration by Patrick Atkins.

Knowledge debt: the structural problem no tool will solve for you

A few years ago, Notion arrived in our teams like a foregone conclusion. One platform. Everyone in the same place. The roadmap, the specs, the research notes, the meeting summaries, the strategic decisions, the onboarding docs. No more scattered files, no more lost emails, no more “hang on, whose Drive is that in?” The promise was beautiful. It still is, on paper.

Except at some point, and that point always comes, the platform that was supposed to make everything accessible became the first place where we waste time.

I. The problem no one names

It’s not that the information isn’t there. It is. Somewhere.

It’s buried inside a sub-page of a sub-page of a space that was called “Product > Q3 2023 > Research > Interviews > Syntheses > V2-final-actually-final”. It was created by someone who’s no longer on the team, with a structure that made perfect sense to them at the time, in a context everyone has half-forgotten.

You search. You don’t find it. You start again from scratch.

And that cycle “search, fail, recreate” repeats itself dozens of times a week in teams that have made Notion their collective brain.

This isn’t just a feeling. The numbers back it up.

According to an Archimag survey from late 2024–early 2025, French office workers spend on average 8.65 hours per week searching for the information they need to do their jobs, nearly 450 hours per year. Across six countries and 12,000 office workers, employees spend nearly 540 hours per year looking for information essential to their activity.

Slite’s 2025 Enterprise Search Report, based on more than 100 knowledge workers worldwide, puts it even more starkly: teams lose a full month each year searching for information. Not hours. Not days. A month.

McKinsey Global Institute estimates that today, 19% of an employee’s time is spent searching for and gathering information, close to the older, widely cited figure of one full workday per week.

The real problem isn’t the volume of information. It’s that quantity ends up drowning relevance.

But when does information expire?

A piece of user research carried out three years ago, in a completely different product context, is it still a signal, or is it noise? When a tool doesn’t compel you to archive, delete, or qualify, everything accumulates without an expiry date. And the more it accumulates, the less usable it becomes.

II. The hidden problem: everyone organises differently

There’s something we rarely talk about, because it feels almost too human to be a product problem.

Even when a team agrees on a template, everyone still fills it in their own way. One person uses collapsible headings. Another nests three levels of bullet points inside a toggle. Someone else embeds a table where you’d expect plain text. None of it is wrong. All of it makes perfect sense to the person who wrote it.

But open that page as someone else, and it’s a different experience entirely.

Reading a Notion page built by a colleague isn’t just reading; it’s decoding. You’re not navigating information; you’re navigating someone else’s mental architecture. And when that person has left the team, or simply built the page six months ago in a sprint you weren’t part of, the cognitive load quietly doubles.

When structure and documentation are clear, new hires become productive 30–50% faster. In teams where knowledge is poorly structured, new hires can take 3–6 months longer to become fully productive.

Templates don’t solve this. They create a shared skeleton, but they can’t enforce a shared logic. Every team, every context, every individual brings their own interpretation of what “structured” means. A template that works perfectly for a growth team will feel completely foreign to a design team working on the same product.

This is the part that no tool audit ever catches, because it’s invisible until you’re the one sitting in front of a page that should take thirty seconds to read and you’re still there five minutes later, trying to work out where the actual decision is buried.

III. The developer counter-example and why it’s more nuanced than it looks

At this point, someone usually says, “Just look at how developers do it.”And it’s a fair observation. Developers tend to use dedicated tools for dedicated purposes. GitHub for code and version history. Linear for tickets and project tracking. Confluence, sometimes, for documentation. Nobody questions it. Nobody asks them to consolidate everything into a single workspace in the name of alignment.

There’s something revealing in the fact that developers, almost universally, resist using Notion for their core workflows. It’s not stubbornness. It’s that they already have tools built around the specific logic of what they do; tools that impose a structure, enforce a format, and make it genuinely hard to misuse them. When your version control system requires a commit message, you write a commit message. The tool has opinions. That’s a feature, not a limitation.

But let’s not romanticise it.

Developers aren’t necessarily satisfied with their stack either. The tension between Linear and Jira is real. Confluence is, by many accounts, its own labyrinth. The overlap between Linear tickets and Notion pages happens on the development side just as much as anywhere else. Choosing dedicated tools doesn’t automatically solve the underlying problem; it just shifts where the friction lives.

The honest takeaway isn’t “do what the developers do”.

It’s this: every use case deserves a tool that was actually built for it. A tool with a defined scope, a clear logic, and enough structure to make consistency the path of least resistance; not a blank canvas where everyone improvises.

IV. This isn’t an individual problem. It’s an organisational one.

Here’s the uncomfortable part.

Even if you’ve read this far and recognised every symptom, the labyrinthine sub-pages, the outdated research nobody’s archived, the colleague’s Notion page you couldn’t decode, there’s very little you can do about it on your own.

Choosing which tools a team uses isn’t a decision any single contributor gets to make. It’s structural.

It involves onboarding, existing integrations, muscle memory, and usually at least one person who built the current system and takes it personally when someone questions it.

Most product teams never consciously make this decision. The stack accumulates by default. Notion because the first PM liked it, Linear because the CTO insisted, a random Miro board because someone needed a whiteboard once, and it stuck.

Nobody sat down and asked: what do we actually need, for which use cases, and what are we willing to stop using?

That question feels disruptive. It shouldn’t.

Not asking it is what’s truly costly in time lost searching, in knowledge that quietly goes stale, in new team members who spend their first two weeks trying to understand a system that was never designed, only inherited.

The teams that get this right, and some do, treat their tool stack the way they treat their product. They audit it. They make intentional decisions. They accept that changing tools mid-flight is painful, but not as painful as five years of compounding entropy.

V. AI won’t fix a structural problem, it’ll just hide it

There’s a pattern emerging in tools like Notion that’s worth naming.

When search becomes too painful, we add AI summaries. When pages become impossible to navigate, we add AI assistants. When nobody can find the right information at the right time, we build agents to surface it automatically.

None of this is wrong, exactly. But it’s worth asking what problem we’re actually solving.

Adding an intelligence layer on top of a poorly structured knowledge base doesn’t resolve the underlying issue; it papers over it. The root cause remains intact: unqualified information, no expiry logic, no shared ownership. The AI becomes a workaround for a decision that was never made.

A bandage, in other words, on a wound that was never properly cleaned.

The most powerful AI features in the world can’t compensate for an organisation that hasn’t decided what information matters, who owns it, and when it should stop existing. That’s not a technology problem. It’s a design problem, and it requires a design response.

VI. So what does a design response look like?

The answer was in front of us the whole time.

Most product teams already maintain a system that requires exactly this kind of thinking. A design system. They know that a component without an owner becomes inconsistent within months. That governance imposed from the top gets ignored, but a co-design session creates shared logic that actually sticks. That an audit isn’t a failure, it’s maintenance.

A knowledge base deserves the same treatment. Not as a metaphor. As a method.

Don’t architect your information structure alone and hand it down. Run workshops. Bring in the people who will live inside it. Not to agree on a template, but to build a shared understanding of what the structure is actually trying to do. A template can be ignored. A logic that you helped define is much harder to abandon.

Ownership isn’t assigned, it’s generated. Through participation, through transparency, through being included in the decisions that shape the thing you’re asked to maintain.

Notion isn’t the villain here. Neither is Figma, or Linear, or any of the other tools that have become load-bearing infrastructure for modern product teams. The issue was never the tools themselves.

It’s that we asked them to do too much, without ever deciding what “too much” meant. We centralised everything and called it organisation. We accumulated everything and called it knowledge. We gave everyone a blank canvas, and were surprised when everyone painted something different.

The question worth asking before the next tool gets added to the stack, before the next AI feature gets bolted on to fix a problem that was never properly diagnosed, isn’t “where should this live?” It’s “what structure does this actually need, and do we have the shared logic to maintain it?”

That’s not a tool problem. It’s a design problem. And it has a design answer.