BMAD-METHOD/docs/learn-wds/module-04-product-brief/lesson-05-using-brief.md

# Module 04: Product Brief

## Lesson 5: Using Your Product Brief

**How this document powers your entire project**

---

## Not Filed Away, Actively Referenced

The Product Brief isn't a document you create and forget. It's your active reference throughout the project - the single source of truth that guides every decision.

**The difference:**

**Filed Away (Useless):**
- Created once, never opened again
- Stored somewhere nobody remembers
- Outdated within weeks
- Ignored when making decisions

**Actively Referenced (Powerful):**
- Opened multiple times per week
- Linked in all project documentation
- Updated when assumptions change
- Consulted before major decisions

**The goal:** Make the brief so useful that people naturally reference it.

---

## How Designers Use It

Designers reference the Product Brief to make confident decisions without constant stakeholder approval.

### Making Design Decisions

**The Question:** "Should we add this feature?"

**Without the Brief:**
- Designer guesses based on intuition
- Asks stakeholders (delays decision)
- Builds it and hopes it's right
- Discovers later it doesn't fit

**With the Brief:**
1. Check the vision - does this align?
2. Check target users - do they need this?
3. Check success criteria - does this contribute?
4. Check constraints - is this feasible?
5. Make confident decision

**Example:**

Designer considering social sharing features:
- Vision: "Family coordination for dog care" → Social sharing doesn't align
- Target users: "Parents managing household" → They need coordination, not social
- Success criteria: "Reduce coordination stress" → Social features add complexity
- Decision: No, doesn't fit the brief

**Time saved:** No meeting needed, confident decision made in minutes.

### Validating Design Solutions

**The Question:** "Is this design on the right track?"

**Without the Brief:**
- Designer relies on personal taste
- Unclear if it serves the right users
- Uncertain if it meets success criteria
- Validation happens late (expensive)

**With the Brief:**
1. Does it serve primary users?
2. Does it solve the core problem?
3. Does it respect constraints?
4. Does it differentiate us?
5. Will it contribute to success criteria?

**Example:**

Designer reviewing interface complexity:
- Target users: "Tech-comfortable parents" → Can handle moderate complexity
- Success criteria: "Task completion < 2 minutes" → Must be fast
- Constraints: "Family-friendly, organized, calm" → Can't be overwhelming
- Decision: Simplify, optimize for speed

### Staying Aligned During Iteration

**The Challenge:** Design evolves through iteration. How do you know if you're still on track?

**The Brief as North Star:**
- Vision doesn't change (unless project pivots)
- Target users don't change (unless you discover new insights)
- Success criteria don't change (unless you learn they're wrong)
- Constraints don't change (unless business reality shifts)

**When iterating:**
- Reference the brief at start of each sprint
- Check alignment after major design changes
- Validate that iterations serve the vision
- Update brief if fundamental assumptions change

---

## How Developers Use It

Developers reference the Product Brief to understand the "why" behind requirements and make technical decisions that serve the vision.

### Understanding the "Why"

**The Problem:** Developers get requirements without context. They build what's specified, not what's needed.

**The Brief Provides Context:**

**Without the Brief:**
- "Build a calendar feature" → Builds generic calendar
- No understanding of user needs
- No context for technical decisions
- Builds to spec, not to purpose

**With the Brief:**
- Reads vision: "Family coordination for dog care"
- Reads target users: "Parents managing household responsibilities"
- Reads success criteria: "Task completion < 2 minutes"
- Understands: This needs to be fast and family-focused, not feature-rich
- Builds accordingly

### Making Technical Decisions

**The Question:** "Which technical approach should we use?"

**Without the Brief:**
- Developer chooses based on personal preference
- Might over-engineer or under-engineer
- Unclear what performance matters
- Uncertain about future requirements

**With the Brief:**
1. Check constraints - what's required?
2. Check success criteria - what performance matters?
3. Check vision - what's the long-term direction?
4. Make informed technical decision

**Example:**

Developer choosing database approach:
- Constraints: "Offline core features required" → Need local storage
- Success criteria: "< 2s load time" → Need fast queries
- Vision: "Family coordination" → Need sync across devices
- Decision: Local-first architecture with sync

### Prioritizing Technical Work

**The Question:** "What should we build first?"

**Without the Brief:**
- Build in order received
- Unclear what's critical vs nice-to-have
- Risk building wrong things first
- Discover priorities late

**With the Brief:**
1. What serves primary users?
2. What contributes to success criteria?
3. What's required by constraints?
4. What enables the vision?

**Example:**

Developer prioritizing features:
- Success criteria: "90% task completion rate" → Core task flow is critical
- Constraints: "6-month timeline to MVP" → Must focus on essentials
- Target users: "Parents managing household" → Notifications are important
- Priority: Task flow, then notifications, then nice-to-haves

---

## How Stakeholders Use It

Stakeholders reference the Product Brief to track progress, make informed decisions, and prevent scope creep.

### Tracking Progress

**The Question:** "Is the project on track?"

**Without the Brief:**
- Subjective assessment
- Unclear what "on track" means
- Debates about what matters
- Anxiety about progress

**With the Brief:**
1. Check success criteria - are we hitting metrics?
2. Check timeline constraints - are we on schedule?
3. Check vision - are we building what we said?
4. Make objective assessment

**Example:**

Stakeholder reviewing progress:
- Success criteria: "1,000 active users by month 6" → Currently at 800 (month 5)
- Timeline: "6-month MVP" → On schedule for launch
- Vision: "Family coordination" → Features align
- Assessment: On track, slight user acquisition concern

### Making Informed Decisions

**The Question:** "Should we approve this change?"

**Without the Brief:**
- Decision based on opinion
- Unclear if change aligns with vision
- Risk of scope creep
- Inconsistent decision-making

**With the Brief:**
1. Does it align with vision?
2. Does it serve target users?
3. Does it contribute to success criteria?
4. Is it feasible within constraints?

**Example:**

Stakeholder evaluating feature request:
- Request: "Add social features"
- Vision: "Family coordination" → Social doesn't align
- Success criteria: "Reduce coordination stress" → Social adds complexity
- Constraints: "6-month timeline" → No time for scope expansion
- Decision: No, doesn't fit the brief

### Preventing Scope Creep

**The Challenge:** Everyone has ideas. How do you say no without seeming negative?

**The Brief as Shield:**

**Without the Brief:**
- "Can we add this?" → "I don't know, maybe?"
- No clear criteria for yes/no
- Scope grows unchecked
- Timeline and budget suffer

**With the Brief:**
- "Can we add this?" → "Let's check the brief"
- Vision: Does it align?
- Users: Do they need it?
- Criteria: Does it contribute?
- Constraints: Do we have time/budget?
- Clear yes/no with justification

**Example:**

Stakeholder suggesting enterprise features:
- Target users: "Parents managing household" → Not enterprise users
- Constraints: "Bootstrap budget, 6-month timeline" → No resources for enterprise
- Vision: "Family coordination" → Consumer focus
- Response: "Great idea for phase 2, but doesn't fit MVP brief"

---

## How Product Managers Use It

Product managers reference the Product Brief to create roadmaps, write user stories, and measure success.

### Creating Roadmaps

**The Question:** "What should we build next?"

**Without the Brief:**
- Roadmap based on requests
- Unclear prioritization criteria
- Risk of building wrong things
- Reactive instead of strategic

**With the Brief:**
1. What serves the vision?
2. What moves success criteria?
3. What target users need most?
4. What's feasible within constraints?

**Example:**

PM planning Q2 roadmap:
- Success criteria: "70% weekly active users" → Focus on retention
- Target users: "Parents managing household" → Need reminders, notifications
- Constraints: "Small team" → Must be achievable
- Roadmap: Notification system, recurring tasks, mobile improvements

### Writing User Stories

**The Question:** "How should we describe this feature?"

**Without the Brief:**
- Generic user stories
- Unclear user context
- Missing success criteria
- Developers guess at intent

**With the Brief:**
- Reference target users for "As a..."
- Reference vision for "I want to..."
- Reference success criteria for "So that..."
- Clear, contextualized stories

**Example:**

Writing story for task assignment:
- Target users: "Parents managing household responsibilities"
- Vision: "Eliminate coordination confusion"
- Success criteria: "Task completion < 2 minutes"
- Story: "As a parent managing household responsibilities, I want to quickly assign tasks to family members so that everyone knows their responsibilities without confusion or back-and-forth communication"

### Measuring Success

**The Question:** "Are we successful?"

**Without the Brief:**
- Success is subjective
- Debates about what matters
- Moving goalposts
- Unclear when to celebrate

**With the Brief:**
- Success criteria are defined
- Metrics are measurable
- Goalposts are fixed
- Clear success indicators

**Example:**

PM measuring launch success:
- User success: "80% report reduced stress" → Survey shows 82% ✅
- Business success: "1,000 active families by month 6" → Hit 1,200 ✅
- Technical success: "99.9% uptime" → Achieved 99.95% ✅
- Design success: "SUS score > 75" → Scored 78 ✅
- Result: Successful launch, all criteria met

---

## When to Update the Brief

The Product Brief is a living document, but not everything requires an update.

### When to Update

**✅ Update when:**

**Fundamental Assumptions Change:**
- Market research reveals different user needs
- Competitive landscape shifts significantly
- Business constraints change (budget, timeline, resources)
- Technical constraints change (platform requirements)
- Success criteria prove unrealistic or wrong

**Example:**
- Discovery: Primary users also need multi-pet support
- Impact: Changes target users, success criteria, constraints
- Action: Update brief, notify team, adjust roadmap

**Major Pivots:**
- Vision changes direction
- Target users shift
- Business model changes
- Positioning evolves

**Example:**
- Decision: Pivot from consumer to enterprise
- Impact: Changes everything
- Action: Major brief update, team alignment session

### When NOT to Update

**❌ Don't update for:**

**Tactical Decisions:**
- Individual feature decisions
- Design iterations
- Minor technical choices
- Day-to-day prioritization

**Example:**
- Decision: Change button color
- Impact: None on strategy
- Action: No brief update needed

**Opinions and Preferences:**
- Stakeholder suggestions
- Team member ideas
- User feature requests
- Competitive feature additions

**Example:**
- Request: "Can we add dark mode?"
- Impact: Doesn't change strategy
- Action: Evaluate against brief, but don't update brief

**The Rule:** Update the brief when fundamental strategy changes, not when tactics evolve.

---

## Making It a Habit

The brief is only powerful if people actually use it. Here's how to make it a habit:

### Make It Accessible

**Where to store it:**
- Project root: `/docs/A-Product-Brief/project-brief.md`
- Always in the same place
- Version controlled (Git)
- Linked from README

**How to reference it:**
- Include path in onboarding
- Link in project documentation
- Reference in meeting agendas
- Quote in decision documents

### Make It Referenced

**In meetings:**
- Start design reviews by reading relevant sections
- Reference it when explaining decisions
- Update it when assumptions change
- End with action items linked to brief

**In documentation:**
- Link to specific sections in PRDs
- Quote it in design specs
- Reference it in user stories
- Connect roadmap items to brief

**In decisions:**
- "Let's check the brief"
- "According to our success criteria..."
- "Our target users need..."
- "Our constraints say..."

### Make It Trusted

**Keep it accurate:**
- Update when things change
- Remove outdated information
- Validate assumptions periodically
- Correct errors immediately

**Keep it concise:**
- Remove what's not useful
- Focus on decisions, not history
- Avoid redundancy
- Stay under 3 pages

**Keep it current:**
- Review quarterly
- Update after major learnings
- Refresh when pivoting
- Don't let it go stale

---

## The Power of Shared Understanding

When everyone on the team references the same Product Brief:

**Designers** make confident decisions aligned with vision
**Developers** understand the "why" and build accordingly
**Stakeholders** track progress and prevent scope creep
**Product Managers** create roadmaps and measure success

**The result:**
- ✅ Faster decisions (no constant meetings)
- ✅ Better alignment (everyone working toward same goals)
- ✅ Less rework (building right things first time)
- ✅ More confidence (clear direction and criteria)
- ✅ Stronger results (coordinated effort)

**This is the power of a single source of truth.**

---

## What's Next

In the final lesson, we'll explore the additional strategic documents you can create as your project needs them - expanding your foundation beyond the core Product Brief.

---

**[Continue to Lesson 6: Additional Strategic Documents →](lesson-06-additional-documents.md)**

---

[← Back to Lesson 4](lesson-04-wds-advantage.md) | [Back to Module Overview](module-04-overview.md)