Architecture Decision Records (ADRs) are a standard practice in engineering teams. They document significant technical choices — why a particular database was selected, why a service boundary was drawn where it was, why a deprecated library wasn't replaced immediately — in a structured format that survives team turnover and organizational growth.
The concept works equally well for business decisions. It's just that nobody calls it that, so teams reinvent it badly — or not at all — for the decisions that aren't technical.
What makes ADRs work in engineering
Three properties make ADRs effective:
- Structured format. Every record has the same fields, which makes them scannable and comparable. You don't have to read a wall of prose to find the conclusion.
- Status tracking. Records have a status — Proposed, Accepted, Deprecated, Superseded. This tells future readers whether the decision is current or historical.
- Explicit rejected alternatives. The options that were considered and ruled out are documented alongside the reasoning. This prevents future engineers from proposing the same alternatives that were already evaluated.
None of these properties are engineering-specific. They apply to any consequential decision.
The business decision record template
The business analog to an ADR has the same core structure with one modification — "Consequences" becomes "Implications" to cover organizational and market effects, not just technical ones:
- Title — short, specific. "Pricing: annual-only for enterprise tier" not "pricing discussion."
- Status — Proposed / Accepted / Deprecated / Superseded.
- Context — the situation that made this decision necessary. What was the forcing function? What constraints existed? Keep this short — two or three sentences.
- Decision — one sentence, imperative. What was decided.
- Why — the two or three factors that drove the decision. Not a comprehensive list — the factors that tipped it.
- Rejected alternatives — what was considered and not chosen, with one-line reasoning for each rejection.
- Implications — what this decision commits the team to, what it makes harder, and what it makes unnecessary. Both positive and negative.
- Authority — who made this decision and what would be needed to revisit it.
Business decisions captured at the point they're made
StandIn brings the structure of decision records into daily work — not as a separate documentation system but as part of how the team declares its state. Decisions are captured with context, authority, and alternatives, in the same workflow where work happens.
Request early accessA worked example: pricing decision
Here is a business decision record applied to a pricing decision:
Title: Pricing: remove monthly plan, annual-only for all tiers
Status: Accepted
Context: Monthly churn for monthly subscribers is 8% vs. 1.2% for annual. Monthly subscribers have lower NPS and higher support load. We have enough annual customers to validate the model.
Decision: We will remove the monthly plan option as of Q3 2026. All new subscriptions will be annual only.
Why: (1) The 8% monthly churn is unsustainable at scale — each annual subscriber is worth 6x a monthly subscriber in LTV. (2) Monthly subscribers exhibit different behavior patterns that increase support costs disproportionately. (3) Annual contracts align incentives: customers commit to the product, we commit to their success.
Rejected alternatives: Monthly at higher price point — rejected because pricing elasticity analysis shows conversion drops sharply above 2x the current monthly price, likely reducing conversion more than churn savings justify. Hybrid model with monthly pilot period — rejected because the churn data shows the problem isn't trial length, it's commitment level.
Implications: Top-of-funnel conversion may drop 15-20% initially. Requires updated sales collateral and objection handling. Removes friction for enterprise procurement (annual invoice is preferred). Makes revenue more predictable and increases LTV per customer.
Authority: CEO + Head of Revenue. Revisable with CEO approval and new data showing the conversion impact exceeds the LTV gain.
Where to keep business decision records
The same principles apply as for engineering ADRs: a stable location, accessible to everyone who makes or is affected by business decisions, with full-text search. A dedicated section in your team wiki works. A separate Notion database with a consistent template works. What doesn't work is a mix of Slack messages, shared docs, and verbal agreements that live in individual memories.
If you already have an ADR folder in your engineering repo, consider maintaining a parallel folder for business decisions. Same format, separate directory. Engineers who review the business decisions alongside the technical ones get a cleaner picture of how the system and the strategy cohere.
How to introduce it without bureaucracy
Start with one domain — pricing, go-to-market, or hiring. Pick the domain where your team most often relitigates past decisions. Introduce the template there. Write three or four records retroactively for important past decisions. Then require new decisions in that domain to be captured in the format before they're considered final.
Once the team sees that the retroactive records are useful — that they can answer "why did we choose X" without a two-hour forensic exercise — adoption spreads naturally to other domains. The value is most visible in hindsight; getting to that first hindsight moment is the only onboarding task.
Frequently asked questions
How is a business decision record different from a strategy doc?
A strategy doc describes direction, goals, and context. A decision record captures a specific choice made at a specific time, by a specific authority. Strategy docs answer "where are we going"; decision records answer "what did we decide to do at this junction, and why." Both are useful; they serve different purposes and shouldn't be conflated.
What's the right granularity — do we record every decision?
No. The threshold is significance: would someone reasonably question this decision in six months? Would it cost more than an hour to reconstruct the reasoning if asked? If yes, record it. Day-to-day operational calls don't meet this bar. Strategic pivots, pricing changes, hiring standards, and market positioning choices do.
Who is responsible for creating the records?
The decision-maker, or a designated owner like a Chief of Staff. The key requirement is that the record is confirmed by the decision-maker within 24 hours — not just written by a notetaker who may have captured the conversation incorrectly. The confirmation step ensures the record reflects the actual decision, not the documented approximation of it.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.