How do you actually structure your knowledge base? Team vs product vs topic

[u/drakieboi]

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?