ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity
BMAD-METHOD/docs/learn/module-04-product-brief/lesson-06-additional-docume...

14 KiB
Raw Blame History

Module 04: Product Brief

Lesson 6: Additional Strategic Documents

Expanding your strategic foundation based on project needs

Beyond the Core Brief

The Product Brief is your foundation - the document every project needs. But some projects need additional strategic documents to provide deeper clarity in specific areas.

The principle: Start with the Product Brief. Add other documents only when your project actually needs them.

All documents live together:

/docs/A-Product-Brief/
  ├── project-brief.md (always)
  ├── core-features.md (if needed)
  ├── tone-of-voice.md (if needed)
  ├── visual-design-brief.md (if needed)
  └── [other strategic docs as needed]

Why this matters:

  • Single folder for all strategic decisions
  • Easy to reference and update
  • Version controlled together
  • Shared across entire team

Document 1: Core Features

When you need it: Complex products with many features that need prioritization

What It Contains

Must-Have Features:

  • Core functionality for MVP
  • Essential to solve the main problem
  • Required for launch

Should-Have Features:

  • Important but not launch-critical
  • Enhance core experience
  • Phase 1 or early Phase 2

Could-Have Features:

  • Nice-to-haves for future iterations
  • Improve experience but not essential
  • Phase 2 or later

Won't-Have Features:

  • Explicitly out of scope
  • Prevents scope creep
  • Clear boundaries

Why It's Valuable

Clear Prioritization:

  • Team knows what to build first
  • No "everything is important" syndrome
  • Focus on what matters

Prevents Scope Creep:

  • "Can we add this?" → Check the features doc
  • Already decided what's in/out
  • Clear boundaries everyone agreed to

Helps with Roadmap:

  • MVP is clear (must-haves)
  • Phase 2 is clear (should-haves)
  • Future is clear (could-haves)

How to Create It

With Saga:

  1. List all possible features
  2. Evaluate each against Product Brief
  3. Categorize: Must/Should/Could/Won't
  4. Document with justification

Time: 20-30 minutes

Document 2: Tone of Voice Guide

When you need it: Products with significant written content or multiple writers

What It Contains

Brand Personality:

  • 3-5 personality traits
  • How you want to sound
  • What makes your voice unique

Voice Characteristics:

  • Formal vs casual
  • Technical vs simple
  • Serious vs playful
  • Authoritative vs friendly

Do's and Don'ts:

  • Specific examples of good copy
  • Specific examples of bad copy
  • What to say and what to avoid

Example Phrases:

  • Real examples in your voice
  • Common scenarios
  • Consistent language

Why It's Valuable

Consistent Communication:

  • All touchpoints sound the same
  • Predictable, trustworthy experience
  • Strong brand identity

Faster Copywriting:

  • Clear guidelines to follow
  • No guessing about tone
  • Confident writing

Better Onboarding:

  • New writers understand voice quickly
  • Less revision needed
  • Consistent quality

How to Create It

With Saga:

  1. Define personality traits
  2. Identify voice characteristics
  3. Create do/don't examples
  4. Document common phrases

Time: 20-30 minutes

Document 3: Visual Design Brief

When you need it: Projects that need custom visual design or brand development

What It Contains

Visual Mood:

  • Adjectives describing the look
  • Emotional tone of visuals
  • Overall aesthetic direction

Reference Inspiration:

  • Links to designs you like
  • Explanation of why you like them
  • What to borrow, what to avoid

Color Direction:

  • Warm vs cool
  • Bright vs muted
  • Energetic vs calm
  • Specific palette if known

Typography Direction:

  • Friendly vs serious
  • Modern vs classic
  • Readable vs decorative
  • Specific fonts if known

Visual Constraints:

  • Brand guidelines to follow
  • Accessibility requirements
  • Platform limitations

Why It's Valuable

Aligns Visual Direction:

  • Designer knows what you want
  • Before design starts, not after
  • Clear expectations

Prevents Revision Cycles:

  • No "I'll know it when I see it"
  • Clear criteria for evaluation
  • Faster to final design

Guides Design Decisions:

  • Color choices align with mood
  • Typography matches personality
  • Consistent visual language

How to Create It

With Saga:

  1. Describe desired mood
  2. Share inspiration examples
  3. Define color/typography direction
  4. Document constraints

Time: 15-20 minutes

Document 4: Technical Architecture Brief

When you need it: Complex technical projects or working with external developers

What It Contains

Platform Requirements:

  • Web, mobile, desktop
  • Browser/device support
  • Online/offline needs

Technology Stack:

  • Preferred frameworks
  • Languages and tools
  • Infrastructure requirements

Integration Requirements:

  • APIs to connect to
  • Third-party services
  • Data sync needs

Performance Requirements:

  • Speed expectations
  • Scalability needs
  • Reliability standards

Security Requirements:

  • Data protection needs
  • Compliance requirements
  • Authentication/authorization

Why It's Valuable

Clear Technical Direction:

  • Developers know what to build with
  • No surprises about requirements
  • Aligned technical decisions

Accurate Estimates:

  • Developers can estimate properly
  • No "we can't build that" surprises
  • Realistic timelines

Prevents Technical Debt:

  • Right architecture from start
  • Scalable foundation
  • Future-proof decisions

How to Create It

With Saga:

  1. Define platform needs
  2. Specify technology preferences
  3. Document integrations
  4. Set performance/security standards

Time: 20-30 minutes

Document 5: Content Strategy

When you need it: Content-heavy products (blogs, documentation, educational platforms)

What It Contains

Content Types:

  • What kinds of content you'll create
  • Format and structure
  • Purpose of each type

Content Goals:

  • What each type achieves
  • How it serves users
  • How it supports business

Publishing Frequency:

  • How often content is created
  • Who creates it
  • Review and approval process

Content Ownership:

  • Who creates
  • Who reviews
  • Who publishes
  • Who maintains

Why It's Valuable

Sustainable Content Creation:

  • Clear expectations
  • Manageable workload
  • Consistent quality

Aligned Content:

  • All content serves strategy
  • No random content
  • Clear purpose

Efficient Process:

  • Defined workflows
  • Clear ownership
  • No bottlenecks

Document 6: Localization Strategy

When you need it: Multi-language or multi-region products

What It Contains

Target Markets:

  • Which languages
  • Which regions
  • Priority order

Cultural Considerations:

  • What needs adaptation beyond translation
  • Cultural sensitivities
  • Regional preferences

Technical Approach:

  • How localization is implemented
  • Translation workflow
  • Quality assurance

Resource Requirements:

  • Translators needed
  • Budget allocation
  • Timeline per market

Why It's Valuable

Prevents "English-First" Problems:

  • Design works in all languages
  • No text overflow issues
  • Cultural appropriateness

Plans for Expansion:

  • Clear roadmap for markets
  • Resource planning
  • Realistic timelines

Quality Localization:

  • Not just translation
  • Cultural adaptation
  • Native-feeling experience

Document 7: Accessibility Requirements

When you need it: Products with specific accessibility needs or compliance requirements

What It Contains

Compliance Level:

  • WCAG 2.1 AA, AAA
  • Specific regulations
  • Industry standards

Priority Users:

  • Specific disabilities to design for
  • Assistive technologies to support
  • User needs to address

Testing Requirements:

  • How accessibility is validated
  • Tools and processes
  • Success criteria

Technical Requirements:

  • Screen reader support
  • Keyboard navigation
  • Color contrast standards
  • Focus management

Why It's Valuable

Accessibility Built In:

  • Not bolted on later
  • Designed from start
  • Lower cost, better results

Clear Requirements:

  • Designers know standards
  • Developers know implementation
  • QA knows testing

Compliance Confidence:

  • Meet legal requirements
  • Serve all users
  • Avoid costly retrofits

Document 8: Data & Privacy Strategy

When you need it: Products handling sensitive user data

What It Contains

Data Collection:

  • What data you collect
  • Why you collect it
  • How you collect it

Data Storage:

  • Where data is stored
  • How it's secured
  • Retention policies

Data Usage:

  • How data is used
  • Who has access
  • Analytics and tracking

Compliance:

  • GDPR, CCPA, or other regulations
  • User rights (access, export, delete)
  • Privacy policy requirements

Why It's Valuable

Privacy by Design:

  • Not an afterthought
  • Built into architecture
  • Compliant from day one

Clear Requirements:

  • Developers know what to build
  • Legal knows what's covered
  • Users know what to expect

Builds Trust:

  • Transparent about data
  • Respects user privacy
  • Professional approach

How to Decide What You Need

Start with Product Brief (always)

Then add documents based on these questions:

Core Features Document

Add if:

  • ✅ Product has 10+ features
  • ✅ Team needs prioritization clarity
  • ✅ Working with external developers
  • ✅ Risk of scope creep

Skip if:

  • ❌ Simple product (< 5 features)
  • ❌ Solo developer
  • ❌ Clear priorities already

Tone of Voice Guide

Add if:

  • ✅ Significant written content
  • ✅ Multiple people writing copy
  • ✅ Brand voice is critical
  • ✅ Customer-facing communication

Skip if:

  • ❌ Minimal text in product
  • ❌ Single writer
  • ❌ Internal tool only

Visual Design Brief

Add if:

  • ✅ Creating custom visual design
  • ✅ Working with external designers
  • ✅ Visual brand is critical
  • ✅ Need alignment before design

Skip if:

  • ❌ Using existing design system
  • ❌ Solo designer with clear vision
  • ❌ Visual design not critical

Technical Architecture Brief

Add if:

  • ✅ Complex technical requirements
  • ✅ Working with external developers
  • ✅ Multiple integration points
  • ✅ Scalability critical

Skip if:

  • ❌ Simple technical stack
  • ❌ Solo developer
  • ❌ Standard architecture

Other Documents

Add based on:

  • Project complexity
  • Team size and distribution
  • Regulatory requirements
  • Business criticality

The rule: Don't create documents you won't use. Start minimal, add as needed.

Creating Additional Documents with WDS

Same conversational approach:

  1. Activate Saga
  2. Tell her which document you need
  3. Have a guided conversation
  4. Saga creates the document
  5. Review and refine

Same speed:

  • 15-30 minutes per document
  • Professional quality
  • Proper structure
  • Easy to update

Same benefits:

  • No blank page
  • Built-in best practices
  • Consistent format
  • Living documents

The Complete Strategic Foundation

When you have all relevant documents:

/docs/A-Product-Brief/
  ├── project-brief.md
  ├── core-features.md
  ├── tone-of-voice.md
  ├── visual-design-brief.md
  ├── technical-brief.md
  ├── content-strategy.md
  ├── localization-strategy.md
  ├── accessibility-requirements.md
  └── data-privacy.md

You have:

  • ✅ Complete strategic clarity
  • ✅ Single source of truth for all decisions
  • ✅ Clear guidance for entire team
  • ✅ Protected scope boundaries
  • ✅ Professional foundation

The result:

  • Designers make confident decisions
  • Developers understand requirements
  • Stakeholders track progress
  • Product managers prioritize effectively
  • Everyone works from same foundation

Keeping It Manageable

Don't create everything at once:

Phase 1 (Always):

  • Product Brief

Phase 2 (As needed for MVP):

  • Core Features (if complex)
  • Technical Brief (if complex)

Phase 3 (As project grows):

  • Tone of Voice (when writing matters)
  • Visual Design Brief (when design starts)

Phase 4 (As you scale):

  • Content Strategy (when content grows)
  • Localization (when expanding markets)
  • Accessibility (when compliance needed)
  • Data & Privacy (when handling sensitive data)

The principle: Add documents when the pain of not having them exceeds the effort of creating them.

Module Complete

You now understand:

✅ Why the Product Brief prevents chaos ✅ The 5 strategic questions it must answer ✅ What the document looks like and how it's structured ✅ How WDS makes this fast (30-45 minutes) ✅ How teams use it throughout the project ✅ What additional documents you can create as needed

You're ready to create your own Product Brief.

Next Steps

1. Complete the Tutorial

2. Create Additional Documents

  • As your project needs them
  • Same conversational approach
  • Same speed and quality

3. Start Using Your Brief

  • Reference it in decisions
  • Update it when things change
  • Share it with your team
  • Make it your single source of truth

4. Continue to Module 05

Start Tutorial 04: Create Your Product Brief →

← Back to Lesson 5 | Back to Module Overview

Congratulations on completing Module 04! You now have the foundation to create strategic clarity for any project.

Part of Module 04: Product Brief