The product decision ADR: why product, hiring, and process decisions belong in the same log

The three properties that make any decision worth documenting

The ADR format was invented by Michael Nygard for software architecture decisions, which is where the "A" in ADR comes from. But the format's usefulness isn't specific to software architecture — it comes from the three properties it's designed to capture, and those properties appear in decisions across every function in a company.

The test for whether a decision is worth documenting — technical or not — is whether it satisfies all three:

1. Named alternatives existed. The team or individual considered more than one option before deciding. A decision that had no alternatives isn't a decision — it's a default. But most meaningful product, hiring, and process choices did have alternatives: $49 vs. $29 vs. $69; hire a designer first vs. hire an engineer first; weekly syncs vs. async-first. The existence of named alternatives is the signal that reasoning exists to be recovered.
2. A constraint drove the selection. There was something — a customer signal, a runway constraint, a competitive position, a technical limitation, a values preference — that made one alternative better than the others at the time of decision. This is the "why" the ADR is designed to preserve. It's also the thing most likely to change: the constraint that made $49 the right price in Q1 may no longer apply in Q3, and knowing what the original constraint was is what makes re-evaluation systematic rather than arbitrary.
3. A new team member would behave differently knowing it. This is the practical test. If a new engineer joins without knowing about the pricing decision and a customer asks them why the tool costs $49, what do they say? If they get it wrong — misrepresent the reasoning, re-litigate a decision that was already made, or create inconsistency with how the founding team describes it — that's the decision worth documenting. The onboarding use case is the clearest version of this: a new hire who can read the decision log doesn't need to absorb institutional reasoning through osmosis over six months.

All three of these properties apply to product, hiring, and process decisions with exactly the same force as they apply to technical decisions. The format is appropriate. The only thing that prevents non-technical decisions from being documented in the engineering ADR log is the assumption that they belong somewhere else — Notion, a Slack channel, the founding team's shared memory. None of those survive a team of four becoming a team of fifteen.

Five categories of non-technical decisions worth logging

1. Product scope bets

The most valuable category, and the one with the highest density of undocumented decisions at early-stage companies. Product scope bets are decisions about what to build and — more importantly — what not to build, and in what sequence.

Technical decisions document what was built. Product scope decisions document why the team chose to build this before that, why a feature was deferred rather than rejected, and what the constraint or customer signal drove the prioritization. These are the decisions that live in product roadmap discussions — often in AI chat sessions where a founder or PM is working through trade-offs — and then vanish when the roadmap moves on.

The "not building this" record type is particularly important for product scope. A decision to not build a mobile app in year one, or to not support a specific integration, or to not pursue enterprise pricing — these are active choices with reasoning, not absences. When the question comes up six months later ("why don't we have a mobile app?"), the team needs the reasoning, not just the current status. Reconstructing it from memory produces answers that sound like rationalizations rather than decisions.

The ADR format for a product scope decision looks like this: Context is the customer feedback, competitive pressure, or resource constraint that made the decision necessary; Decision is what's in scope and what's explicitly out of scope; Consequences is what this enables (focus, speed) and what it forecloses (the customer segment that wanted the excluded feature).

2. Pricing and packaging decisions

Pricing decisions are among the most frequently re-litigated decisions at early-stage companies. They're also among the least documented. The typical pattern: pricing is set in a two-hour session during which the founder runs through competitor prices, calculates value-per-seat, remembers a user interview comment, and lands on a number. The number gets shipped. Six months later, a new hire or a new investor asks why, and nobody can reconstruct the full reasoning from memory.

A pricing ADR doesn't need to be long. It needs to capture: the options considered (the price points evaluated, not just the one chosen), the constraint that drove the selection (competitive positioning, value calculation, acceptable friction for the target ICP), and the conditions that would trigger re-evaluation. That last point is important for pricing specifically: a price point that's right at $1M ARR may need to be revisited at $3M ARR, and the review trigger should be explicit ("re-evaluate if monthly churn exceeds X%" or "re-evaluate when we add enterprise tier"). Without the review trigger, pricing re-evaluation happens reactively — in response to lost deals or churned customers — rather than proactively against the original reasoning.

Packaging decisions (what's in free vs. paid, where the tier boundaries fall, what the expansion motion looks like) have the same documentation value. The rationale for putting a specific feature in Pro tier rather than free is rarely obvious to a new team member or an enterprise prospect asking "why do I have to upgrade for X?" A packaging ADR that documents "this feature is in Pro because it's a team-coordination feature, not an individual-productivity feature — the ICP for free tier is a solo founder, not a team lead" answers that question in one sentence.

3. Hiring and team structure decisions

Hiring decisions are almost never documented, despite being among the most consequential and expensive choices an early-stage company makes. The typical record is "we hired X in month Y" — which is the decision outcome with none of the reasoning. The reasoning that's actually worth preserving is different: which role was prioritized over which alternatives, what capability gap the hire was designed to address, and what the trade-off was in hiring for this profile rather than a different one.

This is different from a hire record. A hire record says "we hired a frontend engineer in Q2." A hiring ADR says: "We hired for frontend before we hired for growth marketing because the primary bottleneck in the conversion funnel was onboarding UX, not top-of-funnel volume. Alternatives considered: (1) hire a growth marketer first to increase trial volume, rejected because conversion rate was 4% and improving volume on 4% conversion is worse than improving conversion rate; (2) contract the frontend work and hire for growth marketing, rejected because the onboarding problem is too embedded in the product architecture for a contractor to resolve without context. Review trigger: if month-3 activation rate doesn't improve to >20%, revisit the hypothesis."

The value of this record is not retrospective documentation for its own sake. It's that the next hiring decision is made better when the team can see the reasoning behind the last one. The new-CTO problem is as acute for hiring decisions as for technical ones: a new leader who can't understand why the team is shaped the way it is has to reconstruct that reasoning through interviews with people who may remember it differently.

Organizational structure decisions — reporting lines, team topology changes, decision-authority allocations — belong in the same category. A decision to move from functional teams to product squads, or to give engineering a seat on the product roadmap process, is a consequential choice with named alternatives and a constraint that drove it. Without a record, "why is it structured this way?" gets answered with whatever the current team's narrative is, which may or may not match what the founders intended.

4. Process adoption decisions

Engineering process decisions — why the team does code review the way it does, why deploys happen on Tuesdays not Fridays, why they use async RFC before opening a pull request for large changes — are exactly the kind of decision that a new engineer infers from observation rather than reads from documentation. The inference is often wrong. The process looks like a convention when it was actually a reasoned choice, and the new engineer who doesn't know the reason will eventually break the convention without knowing they're breaking it.

Process decisions are different from technical decisions in one important way: their documentation value decays faster. A technical architecture decision might be stable for two to three years. A process decision might need to be revisited every six months as the team grows. This makes the review trigger field especially important for process ADRs: "this process was chosen for a five-person team; re-evaluate when headcount exceeds fifteen" is the kind of condition that prevents process debt from accumulating silently.

Process decisions also have a cross-functional dimension that technical decisions rarely have. An engineering process decision about when to involve design in the build process isn't a decision that engineering owns unilaterally — it's a cross-functional decision whose downstream effect on the design team should be part of the record. The Consequences section of a process ADR should note who is affected by the process, not just the team that adopted it.

5. Market and ICP decisions

Who the product is for — the ICP, the go-to-market motion, the positioning — is one of the earliest and most consequential decisions an early-stage company makes. It's also almost never written down in a form that survives the founding team. The founding team knows the ICP because they chose it; everyone who joins later infers it from the product, the marketing copy, and whatever the founding team says when asked. These are three different signals that frequently diverge.

ICP decisions have named alternatives: "we chose to target L5+ engineers at 5–50-person SaaS companies rather than enterprise engineering managers because the sales motion for enterprise requires a dedicated AE, and we don't have the runway to build enterprise sales before product-market fit." A new hire reading that sentence understands why the onboarding flow is frictionless instead of enterprise-ready, why the pricing is individual-seat rather than site-license, and why the marketing copy uses technical language rather than executive-tier language. The same new hire who infers the ICP from the product alone may infer differently, and build or position for the wrong audience.

Market decisions compound with time. A pivot in ICP that happens without a record of the original ICP means the team loses the ability to evaluate the pivot clearly — the new direction is treated as original intent rather than as a reasoned change from a prior position. The decision log format for ICP decisions works exactly like it does for technical ones: the prior decision and its reasoning, the new information that changed it, the new decision and its new reasoning.

Why the standard ADR format works without modification

It's tempting to design a separate template for non-technical decisions: a "product decision record" format, a "people decision template," a "strategy document." These proliferate because the people creating them don't realize the standard ADR format already works, and they want something that feels appropriate for the decision type they're documenting.

The standard Markdown ADR template — Title, Status, Context, Decision, Consequences, and optionally Considered Options — applies directly to every non-technical decision type described in this post. Let's apply it to the pricing decision from the opening scenario:

# ADR-042: Pricing — $49/seat/month Pro tier

**Date:** 2025-11-12
**Status:** Accepted
**Deciders:** Co-founder (CPO), Co-founder (CTO)

## Context

We are setting the initial price point for the Pro tier ahead of the public launch.
Three signals available: (1) competitor analysis — nearest comparable tool is at $59/seat;
(2) early user interviews (n=6) — $49 "felt right" to 5 of 6, $79 "felt expensive" to 4 of 6;
(3) value calculation — ICP (L5+ engineers at Series A/B companies) has ~$200/month discretionary
spend for developer tools per Stripe Atlas benchmarks. $49 is well within threshold.

## Considered options

1. $29/seat — Positions as low-cost alternative. Risk: devalues the product and attracts
   cost-sensitive customers who churn faster. Rejected.
2. $49/seat — Sits $10 below nearest competitor. Priced appropriately for individual-buyer
   motion (no approval chain needed for most ICP). Chosen.
3. $69/seat — Maximizes per-seat revenue. Risk: pushes past the no-approval-needed threshold
   for many ICP buyers, requiring a manager sign-off and adding friction in the trial-to-paid
   conversion. Rejected for now; revisit when expansion revenue (team tier) is the primary motion.

## Decision

$49/seat/month for Pro. Free tier retains one-export limit to drive trial and referral.
Team tier at $29/seat (volume) positioned as the expansion motion, not the entry point.

## Consequences

The price point supports individual-buyer motion — no procurement process for most ICP.
Margin allows for a limited-time annual discount (20%) to convert monthly trials.
Revenue per account grows only through seat expansion, not price expansion — acceptable
given the current ICP but will require re-evaluation when targeting larger teams.

## Review triggers

- Re-evaluate if monthly trial-to-paid conversion drops below 8%.
- Re-evaluate if average deal size exceeds 4 seats (signals team-buyer motion is primary).
- Re-evaluate at $1M ARR to assess whether $49 is still appropriate for the customer profile
  that's actually converting, vs. the profile we designed for at launch.

This is a complete pricing ADR in the standard format. No new template fields, no special format. The Considered Options section carries the alternatives. The Consequences section carries what the price point optimizes for and what it forecloses. The Review triggers (a common extension used in security ADRs and equally applicable here) encode the conditions under which the decision should be revisited.

The decision is now recoverable by any future team member without interviewing the founding team. The investor asking "why $49?" gets a one-sentence answer with a pointer to the full record.

The cross-functional ownership problem

Technical decisions usually have a clear owner: the engineering team that made them, in the engineering ADR repository. Non-technical decisions are more complicated. A pricing decision involves product, engineering, and sometimes marketing. A hiring decision involves the hiring manager, the co-founder, and anyone who interviewed. A process decision may span multiple functions.

The temptation is to route non-technical decisions to wherever the decision-makers already work — Notion for product decisions, a Google Doc for hiring decisions, a Confluence page for process decisions. This is the scattering pattern that ADRs are designed to prevent. A new team member looking for "why is the product priced at $49?" shouldn't have to know to look in Notion rather than the repo. A new engineer trying to understand why the team uses async RFC shouldn't have to find the right Notion page rather than reading decisions/process/0001-async-rfc-before-pr.md.

The practical recommendation: put non-technical ADRs in the same repository as technical ones, organized by type. A simple directory structure works:

decisions/
  technical/     (or just decisions/ root for technical)
    0001-choose-postgresql.md
  product/
    0001-pricing-49-per-seat.md
    0002-no-mobile-app-year-one.md
  hiring/
    0001-frontend-before-growth-marketing.md
  process/
    0001-async-rfc-before-large-prs.md

The Deciders field in each ADR header handles the multi-owner case: "Deciders: CPO, CTO, Head of Design" is a complete record of who the decision belonged to. The fact that the decision involves multiple functions is a reason to be more explicit about the Deciders field, not a reason to route the record to a different system.

For companies that already have a decision log in engineering but not elsewhere, the migration path is straightforward: add the product/ and process/ directories to the existing decisions/ folder, write the two or three most important undocumented product decisions first, and expand from there. Volume calibration applies to non-technical decisions the same way it applies to technical ones — five decisions per quarter per function is a reasonable target for a small team, not fifty.

What AI chat reveals about non-technical decisions

The WhyChose extractor was built to recover technical architecture decisions from AI chat exports. In practice, it captures non-technical decisions with equal or higher confidence — because product and business deliberation in AI chat is structurally more explicit than technical deliberation.

When an engineer uses AI chat for a technical architecture question, the conversation often explores, questions, builds up context incrementally. It can take ten messages before the actual decision frame becomes clear. When a founder or PM uses AI chat to work through a product or business question, the framing is almost always explicit from the first message: "I'm trying to decide between hiring a designer and hiring a second engineer. Here's the situation: [context]. What should I think about?" That structure — explicit current situation, named alternatives, stated constraint — is exactly what the extractor's question-shape and trade-off marker patterns are looking for.

The specific session types most worth running through the extractor for non-technical decision recovery:

• Pricing and packaging deliberation sessions. "Should we charge $49 or $29?" produces an extremely high-confidence extraction — it's a named binary with a stated constraint. The longer form ("I'm working through our pricing model and trying to decide between several options — here's what I know about our target customer...") produces multiple extraction candidates. These sessions are easy to find in chat history by date proximity to the launch or pricing change.
• Hiring and org structure deliberation sessions. Decisions about role sequencing ("I'm trying to figure out whether to hire a designer or a second engineer"), candidate comparison ("I'm comparing two finalists for the engineering role — here are the key differences..."), and org structure ("should we move to product squads or stay functional?") all produce high-confidence extraction candidates because the framing names alternatives and states the reasoning constraint. The trade-off marker patterns ("the advantage of X is..., the disadvantage is...") are common in this category.
• Product scope deliberation sessions. "Should we build X this quarter or defer it?" and "I'm deciding whether to add [feature] to the free tier or keep it paid-only" are exact match patterns for the extractor's commit-phrase heuristics. The quarterly decision review produces a cluster of these sessions from the weeks before roadmap planning — the extraction pass applies to product planning sessions as directly as it does to architecture sessions.
• ICP and positioning deliberation sessions. These often appear as longer exploratory sessions — a founder working through market segmentation, debating go-to-market motion, or deciding which customer archetype to optimize the product for first. The sessions themselves are less structured than the pricing or hiring format, but they contain decision records: "we're going to target [segment] rather than [segment] because [constraint]" is a high-confidence extraction candidate wherever it appears.

The extractor's ChatGPT export and Claude export processes work identically for non-technical sessions. The only difference in the extraction output is the category field: technical decisions show up as architecture or technology choices, product decisions show up as scope or prioritization decisions. Both are first-class records.

For teams doing their first extraction pass on a historical export: the non-technical sessions are often the highest-value recovery targets, precisely because nothing else in the codebase or git history records this reasoning. Technical decisions leave traces — code, PRs, deploy logs, the architecture itself. Non-technical decisions leave nothing except the reasoning in the chat sessions and the outcome in the company's current state. The outcome is visible. The reasoning is in the export.

The "different function" triage test

When running the quarterly decision review and triaging extraction output for promotion to ADR-level records, the standard technical-decision criteria (durable, named alternatives, constraint-driven) apply to non-technical decisions without modification. One additional filter is useful specifically for non-technical decisions: the "different function" test.

Ask: if someone from a different function — a new engineer reading a product decision, or a new product manager reading an engineering decision — encountered the current state of the company without this record, what would they infer incorrectly? A new engineer who doesn't know why the product is priced at $49 may infer that the price was set based on the cost to serve, or that it's a round number with no specific reasoning. A new product manager who doesn't know why the engineering team uses async RFC before large PRs may infer it's optional, or that it applies only to backend changes, or that it can be skipped when the change is urgent.

Decisions that pass the different-function test — where someone from outside the decision's origin function would predictably misunderstand the current state without the record — are the highest-priority non-technical ADRs to write or recover. They're the ones that cause the most expensive confusion as the team grows, because the confusion happens across function boundaries where oral institutional knowledge doesn't travel reliably.

This is the same phenomenon that the new-CTO onboarding problem describes at the individual-decision level: one undocumented decision creates weeks of reconstruction work for the new leader. At scale, a company with no non-technical decision log has this problem for every product, hiring, and process decision it has ever made — and the reconstruction work happens continuously as the team grows, rather than once when a new leader joins.

Where to start

The practical entry point for non-technical decision documentation is the same as for technical decisions: don't try to document everything at once. Start with the decisions that are most actively in question — the ones that new hires ask about, the ones that investors probe, the ones that the founding team gives inconsistent answers on.

For most early-stage companies, that's a list of five to ten decisions: why the product is priced the way it is, what the ICP is and why that segment rather than the adjacent one, what the first two or three major product scope choices were (including the features explicitly deferred), and why the team is structured the way it is. These decisions are the most expensive to not have documented, and they're usually recoverable from AI chat history for any company that has been using AI tools in its daily work.

Run the extractor on the founding team's ChatGPT and Claude exports, filter for non-technical extraction candidates, and write up the three that would most clearly answer the question "why is it this way?" for a new team member joining next month. That's a three-hour investment that eliminates the most expensive category of institutional knowledge loss. The decision log template works for all five categories without modification — the format is the same, only the content domain changes.

The company that has this log when it grows from ten people to twenty-five doesn't spend those fifteen new hires' first weeks reconstructing why things are the way they are. It spends them building what's next — on top of decisions that are findable, readable, and honest about the reasoning that would have been lost otherwise. Add that to the waitlist if you want to be the first to try the full decision log flow when it ships.