Introducing the Decision Diff
What if product decisions had the same rigor as pull requests?
I've spent the last six posts describing the same problem from different angles. A PM changes scope in Slack and 3 people see it, 8 need to. A PRD gets edited 6 times and engineers find out about 2. A feature ships wrong and nobody can answer "who signed off on this?". Teams hold meetings to compensate for changes that don't travel.
Different stories. Same structural failure. Changes happen, but nothing ensures they reach the right people, get approved by someone accountable, or propagate to the systems where work actually happens.
So we built the missing primitive. We call it a Decision Diff.
What a Decision Diff Actually Is
A Decision Diff is a structured change record. Not a Slack message. Not a Jira comment. Not a line buried in a PRD revision history. A standalone artifact that captures one coherent scope change and governs it from the moment it's proposed to the moment it reaches every person and ticket it affects.
Every Decision Diff has four parts:
| Part | What it does | Why it matters |
| Evidence | Citations from the source: the Slack message, the PRD section, the stakeholder email that triggered the change | Nobody has to trust memory. The "why" is always attached. |
| Required sign-offs | Named approvers based on ownership rules, not whoever happened to be in the thread | "Who signed off?" becomes answerable in 5 seconds, not 40 minutes. |
| Impact checklist | Which Jira tickets, test plans, and downstream work are affected by this change | Engineers and QA know immediately if their work just shifted under them. |
| Audit trail | Immutable timeline: who proposed, who approved, who acknowledged, when, with what evidence | The retro forensics are done before the retro even starts. |
That's it. One object per decision. One anchor (usually a Jira ticket). Evidence attached. Approvers named. Impact mapped. Trail permanent.
How It Works in Practice
Here's what Flow 1 looks like. A PM posts a scope change in a Slack thread. Maybe it's "client needs role-based permissions, not admin-only" or "we're cutting the bulk export from V1."
Instead of hoping the right people read the thread, the PM triggers a Decision Diff. The system pulls the Slack message as evidence, uses AI to pre-fill the fields (what changed, what's affected, who needs to approve), and presents a confirmation modal. The PM reviews, adjusts if needed, and submits.
From there:
The tech lead gets a DM with the diff summary, the evidence, and approve/reject buttons. The QA lead gets the same. They can approve in under 60 seconds because everything they need is right there. No context switching to Confluence. No hunting through Slack history. No "let me check the PRD first."
On approval, the system propagates. A comment lands on the Jira ticket with the summary, the approvers, and a link to the full diff. The Slack thread gets a canonical card showing the current status. If the team runs soft gates, Jira won't let the ticket transition to "Ready for QA" until the pending diff is resolved.
The engineer working on that ticket sees it immediately. They don't discover the change during code review three days later. They don't find out at the sprint demo when the PM says "wait, that changed."
Why This Isn't Just Another Process Tool
I know what you're thinking. "Great, another tool that adds process overhead."
Fair. But consider what the current "process" actually costs.
We tracked a single scope change that went through Slack and reached 3 of 8 people. It produced 135 hours of rework. $27,000 burned. We tracked a sprint where a PRD changed 6 times and engineers caught 2 of those changes. The other 4 showed up as mystery velocity drops, "bugs" that were actually stale specs, and PRs that needed complete rewrites after code review.
The Decision Diff doesn't add process. It replaces the invisible, unreliable process you're already running. Right now, your process for scope changes is: PM posts somewhere, hopes it propagates, maybe mentions it in standup, maybe remembers to update Jira. That's a process. It's just a bad one.
The diff makes the existing process explicit and reliable. The PM still makes the decision. The approval still happens. The propagation still needs to occur. The diff just makes sure it actually does.
The Design Choices That Matter
We made some deliberate bets building this:
Manual-first capture. The PM initiates the diff, not some automated watcher. This is intentional. Auto-detection sounds magical until it fires a false positive during a pilot and the team writes off the entire tool. In a pilot, one false alarm kills trust faster than ten correct detections build it. The PM knows when a change matters. We let them say so.
AI-assisted, not AI-generated. When the PM triggers a diff from a Slack thread, AI pre-fills the fields: title, what changed, rationale, impacted tickets. But the PM confirms everything before it goes out. The AI is doing the tedious work (reading through a 47-message thread to extract the actual decision) and the human is doing the judgment work (is this right? did I miss an affected team?). We want the PM spending 30 seconds confirming, not 5 minutes writing from scratch.
In-context first. 80% of interactions happen in Slack and Jira, where teams already live. The Meetless UI exists for the deep work: audit trails, sprint dashboards, policy configuration. But the daily flow is Slack trigger, Slack approval, Jira propagation. Zero new tabs for the critical path.
One diff per decision, not per artifact. A single scope change might affect a Jira ticket, two Confluence pages, and a test plan. That's not three diffs. It's one diff with one anchor (the Jira ticket) and multiple linked items. The diff fans out to all of them on approval. Users never have to ask "should I create 3 diffs or 1?"
What This Means for Your Team
If you're a PM, this means you stop being the human router for every scope change. You make the decision, you confirm the diff, and the system handles propagation. No more pinging 7 people individually. No more wondering if everyone saw your standup mention.
If you're an engineer, this means you stop discovering scope changes in code review or at the sprint demo. When the spec changes, you know. And you know because a structured notification told you, not because someone happened to mention it in a channel you happened to check.
If you're a QA lead, this means your test cases stop going stale without warning. When acceptance criteria shift, the diff tells you which tickets are affected before you write 14 tests against the wrong spec.
If you're an EM or delivery lead, this means "who signed off on this?" is always answerable. The audit trail exists. The approval timestamps exist. The evidence citations exist. The retro becomes productive because you're not spending the first 40 minutes reconstructing what happened.
Where We Are
We're running early pilots. The creation flow works. Slack approvals work. Jira propagation works. The audit trail works. We're still building the sprint dashboard and the ROI reporting, but the core loop (detect, package, approve, propagate) is live.
If your team loses time to scope changes that nobody tracks, nobody approves, and nobody propagates, we'd like to hear from you. Not because we want to sell you something today. Because we're trying to learn whether the problem screams loud enough to build a company around.
So far, watching a team catch a spec change before it became 3 weeks of rework was the first time I thought "ok this actually works."
If this problem sounds familiar, tell us your version. Join the Meetless Slack community, check the feedback repo, or find us on Twitter/X.
