
Founding Supporters: Support the following people and companies because they supported us from the beginning: DataEI | Dr. Bob Schatz | .Tech Domains | Fairman Studios | Jean-Philippe Martin | RocketSmart AI | UMBC
In today's newsletter:
How Jennifer Aniston’s LolaVie brand grew sales 40% with CTV ads
The DTC beauty category is crowded. To break through, Jennifer Aniston’s brand LolaVie, worked with Roku Ads Manager to easily set up, test, and optimize CTV ad creatives. The campaign helped drive a big lift in sales and customer growth, helping LolaVie break through in the crowded beauty category.
Decision Documentation: Capture the "Why" Behind Decisions
You make a decision. You choose Tool A over Tool B. You decide to sunset Feature X. You pivot the pricing model.
Six months later, someone asks: "Why did we choose this again?"
You can't remember. The context is gone. The reasoning is lost.
So you have to re-debate the decision. Or worse you reverse it, only to remember later why it was the right call.
This is the institutional amnesia problem. Decisions get made, but the "why" disappears.
The fix? Decision documentation.
A simple log that captures what was decided, why, and by whom so you never have to re-litigate the same decisions over and over.
The $50K Tool They Almost Switched Away From
Let me tell you about Nina, founder of a 6-person marketing analytics company.
Two years ago, Nina's team chose Segment for data integration. It cost $50K/year.
It wasn't cheap. But after evaluating 5 alternatives, they decided: Segment was worth it.
Why?
It integrated with 15 tools out-of-the-box
Their data engineer was already familiar with it
The API was robust and well-documented
Migrating from their old tool would take 3 months. Segment cut that to 2 weeks
They documented the decision... nowhere.
Fast-forward 18 months.
A new hire joined. He saw the $50K line item on the budget and said: "Why are we paying this? There are cheaper alternatives."
The team started debating:
"Can we switch to Tool B for $10K/year?"
"Why did we choose Segment again?"
"Who made this decision?"
No one remembered the full context.
They spent 2 weeks re-evaluating alternatives, pulling together comparison spreadsheets, and debating in Slack.
Then Nina found an old email thread where the original decision was explained.
She read it to the team.
"Oh. Okay, that makes sense. Segment stays."
Two weeks wasted re-debating a decision that had already been made because the 'why' wasn't documented.
Nina created a Decision Log.
Now, every major decision gets documented:
Date | Decision | Why | Owner | Status |
|---|---|---|---|---|
Jan 2024 | Use Segment for data integration | Best API, fastest migration, team familiar | Nina | Active |
Mar 2024 | Sunset Feature X | <5% of users, high maintenance cost | CTO | Done |
Jun 2024 | Switch to annual pricing | Better cash flow, 20% discount | Nina | Active |
Next time someone questions a decision, Nina points them to the log.
No re-debate. No wasted time. Just context.
"Decision documentation saves us 10+ hours per quarter—because we don't re-litigate old decisions."
Why Decisions Get Forgotten
Here's the problem:
Most decisions happen in meetings, Slack threads, or hallway conversations.
The decision gets made. Everyone nods. Then everyone moves on.
But the context—the "why"—lives only in people's heads.
Six months later:
People forget the reasoning
New hires weren't there
The original decision-maker left the company
Result: The decision gets questioned. Debated again. Sometimes reversed (even though it was the right call).
Think of decision-making like code.
If you write code with no comments, no documentation, no commit messages—future you (or a new developer) has no idea why it was written that way.
So you spend hours reverse-engineering the logic.
Decision documentation is like code comments for your company.
Why This Matters for Microteams
Big companies have meeting notes, decision memos, and project wikis.
You? Decisions happen fast—in Slack, over lunch, or in a 10-minute call. And then they vanish.
Here's why decision documentation is critical:
Your team is small. Losing one person = losing institutional knowledge.
You move fast. Decisions stack up quickly.
Re-debating wastes time. Every hour spent relitigating is an hour not spent building.
New hires need context. They'll question decisions unless they understand the "why."
The best microteams don't just make decisions. They capture them.
The Decision Documentation Framework
Here's how to build a decision log that preserves context and prevents re-litigation.
Step 1: Define What Counts as a "Decision"
Not every choice needs to be documented.
Document decisions that are:
Strategic (affect the business long-term)
Expensive (involve significant cost or commitment)
Irreversible (or hard to reverse) (migrations, big hires, product pivots)
Frequently questioned (if people keep asking "why," document it)
Examples of decisions to document:
Decision Type | Example |
|---|---|
Tool/platform choice | "We chose Stripe over PayPal for payments" |
Product strategy | "We're sunsetting Feature X" |
Pricing changes | "We're switching from monthly to annual pricing" |
Hiring/firing | "We're not backfilling the marketing role" |
Process changes | "We're moving from sprints to continuous deployment" |
Partnerships | "We're partnering with Company Y for co-marketing" |
Don't document:
Trivial choices (e.g., "What color should the button be?")
Temporary decisions (e.g., "Let's try this for a week")
Rule: If it'll affect the business for 6+ months, document it.
Step 2: Choose a Format
Decision log = Simple table or doc where all decisions live.
Options:
Option 1: Google Sheet / Airtable (simplest)
Date | Decision | Why | Owner | Status | Related Docs |
|---|---|---|---|---|---|
Jan 10, 2024 | Use Segment | Best API, familiar to team | Nina | Active | [Comparison doc] |
Feb 5, 2024 | Sunset Feature X | <5% usage, high cost | CTO | Done | [Usage data] |
Option 2: Notion / Confluence (richer format)
Create a "Decision Log" database with properties:
Decision title
Date
Owner
Status (Active / Archived / Reversed)
Rationale (paragraph or bullet points)
Related docs (links)
Option 3: Markdown in GitHub (for engineering teams)
Create a /decisions folder with one markdown file per decision:
/decisions/
001-use-segment-for-data.md
002-sunset-feature-x.md
003-annual-pricing.mdRecommendation for most teams: Start with a Google Sheet. Upgrade to Notion if you need more structure.
Step 3: Template the Decision Entry
Every decision should capture the same information.
Template:
## Decision: [What was decided]
**Date:** [When]
**Owner:** [Who made the call]
**Status:** [Active / Archived / Reversed]
**Context:**
[What problem were we solving? What was the situation?]
**Options Considered:**
1. Option A: [Pros/cons]
2. Option B: [Pros/cons]
3. Option C: [Pros/cons]
**Decision:**
[What we chose and why]
**Rationale:**
- [Reason 1]
- [Reason 2]
- [Reason 3]
**Trade-offs Accepted:**
[What we're giving up by choosing this]
**Success Criteria:**
[How we'll know this was the right call]
**Review Date (optional):**
[When we'll revisit this decision]
**Related Docs:**
- [Link to comparison sheet]
- [Link to data/research]This captures everything someone would need to understand the decision.
Step 4: Document Immediately After the Decision
Don't wait. Document while the context is fresh.
Workflow:
Decision is made (in meeting, Slack, email)
Owner (person who made the call) writes decision entry (5-10 min)
Shares in Slack/email: "Documented decision here: [link]"
Team reviews for accuracy (optional: 24-hour comment window)
If you wait a week, you'll forget the nuances. Do it immediately.
Step 5: Link to Supporting Docs
Don't duplicate information. Link to it.
Example:
Decision: "We're using Segment for data integration."
Rationale: "After evaluating 5 tools (see [comparison sheet]), Segment had the best API and fastest migration path."
Related docs:
[Tool comparison spreadsheet]
[Migration plan]
[Pricing breakdown]
This keeps the decision log concise while preserving full context.
Step 6: Review Key Decisions Quarterly
Not all decisions age well.
Quarterly review:
Open the decision log
For each active decision, ask:
Is this still the right call?
Has the context changed?
Should we reverse or revise this?
Update status:
Active (still relevant)
Archived (no longer relevant but kept for historical context)
Reversed (we changed our mind, log why)
This prevents zombie decisions (decisions that are outdated but still followed).
Step 7: Use the Log to Onboard New Hires
New hires don't have context. The decision log gives it to them.
Onboarding checklist:
[ ] Read top 10 decisions in the Decision Log
[ ] Understand why we chose our tools, pricing, and product strategy
[ ] Ask questions if anything is unclear
This prevents new hires from re-opening settled debates.
What to Capture (and What to Skip)
Capture:
✅ What was decided
✅ Why we chose this (not just what, but why)
✅ What alternatives we considered
✅ Trade-offs we accepted
Don't capture:
❌ Blow-by-blow meeting notes (too much detail)
❌ Every opinion voiced (just the final reasoning)
❌ Implementation details (link to those docs instead)
Rule: The decision entry should be readable in 2-3 minutes.
Common Decision Documentation Mistakes
Mistake 1: Only documenting the "what," not the "why"
Bad: "We chose Segment."
Good: "We chose Segment because it had the best API and saved 1 month of migration time."
Mistake 2: Documenting too late
Context is forgotten if you wait
Fix: Write it within 24 hours of the decision
Mistake 3: Burying it in meeting notes
Meeting notes get lost
Fix: Decisions go in the Decision Log, not scattered across Google Docs
Mistake 4: No owner assigned
If no one owns updating the log, it won't get updated
Fix: The person who made the decision documents it
Mistake 5: Never revisiting decisions
Decisions become stale
Fix: Quarterly review
Example Decision Log Entries
Entry 1:
Decision: Switch to annual pricing (June 2024)
Why: Better cash flow, 20% discount incentivizes annual plans, reduces churn (annual customers churn 50% less than monthly).
Trade-offs: Some customers prefer monthly (we'll still offer it, but at full price).
Status: Active
Entry 2:
Decision: Sunset Feature X (March 2024)
Why: <5% of users actively use it, maintenance cost = 15 hours/month, no new users adopting it.
Alternatives considered: Keep it, charge extra for it, open-source it.
Decision: Sunset it. Notify users 60 days in advance, offer migration to alternative.
Status: Done (sunset completed May 2024)
Entry 3:
Decision: Hire a full-time engineer instead of contractors (January 2024)
Why: Contractors lack context, hand-offs are inefficient, long-term cost is higher. Full-time hire = better velocity and ownership.
Trade-offs: Higher upfront cost ($120K salary vs. $80K/year in contractors), commitment.
Status: Active (hired Engineer A in Feb 2024, working out well)
Today's 10-Minute Action Plan
You don't need to document every decision ever made. Just start logging new ones.
Here's what to do in the next 10 minutes:
Create a "Decision Log" doc (Google Sheet, Notion, whatever you use)
Add 3 columns: Date, Decision, Why
Document the last major decision your team made (even if it was weeks ago)
Share the log with your team
Make it a rule: "All major decisions get logged here."
That's it. One log created, one decision documented, 10 minutes.
Next time a decision is made, add it immediately. In 6 months, you'll have a library of context that saves hours of re-debate.
