89. Documentation

Documentation is how a startup stops depending on memory.

It lets people join faster, customers get consistent answers, investors understand the business, and founders stop repeating the same explanation every week. Good documentation is not a huge wiki. It is the right information, written clearly, owned by someone, and used in real work.

The point of documentation is not to write everything down. The point is to reduce repeated confusion, preserve decisions, improve handoffs, and make the company less fragile.

The core documentation question is: what knowledge is repeated, risky, or decision-shaping enough that it should no longer live only in someone’s head or chat history?

What To Document Early

Start with the documents that remove repeated questions or reduce risk.

Document	Why it matters
Company overview	Helps new hires, advisors, and partners understand the business.
Current goals	Keeps the team focused on the same priorities.
ICP and customer notes	Preserves market learning.
Product specs	Reduces guessing and rework.
Decision log	Prevents relitigating old decisions.
Sales playbook	Turns founder learning into repeatable selling.
Support docs	Improves customer trust and reduces repeated founder support.
Hiring docs	Makes hiring less vibe-driven.
Finance and legal index	Saves pain during audits, diligence, taxes, and fundraising.

Do not create a large documentation system before you have a writing habit. Start small and useful.

Documentation Principles

Good startup documentation follows a few principles:

Write for the next person who will need context.
Keep docs close to the workflow where they are used.
Prefer short, current, useful docs over long, stale ones.
Give important docs an owner.
Record decisions, not just conclusions.
Delete or archive what nobody uses.
Use examples from real customers, calls, tickets, and projects.

The purpose is not completeness. The purpose is operational memory.

Company Wiki

The company wiki should answer basic questions:

What does the company do?
Who is the customer?
What are the current goals?
Who owns what?
What tools are used?
What meetings exist?
Where are decisions recorded?
Where are legal, finance, product, sales, and support docs?

If a new hire cannot understand the company in two hours of reading, the wiki is missing its job.

Source Of Truth Map

Every startup should know where truth lives.

Area	Source of truth
Company goals	Current goals doc or operating review
Product roadmap	Product planning doc or project board
Customer notes	CRM, research repository, or customer notes database
Sales pipeline	CRM
Support issues	Help desk or support tracker
Decisions	Decision log
Legal and finance records	Controlled shared drive or secure repository
Metrics	Dashboard with owner and definitions
Hiring	ATS, pipeline tracker, or hiring doc

If the same truth lives in three places, the company will eventually trust the wrong one. Decide which place wins.

Documentation Triage

Founders should not document everything. Document what is repeated, risky, expensive, or decision-shaping.

Use this triage:

If the knowledge is…	Document it as…
Repeated every week	FAQ, playbook, checklist, or onboarding doc.
Used for customer promises	Sales, support, pricing, security, or implementation doc.
Needed for a product decision	Spec, decision memo, research note, or roadmap note.
Needed for compliance, tax, payroll, ESOP, or contracts	Controlled record with owner and access rules.
Needed to understand why a decision happened	Decision log.
Needed to onboard someone	Role guide, company overview, or process doc.
Temporary project context	Project brief with owner and end date.
Just a conversation	Do not document unless it creates an action, decision, or reusable lesson.

This keeps documentation practical. A startup does not need a museum of every thought. It needs enough memory to prevent repeated confusion and expensive forgetting.

Product Specs

Product specs do not need to be long. They should explain:

Problem.
User.
Goal.
Scope.
Out of scope.
Flows.
Data.
Permissions.
Edge cases.
Analytics.
Launch plan.
Support impact.

A good spec prevents engineers from guessing what the founder meant. It also helps founders think before building.

Product Spec Template

A lightweight spec can use this shape:

Section	Prompt
Customer problem	What user pain are we solving?
Evidence	What customer calls, tickets, data, or sales signals support this?
Goal	What should be true after this ships?
Non-goals	What are we explicitly not solving?
User flow	How will the user experience it?
Edge cases	What can go wrong?
Data and permissions	What data is created, changed, exposed, or protected?
Success metric	How will we know it worked?
Launch and support	What must sales, support, or onboarding know?

The spec should answer the questions that would otherwise become rework.

Customer Notes

Customer notes should capture actual language, pain, workflow, objections, alternatives, buying process, and follow-up. Do not summarize everything into vague positivity.

Useful fields:

Customer segment.
Role.
Current workaround.
Pain.
Trigger.
Objection.
Buying process.
Exact phrases.
Next step.
Pattern observed.

Preserve quotes and patterns. Customer language improves positioning, sales, product, and support.

Customer Learning Repository

Customer notes are most useful when patterns can be found.

Tag notes by:

Segment.
Role.
Pain.
Current workaround.
Trigger.
Objection.
Competitor or alternative.
Buying process.
Feature request.
Churn risk.
Exact language.

Every month, review the repository and write a short “what customers taught us” memo. This is one of the cheapest ways to improve positioning, roadmap, sales scripts, onboarding, and support.

Sales And Support Docs

A sales playbook helps the company learn repeatability:

ICP.
Problem.
Discovery questions.
Demo flow.
Pricing.
Objections.
Follow-up.
Qualification.
CRM rules.
Examples of good calls.

Support docs reduce repeated founder support and improve trust:

Setup steps.
Known issues.
Troubleshooting.
Billing questions.
Security answers.
Data import guidance.
Escalation rules.

If support questions repeat, the answer belongs in a doc or product improvement.

Sales Playbook Maturity

The sales playbook should evolve as the founder learns.

Early version:

ICP hypothesis.
Problem statement.
Discovery questions.
Demo flow.
Common objections.
Follow-up template.
Lost-deal notes.

Later version:

Qualification rules.
Segment-specific messaging.
Pricing and packaging guidance.
Competitive positioning.
Security and procurement answers.
Case studies and proof.
CRM hygiene.
Hand-off to onboarding.

Do not write a polished sales playbook before the founder has sold manually. The playbook should capture reality, not imagination.

Decision Logs

Decision logs preserve why the company chose a path.

Include:

Date.
Owner.
Decision.
Options considered.
Reason.
Expected outcome.
Review trigger.
Reversal criteria.

Decision logs are especially useful when founders disagree, teams change, or old context disappears.

Meeting Notes That Matter

Most meeting notes are useless because they summarize discussion but not decisions.

Useful notes include:

Date and attendees.
Context.
Decision made.
Action items.
Owners.
Due dates.
Open questions.
Follow-up date.

If a meeting has no decision, action, or learning, ask whether it should exist.

What Belongs Outside The General Wiki

Some documents should not live in an open company wiki.

Keep controlled access for:

Cap table and shareholder records.
Board minutes and approvals.
ESOP grants and employee compensation.
Customer contracts and commercial terms.
Vendor contracts.
Payroll, tax, GST, TDS, and accounting records.
IP assignments.
Security incidents.
Sensitive customer data.
Acquisition, fundraising, or legal dispute materials.

The principle is simple: make operational knowledge easy to find, but protect sensitive records. Documentation should increase trust, not create data leakage.

Writing Culture

Writing is not about sounding polished. It is about making thinking visible.

A startup should write:

Memos for important decisions.
Async updates for progress.
Meeting notes for actions.
Customer summaries for learning.
Project briefs for execution.
Retrospectives for mistakes.
Investor updates for accountability.

Rule: if a decision affects more than one person for more than one week, write it down.

Async Updates

Async updates help remote, hybrid, and busy teams move without constant meetings.

A good async update says:

What changed?
Why does it matter?
What is blocked?
What decision is needed?
What will happen next?
Who owns it?
By when?

This is especially useful for product updates, customer escalations, weekly progress, hiring pipeline, investor asks, and cross-functional projects.

The founder should model this. If the founder communicates only through scattered voice notes, DMs, and hallway comments, the team will copy that chaos.

Keeping Docs Alive

Every important doc needs:

Owner.
Last updated date.
Source-of-truth status.
Review cadence.
Link from a central page.

Docs should be used inside workflows. Link them in onboarding, meetings, sales, support, and project work. If nobody uses a doc, either delete it or make it useful.

AI-Assisted Documentation Guardrails

AI can help founders draft docs quickly, but it can also create confident nonsense. Use AI as an assistant, not as the source of truth.

Good uses:

Turn rough notes into a clearer memo.
Summarize customer call transcripts after a human checks them.
Convert repeated support answers into a help article draft.
Create first drafts of checklists, onboarding docs, or project briefs.
Rewrite dense language into simpler English.

Bad uses:

Inventing policy without founder approval.
Summarizing legal, finance, or customer commitments without review.
Creating product specs without customer evidence.
Publishing support answers that nobody tested.
Generating a large wiki nobody owns.

Add a rule: every AI-generated doc needs a human owner, evidence check, and last-reviewed date. Speed is useful only if the result is trusted.

Documentation Maintenance

Documentation fails when maintenance is unclear.

Use a simple status:

Status	Meaning
Current	Can be relied on now.
Draft	Useful but not final.
Needs review	Likely outdated or incomplete.
Archived	Preserved for history, not current truth.

Put status and owner at the top of important docs. A stale doc with no warning is worse than no doc because it creates false confidence.

Every quarter, review:

Which docs were used?
Which docs caused confusion?
Which docs are duplicated?
Which docs should be deleted?
Which founder knowledge still needs capture?

India Angle

Indian startups often work with distributed teams, agencies, interns, contractors, and informal communication channels. Written context protects execution.

Documentation also helps when team members are in different cities, speak different first languages, or join from companies with very different work cultures. It reduces dependence on verbal explanation and founder availability.

Documentation matters during fundraising, audits, compliance, and exit diligence too. Cap table, incorporation, contracts, tax filings, IP assignments, payroll, ESOP records, and board records should not live in scattered personal folders.

For Indian companies, docs also protect against operational mess around invoices, GST records, vendor contracts, employee documents, ESOP paperwork, board approvals, and customer agreements. This is not glamorous work, but poor records become expensive during funding, audits, disputes, or acquisition conversations.

Treat legal and finance documents as controlled records, not general wiki pages. Access, ownership, and backups matter.

Common Documentation Mistakes

No source of truth.
Docs nobody reads.
Stale docs.
Too much process.
No owner.
Knowledge stuck in the founder’s head.
Important decisions hidden in chat.
Customer learning scattered across calls and notebooks.
Legal and finance records stored casually.
Writing docs but never linking them into work.
Using documentation to avoid decisions.
Creating a wiki so large nobody knows where truth lives.
Letting AI generate docs that nobody verifies.
Recording what happened but not why it happened.

Documentation Smell Test

Your documentation is working if:

New hires become useful faster.
Customer answers are more consistent.
Product work has fewer repeated clarifications.
Decisions do not need to be re-explained every week.
Founders repeat themselves less.
Support and sales learn from past customer conversations.
Fundraising or diligence does not require a panic search.

It is not working if everyone says “it is somewhere in Slack.”

Decision Memo Template

Every important decision should leave a small trail.

Use this template:

Field	Prompt
Decision	What did we decide?
Date	When was it decided?
Owner	Who owns execution?
Options considered	What alternatives were seriously considered?
Evidence	What customer, data, financial, or team evidence mattered?
Tradeoffs	What are we accepting?
Reversal criteria	What would make us revisit it?
Review date	When will we check?

The goal is not bureaucracy. It is memory. A startup forgets quickly when people, priorities, and markets change.

Documentation Ownership System

Every critical doc needs an owner and freshness rule.

Doc	Owner	Review rhythm
Company goals	Founder/COO	Weekly or monthly
Product roadmap	Product owner	Weekly
Sales playbook	Sales owner/founder	After every 5-10 serious calls
Customer notes repository	Founder/customer owner	Weekly
Support docs	Support/customer success owner	Monthly
Finance records	Finance owner/CA/founder	Monthly
Legal/IP docs	Founder/counsel	Quarterly or on change

If a document has no owner, it is a suggestion. If it has no review rhythm, it will become stale.

Founder Brain Download

Once a month, founders should extract knowledge stuck in their heads.

Prompts:

What do customers keep asking me privately?
What decision do people still route through me?
What explanation have I repeated three times?
What risk am I tracking that the team cannot see?
What context would a new hire need to avoid mistakes?

Turn the answers into docs, meeting topics, or delegated decisions.

Reader Action

Create five starter docs this week:

Company overview.
Current goals.
Customer and ICP notes.
Product decision log.
Operating rhythm.

Keep them short. Link them from one central page. Review them after two weeks and remove anything nobody uses.

Then add one rule: any repeated question gets answered once in writing. This single habit can build the documentation system naturally.

Documentation Map

Every startup needs a map of where truth lives. Without a map, the team wastes time searching and eventually stops trusting docs.

Create a simple documentation map:

Category	Source of truth	Owner	Notes
Company goals
Product roadmap
Customer notes
Sales playbook
Support docs
Hiring process
Finance records			Controlled access
Legal/IP records			Controlled access
Decision log

The map matters more than the tool. Whether you use Notion, Google Drive, GitHub, Linear, a CRM, or a folder structure, people should know where the trusted version lives.

Documentation Cleanup Sprint

When docs become messy, run a cleanup sprint instead of creating another wiki.

Steps:

List the top 20 docs or folders people use.
Mark each as current, draft, needs review, duplicate, or archive.
Pick owners for critical docs.
Delete or archive duplicates.
Add last-reviewed dates.
Link important docs from one home page.
Add a rule for future doc creation.

Do not aim for perfect documentation. Aim for trusted documentation. A small set of reliable docs beats a large graveyard of abandoned pages.

Meeting-To-Doc Rule

Some meetings should produce documentation automatically:

Meeting	Doc output
Product decision	Decision memo or roadmap update
Customer review	Customer notes, objections, or support themes
Sales review	Pipeline changes, win/loss notes, playbook update
Hiring interview	Candidate scorecard
Board/advisor update	Metrics snapshot and open questions
Incident review	Incident note and prevention actions

If a meeting creates important knowledge but no record, the company will pay the same thinking cost again.

Founder Knowledge Risk

Founder knowledge is a company asset and a company risk.

High-risk knowledge includes:

Why a product direction was rejected.
Which customers are unhappy but quiet.
What an investor or advisor warned about.
Which sales objection keeps repeating.
How pricing is actually negotiated.
Which compliance or finance task cannot slip.
Which employee needs feedback.

Capture the knowledge that would hurt if the founder was unavailable for two weeks. That is the practical test.

Documentation Decay Review

Docs decay silently. A document that was true three months ago can become dangerous if the team still trusts it.

Run a monthly decay review for critical docs:

Doc Type	Decay Signal	Review Question
Goals	Priorities changed but doc did not.	Does this still match current company focus?
Product spec	Shipped behavior differs from spec.	Is the spec historical or current?
Sales playbook	Sales team ignores it.	Does it reflect actual objections and winning language?
Support doc	Customers ask questions the doc claims to answer.	Is the answer clear and current?
Onboarding doc	New hires keep asking the same questions.	What context is missing?
Decision log	Decisions are made in chat but not recorded.	Which decisions need a record?
Finance/admin doc	Owner changed or process moved.	Who owns this now?

Mark each critical doc:

Current.
Needs review.
Historical.
Archive.

A historical doc is not bad. It becomes bad only when people think it is current.

Documentation Minimums By Stage

Documentation should grow with stage. Too little creates chaos. Too much creates a graveyard.

Stage	Minimum Docs
Two founders	Decision log, customer notes, weekly priorities, runway/cash notes.
MVP	Product scope, bugs/issues, customer learning repository, onboarding checklist.
First revenue	Sales notes, pricing notes, support themes, customer success checklist.
First hires	Company overview, role expectations, how work gets reviewed, tools map.
Funded team	Monthly metrics, investor updates, hiring process, approval/decision rules.
Growth	Function playbooks, incident reviews, management rituals, security/access docs.

Do not document because documentation sounds mature. Document what prevents repeated mistakes and unlocks delegation.

The “One Reader” Rule

Every important doc should name its primary reader.

Doc	Primary Reader	Job Of The Doc
Product spec	Engineer/designer/product owner.	Clarify what to build and why.
Customer note	Founder/product/GTM.	Preserve market learning.
Sales playbook	Person selling.	Help them qualify and handle objections.
Support doc	Customer or support owner.	Resolve a repeated question quickly.
Decision memo	Future team.	Explain why a decision was made.
Onboarding doc	New hire.	Help them become useful faster.

If a document is written for everyone, it is often useful to no one. Write for the reader who will make a better decision because the doc exists.

Decision Brief For High-Stakes Choices

Founders should not write long memos for every decision. But high-stakes choices deserve enough context that future teammates can understand why the company moved.

Use this template:

Decision:
Owner:
Date:

Context:
What is happening and why does it matter now?

Options considered:
1.
2.
3.

Decision criteria:
What matters most: speed, cash, customer value, risk, learning, quality, morale?

Chosen option:
What are we doing?

Tradeoffs:
What are we deliberately not doing?

Review trigger:
When should we revisit this decision?

The tradeoff section is the most important. Teams waste time when they reopen old ideas without knowing why those ideas were rejected.

Documentation Quality Checklist

Before calling a document done, check whether it can actually be used.

Question	Why it matters
Who is the reader?	Prevents generic writing.
What decision or action should the doc support?	Keeps the doc useful.
Is the source of truth clear?	Prevents duplicate versions.
Is there an owner and review date?	Prevents decay.
Does it include enough context for a new person?	Reduces founder dependency.
Are links, numbers, and examples current?	Protects trust.
Is the doc shorter than the repeated explanation it replaces?	Keeps documentation lightweight.

Good documentation should reduce future meetings, repeated questions, onboarding confusion, and decision drift. If it does not do any of those, it may be documentation theatre.

Source Of Truth Ownership Review

As the team grows, upgrade the basic source of truth map into an ownership review. This tells the team not only where the current version lives, but who keeps it accurate.

Information	Owner	Review rhythm
Company goals	CEO/founder	Quarterly/monthly
Weekly priorities	Founder or function leads	Weekly
Product roadmap	Product/founder	Monthly
Customer notes	Sales/CS/product	Weekly
Sales pipeline	Sales/founder	Weekly
Support themes	Support/CS/product	Weekly
Hiring pipeline	Hiring manager/founder	Weekly
Finance and runway	Founder/finance	Monthly
Legal and compliance docs	Founder/finance/legal owner	Monthly/quarterly
Decision log	Founder/ops	Ongoing

The map prevents tool confusion. A team may use Slack, WhatsApp, email, Notion, Linear, Google Drive, GitHub, CRM, and spreadsheets. That is manageable only if everyone knows which one wins when information conflicts.

If two tools both claim to be the source of truth, the company does not have two sources. It has no source.

Documentation Governance Without Bureaucracy

Documentation fails when nobody knows whether a document is current, historical, private, or safe to reuse. Founders do not need a corporate governance process. They need a lightweight way to keep docs trusted.

Classify important docs into five types:

Doc Type	Use	Rule
Operating doc	Current process, owner, or playbook.	Must have owner and review date.
Decision doc	Why a choice was made.	Should not be rewritten casually; append updates.
Historical doc	Old plan, old spec, old strategy.	Mark historical so people do not execute from it.
External doc	Investor, customer, hiring, or public-facing material.	Needs review before sending.
Sensitive doc	Legal, finance, HR, security, customer data.	Restrict access and avoid casual sharing.

Add a small header to critical docs:

Status: Current / Needs review / Historical
Owner:
Last updated:
Review date:
Primary reader:
Source of truth:
Sensitive? Yes / No

This is enough governance for many startups. The goal is not to make writing slower. The goal is to stop the team from trusting stale information.

The Founder Documentation Standard

The founder sets the writing culture. If the founder makes decisions in private chats and leaves no trail, the team will copy that behavior. If the founder writes short, clear decision notes, the team learns that clarity matters.

Founder-standard docs should be:

Short enough to read.
Specific enough to act on.
Honest about tradeoffs.
Clear about owner and next step.
Easy to find later.

Use this rule: any decision that changes product direction, customer promise, pricing, hiring, spending, legal risk, security posture, or company priority deserves a written note.

Permission And Access Hygiene

As the company grows, docs become an access-control problem. Contractors, agencies, interns, former employees, vendors, and candidates may have seen documents they should not keep accessing forever.

Review access monthly or quarterly for:

Company drive or workspace.
Product roadmap.
Customer notes.
Sales pipeline.
Hiring folders.
Finance folders.
Legal and compliance folders.
Investor data room.
Source code and technical docs.

Ask:

Question	Action
Who has access but no longer needs it?	Remove.
Which docs are public inside the company but should be restricted?	Move or restrict.
Which docs are locked so tightly that work slows down?	Add the right people.
Which sensitive docs are copied into casual folders?	Consolidate and clean up.

Documentation is not only about knowledge. It is also about control.

Documentation Debt Cleanup Sprint

Documentation debt appears when old docs remain findable, decisions live in chat, and nobody knows which version is current. Run a cleanup sprint every quarter or before major hiring, fundraising, enterprise sales, audit, or handoff.

Use a one-week sprint:

Day	Work	Output
Day 1	Inventory important docs.	List of docs by function: product, sales, finance, people, legal, engineering, operations.
Day 2	Mark status.	Current, needs review, historical, duplicate, sensitive, delete candidate.
Day 3	Assign owners.	Every critical doc has owner and review date.
Day 4	Merge or archive duplicates.	One source of truth per topic.
Day 5	Fix access.	Sensitive docs restricted; working docs accessible to right people.
Day 6	Write missing decision notes.	Key decisions no longer depend on memory.
Day 7	Publish source-of-truth map.	Team knows where to find the current version.

The goal is not a perfect knowledge base. The goal is to reduce confusion and protect trust.

Decision Log Template

Every startup should keep a simple decision log. It is one of the highest-return documents a founder can create.

Decision:
Date:
Owner:
Context:
Options considered:
Evidence:
Tradeoff:
Decision:
What we are not doing:
Review trigger:
People informed:

Use it for:

Pricing changes.
Product direction.
Hiring plan.
Major customer commitments.
Fundraising strategy.
Cost cuts.
Vendor selection.
Security or data decisions.
Market focus changes.
Pivot or shutdown decisions.

Decision logs reduce repeated debates. They also make the company more legible to new hires, advisors, investors, and future you.

Documentation Minimum By Stage

Do not over-document a tiny company, but do not under-document critical work.

Stage	Minimum documentation
Idea/discovery	Interview notes, idea memo, decision log, customer list.
MVP	Product brief, roadmap, release notes, support issues, setup instructions.
First customers	CRM notes, onboarding checklist, pricing/package notes, customer commitments.
Early team	Role docs, hiring scorecards, company operating rhythm, access map.
Fundraising	Investor memo, metric definitions, cap table source, finance model assumptions.
Scaling	Function playbooks, manager cadence, security docs, incident log, policy docs.

Documentation should grow with coordination cost. If two people need to remember the same thing repeatedly, write it once.

Delegation-Ready Documentation

Documentation is most useful when it lets the founder delegate without lowering quality. A doc is delegation-ready when someone else can perform the work, make normal decisions, and know when to escalate.

Use this checklist:

Question	Why It Matters
What outcome does this process create?	Prevents task-following without judgment.
Who owns it?	Avoids orphaned work.
What inputs are needed?	Prevents repeated founder clarification.
What steps matter most?	Captures workflow reality.
What decisions can the owner make alone?	Enables speed.
What must be escalated?	Protects quality and risk.
What does good look like?	Makes review possible.
Where are examples?	Helps new people learn taste.

Delegation-ready docs are especially important for:

Customer onboarding.
Sales follow-up.
Support triage.
Hiring screens.
Finance close.
Investor updates.
Product release checks.
Vendor and tool administration.

If the founder still needs to review every ordinary case, the doc is incomplete or the owner is not trained yet.

Documentation As Due Diligence

Good documentation is not only internal hygiene. It becomes evidence during fundraising, enterprise sales, hiring, partnerships, audits, and acquisition conversations.

Map docs to external trust:

External Moment	Docs That Build Trust
Fundraising	Investor memo, metric definitions, cap table source, financial assumptions, customer proof.
Enterprise sale	Security notes, support process, implementation plan, SLA expectations, product roadmap boundaries.
Hiring leader	Company operating rhythm, role scorecard, decision rights, team context.
Board/advisor update	KPI packet, decision log, risks, asks, progress against goals.
Acquisition diligence	Corporate records, contracts, IP ownership, revenue quality, customer commitments, data map.

Do not wait until diligence to clean the company. A startup that can explain itself clearly usually operates more clearly too.

Source Of Truth Ownership Map

After the basic source-of-truth map exists, add ownership. The most common documentation problem is not lack of writing. It is uncertainty about which document is current and who is responsible for keeping it true.

Area	Source of truth	Owner	Review rhythm
Company strategy	Strategy memo or operating plan	CEO/founder	Monthly or quarterly
Product roadmap	Product planning doc/tool	Product/engineering owner	Weekly or biweekly
Customer conversations	CRM, interview repository, or notes database	Customer-facing owner	Weekly
Sales pipeline	CRM or sales spreadsheet	Revenue owner	Weekly
Pricing and packaging	Pricing doc	Founder/revenue owner	Monthly or after major deal
Finance model	Finance spreadsheet/system	Founder/finance owner	Monthly; weekly if runway is tight
Legal/company docs	Secure folder/data room	Founder/ops/legal owner	Quarterly or event-based
Hiring scorecards	Hiring folder or ATS	Hiring manager/founder	Before each role opens
Operating decisions	Decision log	Founder/ops owner	Weekly

The map should answer: “Where do I look for the current truth?” If people need to ask in chat, the map is not working yet.

Current versus historical docs

Do not delete useful history, but mark it clearly.

Label	Meaning
Current	Use this for decisions now.
Draft	Under review; do not treat as final.
Historical	Useful context, but no longer current.
Superseded	Replaced by another doc; link to current source.
Sensitive	Restricted access.
Archive	Kept for record only.

This prevents a dangerous startup pattern: someone copies an old pricing sheet, old onboarding flow, old investor narrative, or old roadmap because it looked official.

Founder Memo Library

As the company grows, founders should build a small library of high-quality memos. These are not essays. They are reusable context.

Useful founder memos:

Memo	When to write it	Why it matters
Customer truth memo	After a discovery sprint, churn review, or sales pattern shift.	Keeps the company anchored in reality.
Strategy tradeoff memo	When choosing ICP, pricing, channel, product direction, or funding path.	Makes the “why” explicit.
Decision reversal memo	When changing a previously important decision.	Preserves trust and context.
Incident or mistake memo	After a serious failure.	Turns pain into operating improvement.
Hiring bar memo	Before a critical role.	Prevents urgent hiring from lowering standards.
Cash/risk memo	When runway, collections, or spending require action.	Creates calm around hard choices.

A good memo should be short enough to read and specific enough to change behavior. If it does not help someone make a better decision, it is probably too vague.

Founder Knowledge Extraction Sprint

Early startups often run on founder memory. The founder remembers why pricing changed, which customer promise is risky, which investor asked for what, which vendor has a special deal, which candidate almost joined, which customer is angry, and which product shortcut will hurt later.

That memory is useful, but it does not scale. Run a founder knowledge extraction sprint before hiring leaders, delegating operations, fundraising, enterprise sales, or entering diligence.

Start with these areas:

Area	What to extract
Customer truth	Best customers, worst customers, objections, churn reasons, support patterns, promises made.
Sales and pricing	Discount rules, negotiation boundaries, payment terms, common objections, renewal risks.
Product decisions	Why major roadmap choices were made, known debt, customer-specific exceptions.
Finance and cash	Burn assumptions, receivables, vendor commitments, hidden liabilities, runway risks.
People	Hiring bar, compensation exceptions, founder expectations, sensitive team context.
Legal and company	Contracts, IP assignments, compliance reminders, investor commitments, board/advisor expectations.
Tools and access	Admin accounts, automations, data exports, scripts, agency/vendor access.

Use this interview format:

Topic:
What does only the founder currently know?
Where is the current source of truth?
What decision depends on this knowledge?
What could break if this stays unwritten?
Who should own it after documentation?
What document, checklist, or register should exist?
Review date:

Do not try to document the entire company in one heroic weekend. Pick the areas where founder memory creates the highest risk: cash, customers, commitments, hiring, access, and strategic decisions.

The test is simple: if the founder is unavailable for a week, can the company still sell, support customers, pay bills, make ordinary decisions, and avoid breaking trust?