Your product team is rebuilding knowledge they already built. Every time a new engineer asks why the authentication module works the way it does, someone spends 20 minutes reconstructing context from memory. The context exists. It’s scattered across six tools and three people who might leave.
This is the product knowledge problem: not a shortage of information but a shortage of findable information. The decisions were made. The constraints were documented somewhere.
The prior attempts were logged in some meeting notes. None of it is organized in a form that’s accessible to the person who needs it right now.
The Three-Gap Product Knowledge Audit identifies where the knowledge gaps are before building the system to address them. This article is for the founding team where the product engineers spend measurable time rebuilding context that should already exist somewhere.
Why Product Knowledge Gets Scattered
The obvious failure mode: product decisions are made in conversations and meeting notes that become irretrievable within weeks. The engineer who made the decision remembers the reasoning for six months. By month seven, they’re reconstructing it from the same scattered sources as everyone else.
The less visible cost is repeated debates. The team relitigates the same architectural decisions every time a new engineer joins or a similar question arises. Not because the team can’t agree, but because the first decision was never recorded in a form anyone can cite.
The 30-minute debate is the symptom. The missing decision record is the cause.
The deepest failure is the exit risk. At an early-stage SaaS company, the founding engineers often carry a disproportionate share of the institutional product knowledge. They know why the database schema is structured the way it is, why the third-party integration was chosen over the in-house alternative. They know why the pricing model was designed for the current tier structure. When one of them leaves, some of that context goes with them permanently.
The Three-Gap Product Knowledge Audit
The audit identifies the three most common product knowledge gaps at early-stage SaaS companies. Each gap produces distinct symptoms.
Gap 1: Missing decision records
Decision records capture what was decided and why. Without them, decisions get revisited with each new team member.
The symptom: the same architectural question gets discussed in engineering review every few months. Nobody has a definitive answer. The discussion ends with “let’s look into it more” rather than “here’s the decision we made and why.”
The audit question for Gap 1: For the five most significant product decisions made in the last 18 months, is there a written record of why each decision was made and what alternatives were considered?
Gap 2: Missing constraint documentation
Constraint documentation captures what the product can and cannot do given current architecture, and why those constraints exist. Without it, new team members make proposals that are immediately rejected on grounds that weren’t documented anywhere.
The symptom: an engineer proposes a feature that would require rearchitecting a core component. The senior engineer knows why the architecture is constrained. The new engineer spent three weeks on a proposal that can’t be built without months of foundational work. Neither the constraint nor the reason for it was written down.
The audit question for Gap 2: What are the three most significant technical constraints affecting the current product? Are those constraints and their reasons documented somewhere findable?
Gap 3: Missing prior-attempt records
Prior-attempt documentation records what was tried before and what happened. Without it, the team repeats experiments that failed the last time.
The symptom: a new team member suggests an approach the team tried 18 months ago. The approach failed for specific reasons that weren’t documented. The team remembers it failed but not why. They either repeat the experiment or reject the proposal without being able to explain why.
The audit question for Gap 3: In the last two years, what are the three most significant product approaches the team tried and abandoned? Are those attempts and their failure modes documented?
How the Conductor Reveals the Gaps in Your Product Knowledge
Ask the Conductor a diagnostic question about your product knowledge gaps.
The Living Library doesn’t just hold what you’ve saved. When product documentation, decision records, and architecture notes have been added to the Library, the Conductor can surface the gaps. It identifies the decision records, constraint explanations, and prior-attempt documentation that are absent from what’s there.
Kiluma’s Conductor is context-aware AI. It reads from your specific Library, not from a general product management framework. When you ask “what product knowledge gaps do we have based on what’s in our Library?” the Conductor identifies the topics where team conversations exist but documentation doesn’t.
The product knowledge base that addresses these gaps is covered in Article 17. That article covers the system. This article is the diagnostic that tells you which gaps are largest.
Run the Three-Gap Audit Before Building Any Documentation System
Before building a product knowledge base, wiki, or documentation system, run the Three-Gap Audit. For each gap, identify the two most significant missing records.
This takes 60 minutes in conversation with the founding engineers. The output is a short list of six specific missing documents: two decision records, two constraint explanations, two prior-attempt records.
Those six documents are the starting point. Write them before designing any system to hold them.
If a Key Engineer Left Tomorrow, What Would Be Lost?
If the engineer who carries the most product context in their head gave notice today, what specific knowledge would disappear? How much of that knowledge is documented in a form that doesn’t require that person to find it? Try Kiluma free for 14 days at kiluma.ai.