How to Write a Good BDR¶

This document provides a practical guide and template for writing high-quality Business Decision Records (BDRs) at ConnectSoft, focusing on business decisions: models, pricing, domains, partner policies, marketplace rules, and strategy. It is written for product managers, executives, Dmitry, and anyone documenting business and strategic decisions.

BDRs capture important business choices, their context, alternatives considered, and impact. This guide shows how to write BDRs that are clear, useful, and maintainable, and explains how BDRs relate to strategy and business model docs.

Tip

When in Doubt: A BDR is helpful whenever Dmitry might later ask "Why did we decide to price/position it like this?" BDRs document the "why" behind business and strategic choices, not just the "what."

When to Write a BDR¶

Write a BDR When:

New or Changed Business Models - Factory pricing tiers, SaaS licensing models, squads pricing
Marketplace Rules - Who can publish, revenue share, curation standards, phasing
Domain & Branding Decisions - How .ai vs .io vs .dev vs .co.il are used
Partner Program Structure - Partner tiers, benefits, commercial models, revenue share
Product Positioning - How products are positioned, target markets, value propositions
Pricing Strategy - Pricing models, tiers, discounts, partner pricing
Go-to-Market Decisions - Sales motions, channels, partnerships

Do NOT Write a BDR For:

Minor pricing adjustments (unless they represent a strategic shift)
Day-to-day operational choices
Tactical marketing decisions
Choices that are clearly documented elsewhere (e.g., in strategy docs)

See: Decisions Overview and Process for when to use ADR vs BDR.

See: BDR Index for examples of existing BDRs.

BDR Structure and Template¶

Standard BDR Template¶

Use this template for all new BDRs:

# BDR-XXXX – Title

- **Type:** Business Decision
- **Status:** Proposed | Accepted | Superseded | Rejected
- **Date:** YYYY-MM-DD
- **Owner:** <name/role>
- **Related Areas:** Business Model / Pricing / Factory / Platforms / Marketplace

## Business Context

<Market situation, product context, constraints, goals.>

## Decision

<What is the chosen business/strategy decision?>

## Rationale

<Why is this the right direction now? Include trade-offs.>

## Impact

### On Customers

- ...

### On ConnectSoft

- ...

### On Partners

- ...

## Alternatives Considered

- **Option A** – Pros/Cons
- **Option B** – Pros/Cons

## Links and References

- Strategy docs
- Market analysis
- Roadmaps
- Related BDRs/ADRs

Template Sections Explained¶

Header Metadata: - Type - Always "Business Decision" for BDRs - Status - Current state of the decision (MUST be present) - Date - When decision was made or proposed - Owner - Who owns this decision (Dmitry, product manager, etc.) - Related Areas - Which business areas this affects

Business Context: - Market situation and competitive landscape - Product context and current state - Constraints (legal, financial, operational) - Business goals and objectives

Decision: - Clear, unambiguous statement of the business choice - Should be understandable in 1–2 sentences - Avoid vague language

Rationale: - Why is this the right direction now? - What trade-offs were considered? - What factors influenced the decision?

Impact: - On Customers - How does this affect customers? - On ConnectSoft - How does this affect ConnectSoft? - On Partners - How does this affect partners?

Alternatives Considered: - What other options were evaluated? - Why were they not chosen? - What are the trade-offs?

Links and References: - Strategy docs (Business Strategy, GTM Strategy) - Market analysis or research - Roadmaps (2026 Roadmap, Factory Roadmap) - Related BDRs or ADRs

See: BDR Template for the standard template.

See: BDR-0001 for a real example.

Content Guidelines¶

Writing Rules¶

Keep Language Non-Legal but Clear: - BDRs should be clear enough for contracts to reference - Avoid legalese, but be precise - Use business language, not legal jargon

Be Explicit About: - Who It Affects - Customers, partners, internal team, specific segments - What Is In vs Out of Scope - Which products, markets, or scenarios this applies to - When It Applies - Effective dates, phasing, sunset dates

Document Trade-offs: - Business decisions always involve trade-offs - Document what was sacrificed for what was gained - Help future readers understand the full picture

Link to Strategy: - BDRs should link to relevant strategy docs - Strategy docs should reference relevant BDRs - Create bidirectional links

Important

Internal Consistency: BDRs MUST be internally consistent with existing BDRs and ADRs. If they conflict, a Superseded chain must be recorded. Always check existing BDRs before creating new ones to ensure consistency.

Example: BDR-0001 Pattern¶

BDR-0001 (Generated Code Ownership) demonstrates good BDR structure:

Pattern: - Clear Business Context - Enterprise trust, competitive advantage, customer value - Explicit Decision - "All code generated into customer Azure DevOps is owned by the customer" - Impact Sections - On customers, ConnectSoft, partners - Honest Rationale - Why this builds trust and competitive advantage - Links to Strategy - References business model and governance docs

Why This Is a Good BDR:

✅ Clear Scope - Applies to all Factory-generated code
✅ Explicit Decision - Unambiguous ownership statement
✅ Business Context - Market situation and customer needs
✅ Impact Documented - Effects on customers, ConnectSoft, partners
✅ Links to Strategy - References business model and governance

Linking BDRs to Strategy and Business Models¶

Relationship to Strategy Docs¶

BDRs Are Canonical: - BDRs are the canonical record of business/strategy choices - Strategy docs are the narrative built on top of BDRs - Strategy docs should reference relevant BDRs

Strategy Docs Should: - List key BDRs in a "Related Decisions" section - Reference BDRs when explaining why choices were made - Link back to BDRs for detailed rationale

BDRs Should: - Link to relevant strategy docs (Business Strategy, GTM Strategy) - Reference roadmaps that reflect the decision - Link to governance docs (IP, SLAs, Security)

Practice: Key Decisions Sections¶

In Strategy/Roadmap Docs:

## Key Decisions

- [BDR-0001](decisions/bdr/BDR-0001-generated-code-ownership.md) - Generated code ownership model
- [BDR-0004](decisions/bdr/BDR-0004-ai-squads-pricing-model.md) - AI Squads pricing model
- [BDR-0005](decisions/bdr/BDR-0005-marketplace-phasing.md) - Marketplace phasing strategy

In BDRs:

## Links and References

- [Business Strategy](../strategy/business-strategy.md) - Overall business objectives
- [2026 Roadmap](../roadmaps/2026-roadmap.md) - Roadmap reflecting this decision
- [Code Ownership Model](../business-model/code-ownership-model.md) - Related business model doc

Decision

BDR Authority: BDRs are the canonical record of business/strategy choices; strategy docs are the narrative built on top. Each major strategy/roadmap page should have a small "Key Decisions" section linking to relevant BDRs. This creates bidirectional links between decisions and strategy.

Example Link Patterns¶

From Strategy to BDR: - Business Strategy → BDR-0001 (Code Ownership), BDR-0004 (Squads Pricing) - GTM Strategy → BDR-0003 (Domain Strategy), BDR-0005 (Marketplace Phasing) - Marketplace Strategy → BDR-0005 (Marketplace Phasing)

From BDR to Strategy: - BDR-0001 → Business Strategy, Code Ownership Model, Governance (IP) - BDR-0004 → Business Strategy, Squads Business Model, Pricing Strategy - BDR-0005 → Marketplace Strategy, 2026 Roadmap, Marketplace Roadmap

See: Business Strategy for strategy docs.

See: 2026 Roadmap for roadmap docs.

Example BDR Scenarios¶

BDR-000X – Marketplace Revenue Share Model

What It Would Clarify: - Revenue split between creators and ConnectSoft (e.g., 70/30) - How revenue is calculated and distributed - Payment terms and frequency - Partner vs. public contributor models

Key Sections: - Business Context: Marketplace growth, creator incentives, ConnectSoft sustainability - Decision: Specific revenue share percentages and terms - Impact: On creators (incentives), ConnectSoft (revenue), partners (commercial models)

See: Marketplace Strategy for marketplace strategy.

See: Commercial Models and Revenue Share for partner revenue share.

Scenario 2: Domain Usage Strategy¶

BDR-0003 – Domain Strategy (.ai, .io, .dev, .co.il)

What It Clarifies: - How .ai vs .io vs .dev vs .co.il are used - Brand positioning for each domain - Content and audience strategy per domain - Governance and approval process

Key Sections: - Business Context: Brand positioning, audience segmentation, market strategy - Decision: Specific domain roles and usage rules - Impact: On brand perception, audience experience, marketing strategy

See: BDR-0003 - This BDR already exists.

See: Domains & Branding Overview for domain strategy.

Scenario 3: Factory Pricing Tiers¶

BDR-000Y – Factory Pricing Tiers Stack (Starter / Growth / Enterprise)

What It Would Clarify: - Pricing tiers and what's included in each - Usage limits and overage policies - Feature differentiation between tiers - Enterprise custom pricing approach

Key Sections: - Business Context: Market positioning, competitive landscape, customer segments - Decision: Specific tier structure, pricing, and features - Impact: On customers (value proposition), ConnectSoft (revenue), sales (positioning)

See: Factory Business Model for Factory business model.

See: Pricing Strategy for pricing strategy.

Scenario 4: Partner Program Tiers¶

BDR-000Z – Partner Program Tiers and Benefits

What It Would Clarify: - Partner tiers (e.g., Certified, Premier, Strategic) - Benefits and requirements for each tier - Revenue share models per tier - Support and enablement levels

Key Sections: - Business Context: Partner ecosystem goals, market needs, competitive positioning - Decision: Specific tier structure, benefits, and requirements - Impact: On partners (value proposition), ConnectSoft (ecosystem growth), customers (delivery quality)

See: Partner Program Levels for partner tiers.