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-05-using-brief.md

14 KiB
Raw Blame History

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 →

← Back to Lesson 4 | Back to Module Overview

Part of Module 04: Product Brief