The Decision Graph: A New Product Primitive
Product teams have task graphs, code graphs, and design systems. They do not have a structured way to connect decisions to data and deliverables. The decision graph fills that gap.
What a Decision Graph Connects
Data Sources
Analytics, conversations, research, designs
Decisions
Connected, traceable, conflict-aware
Deliverables
PRDs, tickets, prototypes, user stories
The Problem with How Teams Handle Decisions
Every product is the sum of its decisions. Which user problem to solve first. Whether to build a feature in-house or use a third-party service. What metric defines success. Which edge cases to handle now versus later. How to sequence work across teams.
A mid-sized product team makes hundreds of these decisions per quarter. Where do they live? Scattered across Slack threads, meeting notes, PRD documents, Jira tickets, email chains, and the memories of individual team members. Some decisions are recorded. Most are not. And even the ones that are recorded exist as isolated entries in flat lists, disconnected from the data that informed them and the deliverables they produced.
This creates three recurring problems:
- Decisions get lost. A month after a decision is made, nobody remembers why the team chose approach A over approach B. The rationale existed in a Slack thread that has been buried under thousands of new messages.
- Decisions conflict silently. Team A decides to deprecate an API. Team B decides to build a new feature on that same API. Neither team knows about the other's decision until implementation creates a collision.
- Decisions become stale. A decision made based on Q1 data may no longer hold in Q3 when the underlying metrics have shifted. But nobody reviews past decisions against current data. The team continues executing against outdated assumptions.
Current Approaches (and Why They Fall Short)
Decision logs (spreadsheets, Confluence, Notion)
Flat lists of decisions with columns for date, owner, status, and rationale. Easy to set up, difficult to maintain. Within weeks, the log goes stale because there is no incentive or mechanism to keep it current. More critically, a flat log cannot represent relationships between decisions. Decision 47 depends on Decision 31 and contradicts Decision 52, but the log shows them as independent rows.
Architecture Decision Records (ADRs)
Structured documents (typically Markdown files) that capture context, decision, and consequences. ADRs are widely used in engineering but rarely adopted by product teams. They capture individual decisions well but do not model the connections between decisions or maintain live links to the data that informed them. For a walkthrough of implementing ADRs in Jira, see our guide on tracking decisions in Jira.
Slack threads and meeting notes
Where most decisions actually happen. The problem is that Slack is not a system of record. Decisions made in threads are ephemeral. They are not searchable by decision type, not linked to the data that informed them, and not connected to the deliverables they produced. Meeting notes are marginally better but suffer the same disconnection problem.
PRD sections labeled “Decisions”
Some PRD templates include a “Key Decisions” section. This is better than nothing, but the decisions are scoped to a single PRD. Cross-PRD decisions (those that affect multiple features or teams) have no natural home. And like all PRD content, these sections are static text that goes stale.
What a Decision Graph Is
A decision graph is a connected model where every product decision is a node, and the edges represent relationships: to the data that informed the decision, to the deliverables it produced, and to other decisions it depends on, contradicts, or supersedes.
The concept is analogous to a knowledge graph in data engineering or a dependency graph in software builds. It provides structure to information that currently exists as unstructured text scattered across tools. But instead of modeling entities and relationships in a database, or files and dependencies in a build system, a decision graph models the thinking behind a product.
Here is what a decision node in the graph contains:
- The decision itself. A clear statement of what was decided.
- Context. The situation or problem that prompted the decision.
- Data sources. Links to the analytics, research, conversations, and documents that informed it.
- Alternatives. What other options were considered and why they were not chosen.
- Consequences. What trade-offs this decision introduces.
- Connected deliverables. The PRDs, tickets, designs, and stories that flow from this decision.
- Related decisions. Other decisions that this one depends on, informs, or potentially conflicts with.
- Status. Active, superseded, or deprecated.
The power of the graph is in the connections, not the nodes. A single decision node is just a structured record (an ADR with more metadata). A graph of connected decisions enables capabilities that no flat record system can provide.
What the Decision Graph Enables
Conflict detection
When two decisions reference the same system, user persona, or metric but reach contradictory conclusions, the graph can flag the conflict. Team A's decision to simplify the nav and Team B's decision to add three new nav items are both reasonable in isolation but contradictory when combined. A decision graph surfaces this before implementation, when the cost of resolution is lowest.
Impact analysis
When a decision needs to change (market conditions shift, new data arrives, a stakeholder changes priorities), the graph shows exactly what is affected. Which PRDs reference this decision? Which tickets flow from it? Which other decisions depend on it? This transforms “we need to change direction” from a multi-week discovery process into a structured review.
Automatic staleness detection
Decisions are made based on data. When that data changes (a metric shifts, a competitor launches, a customer segment behaves differently), the decisions based on it may no longer hold. A decision graph maintains the connection between decisions and their source data. When the source changes, affected decisions are flagged for review.
Full traceability
Any deliverable (a ticket, a PRD section, a user story) can be traced back through the graph to the decision that authorized it, the data that informed that decision, and the alternatives that were considered. This is essential for compliance in regulated industries but valuable for any team that wants to understand its own product history.
Institutional memory
When a new PM joins the team, the decision graph provides a navigable history of every product decision, why it was made, and what it affected. Instead of spending weeks doing Slack archaeology and interviewing teammates, the new PM can explore the graph and understand the product's decision history in hours.
Decision Graph vs. Other Product Primitives
Product teams already have several structured models for different aspects of their work:
| Primitive | What It Models | Limitation |
|---|---|---|
| Task graph (Jira/Linear) | Work items and dependencies | No connection to why work exists |
| Code graph (GitHub) | Code structure and dependencies | No connection to product decisions |
| Design system (Figma) | UI components and patterns | No connection to requirements |
| Roadmap | Sequencing and priorities | No connection to underlying data |
| Decision graph | Decisions, data, and deliverable connections | Requires a purpose-built platform |
The decision graph does not replace these primitives. It connects them. A task in the task graph traces to a decision in the decision graph. A component in the design system traces to the requirement in the decision graph that defined it. The decision graph provides the “why” layer that other primitives lack.
How Vantage Implements the Decision Graph
Vantage is built around the decision graph as its core data model. Every integration (Slack, Linear, Jira, Figma, Amplitude, GitHub, Notion) feeds data into the graph. Every deliverable (PRDs, tickets, user stories, prototypes) is generated from the graph and maintains its connections.
The decision graph is not a feature of Vantage. It is the architecture. Every capability Vantage provides (document generation, conflict detection, automatic updates, compliance checking, grooming sessions) is built on top of the graph. Without connected decisions, these capabilities would not be possible.
For product teams, the decision graph is the missing primitive: the structured model of product thinking that connects the strategic (“why are we building this?”) to the operational (“what tickets do we need?”) and keeps the connection live as both evolve.