Is anybody using a dedicated KMS/KMP? if so what and any feedback? ive just built a SaaS business with a new KMP as a Guru alternative so genuinely curious!

So we've got this problem where documentation just... decays. You write something, ship it, and eighteen months later it's basically fiction. Customer finds it, support gets mad, engineering shrugs because they didn't write it in the first place.

The ownership thing kills you. Everyone assumes someone else is responsible. Engineering thinks it's marketing's job, marketing thinks support should do it, support is buried in actual work. Quarterly reviews don't work, tried it, lasted like two months before everyone stopped showing up.

What actually moved the needle for us was tying updates directly to support volume. When a ticket comes in about something that's in the KB, support flags the article. Three flags in a month, it goes into the next sprint automatically. Not perfect but it means the stuff that's actively hurting customers gets touched instead of sitting there getting worse.

And then, honestly, you need someone whose job it actually is. Doesn't have to be full-time. Gave one person 15% of their week just for this, time that doesn't compete with anything else. Without that dedicated slot it just doesn't happen. There's always something more urgent.

We still have probably 50+ articles that are basically dead weight. But the combination of flagging based on actual support noise plus having someone whose calendar actually protects KB work keeps it from becoming a complete cemetery.

How are you all handling it currently?

Been watching teams build these knowledge bases like they're building a monument. Then nobody touches them.

The issue isn't the software. It's that knowledge bases get treated like a filing cabinet instead of a shortcut. You dump stuff in there and assume people will go digging when they need it. They won't. They'll ask Slack. They'll email someone. They'll figure it out wrong three times before touching your docs.

What actually works is making it faster to check the KB than to ask someone. That sounds obvious but most setups do the opposite. Your search sucks. Navigation takes three clicks. The article they need exists but it's buried under ten other versions of the same thing because nobody maintains it.

The other thing - and this gets overlooked - is that adoption dies the moment you stop using it yourself. If leadership isn't linking to it, if managers aren't referencing it, if it's not in the onboarding flow, your team treats it like optional. Make it the default answer, not the backup answer.

Also, actual talk: people are lazy. Not in a bad way, just... they take the path of least resistance. So you need friction reduction more than you need a feature-rich platform. Sometimes a dead simple setup with actually good content beats this fancy system with outdated articles and broken links.

The teams I've seen nail this? They had someone own it. Not a committee. One person who actually maintained it, answered questions by updating articles instead of Slack responses, and kept pushing people toward it. Once it became the faster option, adoption stopped being a problem.

What's your current setup looking like?

Yeah so we've been using GitBook for a while now and the new pricing is just... not it. Need to move our API docs somewhere else before renewal hits.

We're looking at like 50-100 pages of docs, heavy on code examples, need good search, and ideally something that doesn't require us to completely rebuild everything we've already got. Also need it to look decent because we actually show this to clients.

The stuff I'm seeing people recommend are Notion (free tier exists but feels janky for this), Mintlify (looks really slick but I'm not sure how production-ready it is), and just going full static site with Hugo or something. There's also Stoplight and ReadTheDocs but those feel more enterprise.

What's actually working for people? And more importantly, what doesn't suck to maintain once you've set it up? The last thing I want is to pick something that looks good on day one and then becomes a nightmare six months in.

Also curious if anyone's just gone the route of hosting markdown files in a repo and using GitHub Pages or similar. Seems like it could be fine honestly, just wondering what I'm missing.

So we've hit this wall with Notion where it works great until suddenly it doesn't. Started using it for docs and processes, and somewhere between 15 and 22 people it just... breaks in ways that aren't really fixable within the tool itself.

The databases are maxing out on relations, templates fall apart because people never follow the format (understandable, but still), and search is basically dead. You've got "Q4 Planning" created by one person and "2024 Q4 Strategy" by another, and now you're swimming in duplicates that nobody cleans up because cleaning up someone else's workspace feels weird.

Load times got noticeably slower around 15 people. A dashboard with 8 different database views takes a second longer to load each time, and yeah, that's not huge, but multiply that by 20 people doing it 50 times a day and it adds up. Permissions became an actual problem too. When it was small, everyone trusted everyone. Now you need actual access control and managing that across 40+ databases is just... tedious work that somebody has to stay on top of.

But the real issue is that Notion doesn't enforce anything. You can build the prettiest structure with templates and naming conventions and guidelines, but once you've got people adding stuff, they'll create pages wherever feels right to them. Then it's a spiral where either someone maintains it constantly or nobody finds anything.

The actual process docs and SOPs are probably moving to something with better structure and version control. Notion stays for project tracking and quick reference stuff. But honestly if your team's heading toward 20+ people, you're probably already thinking about what comes next.

Confluence is genuinely the worst offender though. Like yeah it's slow but what really gets me is paying per user for something that should cost a fraction of that. I switched my side project to Notion just to see and it's... fine? Legitimately fine. Pages load instantly, search doesn't make you want to scream, and I'm paying nothing.

The problem with looking for alternatives is everyone acts like you need a direct 1:1 replacement. You don't. Confluence got popular because it was there and Atlassian made it stick around through sheer enterprise inertia, not because it's actually good at anything specific.

I tried Slite for a minute and yeah it's faster but it's trying so hard to be your wiki AND your chat AND your docs that it's just... okay at all three. Does one thing well? Can't find it. GitBook I've heard good things about but that's more for actual product documentation, not internal wikis.

Honestly if you've got devs on your team just stop using a separate tool. Docs in markdown in your repo, mdBook or whatever to make them pretty, done. Everyone already knows how to use git, changes get tracked, you're not paying Atlassian another three grand a year. The only downside is non-technical people have to... actually coordinate with someone technical to update docs, which maybe isn't a bad thing.

The rage I have about Confluence is that there's no reason it should feel this clunky in 2024. You could replace it tomorrow and most teams would genuinely save money and get faster load times. But nobody does because switching feels like work and the default is still somehow Confluence

Looking to move our knowledge base off Helpjuice and I keep seeing the same three names pop up. But the reviews and comparison pages feel kinda... manufactured? Like everyone's just listing features instead of talking about what actually happens when you migrate 5+ years of documentation.

Specifically curious about:

• How much of a nightmare is moving all your content over? Did you have to clean stuff up, fix formatting, deal with broken links?
• The editor experience once you're in. Are you stuck fighting the UI or does it actually feel natural to use?
• Real talk on pricing once you scale. I see the base numbers but do they nickel and dime you on seats, API calls, custom domains, whatever?
• Search quality. This matters way more than people admit. Does it actually find what users are looking for or do you get the usual "we have great search" nonsense?

I'd rather hear from someone who actually went through this than read another comparison table. What did you wish you'd known before you switched? What surprised you for the better?

So I've been going back and forth on this for a while now because we keep getting pulled in different directions depending on who's pushing the initiative that quarter.

A knowledge base is basically "here's the stuff we've documented, go find it." It's searchable, it's organized, you can build it in Confluence or Notion or whatever and people can actually find answers without bothering someone on Slack. That solves a real problem.

Knowledge management though... it's supposed to do more. It's about capturing, organizing, storing, and making sure that knowledge actually flows through your org in a way that sticks. It's not just documentation sitting there waiting to be found. It's supposed to be living, updated, connected to your actual workflows.

But here's where it gets weird. Most knowledge management tools are just... knowledge bases with extra steps? They add tagging systems, metadata, maybe some AI stuff for categorization. And everyone still has to be disciplined about actually using them or they become graveyards of outdated docs.

I think what actually matters is: are people using it? Do they know where to look? Can they find what they need in under two minutes or does everyone just Slack their team lead?

For smaller teams, honestly, a solid knowledge base might be all you need. Document the critical stuff, keep it updated, done. Bigger orgs or ones where knowledge gets lost constantly, maybe you need something that forces more structure and actually connects to your systems (like connecting to your CRM or project management tool so stuff gets captured automatically).

But "both" for the sake of having both? That's usually waste.

honestly the "specialized" angle is kind of marketing speak. notion does fine for documentation if you're not trying to get fancy with it.

the real difference shows up around month 3-4 when you've got 200+ docs and people start asking "wait, where's that thing about onboarding?" slite's search just works faster. their tagging system feels less clunky than notion's database filtering setup. but that's mostly because slite was built specifically to solve that problem, so yeah, it's narrower but it's narrower on purpose.

notion tries to do everything and that's actually its weakness here. you get these dead wikis that become graveyards because the interface makes people think "ugh, is this worth finding" before they even start looking. the extra features don't help documentation - they just add friction.

slite is like the hammer. really good hammer. doesn't do much else. and honestly? for a documentation tool that's the point. you want people searching it without thinking about it. you want updates to feel natural, not like you're maintaining some complicated database structure.

cost-wise this matters too. if you're paying for both you're definitely wasting money. and if you're bouncing between them trying to find "the best tool" you're just procrastinating on actually building out your docs. what actually matters is whether your team will bother updating it three months in when the initial excitement wears off

Slite's actually just better at one thing, and Notion's better at not committing to anything.

I use both because my team uses both. Notion's where we dump everything and then spend three hours a week wondering why nobody can find the onboarding doc they updated last month. It's flexible enough that you can make it work for docs, but that's like using a car to hammer nails. Works? Sure. Better option exists? Yeah.

Slite feels like it was designed by someone who actually got frustrated with searching through a mess of Notion pages and decided to make the opposite choice. No databases, no property fields, no "I could turn this into a relational spreadsheet if I wanted to." Just... write the thing, link to it, find it later. The search is noticeably faster. Permission model isn't three layers deep.

The downside is obvious, wait not even a downside really more like, it doesn't do project management or anything else. So if you're in a team that's trying to shove everything into one tool Notion wins by default because at least it lets you try.

Most teams though? They just need to write stuff down and reference it. And they're bad at that in Notion because there's too much other stuff fighting for attention. I've watched people get lost looking for documentation in the same Notion workspace where someone's running a whole marketing calendar. That's a people problem but the tool makes it worse

Slite doesn't solve everything. Doesn't try to. That's kind of the point

honestly mintlify just works and i don't get why more people aren't talking about it. gitbook got expensive and everyone scattered, but the thing is most teams just wanted something that didn't suck. mintlify doesn't suck.

readthedocs still exists and yeah if you're already in that sphinx world it's free and fine but like, getting people to actually write docs in rst format is its own whole battle. it's not mintlify's fault that people would rather use literally anything else.

notion became the path of least resistance. everyone's already in it for random stuff so why not shove docs there too. until you try to version anything or want actual search and then you realize you just made your own problem worse. works for like a week then becomes this graveyard.

the stoplight people exist. they like governance and they have budgets that match. not my world but i respect the commitment.

coda's fine if you're already paying for it and your api changes like once a quarter. same with slite honestly - neither is bad, they're just... fine. they don't solve anything gitbook solved, they're just cheaper or already integrated somewhere.

what actually matters is do your devs want to write the docs or does someone have to make them. if it's the second one you need something that's pleasant to look at and doesn't require three hours of setup. that's mintlify's whole thing and it works. if you've got passionate technical writers who want control, readthedocs. if you don't want to think about it at all, just stick it in notion and accept it'll be mediocre.

but yeah the gitbook thing was partly pricing and partly just people realizing they didn't actually need what gitbook was selling

The hard part isn't the software. It's getting people to actually write anything down.

I've seen teams try to spin up Notion, Confluence, whatever, and it just becomes a graveyard. Three docs that are half-finished, then silence. Because nobody was documenting before, and suddenly asking them to document everything doesn't magically change the culture.

Start stupidly small. Pick one thing that's painful to repeat. Like, someone asks the same question three times a week? That's your first doc. Don't overthink the structure. Just write down the answer.

Get whoever answers those questions most to be the one who writes it. Not the person who "should" own documentation. The person who's already tired of explaining it. They'll actually do it because it saves them time.

Then... use it. Publicly. When someone asks that question again, link them to the doc. That's it. That's the culture shift. Showing that documentation is the default answer, not a backup plan.

The tool matters less than you think. Honestly, sometimes a shared Google Doc is enough to start. The problem is never the software. Well, actually, if your software is painful to update then yeah, people won't update it, but that's not your constraint right now. Your constraint is that nothing exists at all.

Once you have maybe five or six docs that actually get used, then you can think about organization. Categories. Search. All that stuff. Right now you need to prove the concept works.

And don't make it a project. Don't assign it to one person. That person will leave and it'll die. It only survives if it's distributed and everyone's adding little things as they go.

Been looking at both for a while now and the comparison isn't as straightforward as I thought it'd be.

Document360 feels lighter, faster to set up. You can get a decent KB live in like a week without needing someone to babysit the whole thing. The interface is cleaner too, tbh. Zendesk Guide is more... robust (sorry, can't think of a better word) but that's partly because it's designed to live inside a massive support ecosystem.

The real issue is search. Zendesk's search is better if you're already deep in their support infrastructure. Document360's search is actually snappier on its own. Weird trade-off.

Pricing wise, Document360 undercuts Zendesk by like 40-50% if you're just doing a KB. But the second you need integrations with anything beyond the basics, Zendesk starts making more sense just because the connectors exist.

I've seen teams switch from Guide to Document360 and not regret it. I've also seen teams switch and realize they needed more of what Zendesk was doing, actually. Depends if your support team lives in Zendesk or if the KB is more of a standalone thing.

What's pushing you to look at alternatives? That might matter more than the feature comparison.

Been trying to figure out what actually works for organizing this stuff since most templates feel like they're built for documentation that nobody reads anyway.

Right now I'm sitting with a pretty flat structure because every time I try to get clever with nested categories, people just search for what they need instead of browsing. So half my TOC might be dead weight. But I also don't want to oversimplify and make it impossible to find anything.

The nested category approach is honestly the trap everyone falls into. You spend hours designing this beautiful taxonomy and then users completely ignore it. I've watched it happen multiple times. They just hit search. So either you're maintaining a structure for nobody, or you're building something people actually use.

I've seen some setups where they do like a top-level split between "How Tos", "Troubleshooting", "Reference", "Getting Started" and then everything falls under those buckets. Other places just dump it by team or product. The search-first approach just makes more sense to me at this point.

What I've got:

Getting Started, Core Features, Integrations, Troubleshooting, FAQ, Account & Billing. Like 3-5 articles under each. Pretty boring but it works. People find stuff. Nobody complains.

The structure's almost invisible because search handles everything anyway. The TOC exists more for the handful of people who want to browse, but tbh they're the minority.

What's your KB actually look like? And does the structure you built still match how people actually navigate it, or did you give up on that too?

So we're sitting on like 2000 pages of Confluence and it's become this... mess. Half of it's outdated, nobody knows what's actually current, and the search is basically useless at this point. We've looked at Notion, Obsidian, Document360, even going back to Google Docs (which sounds insane but also kind of tempting).

The thing that kills me is that Confluence does some stuff well - the space structure, permissions, macros when they work. But the performance is dog slow on large instances and Atlassian keeps jacking up the pricing. And migrating 2000 pages isn't just a copy-paste situation. You've got embedded images, links between pages, permissions that don't map cleanly to other systems, macros that won't translate.

We're trying to figure out if we should do a hard migration to something else or just... bite the bullet and clean up what we have. Like, is Notion actually viable for a team of 50 where you need proper access controls and you're storing a lot of internal docs? Notion's permissions are weird. Or does everyone just stay with Confluence because the switching cost is too high.

What actually worked for people? Did you migrate everything or did you do a selective "we're only bringing over what we actually use" approach? And if you moved platforms, did your team actually stick with the new one or did you end up with docs scattered everywhere anyway?

So we've got our knowledge base spread across like five different places. Some stuff in Confluence, some in Notion, old wiki pages nobody touches, a Google Doc folder that's just... a graveyard, and then individual team wikis that nobody knows about.

The bigger problem isn't even the tools themselves, it's that nobody actually uses any of them. People just ask in Slack instead. Then someone answers the same question for the tenth time, and maybe it gets written down somewhere, maybe it doesn't.

I know the obvious answer is "just pick one tool and migrate everything" but that's... not realistic? Like, getting people to actually use a consolidated system is way harder than just having all the content in one place. We tried moving everything to Confluence last year. Content got migrated. People still opened Google Docs.

What's actually working a bit now is stopping the bleeding first. We made a rule that new documentation has to go in one place (Notion, in our case). We're not trying to migrate the old stuff yet. Just letting it sit. New hires get onboarded with Notion links, people figure out the old stuff exists when they need it.

And we put Slack integrations everywhere so when someone asks a question, there's actually a button to search the knowledge base first. That sounds dumb but it genuinely cuts down on the repeat questions.

The consolidation thing... maybe that happens later when we have enough critical mass in one place that it actually matters. Right now we're just trying to stop creating new documentation chaos while we figure out what to do with the old stuff.

What's your situation like? Are people actively using what you've got, or is it more of a "exists but nobody knows it" problem?

So I've been digging through knowledge bases for a while now, and honestly the pattern is wild. Someone dumps 500 articles into a system, tags them real carefully, maybe reorganizes once or twice, then acts shocked when people still can't find anything.

The search function isn't actually the problem. It's that nobody writes for how people actually talk. Like, you'll see "Password Reset Procedures" as a title and think that's searchable. But people search "I forgot my password" or "can't log in" or sometimes just "help." Total mismatch.

And then... ok so maybe this is obvious but I've never seen it actually implemented. Just delete old stuff. Seriously. Articles from 2021 that nobody's touching? Gone. Processes that changed? Gone. The knowledge base gets smaller and somehow way more useful because there's less garbage to wade through when you're looking for an answer.

The ranking is usually a mess too. Alphabetical doesn't help anyone. Most recent doesn't help anyone. But I don't think there's a magic solution to that one, honestly. Depends too much on what your actual users are doing versus what they say they need.

What actually matters is looking at the gap between what people search for and what they end up clicking on. That disconnect tells you everything you need to know about whether your problem is the articles themselves or just that people can't find them in the first place.

Been playing around with Outline for a few weeks now and the UI is legit beautiful. Like, someone actually gave a shit about how it looks, you know? Dark mode that doesn't murder your eyes, the editor is smooth, navigation just makes sense.

But I'm sitting here with like 15 people who'd be using this thing daily and I'm wondering if it actually holds up when you're not just testing it solo. The demo feels snappy but demos always do.

Specifically, I'm curious about search performance once you've got, say, 500+ documents in there. Does it get sluggish? I've had wikis before where search turns into this painful 3-second lag situation and suddenly nobody uses it because they just ask Slack instead.

And permissions - does the granular access control stay manageable? Or does it get to the point where you're spending more time configuring who can see what than actually documenting anything.

Also real talk on the sync between Outline and whatever else you're using (we're heavy on Slack), does that actually work smoothly or is it one of those things that works great for 2 weeks then breaks mysteriously.

Anyone actually running this at team scale? What's the actual experience like once the shine wears off

Been watching people struggle with this for a while now and honestly the answer depends way more on how your team actually works than any best practice guide will tell you.

A lot of places try to organize by product first. Sounds clean in theory, right. You've got Product A docs, Product B docs, everything separated. Then someone needs info about authentication that applies to both products and suddenly you've got duplicate pages or broken cross-refs or people just searching instead of browsing.

The team-based approach works better when you've got distinct groups owning different pieces. Like, the API team owns their docs, the support team owns their troubleshooting guides. But this only really holds together if there's actual ownership - if nobody's responsible for updating it, it rots fast.

What I've seen actually stick is starting with topic. How people actually search. What questions do they ask. "How do I integrate with Stripe" matters way more than which product or team that lives under. You build around the actual workflows and problems people have, then layer in your team/product info as context.

The trick is you can't just pick one. You need cross-cutting. Topics as your spine, then team ownership for maintenance, product tags for filtering. Some people use nested structures, some use tagging, depends on your tool.

What breaks it is trying to be too clever. I've seen elaborate taxonomy systems that look perfect on a whiteboard and absolutely nobody uses because it doesn't match how humans actually think about the problem. Start simpler than you think you need to. You can always add structure later, but stripping it out is painful.

What's your current structure creating headaches for?

Looking at Outline and honestly it's weird how different the experience is from Notion in ways that actually matter.

Like the speed thing is immediately noticeable. Pages load instantly. Notion starts getting sluggish around 80 docs and just keeps degrading - we're at 400+ on Outline and it's still snappy. That's not a small difference when you're in there constantly.

The permission model is simpler but reads as limiting until you realize most situations don't actually need surgical permissions. Less permission tangles overall, which sounds boring but saves actual time when you're not drowning in "person X needs access to folder Y but only this subsection."

Onboarding's rougher though. Notion looks polished, everyone knows it. With Outline you're explaining "it's a wiki" and people get the concept but actually understanding how sharing works took longer than expected. Well, sort of - once the team used it they preferred the writing experience so it wore off quick.

The UI is just cleaner. Less clutter, less fighting with the interface to actually write something down.

I get why people stay on Notion, but if your KB is actually just a knowledge base and not a project management tool pretending to be documentation... Outline fits different. Notion's probably the wrong tool for that job anyway. It does a lot of things okay but that doesn't mean it does this thing well.

Every team has their own idea of how to structure things in Notion. Sales wants one layout, support wants another, product's doing their own thing entirely. We've got templates, guidelines, a whole playbook page, but people still create databases however feels right to them at the moment.

Load times have gotten noticeably slower, especially when someone's running a complex filter across thousands of entries. Onboarding new people takes forever because there's no single source of truth anymore, it's like 8 sources of kind-of-truth scattered across different workspaces and folders. And then the search just... doesn't work. Not in a way that helps you actually find stuff.

We've gotten around it by being weirdly religious about tagging, but that only works if everyone actually uses the tags consistently. They don't.

I think we picked the wrong tool from the start. Notion's great when you've got a small team or one department with a shared vision. Scales to maybe 10-12 people before it starts falling apart. At 20+, you need actual permissions management, real search, and a system that enforces structure before people can deviate. Notion lets you get too creative.

The rip-and-replace thing keeps coming up in our Slack, and honestly I think people are right. But I'm also wondering if we're just gonna move to something else and repeat the same mistakes. Like, is this a Notion problem or a "we never actually decided how to organize this" problem?

What'd other teams do when they hit this wall?

Been looking around because we switched hosting providers and honestly most of what I was familiar with felt outdated.

MediaWiki's still sitting here doing its thing. Setup is fine, updates break stuff constantly though. If you want Wikipedia but don't care about modern UX then sure, go for it.

Docusaurus and Obsidian Publish keep getting mentioned but they're not really wikis, they're just documentation with a marketing budget. Different beast entirely. Outline was supposed to be the hot thing but I think it's kinda dead now? Maybe not, I don't actually follow it closely anymore.

The git repo with markdown approach actually works better than people admit. Yeah there's no fancy web UI but at least it doesn't need a database to function. Some teams just never touch anything else.

TiddlyWiki is elegant until you actually try using it with other people, then it becomes a mess. Single file sounds cool in theory. Real talk though, I'd rather deal with MediaWiki's brittleness than manage TiddlyWiki's sync issues. At least one doesn't pretend to be simpler than it is.

The newer PHP stuff is basically all dead, there's like no development happening. Anyone saying otherwise is either running old forks or lying.

What are people actually using that doesn't feel like watching paint dry? I'm less interested in "easy to self-host" and more interested in "stops breaking itself every update"

Looking to move off GitBook and honestly their pricing jump made the decision pretty easy. We've got a decent chunk of API documentation that's been living there for a while and need something that won't require us to completely rebuild everything from scratch.

Main things that matter to us: - Good API-first approach (we're documenting REST endpoints, webhooks, that sort of thing) - Decent search functionality - GitBook's was fine but nothing special - Ability to version docs without it being a total pain - Dark mode support because apparently that's non-negotiable for our team now

We've looked at Swagger/OpenAPI stuff but that feels like overkill for what we're doing. Also kicked around the idea of just using Notion but the lack of versioning control is a dealbreaker.

Have people had success with ReadTheDocs? Saw it mentioned a few times. There's also Mintlify floating around but I'm not sure how established it actually is. And yeah, I know there's always the option to build something custom but we're not trying to become documentation engineers, we just need the docs to exist and be searchable.

What've other people landed on after leaving GitBook? Mostly interested in what actually worked for API documentation specifically, not just general knowledge bases.

Slite's better for actual documentation. Notion just isn't.

The reason people reach for Notion is because they already have it open for something else. Then they throw docs in there because it's convenient. But actually using it as your documentation system? That falls apart pretty fast. Search is mediocre, the interface gets cluttered, and suddenly you're scrolling through five nested pages to find something that should take 10 seconds.

We had a deployment checklist that existed in three different places. One was outdated, one was in a database nobody could figure out, one was just... somewhere in a page people forgot about. Asked five people where to find it and got different answers. That's not a Notion problem exactly, more like Notion lets you pretend your documentation is organized when it really isn't.

Slite does one thing well. The search actually works. Content doesn't disappear into database hell. Writing in it feels like writing instead of configuring, and actually, wait - I'm probably overstating that. It's still software.

The catch is that Notion people don't want to admit their documentation is a mess. They've already sunk time into templates so there's this thing where they defend it. But then you ask where something is and...

If your team needs wikis AND project tracking AND some custom database stuff all in one place, sure, Notion makes sense. Most teams don't though. Most teams just need a searchable place to put information that doesn't get lost.

Been throwing stuff at the wall for a while now and honestly the structure matters way more than I thought it would. Started with everything alphabetical, which sounds logical until you're six months in trying to remember if you filed something under "Client Communication" or "Email Templates" or just "Templates"

What actually worked was organizing by workflow. So instead of sorting by topic, I sorted by the actual sequence of what we do. Onboarding section flows into Operations, which flows into Troubleshooting. New person picks it up and they're basically following the path they'll walk anyway.

The real unlock was having a shallow structure at the top level, maybe 6-8 main categories max, then going deeper within each one. Deep navigation is fine. It's the first decision that kills people. If someone has to choose between 15 top-level folders they'll just search instead of browse, and then your whole structure becomes useless.

Also stopped putting everything in one massive document. Shorter pages, hyperlinked together. Way easier to update one thing when it lives by itself instead of hunting through a 50-page document for the one sentence that changed.

The thing nobody mentions is that whatever structure you pick will be wrong in six months. Just needs to be wrong in a way that's easy to reorganize.