Blog
Most decision logs die in three weeks
You started one. It has four entries. The last is from March.
Twelve fields per decision
Kalpataru Sahoo ·
This is the normal outcome, and it isn’t a discipline problem. It’s a design problem — and it’s visible in the templates themselves.
Pull up almost any decision log template and you’ll be asked to record: an ID, the date, a summary of the decision, the owner, stakeholders consulted, options considered, the rationale, expected impact and tradeoffs, links to supporting evidence, a status, a review date, and later the actual outcome.
Every one of those is defensible in isolation. Together they turn a single decision into a twenty-minute documentation task. You’ll do it for the first few, during the week you decided to Get Organised. You won’t do it in the week you’re actually making decisions worth logging.
The templates optimise for completeness. You need something that optimises for still existing in six months.
What you'll genuinely ask later
Before deciding what to record, be honest about what you’ll come back for. In practice it’s four things:
- What did we decide?
- When?
- What did we rule out?
- Why did we pick this?
Notice what’s missing. You will rarely go looking for “stakeholders consulted” or “expected impact as estimated at the time”. Those fields exist because the template was built for project governance and audit trails — a real need, but not yours.
Log only what can't be reconstructed
Here’s the principle that makes a log survivable:
Record the things that exist only in someone’s head. Skip the things you could reconstruct later.
Apply it to the twelve fields and most of them fall away. The date is in the email. The owner is obvious from the thread. The status is visible in whether the thing shipped. Links to evidence can be found again.
But two things are genuinely unrecoverable:
The alternatives you rejected. Six months on, the option you chose looks inevitable. The three you considered and dismissed have evaporated — along with any ability to tell whether the reasoning still holds.
Why you chose it. Not the decision, the reason. This lives in nobody’s inbox. It was said out loud on a call, or thought silently by you, and if it isn’t written in the moment it’s gone.
Everything else is reconstructible. Those two aren’t. So those two are the log.
The four-field version
| Date | Decision, in one sentence | What we ruled out | Why |
|---|---|---|---|
That’s it. One row. Sixty seconds.
Two rules for using it:
Write the decision as one sentence. Vague entries are the most common way these logs become useless — “revisited pricing approach” tells future-you nothing. “Moved to annual-only billing for the Pro plan” does.
Log on a trigger, not a schedule. “Review the log weekly” fails because Friday-you doesn’t remember Tuesday’s reasoning. The trigger is the moment the decision lands — when you hit send on the message that settles it, add the row. If you’re writing it from memory, you’ve already lost the part worth keeping.
What counts as a decision
Not everything. A useful filter: would a reasonable person, six months from now, want to know why this went the way it did?
That’s usually pricing, hiring, scope cuts, build-versus-buy, which customer segment to chase, and anything you argued about. It’s not which tool to use for standups.
Where to keep it
One file. A single note, a spreadsheet tab, a markdown file in the repo. Do not build a system for it — the system is how it dies. If adding a row takes more than one click to reach, you’ve overbuilt it.
The limit worth admitting
Even the four-field version depends on you being present and willing at the moment of the decision. Most of the time you will be. Some of the time — the launch week, the month the deal nearly died — you won’t, and those are exactly the decisions you’ll most want to look up.
That’s the gap. A log records what you remembered to record, which means the busiest periods leave the thinnest trail. Memoraxis approaches it from the other side: it connects the apps where decisions actually get made, keeps the record of what came through as it happens, and lets you ask afterwards what was decided and what changed — including for the weeks you never wrote anything down.
It won’t invent a rationale nobody ever stated, and what it can see depends on which apps you connect. But it doesn’t ask you to be organised on your worst week.
FAQ
- How is a decision log different from meeting notes?
- Meeting notes record a conversation; a decision log records an outcome. Notes are long, chronological and rarely re-read. A log is one line per decision and exists specifically to be looked up later. Keeping both is fine — only one of them you'll actually search.
- Should the whole team have access?
- Yes, and it should be boring to add to. The value compounds when someone who wasn't in the room can see what was ruled out. That's also the point at which a personal note file stops being enough.
- What if we change a decision later?
- Add a new row; don't edit the old one. The fact that you reversed it — and when — is itself the most useful thing in the log. Editing history away deletes the lesson.
- Isn't four fields too few for an audit trail?
- Yes. If you need governance or compliance evidence, use a full template — that's what they're for. This is for founders and small teams who want to remember their own reasoning, which is a different job.
For the weeks you never wrote anything down
Connect a mailbox and a calendar. What comes through them is remembered from that point on, so you can ask later what was decided and what changed.
Get started free