494 lines
14 KiB
Markdown
494 lines
14 KiB
Markdown
# 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)
|
|
|
|
*Part of Module 04: Product Brief*
|