Tribal knowledge: what it is, why product teams cannot document their way out, and what works.

What tribal knowledge is

Tribal knowledge is the unwritten, unofficial knowledge that a small group in an organisation holds and everyone else has to ask for. It is not in the wiki, not in the spec, not in the ticket. It is in the heads of the people who were there, and it is transferred by conversation, which means it is transferred slowly, inconsistently, and only to people who know to ask.

Every company has it. It is the default state of knowledge, because writing things down is work and talking is not. The term gets used alongside institutional knowledge and tacit knowledge, and they are not the same thing, which matters for what you do about it. Institutional knowledge is everything the organisation knows. Tribal knowledge is the unwritten part. Tacit knowledge is the part that is genuinely hard to put into words: judgement, taste, a feel for which customer means it. Most tribal knowledge is not tacit. It is perfectly ordinary information that was said once and never kept.

Tribal knowledge examples from a product team

Abstract definitions are easy to nod at. Here is what it looks like on a Tuesday.

• The reason behind a decision. Everyone knows the export is capped at 5,000 rows. Two people know it is because the estimate for 10,000 came back at three times the guess. When one of them leaves, the cap becomes a mystery, and the next person reopens it.
• The request that keeps coming. Sales has asked about a read-only role for finance four times, from three different prospects. Each time it was mentioned in a call. Nobody counted, so it never made the list.
• The definition everyone uses differently. "Activation" means a week-one return to the person who built the dashboard, and a signup to the person who reports the number. They argued about it in March and settled it in a standup. The standup is not where anyone looks.
• The open question. Andreas asked in the standup whether SSO users still get the verification email after the profile change. Nobody answered. Three weeks later a customer reports it.
• The customer context. The security team at one account wants a ninety-day retention default and will not sign without it. The account manager knows. The engineer about to change the retention logic does not.
• The thing that was tried. Two quarters ago the team tested card-at-signup and trials collapsed. The decision to put the card at upgrade came out of that. The test, and the lesson, live in a pricing review recording.
• Who to ask. Which engineer actually knows the data model. Which prospect escalates. What "soon" means from this team. This one is genuinely tacit, and it is the smallest category.

Notice what the first six have in common. Every one of them was said out loud, in a meeting, in front of other people. Only the last one lives purely in someone's head.

Why product teams have more of it than most

Product teams generate knowledge at the speed of conversation. A standup decides something. A customer call produces three requests. A planning session supersedes a decision from two weeks earlier. None of this waits for someone to write it down, and the person best placed to write it, the product manager, is also the person in all of those meetings and the one everyone messages afterwards for the answers.

So the product manager becomes the team's human FAQ: the place sales, support and engineering go to find out what was decided and why. That person is not a knowledge base; they are a bottleneck with a good memory. When they are on holiday, the team re-decides things. When they leave, the team starts over.

Why "document it" does not work

Every article on tribal knowledge ends the same way: identify who holds it, interview them, write it into a wiki or a set of procedures. For a factory process that changes twice a year, that works. For a product team it fails within a quarter, for three reasons.

The holder has the least time. The person who knows the most is in the most meetings. Asking them to also write it all down is asking for a second job from the one person who cannot take one.

The knowledge is created faster than it can be written. A wiki page written on Monday is wrong by Thursday's planning session. Nobody goes back to edit it, so the wiki slowly becomes a record of what used to be true, which is worse than no record, because it is confident.

The format is wrong for the questions. A wiki is organised by page. Questions arrive by product area and by situation: "what did we decide about retention?" The answer is spread across four meetings and a spec, and no page holds it.

Interviews and wikis are the right tool for the genuinely tacit column, the judgement and the relationships. They are the wrong tool for everything else, and everything else is most of it.

The part the standard advice misses

Look at the examples again. The reason for the export cap was said in planning on 19 March at 14:02. The read-only role was asked for in four recorded calls. The activation definition was settled in a standup. The open question was asked in a standup. The customer's retention requirement was stated on a call.

Every one of those meetings was recorded. Fireflies, Otter, Zoom's own recorder: most product teams have had a notetaker in every call for two years. The transcripts exist. They are filed by date, one per meeting, and opened once.

This changes what "capturing tribal knowledge" means. It is not an extraction problem, where you have to get knowledge out of people's heads. For the biggest category, it is a filing problem: the knowledge is already in text, and nobody has read it with the right question in mind.

How to capture tribal knowledge in a product team

A method that does not depend on the busiest person's spare time:

1. Record everything that is already being recorded. You almost certainly are. Make sure the customer calls are included, not just the internal ones; that is where the requests live.
2. Read the transcripts for four things. Decisions, with the reason given. Open questions, with whether they were answered. Customer requests, counted. Risks that were flagged. Ignore the rest.
3. File by product area, not by meeting. Nobody will ever ask what happened on 19 March. They will ask about billing. One place per area, with everything from every meeting that touched it.
4. Keep the source on every entry. The meeting, the moment, the person. An entry that cannot be checked is a rumour with good formatting, and the team will stop trusting it the first time it is wrong.
5. Supersede, never delete. When planning changes the cap, the old entry stays, marked superseded, pointing at the new one. The history is what makes the record believable.
6. Make it reachable where the questions are asked. If the answer still has to come through the product manager, you have moved the bottleneck, not removed it.

Done by hand, this is a few hours a week, which is why it does not happen by hand for long. It is, almost exactly, the job a machine should do.

Where Wisibl fits

This is the job Wisibl does. It reads the transcripts from Fireflies or by upload, plus the documents the team keeps, and files the decisions, reasons, open questions, requests and risks it finds under the product area they concern, with the moment they were said attached. When someone in sales or support or engineering asks a question, they get the answer with its source, or an honest "no decision on record", which is often the more useful of the two. The product manager stops being the FAQ.

It covers the middle column of the figure, which is most of the tribal knowledge in a product team. The right column, the judgement, is still yours. It always was.