Business Requirements Document (BRD) Writing

There is a prompt instruction at https://www.zangwei.dev/prompts/product-planning/business-requirement-document-brd-prompt . Extract and follow the prompt to create file /docs/handbook/planning/brd.md

You are a senior business-focused Product Lead. You need to write a BRD (Business Requirement Document) for company leadership (founder / CEO / shareholders).

## What a BRD is (and is not)
- BRD is about **Business**, not feature lists or engineering details
- The audience is **decision makers**, not executors
- The purpose is not to describe how to build it, but to answer:
  - Is it worth doing?
  - How much resource is worth investing?
  - What business outcome will it generate?

From a business perspective, systematically evaluate feasibility and provide decision inputs for project initiation and resource allocation.

## General requirements
- Business logic and outcome orientation; avoid excessive product/technical detail
- Emphasize market value, resource input, expected output, and monetization
- Quantify when possible; otherwise state clear assumptions (label as assumptions)
- Writing style should resemble a business memo, not a PRD or technical spec

---

## BRD output structure

1) Product background
1.1 Demand sources
- Analyze from both user demand and business/partner demand
- Core problems and opportunities in the current market or business
- Why now?
- If we do not build it, what opportunities/risks might we miss?

1.2 Market background
- Market status: size, stage, growth
- Competitive landscape: key competitors, concentration, strengths/weaknesses
- Market pains: weaknesses of existing solutions
- Trends: the next 2–3 years and opportunity window
- Potential upside (ranges or assumption-based)

2) Product plan (business view)
2.1 Product definition & positioning
- What kind of product should we build?
- Why build it (business motivation)?
- Core value and differentiation
- One-sentence positioning / analogy (e.g., the X of Y)

2.2 Target users
- User types (payer / user / decision maker)
- Core needs and willingness-to-pay drivers
- 2–3 archetypal personas and their business scenarios

2.3 Product scope (outcome-driven)
- Describe the end-state product (not implementation)
- Core capabilities and key modules (only what is tightly tied to business value)
- Non-functional requirements that matter for business (stability, compliance, security)

2.4 Plan & resource assessment
- Key resources required:
  - people (roles, size, duration)
  - money (R&D, operations, marketing, etc.)
  - time (from kickoff to business results)
- What is must-have/urgent vs what can be staged
- Causal link between resource input and business goals
- Initial roadmap (stage goals + timeline)

3) Product model
3.1 Business model (value flow)
- Where the product sits in the value chain
- Relationship/value flow among users, platform, partners

3.2 Commercial model
- Model type (single-sided / platform / value-added, etc.)
- How user value converts to business value
- Scalability and ceiling

3.3 Profit model
- How does it ultimately make money?
- Primary monetization points and pricing logic
- Why users will keep paying
- Stability and growth potential of the model

3.4 Operating model
- Operating focus by stage:
  - seed: validate value and demand
  - growth: expand scale and efficiency
  - platform: strengthen moats and margins
- Key operating metrics (acquisition, activity, retention, conversion)

4) Forecasts
4.1 Cost forecast
- people cost
- tech/infrastructure cost
- operations/marketing cost
- other necessary costs

4.2 Revenue forecast
- revenue model and key assumptions
- breakeven point and time expectation
- scenario ranges (conservative / base / optimistic)

4.3 Risks and mitigations
- market risks
- business model risks
- execution/resource risks
- mitigation strategies

5) Summary
- Overall feasibility judgment (business view)
- Core market advantages and competitive moats
- Fit between resource input and potential return
- Clear recommendation:
  - do not proceed
  - small-scale validation
  - formal project initiation