365 lines
10 KiB
Markdown
365 lines
10 KiB
Markdown
# Module 04: Product Brief
|
|
|
|
## Lesson 2: The 5 Strategic Questions
|
|
|
|
**What every Product Brief must answer**
|
|
|
|
---
|
|
|
|
## The Framework That Guides Everything
|
|
|
|
Every successful Product Brief answers 5 critical questions. These aren't just sections to fill out - they're the questions that guide every design decision throughout your project.
|
|
|
|
**The 5 Strategic Questions:**
|
|
|
|
1. **What & Why** - What are we building and why does it matter?
|
|
2. **Who** - Who is this for?
|
|
3. **How We'll Know** - How will we know it's successful?
|
|
4. **Context** - What else exists and how are we different?
|
|
5. **Boundaries** - What are our constraints?
|
|
|
|
When you can answer these questions clearly, everything else flows. When you can't, every decision becomes a debate.
|
|
|
|
---
|
|
|
|
## Question 1: What & Why
|
|
|
|
**What are we building and why does it matter?**
|
|
|
|
This is your vision and positioning. It's the north star that guides every decision.
|
|
|
|
### Vision: The Big Picture
|
|
|
|
Your vision is a clear, compelling statement of what you're building and why it matters. It's aspirational but grounded. It inspires but also guides.
|
|
|
|
**A good vision statement:**
|
|
- Describes what you're building
|
|
- Explains the problem you're solving
|
|
- Identifies who benefits
|
|
- Conveys why this matters
|
|
|
|
**Example structure:**
|
|
"We're building [PRODUCT] for [TARGET USER] because [PROBLEM/OPPORTUNITY]. This matters because [IMPACT]."
|
|
|
|
**What makes a vision powerful:**
|
|
- ✅ Clear enough to guide decisions
|
|
- ✅ Inspiring enough to motivate the team
|
|
- ✅ Specific enough to say no to things that don't fit
|
|
- ✅ Flexible enough to allow creative solutions
|
|
|
|
**What makes a vision weak:**
|
|
- ❌ Too vague ("make the world better")
|
|
- ❌ Too tactical ("add a calendar feature")
|
|
- ❌ Too broad ("solve all problems")
|
|
- ❌ Too limiting ("exactly 3 buttons")
|
|
|
|
### Positioning: Who & What Makes It Unique
|
|
|
|
Positioning answers three critical questions:
|
|
- **Target:** Who is this for?
|
|
- **Value:** What problem does it solve?
|
|
- **Differentiation:** How is it different from alternatives?
|
|
|
|
**Why positioning matters:**
|
|
- Guides design decisions (what feels right for this audience?)
|
|
- Informs feature prioritization (what solves their problem best?)
|
|
- Shapes communication (how do we talk to them?)
|
|
- Prevents scope creep (does this fit our positioning?)
|
|
|
|
---
|
|
|
|
## Question 2: Who
|
|
|
|
**Who is this for?**
|
|
|
|
You can't design for "everyone." You need to know exactly who you're serving and who has a stake in the project's success.
|
|
|
|
### Target Users
|
|
|
|
**Primary Users:**
|
|
- Who uses the product directly?
|
|
- What are their goals and needs?
|
|
- What's their context and constraints?
|
|
|
|
**Secondary Users:**
|
|
- Who benefits indirectly?
|
|
- How does the product affect them?
|
|
- What do they need from it?
|
|
|
|
**Why this matters:**
|
|
Different users have different needs. You can't optimize for everyone. Knowing your primary users lets you make confident trade-offs.
|
|
|
|
### Stakeholders
|
|
|
|
**Business Stakeholders:**
|
|
- Who decides if this project continues?
|
|
- Who controls the budget?
|
|
- What do they need to see to consider it successful?
|
|
|
|
**Technical Stakeholders:**
|
|
- Who builds and maintains this?
|
|
- What are their constraints and preferences?
|
|
- What technical decisions affect them?
|
|
|
|
**Why this matters:**
|
|
Stakeholders aren't users, but they affect the project. Understanding their needs prevents surprises and ensures support.
|
|
|
|
---
|
|
|
|
## Question 3: How We'll Know
|
|
|
|
**How will we know it's successful?**
|
|
|
|
Success criteria are measurable outcomes that indicate whether the project achieved its goals. Without them, "success" is just opinion.
|
|
|
|
### The Four Dimensions of Success
|
|
|
|
**User Success:**
|
|
- How do users benefit?
|
|
- What behaviors change?
|
|
- What satisfaction metrics improve?
|
|
|
|
**Examples:**
|
|
- "80% of users report reduced stress"
|
|
- "Average task completion time < 2 minutes"
|
|
- "90% task completion rate"
|
|
|
|
**Business Success:**
|
|
- What business outcomes improve?
|
|
- What revenue or growth metrics matter?
|
|
- What efficiency gains occur?
|
|
|
|
**Examples:**
|
|
- "1,000 active users by month 6"
|
|
- "70% weekly active user rate"
|
|
- "$50K MRR by month 12"
|
|
|
|
**Technical Success:**
|
|
- What performance standards must be met?
|
|
- What reliability metrics matter?
|
|
- What security requirements exist?
|
|
|
|
**Examples:**
|
|
- "99.9% uptime"
|
|
- "Page load < 2 seconds"
|
|
- "Zero critical security issues"
|
|
|
|
**Design Success:**
|
|
- What usability standards must be met?
|
|
- What satisfaction scores matter?
|
|
- What engagement metrics indicate good design?
|
|
|
|
**Examples:**
|
|
- "SUS score > 75"
|
|
- "NPS score > 40"
|
|
- "80% feature discoverability"
|
|
|
|
### Making Criteria SMART
|
|
|
|
Every success criterion should be:
|
|
- **Specific** - Clear and unambiguous
|
|
- **Measurable** - Can track progress
|
|
- **Achievable** - Realistic given resources
|
|
- **Relevant** - Aligned with project goals
|
|
- **Time-bound** - Has a deadline
|
|
|
|
**Weak criteria:**
|
|
- ❌ "Make it better"
|
|
- ❌ "Increase engagement"
|
|
- ❌ "Users will love it"
|
|
|
|
**Strong criteria:**
|
|
- ✅ "Increase daily active users by 40% within 3 months"
|
|
- ✅ "Reduce support tickets by 50% within 6 months"
|
|
- ✅ "Achieve NPS score of 45+ by launch"
|
|
|
|
---
|
|
|
|
## Question 4: Context
|
|
|
|
**What else exists and how are we different?**
|
|
|
|
Understanding the competitive landscape informs design decisions and positioning strategy.
|
|
|
|
### Competitive Landscape
|
|
|
|
**Direct Competitors:**
|
|
- Who offers the same solution?
|
|
- What do they do well?
|
|
- What do they do poorly?
|
|
- How are we different?
|
|
|
|
**Indirect Alternatives:**
|
|
- What other ways do people solve this problem?
|
|
- Why might someone choose those instead?
|
|
- What can we learn from them?
|
|
|
|
**Why this matters:**
|
|
- Informs design decisions (what's expected vs what's differentiated)
|
|
- Guides feature prioritization (what's table stakes vs competitive advantage)
|
|
- Shapes positioning (how we talk about what makes us different)
|
|
- Prevents "me too" design (copying without understanding why)
|
|
|
|
### Your Unique Positioning
|
|
|
|
**What makes you different:**
|
|
- Approach (how you solve the problem)
|
|
- Audience (who you serve)
|
|
- Experience (how it feels to use)
|
|
- Business model (how you make money)
|
|
- Technology (what enables your solution)
|
|
|
|
**Why differentiation matters:**
|
|
If you're not different, you're competing on price. If you're different in ways that matter to your target users, you're competing on value.
|
|
|
|
---
|
|
|
|
## Question 5: Boundaries
|
|
|
|
**What are our constraints?**
|
|
|
|
Constraints aren't limitations - they're clarity. They guide decisions and prevent wasted effort on impossible solutions.
|
|
|
|
### Technical Constraints
|
|
|
|
**Platform Requirements:**
|
|
- Web, mobile, desktop?
|
|
- Which browsers/devices?
|
|
- Online/offline capability?
|
|
|
|
**Integration Requirements:**
|
|
- What systems must it connect to?
|
|
- What APIs are available?
|
|
- What data needs to sync?
|
|
|
|
**Performance Requirements:**
|
|
- How fast must it load?
|
|
- How many users must it support?
|
|
- What's the acceptable downtime?
|
|
|
|
**Security & Compliance:**
|
|
- What data protection is required?
|
|
- What regulations apply (GDPR, CCPA, HIPAA)?
|
|
- What security standards must be met?
|
|
|
|
### Business Constraints
|
|
|
|
**Budget:**
|
|
- What's the total budget?
|
|
- What can be spent on design vs development?
|
|
- What's the runway?
|
|
|
|
**Timeline:**
|
|
- When must it launch?
|
|
- What are the key milestones?
|
|
- What's the MVP vs future phases?
|
|
|
|
**Resources:**
|
|
- How many people?
|
|
- What skills are available?
|
|
- What can be outsourced?
|
|
|
|
**Market Positioning:**
|
|
- What price point?
|
|
- What market segment?
|
|
- What brand perception?
|
|
|
|
### Design Constraints
|
|
|
|
**Brand Guidelines:**
|
|
- What visual standards exist?
|
|
- What voice and tone?
|
|
- What's on-brand vs off-brand?
|
|
|
|
**Accessibility:**
|
|
- What compliance level (WCAG 2.1 AA, AAA)?
|
|
- What specific disabilities to design for?
|
|
- What testing is required?
|
|
|
|
**Localization:**
|
|
- What languages?
|
|
- What cultural considerations?
|
|
- What regional variations?
|
|
|
|
**Existing Systems:**
|
|
- What design systems exist?
|
|
- What components are available?
|
|
- What patterns are established?
|
|
|
|
### Why Constraints Matter
|
|
|
|
**Constraints guide decisions:**
|
|
- "Should we add this feature?" → Check constraints
|
|
- "Can we support this platform?" → Check constraints
|
|
- "Should we use this approach?" → Check constraints
|
|
|
|
**Constraints prevent waste:**
|
|
- No designing solutions that can't be built
|
|
- No building for platforms you don't support
|
|
- No planning for budgets you don't have
|
|
|
|
**Constraints enable creativity:**
|
|
- Limitations force innovative solutions
|
|
- Boundaries create focus
|
|
- Clarity enables confident decisions
|
|
|
|
---
|
|
|
|
## How the Questions Work Together
|
|
|
|
These 5 questions aren't isolated - they work together to create a complete strategic picture.
|
|
|
|
**Vision & Positioning** (What & Why) → Guides everything else
|
|
↓
|
|
**Target Users** (Who) → Informs what success looks like
|
|
↓
|
|
**Success Criteria** (How We'll Know) → Defines measurable outcomes
|
|
↓
|
|
**Competitive Landscape** (Context) → Shapes differentiation strategy
|
|
↓
|
|
**Constraints** (Boundaries) → Grounds everything in reality
|
|
|
|
**When making any design decision:**
|
|
1. Does it align with the vision?
|
|
2. Does it serve the target users?
|
|
3. Does it contribute to success criteria?
|
|
4. Does it differentiate us from competitors?
|
|
5. Is it possible within our constraints?
|
|
|
|
If the answer to all 5 is yes, it's probably a good decision. If any answer is no, reconsider.
|
|
|
|
---
|
|
|
|
## The Power of Clear Answers
|
|
|
|
When everyone on your team can answer these 5 questions the same way, you have alignment. When they can't, you have chaos.
|
|
|
|
**With clear answers:**
|
|
- Designers make confident decisions
|
|
- Developers understand the "why"
|
|
- Stakeholders trust the direction
|
|
- Product managers prioritize effectively
|
|
- The team moves fast
|
|
|
|
**Without clear answers:**
|
|
- Every decision requires a meeting
|
|
- Every meeting creates more confusion
|
|
- Every confusion creates delay
|
|
- Every delay creates frustration
|
|
|
|
**This is why the Product Brief matters. It answers the questions before they become problems.**
|
|
|
|
---
|
|
|
|
## What's Next
|
|
|
|
In the next lesson, we'll look at what a Product Brief actually looks like - the document structure, how to keep it concise, and how to make it useful for your entire team.
|
|
|
|
---
|
|
|
|
**[Continue to Lesson 3: The Document Structure →](lesson-03-document-structure.md)**
|
|
|
|
---
|
|
|
|
[← Back to Lesson 1](lesson-01-chaos-problem.md) | [Back to Module Overview](module-04-overview.md)
|