Should we have a #decisions channel in Slack?

It's better than nothing and a fine place to start: post the verdict, reason, and owner there whenever a thread closes. But it inherits Slack's problems: no structure, no supersede history, search by keyword only. Treat it as the inbox for a real log, not the log itself.

What should a decision record from a Slack thread contain?

Four fields: the verdict as one imperative sentence, the reason it was made, the alternatives that were rejected, and who agreed, plus a review date if the call is temporary. Link the original thread for the full debate.

How do we get the team to actually record decisions?

Lower the cost, don't raise the pressure. Make the format tiny, make the decider responsible for closing the thread, and backfill whenever someone asks a question that a record would have answered. Habits that require discipline from everyone fail; habits owned by one named person per decision mostly hold.

How do we stop product decisions getting lost in Slack?

Slack is where decisions happen, not where they survive. Keep deciding in threads (that part works), but capture the verdict somewhere permanent at the moment it's made: one sentence, the reason, the rejected options, who agreed. Teams that succeed make capture a reflex tied to the decision, not a cleanup job for later.

Product decisions do get made in Slack, and that part works: the debate is fast, the right people are in the thread, the call gets made. What fails is everything after. The verdict lives on page four of a thread, findable only by people who already know it exists.

Why Slack loses decisions

Slack is a stream, not a record. Three mechanisms do the damage.

The thread never closes. Most Slack decisions are implicit: someone proposes, two people thumbs-up, the topic moves on. Nobody states the verdict, so there's nothing to find later. Just a debate with no visible winner.

Search returns messages, not conclusions. Searching "pricing page" surfaces forty messages across six channels, with superseded takes ranked equal to the final call. To learn the answer, a reader has to re-run the whole argument.

And the record decays. People leave and take context with them. Channels get archived. History gets truncated. A decision that lives only in Slack has a half-life.

The standard fix ("someone should write these up") fails for a predictable reason: it asks a person to leave the conversation, open another tool, and file. Filing loses to shipping every time.

What actually works

Close threads explicitly. When a call lands, the decider posts one final message: the verdict as a single imperative sentence. "Verdict: we ship usage-based pricing; seat-based is out." Mark it with a fixed emoji so it's scannable. An unstated decision is the root failure; everything else builds on this.

Use a tiny, fixed format. Verdict, reason, rejected alternatives, who agreed, with a review date if the call is temporary. That's the whole decision log entry. If it takes more than a minute to write, the format is too heavy and it will be skipped.

Route verdicts to one durable place. A #decisions channel, a doc, a log: the medium matters less than there being exactly one, outside the stream, append-only. When a decision is reversed, add a successor entry; don't edit history.

Filter hard. Log a decision only if it will constrain how someone builds or plans later. Most threads fail that test, which is what keeps the log short enough that people trust it and read it.

Make the decider own the close. Habits assigned to "the team" die. Habits assigned to the one person who made the call mostly survive.

Where Lockstep fits

Lockstep exists because the filing step is where every manual version of this dies. It watches the Slack channels where your product and engineering work happens (Notion too; Jira, Confluence, and Google Docs support is newer), drafts the decision record with its reason, and the owner approves it in one click, so the record stays ahead of reality instead of behind it. We're at design-partner stage, and it's Apache-2.0 if you'd rather self-host. See how it works, or how it compares to keeping decisions in Notion.