SpeckyDocs

Decision Log

What it does

The Decision Log is a structured, searchable record of every significant product decision your team makes. Each entry captures not just *what* was decided, but *why* — the context, the options considered, the evidence weighed, and the expected outcome.

Most teams make hundreds of product decisions per quarter, but the reasoning behind those decisions lives in Slack threads, meeting notes, and people's heads. When a new engineer asks "why did we build it this way?" or a stakeholder challenges a past choice, the answer is usually lost. The Decision Log fixes that.

Specky automatically links decisions to related signals, PRDs, and Jira tickets, so every decision has a full evidence trail.

When to use it

  • After any significant product decision — scope changes, build vs. buy, feature cuts, priority shifts
  • During retrospectives — review past decisions and their actual outcomes
  • When onboarding new team members — give them context on why the product is the way it is
  • Before making a similar decision — search for past decisions to avoid repeating mistakes
  • During stakeholder reviews — show the evidence and reasoning behind your choices

    • How to use it

  • Open Decision Log from the sidebar
  • Click Add Decision
  • Fill in the structured form:
    • - Title — a clear, one-line statement of the decision (e.g. "Delay dark mode to Q3") - Context — what situation prompted this decision - Options considered — at least two alternatives you evaluated - Chosen option — what you decided - Rationale — why this option over the others - Expected outcome — what you expect to happen as a result
  • Link related signals, PRDs, or Jira tickets using the Link button
  • Set a Review date if you want to revisit the decision later
  • Click Save — the decision is now searchable and linked in the Product Graph

    • Example

    Decision: Delay dark mode to Q3 2026

    Context: Three competing priorities in Q2 (checkout redesign, API v2, mobile app) with limited engineering capacity.

    Options considered:

  • Build dark mode in Q2 as planned
  • Delay dark mode to Q3
  • Outsource dark mode to a contractor

    • Chosen option: Delay to Q3

    Rationale: Dark mode was requested by fewer than 5% of users based on Slack analysis (12 mentions in 90 days vs. 89 mentions for checkout issues). Engineering capacity is fully committed to higher-impact work.

    Expected outcome: No measurable churn impact; revisit in Q3 when capacity allows.