# 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**
- [Tutorial 04: Create Your Product Brief](tutorial-04.md)
- 30-45 minutes with Saga
- Create your actual Product Brief

**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**
- [Module 05: Platform Requirements](../module-05-platform-requirements/module-05-platform-requirements-overview.md)
- Understanding user psychology
- Connecting business goals to user needs

---

**[Start Tutorial 04: Create Your Product Brief →](tutorial-04.md)**

---

[← Back to Lesson 5](lesson-05-using-brief.md) | [Back to Module Overview](module-04-overview.md)

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

*Part of Module 04: Product Brief*