mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00:00
feat: major overhaul of BMM planning workflows with intent-driven discovery
This comprehensive update transforms the Product Brief and PRD workflows from rigid template-filling exercises into adaptive, context-aware discovery processes. Changes span workflow instructions, templates, agent configurations, and supporting infrastructure. ## Product Brief Workflow (96% audit compliance) ### Intent-Driven Facilitation - Transform from linear Q&A to natural conversational discovery - Adaptive questioning based on project context (hobby/startup/enterprise) - Real-time document building instead of end-of-session generation - Skill-level aware facilitation (expert/intermediate/beginner) - Context detection from user responses to guide exploration depth ### Living Document Approach - Continuous template updates throughout conversation - Progressive refinement vs batch generation - Template-output tags aligned with discovery flow - Better variable mapping between instructions and template ### Enhanced Discovery Areas - Problem exploration with context-appropriate probing - Solution vision shaping based on user's mental model - User understanding through storytelling vs demographics - Success metrics tailored to project type - Ruthless MVP scope management with feature prioritization ### Template Improvements - Added context-aware conditional sections - Better organization of optional vs required content - Clearer structure for different project types - Improved reference material handling ## PRD Workflow (improved from 65% to 85%+ compliance) ### Critical Fixes - Add missing `date: system-generated` config variable - Fix status file extension mismatch (.yaml not .md) - Remove 38% bloat (unused technical_decisions variables) - Add explicit template-output tags for runtime variables ### Scale-Adaptive Intelligence - Project type detection (API/Web App/Mobile/SaaS/etc) - Domain complexity mapping (14 domain types) - Automatic requirement tailoring based on detected context - CSV-driven project type and domain knowledge base ### Separated Epic Planning - Move epic/story breakdown to dedicated child workflow - Create create-epics-and-stories workflow for Phase 2 - Cleaner separation: PRD defines WHAT, epics define HOW - Updated PM agent menu with new workflow triggers ### Enhanced Requirements Coverage - Project-type specific requirement sections (endpoints, auth, platform) - Domain-specific considerations (healthcare compliance, fintech security) - UX principles with interaction patterns - Non-functional requirements with integration needs - Technical preferences capture ### Template Restructuring - Separate PRD template from epic planning - Context-aware conditional sections - Better scale level indicators (L0-L4) - Improved reference document handling - Clearer success criteria sections ## Architecture Workflow Updates ### Template Enhancements - Add domain complexity context support - Better integration with PRD outputs - Improved technical decision capture - Enhanced system architecture sections ### Instruction Improvements - Reference new domain-research workflow - Better handling of PRD inputs - Clearer architectural decision framework ## Agent Configuration Updates ### BMad Master Agent - Fix workflow invocation instructions - Better fuzzy matching guidance - Clearer menu handler documentation - Remove workflow invention warnings ### PM Agent - Add create-prd trigger (renamed from 'prd') - Add create-epics-and-stories workflow trigger - Add validate-prd workflow trigger with checklist - Better workflow status integration ### Game Designer Agent - Rename triggers for consistency (create-game-brief, create-gdd) - Align with PM agent naming conventions ## New Supporting Infrastructure ### Domain Research Workflow - New discovery workflow for domain-specific research - Complements product brief for complex domains - Web research integration for domain insights ### Create Epics and Stories Workflow - Dedicated epic/story breakdown process - Separates planning (PRD) from decomposition - Better Epic → Story → Task hierarchy - Acceptance criteria generation ### Data Files - project-types.csv: 12 project type definitions with requirements - domain-complexity.csv: 14 domain types with complexity indicators ## Quality Improvements ### Validation & Compliance - Product Brief: 96% BMAD v6 compliance (EXCELLENT rating) - PRD: Improved from 65% to ~85% after critical fixes - Zero bloat in Product Brief (0%) - Reduced PRD bloat from 38% to ~15% ### Template Variable Mapping - All template variables explicitly populated via template-output tags - Runtime variables properly tracked - Config variables consistently used - Better separation of concerns ### Web Bundle Configuration - Complete web_bundle sections for all workflows - Proper child workflow references - Data file inclusions (CSV files) - Correct bmad/-relative paths ## Breaking Changes ### File Removals - Delete src/modules/bmm/workflows/2-plan-workflows/prd/epics-template.md (replaced by create-epics-and-stories child workflow) ### Workflow Trigger Changes - PM agent: 'prd' → 'create-prd' - PM agent: 'gdd' → 'create-gdd' - New: 'create-epics-and-stories' - New: 'validate-prd' ## Impact This update significantly improves the BMM module's ability to: - Adapt to different project types and scales - Guide users through discovery naturally vs mechanically - Generate higher quality planning documents - Support complex domains with specialized knowledge - Scale from Level 0 quick changes to Level 4 enterprise projects The workflows now feel like collaborative discovery sessions with an expert consultant rather than form-filling exercises.
This commit is contained in:
Brian Madison
@@ -0,0 +1,423 @@
|
||||
# Domain Research - Collaborative Domain Exploration
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>This is COLLABORATIVE RESEARCH - engage the user as a partner, not just a data source</critical>
|
||||
<critical>The goal is PRACTICAL UNDERSTANDING that directly informs requirements and architecture</critical>
|
||||
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>LIVING DOCUMENT: Write to domain-brief.md continuously as you discover - never wait until the end</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Set research context">
|
||||
<action>Welcome {user_name} to collaborative domain research
|
||||
|
||||
Check for context:
|
||||
|
||||
- Was this triggered from PRD workflow?
|
||||
- Is there a workflow-status.yaml with project context?
|
||||
- Did user provide initial domain/project description?
|
||||
|
||||
If context exists, reflect it back:
|
||||
"I understand you're building [description]. Let's explore the [domain] aspects together to ensure we capture all critical requirements."
|
||||
|
||||
If no context:
|
||||
"Let's explore your project's domain together. Tell me about what you're building and what makes it unique or complex."</action>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Domain detection and scoping">
|
||||
<action>Through conversation, identify the domain and its complexity
|
||||
|
||||
Listen for domain signals and explore:
|
||||
|
||||
- "Is this in a regulated industry?"
|
||||
- "Are there safety or compliance concerns?"
|
||||
- "What could go wrong if this fails?"
|
||||
- "Who are the stakeholders beyond direct users?"
|
||||
- "Are there industry standards we need to follow?"
|
||||
|
||||
Based on responses, identify primary domain(s):
|
||||
|
||||
- Healthcare/Medical
|
||||
- Financial Services
|
||||
- Government/Public Sector
|
||||
- Education
|
||||
- Aerospace/Defense
|
||||
- Automotive
|
||||
- Energy/Utilities
|
||||
- Legal
|
||||
- Insurance
|
||||
- Scientific/Research
|
||||
- Other specialized domain
|
||||
|
||||
Share your understanding:
|
||||
"Based on our discussion, this appears to be a [domain] project with [key characteristics]. The main areas we should research are:
|
||||
|
||||
- [Area 1]
|
||||
- [Area 2]
|
||||
- [Area 3]
|
||||
|
||||
What concerns you most about building in this space?"</action>
|
||||
|
||||
<template-output>domain_overview</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Collaborative concern mapping">
|
||||
<action>Work WITH the user to identify critical concerns
|
||||
|
||||
"Let's map out the important considerations together. I'll share what I typically see in [domain], and you tell me what applies to your case."
|
||||
|
||||
For detected domain, explore relevant areas:
|
||||
|
||||
HEALTHCARE:
|
||||
"In healthcare software, teams often worry about:
|
||||
|
||||
- FDA approval pathways (510k, De Novo, PMA)
|
||||
- HIPAA compliance for patient data
|
||||
- Clinical validation requirements
|
||||
- Integration with hospital systems (HL7, FHIR, DICOM)
|
||||
- Patient safety and liability
|
||||
|
||||
Which of these apply to you? What else concerns you?"
|
||||
|
||||
FINTECH:
|
||||
"Financial software typically deals with:
|
||||
|
||||
- KYC/AML requirements
|
||||
- Payment processing regulations (PCI DSS)
|
||||
- Regional compliance (US, EU, specific countries?)
|
||||
- Fraud prevention
|
||||
- Audit trails and reporting
|
||||
|
||||
What's your situation with these? Any specific regions?"
|
||||
|
||||
AEROSPACE:
|
||||
"Aerospace software often requires:
|
||||
|
||||
- DO-178C certification levels
|
||||
- Safety analysis (FMEA, FTA)
|
||||
- Simulation validation
|
||||
- Real-time performance guarantees
|
||||
- Export control (ITAR)
|
||||
|
||||
Which are relevant for your project?"
|
||||
|
||||
[Continue for other domains...]
|
||||
|
||||
Document concerns as the user shares them
|
||||
Ask follow-up questions to understand depth:
|
||||
|
||||
- "How critical is this requirement?"
|
||||
- "Is this a must-have for launch or can it come later?"
|
||||
- "Do you have expertise here or need guidance?"</action>
|
||||
|
||||
<template-output>concern_mapping</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Research key requirements together">
|
||||
<action>Conduct research WITH the user watching and contributing
|
||||
|
||||
"Let me research the current requirements for [specific concern]. You can guide me toward what's most relevant."
|
||||
|
||||
<WebSearch>{specific_requirement} requirements {date}</WebSearch>
|
||||
|
||||
Share findings immediately:
|
||||
"Here's what I found about [requirement]:
|
||||
|
||||
- [Key point 1]
|
||||
- [Key point 2]
|
||||
- [Key point 3]
|
||||
|
||||
Does this match your understanding? Anything surprising or concerning?"
|
||||
|
||||
For each major concern:
|
||||
|
||||
1. Research current standards/regulations
|
||||
2. Share findings with user
|
||||
3. Get their interpretation
|
||||
4. Note practical implications
|
||||
|
||||
If user has expertise:
|
||||
"You seem knowledgeable about [area]. What should I know that might not be in public documentation?"
|
||||
|
||||
If user is learning:
|
||||
"This might be new territory. Let me explain what this means practically for your development..."</action>
|
||||
|
||||
<template-output>regulatory_requirements</template-output>
|
||||
<template-output>industry_standards</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Identify practical implications">
|
||||
<action>Translate research into practical development impacts
|
||||
|
||||
"Based on what we've learned, here's what this means for your project:
|
||||
|
||||
ARCHITECTURE IMPLICATIONS:
|
||||
|
||||
- [How this affects system design]
|
||||
- [Required components or patterns]
|
||||
- [Performance or security needs]
|
||||
|
||||
DEVELOPMENT IMPLICATIONS:
|
||||
|
||||
- [Additional development effort]
|
||||
- [Special expertise needed]
|
||||
- [Testing requirements]
|
||||
|
||||
TIMELINE IMPLICATIONS:
|
||||
|
||||
- [Certification/approval timelines]
|
||||
- [Validation requirements]
|
||||
- [Documentation needs]
|
||||
|
||||
COST IMPLICATIONS:
|
||||
|
||||
- [Compliance costs]
|
||||
- [Required tools or services]
|
||||
- [Ongoing maintenance]
|
||||
|
||||
Does this align with your expectations? Any surprises we should dig into?"</action>
|
||||
|
||||
<template-output>practical_implications</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Discover domain-specific patterns">
|
||||
<action>Explore how others solve similar problems
|
||||
|
||||
"Let's look at how successful [domain] products handle these challenges."
|
||||
|
||||
<WebSearch>best {domain} software architecture patterns {date}</WebSearch>
|
||||
<WebSearch>{domain} software case studies {date}</WebSearch>
|
||||
|
||||
Discuss patterns:
|
||||
"I found these common approaches in [domain]:
|
||||
|
||||
Pattern 1: [Description]
|
||||
|
||||
- Pros: [Benefits]
|
||||
- Cons: [Tradeoffs]
|
||||
- When to use: [Conditions]
|
||||
|
||||
Pattern 2: [Description]
|
||||
|
||||
- Pros: [Benefits]
|
||||
- Cons: [Tradeoffs]
|
||||
- When to use: [Conditions]
|
||||
|
||||
Which resonates with your vision? Or are you thinking something different?"
|
||||
|
||||
If user proposes novel approach:
|
||||
"That's interesting and different from the standard patterns. Let's explore:
|
||||
|
||||
- What makes your approach unique?
|
||||
- What problem does it solve that existing patterns don't?
|
||||
- What are the risks?
|
||||
- How do we validate it?"</action>
|
||||
|
||||
<template-output>domain_patterns</template-output>
|
||||
<template-output if="novel approach">innovation_notes</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Risk assessment and mitigation">
|
||||
<action>Collaboratively identify and address risks
|
||||
|
||||
"Every [domain] project has risks. Let's think through yours:
|
||||
|
||||
REGULATORY RISKS:
|
||||
|
||||
- What if regulations change during development?
|
||||
- What if approval/certification takes longer?
|
||||
- What if we misinterpret requirements?
|
||||
|
||||
TECHNICAL RISKS:
|
||||
|
||||
- What if the domain requirements conflict with user experience?
|
||||
- What if performance requirements are harder than expected?
|
||||
- What if integrations are more complex?
|
||||
|
||||
MARKET RISKS:
|
||||
|
||||
- What if competitors move faster?
|
||||
- What if domain experts are hard to find?
|
||||
- What if users resist domain-mandated workflows?
|
||||
|
||||
For each risk you're concerned about, let's identify:
|
||||
|
||||
1. How likely is it?
|
||||
2. What's the impact if it happens?
|
||||
3. How can we mitigate it?
|
||||
4. What's our plan B?"</action>
|
||||
|
||||
<template-output>risk_assessment</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Create validation strategy">
|
||||
<action>Plan how to ensure domain requirements are met
|
||||
|
||||
"Let's plan how to validate that we're meeting [domain] requirements:
|
||||
|
||||
COMPLIANCE VALIDATION:
|
||||
|
||||
- How do we verify regulatory compliance?
|
||||
- Who needs to review/approve?
|
||||
- What documentation is required?
|
||||
|
||||
TECHNICAL VALIDATION:
|
||||
|
||||
- How do we prove the system works correctly?
|
||||
- What metrics matter?
|
||||
- What testing is required?
|
||||
|
||||
DOMAIN EXPERT VALIDATION:
|
||||
|
||||
- Who are the domain experts to involve?
|
||||
- When should they review?
|
||||
- What are their success criteria?
|
||||
|
||||
USER VALIDATION:
|
||||
|
||||
- How do we ensure it's still usable despite constraints?
|
||||
- What user testing is needed?
|
||||
- How do we balance domain requirements with UX?
|
||||
|
||||
What validation is most critical for your confidence?"</action>
|
||||
|
||||
<template-output>validation_strategy</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Document decision points">
|
||||
<action>Capture key decisions and rationale
|
||||
|
||||
"Let's document the important decisions we've made:
|
||||
|
||||
DOMAIN APPROACH:
|
||||
|
||||
- We're choosing [approach] because [rationale]
|
||||
- We're prioritizing [requirement] over [requirement] because [reason]
|
||||
- We're deferring [requirement] to Phase 2 because [justification]
|
||||
|
||||
COMPLIANCE STRATEGY:
|
||||
|
||||
- We'll pursue [pathway] for regulatory approval
|
||||
- We'll implement [standard] for industry compliance
|
||||
- We'll handle [requirement] by [approach]
|
||||
|
||||
RISK DECISIONS:
|
||||
|
||||
- We accept [risk] because [reason]
|
||||
- We'll mitigate [risk] through [approach]
|
||||
- We'll monitor [risk] by [method]
|
||||
|
||||
Any decisions you want to revisit or rationale to add?"</action>
|
||||
|
||||
<template-output>key_decisions</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Create actionable recommendations">
|
||||
<action>Synthesize research into specific recommendations
|
||||
|
||||
"Based on our research, here are my recommendations for your PRD and development:
|
||||
|
||||
MUST HAVE (Domain Critical):
|
||||
|
||||
1. [Specific requirement with why it's critical]
|
||||
2. [Specific requirement with why it's critical]
|
||||
3. [Specific requirement with why it's critical]
|
||||
|
||||
SHOULD HAVE (Domain Important):
|
||||
|
||||
1. [Requirement that's important but not blocking]
|
||||
2. [Requirement that's important but not blocking]
|
||||
|
||||
CONSIDER (Domain Nice-to-Have):
|
||||
|
||||
1. [Enhancement that would differentiate]
|
||||
2. [Enhancement that would differentiate]
|
||||
|
||||
DEVELOPMENT SEQUENCE:
|
||||
|
||||
1. First: [What to build first and why]
|
||||
2. Then: [What comes next and why]
|
||||
3. Later: [What can wait and why]
|
||||
|
||||
EXPERTISE NEEDED:
|
||||
|
||||
- [Domain expert role]: For [specific areas]
|
||||
- [Technical expert role]: For [specific requirements]
|
||||
|
||||
TIMELINE CONSIDERATIONS:
|
||||
|
||||
- Allow [time] for [process/approval]
|
||||
- Start [requirement] early because [reason]
|
||||
- [Requirement] can be parallel with development
|
||||
|
||||
Do these recommendations feel right? What would you adjust?"</action>
|
||||
|
||||
<template-output>recommendations</template-output>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Package for PRD integration">
|
||||
<action>Create clear handoff to PRD workflow
|
||||
|
||||
"I've captured everything in domain-brief.md. Here's the summary for your PRD:
|
||||
|
||||
DOMAIN: {identified_domain}
|
||||
COMPLEXITY: {high|medium}
|
||||
|
||||
KEY REQUIREMENTS TO INCORPORATE:
|
||||
|
||||
- [Requirement 1 - critical for domain]
|
||||
- [Requirement 2 - critical for domain]
|
||||
- [Requirement 3 - important consideration]
|
||||
|
||||
IMPACTS ON:
|
||||
|
||||
- Functional Requirements: [How domain affects features]
|
||||
- Non-Functional Requirements: [Performance, security, etc.]
|
||||
- Architecture: [System design considerations]
|
||||
- Development: [Process and timeline impacts]
|
||||
|
||||
REFERENCE DOCS:
|
||||
|
||||
- Full domain analysis: domain-brief.md
|
||||
- Regulations researched: [List with links]
|
||||
- Standards referenced: [List with links]
|
||||
|
||||
When you return to PRD, reference this brief for domain context.
|
||||
|
||||
Any final questions before we wrap up the domain research?"</action>
|
||||
|
||||
<template-output>summary_for_prd</template-output>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Close with next steps">
|
||||
<output>**✅ Domain Research Complete, {user_name}!**
|
||||
|
||||
We've explored the {domain} aspects of your project together and documented critical requirements.
|
||||
|
||||
**Created:**
|
||||
|
||||
- **domain-brief.md** - Complete domain analysis with requirements and recommendations
|
||||
|
||||
**Key Findings:**
|
||||
|
||||
- Primary domain: {domain}
|
||||
- Complexity level: {complexity}
|
||||
- Critical requirements: {count} identified
|
||||
- Risks identified: {count} with mitigation strategies
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
1. Return to PRD workflow with this domain context
|
||||
2. Domain requirements will shape your functional requirements
|
||||
3. Reference domain-brief.md for detailed requirements
|
||||
|
||||
**Remember:**
|
||||
{most_important_finding}
|
||||
|
||||
The domain research will ensure your PRD captures not just what to build, but HOW to build it correctly for {domain}.
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
180
src/modules/bmm/workflows/1-analysis/domain-research/template.md
Normal file
180
src/modules/bmm/workflows/1-analysis/domain-research/template.md
Normal file
@@ -0,0 +1,180 @@
|
||||
# Domain Brief - {project_name}
|
||||
|
||||
Generated: {date}
|
||||
Domain: {primary_domain}
|
||||
Complexity: {complexity_level}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{brief_overview_of_domain_research_findings}
|
||||
|
||||
## Domain Overview
|
||||
|
||||
### Industry Context
|
||||
|
||||
{domain_overview}
|
||||
|
||||
### Regulatory Landscape
|
||||
|
||||
{regulatory_environment}
|
||||
|
||||
### Key Stakeholders
|
||||
|
||||
{stakeholder_analysis}
|
||||
|
||||
## Critical Concerns
|
||||
|
||||
### Compliance Requirements
|
||||
|
||||
{concern_mapping}
|
||||
|
||||
### Technical Constraints
|
||||
|
||||
{technical_limitations_from_domain}
|
||||
|
||||
### Safety/Risk Considerations
|
||||
|
||||
{safety_risk_factors}
|
||||
|
||||
## Regulatory Requirements
|
||||
|
||||
{regulatory_requirements}
|
||||
|
||||
## Industry Standards
|
||||
|
||||
{industry_standards}
|
||||
|
||||
## Practical Implications
|
||||
|
||||
### Architecture Impact
|
||||
|
||||
{architecture_implications}
|
||||
|
||||
### Development Impact
|
||||
|
||||
{development_implications}
|
||||
|
||||
### Timeline Impact
|
||||
|
||||
{timeline_implications}
|
||||
|
||||
### Cost Impact
|
||||
|
||||
{cost_implications}
|
||||
|
||||
## Domain Patterns
|
||||
|
||||
### Established Patterns
|
||||
|
||||
{domain_patterns}
|
||||
|
||||
### Innovation Opportunities
|
||||
|
||||
{innovation_notes}
|
||||
|
||||
## Risk Assessment
|
||||
|
||||
### Identified Risks
|
||||
|
||||
{risk_assessment}
|
||||
|
||||
### Mitigation Strategies
|
||||
|
||||
{mitigation_approaches}
|
||||
|
||||
## Validation Strategy
|
||||
|
||||
### Compliance Validation
|
||||
|
||||
{compliance_validation_approach}
|
||||
|
||||
### Technical Validation
|
||||
|
||||
{technical_validation_approach}
|
||||
|
||||
### Domain Expert Validation
|
||||
|
||||
{expert_validation_approach}
|
||||
|
||||
## Key Decisions
|
||||
|
||||
{key_decisions}
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Must Have (Critical)
|
||||
|
||||
{critical_requirements}
|
||||
|
||||
### Should Have (Important)
|
||||
|
||||
{important_requirements}
|
||||
|
||||
### Consider (Nice-to-Have)
|
||||
|
||||
{optional_enhancements}
|
||||
|
||||
### Development Sequence
|
||||
|
||||
{recommended_sequence}
|
||||
|
||||
### Required Expertise
|
||||
|
||||
{expertise_needed}
|
||||
|
||||
## PRD Integration Guide
|
||||
|
||||
### Summary for PRD
|
||||
|
||||
{summary_for_prd}
|
||||
|
||||
### Requirements to Incorporate
|
||||
|
||||
- {requirement_1}
|
||||
- {requirement_2}
|
||||
- {requirement_3}
|
||||
|
||||
### Architecture Considerations
|
||||
|
||||
- {architecture_consideration_1}
|
||||
- {architecture_consideration_2}
|
||||
|
||||
### Development Considerations
|
||||
|
||||
- {development_consideration_1}
|
||||
- {development_consideration_2}
|
||||
|
||||
## References
|
||||
|
||||
### Regulations Researched
|
||||
|
||||
- {regulation_1_with_link}
|
||||
- {regulation_2_with_link}
|
||||
|
||||
### Standards Referenced
|
||||
|
||||
- {standard_1_with_link}
|
||||
- {standard_2_with_link}
|
||||
|
||||
### Additional Resources
|
||||
|
||||
- {resource_1}
|
||||
- {resource_2}
|
||||
|
||||
## Appendix
|
||||
|
||||
### Research Notes
|
||||
|
||||
{detailed_research_notes}
|
||||
|
||||
### Conversation Highlights
|
||||
|
||||
{key_discussion_points_with_user}
|
||||
|
||||
### Open Questions
|
||||
|
||||
{questions_requiring_further_research}
|
||||
|
||||
---
|
||||
|
||||
_This domain brief was created through collaborative research between {user_name} and the AI facilitator. It should be referenced during PRD creation and updated as new domain insights emerge._
|
||||
@@ -0,0 +1,36 @@
|
||||
workflow:
|
||||
id: domain-research
|
||||
name: "Domain Research"
|
||||
module: bmm
|
||||
version: "6.0.0-alpha"
|
||||
description: "Collaborative exploration of domain-specific requirements, regulations, and patterns for complex projects"
|
||||
|
||||
environment:
|
||||
# Inherit from parent workflow or set defaults
|
||||
user_name: "partner"
|
||||
user_skill_level: "intermediate"
|
||||
communication_language: "English"
|
||||
document_output_language: "English"
|
||||
date: "{system.date}"
|
||||
|
||||
required_files:
|
||||
- instructions.md
|
||||
- template.md
|
||||
|
||||
optional_files:
|
||||
- domain-knowledge-base.md
|
||||
|
||||
outputs:
|
||||
- domain-brief.md
|
||||
|
||||
metadata:
|
||||
category: "analysis"
|
||||
complexity: "medium"
|
||||
estimated_time: "30-45 minutes"
|
||||
prerequisites:
|
||||
- "Basic project understanding"
|
||||
when_to_use:
|
||||
- "Complex regulated domains (healthcare, finance, aerospace)"
|
||||
- "Novel technical domains requiring deep understanding"
|
||||
- "Before PRD when domain expertise needed"
|
||||
- "When compliance and regulations matter"
|
||||
@@ -1,21 +1,19 @@
|
||||
# Product Brief - Interactive Workflow Instructions
|
||||
# Product Brief - Context-Adaptive Discovery Instructions
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
||||
<critical>This workflow uses INTENT-DRIVEN FACILITATION - adapt organically to what emerges</critical>
|
||||
<critical>The goal is DISCOVERING WHAT MATTERS through natural conversation, not filling a template</critical>
|
||||
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Concise, professional, strategically focused. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
|
||||
<critical>LIVING DOCUMENT: Write to the document continuously as you discover - never wait until the end</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Product Brief is optional - you can continue without status tracking.</output>
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
<action if="status file not found">Set standalone_mode = true</action>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
@@ -25,9 +23,10 @@
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_level < 2">
|
||||
<output>Note: Product Brief is most valuable for Level 2+ projects. Your project is Level {{project_level}}.</output>
|
||||
<output>You may want to skip directly to technical planning instead.</output>
|
||||
</check>
|
||||
<output>**Note: Level {{project_level}} Project**
|
||||
|
||||
Product Brief is most valuable for Level 2+ projects, but can help clarify vision for any project.</output>
|
||||
</check>
|
||||
|
||||
<check if="product-brief status is file path (already completed)">
|
||||
<output>⚠️ Product Brief already completed: {{product-brief status}}</output>
|
||||
@@ -38,7 +37,7 @@
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="product-brief is not the next expected workflow (latter items are completed already in the list)">
|
||||
<check if="product-brief is not the next expected workflow">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Product Brief is out of sequence.</output>
|
||||
<ask>Continue with Product Brief anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
@@ -51,241 +50,427 @@
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Initialize product brief session">
|
||||
<action>Welcome the user in {communication_language} to the Product Brief creation process</action>
|
||||
<action>Explain this is a collaborative process to define their product vision and strategic foundation</action>
|
||||
<action>Ask the user to provide the project name for this product brief</action>
|
||||
<step n="1" goal="Begin the journey and understand context">
|
||||
<action>Welcome {user_name} warmly in {communication_language}
|
||||
|
||||
Adapt your tone to {user_skill_level}:
|
||||
|
||||
- Expert: "Let's define your product vision. What are you building?"
|
||||
- Intermediate: "I'm here to help shape your product vision. Tell me about your idea."
|
||||
- Beginner: "Hi! I'm going to help you figure out exactly what you want to build. Let's start with your idea - what got you excited about this?"
|
||||
|
||||
Start with open exploration:
|
||||
|
||||
- What sparked this idea?
|
||||
- What are you hoping to build?
|
||||
- Who is this for - yourself, a business, users you know?
|
||||
|
||||
CRITICAL: Listen for context clues that reveal their situation:
|
||||
|
||||
- Personal/hobby project (fun, learning, small audience)
|
||||
- Startup/solopreneur (market opportunity, competition matters)
|
||||
- Enterprise/corporate (stakeholders, compliance, strategic alignment)
|
||||
- Technical enthusiasm (implementation focused)
|
||||
- Business opportunity (market/revenue focused)
|
||||
- Problem frustration (solution focused)
|
||||
|
||||
Based on their initial response, sense:
|
||||
|
||||
- How formal/casual they want to be
|
||||
- Whether they think in business or technical terms
|
||||
- If they have existing materials to share
|
||||
- Their confidence level with the domain</action>
|
||||
|
||||
<ask>What's the project name, and what got you excited about building this?</ask>
|
||||
|
||||
<action>From even this first exchange, create initial document sections</action>
|
||||
<template-output>project_name</template-output>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Gather available inputs and context">
|
||||
<action>Explore what existing materials the user has available to inform the brief</action>
|
||||
<action>Offer options for input sources: market research, brainstorming results, competitive analysis, initial ideas, or starting fresh</action>
|
||||
<action>If documents are provided, load and analyze them to extract key insights, themes, and patterns</action>
|
||||
<action>Engage the user about their core vision: what problem they're solving, who experiences it most acutely, and what sparked this product idea</action>
|
||||
<action>Build initial understanding through conversational exploration rather than rigid questioning</action>
|
||||
|
||||
<template-output>initial_context</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Choose collaboration mode">
|
||||
<ask>How would you like to work through the brief?
|
||||
|
||||
**1. Interactive Mode** - We'll work through each section together, discussing and refining as we go
|
||||
|
||||
**2. YOLO Mode** - I'll generate a complete draft based on our conversation so far, then we'll refine it together
|
||||
|
||||
Which approach works best for you?</ask>
|
||||
|
||||
<action>Store the user's preference for mode</action>
|
||||
<template-output>collaboration_mode</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Define the problem statement" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide deep exploration of the problem: current state frustrations, quantifiable impact (time/money/opportunities), why existing solutions fall short, urgency of solving now</action>
|
||||
<action>Challenge vague statements and push for specificity with probing questions</action>
|
||||
<action>Help the user articulate measurable pain points with evidence</action>
|
||||
<action>Craft a compelling, evidence-based problem statement</action>
|
||||
|
||||
<template-output>problem_statement</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Develop the proposed solution" if="collaboration_mode == 'interactive'">
|
||||
<action>Shape the solution vision by exploring: core approach to solving the problem, key differentiators from existing solutions, why this will succeed, ideal user experience</action>
|
||||
<action>Focus on the "what" and "why", not implementation details - keep it strategic</action>
|
||||
<action>Help articulate compelling differentiators that make this solution unique</action>
|
||||
<action>Craft a clear, inspiring solution vision</action>
|
||||
|
||||
<template-output>proposed_solution</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Identify target users" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide detailed definition of primary users: demographic/professional profile, current problem-solving methods, specific pain points, goals they're trying to achieve</action>
|
||||
<action>Explore secondary user segments if applicable and define how their needs differ</action>
|
||||
<action>Push beyond generic personas like "busy professionals" - demand specificity and actionable details</action>
|
||||
<action>Create specific, actionable user profiles that inform product decisions</action>
|
||||
|
||||
<template-output>primary_user_segment</template-output>
|
||||
<template-output>secondary_user_segment</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Establish goals and success metrics" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide establishment of SMART goals across business objectives and user success metrics</action>
|
||||
<action>Explore measurable business outcomes (user acquisition targets, cost reductions, revenue goals)</action>
|
||||
<action>Define user success metrics focused on behaviors and outcomes, not features (task completion time, return frequency)</action>
|
||||
<action>Help formulate specific, measurable goals that distinguish between business and user success</action>
|
||||
<action>Identify top 3-5 Key Performance Indicators that will track product success</action>
|
||||
|
||||
<template-output>business_objectives</template-output>
|
||||
<template-output>user_success_metrics</template-output>
|
||||
<template-output>key_performance_indicators</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Define MVP scope" if="collaboration_mode == 'interactive'">
|
||||
<action>Be ruthless about MVP scope - identify absolute MUST-HAVE features for launch that validate the core hypothesis</action>
|
||||
<action>For each proposed feature, probe why it's essential vs nice-to-have</action>
|
||||
<action>Identify tempting features that need to wait for v2 - what adds complexity without core value</action>
|
||||
<action>Define what constitutes a successful MVP launch with clear criteria</action>
|
||||
<action>Challenge scope creep aggressively and push for true minimum viability</action>
|
||||
<action>Clearly separate must-haves from nice-to-haves</action>
|
||||
|
||||
<template-output>core_features</template-output>
|
||||
<template-output>out_of_scope</template-output>
|
||||
<template-output>mvp_success_criteria</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Assess financial impact and ROI" if="collaboration_mode == 'interactive'">
|
||||
<action>Explore financial considerations: development investment, revenue potential, cost savings opportunities, break-even timing, budget alignment</action>
|
||||
<action>Investigate strategic alignment: company OKRs, strategic objectives, key initiatives supported, opportunity cost of NOT doing this</action>
|
||||
<action>Help quantify financial impact where possible - both tangible and intangible value</action>
|
||||
<action>Connect this product to broader company strategy and demonstrate strategic value</action>
|
||||
|
||||
<template-output>financial_impact</template-output>
|
||||
<template-output>company_objectives_alignment</template-output>
|
||||
<template-output>strategic_initiatives</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Explore post-MVP vision" optional="true" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide exploration of post-MVP future: Phase 2 features, expansion opportunities, long-term vision (1-2 years)</action>
|
||||
<action>Ensure MVP decisions align with future direction while staying focused on immediate goals</action>
|
||||
|
||||
<template-output>phase_2_features</template-output>
|
||||
<template-output>long_term_vision</template-output>
|
||||
<template-output>expansion_opportunities</template-output>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Document technical considerations" if="collaboration_mode == 'interactive'">
|
||||
<action>Capture technical context as preferences, not final decisions</action>
|
||||
<action>Explore platform requirements: web/mobile/desktop, browser/OS support, performance needs, accessibility standards</action>
|
||||
<action>Investigate technology preferences or constraints: frontend/backend frameworks, database needs, infrastructure requirements</action>
|
||||
<action>Identify existing systems requiring integration</action>
|
||||
<action>Check for technical-preferences.yaml file if available</action>
|
||||
<action>Note these are initial thoughts for PM and architect to consider during planning</action>
|
||||
|
||||
<template-output>platform_requirements</template-output>
|
||||
<template-output>technology_preferences</template-output>
|
||||
<template-output>architecture_considerations</template-output>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Identify constraints and assumptions" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide realistic expectations setting around constraints: budget/resource limits, timeline pressures, team size/expertise, technical limitations</action>
|
||||
<action>Explore assumptions being made about: user behavior, market conditions, technical feasibility</action>
|
||||
<action>Document constraints clearly and list assumptions that need validation during development</action>
|
||||
|
||||
<template-output>constraints</template-output>
|
||||
<template-output>key_assumptions</template-output>
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Assess risks and open questions" optional="true" if="collaboration_mode == 'interactive'">
|
||||
<action>Facilitate honest risk assessment: what could derail the project, impact if risks materialize</action>
|
||||
<action>Document open questions: what still needs figuring out, what needs more research</action>
|
||||
<action>Help prioritize risks by impact and likelihood</action>
|
||||
<action>Frame unknowns as opportunities to prepare, not just worries</action>
|
||||
|
||||
<template-output>key_risks</template-output>
|
||||
<template-output>open_questions</template-output>
|
||||
<template-output>research_areas</template-output>
|
||||
</step>
|
||||
|
||||
<!-- YOLO Mode - Generate everything then refine -->
|
||||
<step n="3" goal="Generate complete brief draft" if="collaboration_mode == 'yolo'">
|
||||
<action>Based on initial context and any provided documents, generate a complete product brief covering all sections</action>
|
||||
<action>Make reasonable assumptions where information is missing</action>
|
||||
<action>Flag areas that need user validation with [NEEDS CONFIRMATION] tags</action>
|
||||
|
||||
<template-output>problem_statement</template-output>
|
||||
<template-output>proposed_solution</template-output>
|
||||
<template-output>primary_user_segment</template-output>
|
||||
<template-output>secondary_user_segment</template-output>
|
||||
<template-output>business_objectives</template-output>
|
||||
<template-output>user_success_metrics</template-output>
|
||||
<template-output>key_performance_indicators</template-output>
|
||||
<template-output>core_features</template-output>
|
||||
<template-output>out_of_scope</template-output>
|
||||
<template-output>mvp_success_criteria</template-output>
|
||||
<template-output>phase_2_features</template-output>
|
||||
<template-output>long_term_vision</template-output>
|
||||
<template-output>expansion_opportunities</template-output>
|
||||
<template-output>financial_impact</template-output>
|
||||
<template-output>company_objectives_alignment</template-output>
|
||||
<template-output>strategic_initiatives</template-output>
|
||||
<template-output>platform_requirements</template-output>
|
||||
<template-output>technology_preferences</template-output>
|
||||
<template-output>architecture_considerations</template-output>
|
||||
<template-output>constraints</template-output>
|
||||
<template-output>key_assumptions</template-output>
|
||||
<template-output>key_risks</template-output>
|
||||
<template-output>open_questions</template-output>
|
||||
<template-output>research_areas</template-output>
|
||||
|
||||
<action>Present the complete draft to the user</action>
|
||||
<ask>Here's the complete brief draft. What would you like to adjust or refine?</ask>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Refine brief sections" repeat="until-approved" if="collaboration_mode == 'yolo'">
|
||||
<ask>Which section would you like to refine?
|
||||
1. Problem Statement
|
||||
2. Proposed Solution
|
||||
3. Target Users
|
||||
4. Goals and Metrics
|
||||
5. MVP Scope
|
||||
6. Post-MVP Vision
|
||||
7. Financial Impact and Strategic Alignment
|
||||
8. Technical Considerations
|
||||
9. Constraints and Assumptions
|
||||
10. Risks and Questions
|
||||
11. Save and continue</ask>
|
||||
|
||||
<action>Work with user to refine selected section</action>
|
||||
<action>Update relevant template outputs</action>
|
||||
</step>
|
||||
|
||||
<!-- Final steps for both modes -->
|
||||
<step n="13" goal="Create executive summary">
|
||||
<action>Synthesize all sections into a compelling executive summary</action>
|
||||
<action>Include:
|
||||
- Product concept in 1-2 sentences
|
||||
- Primary problem being solved
|
||||
- Target market identification
|
||||
- Key value proposition</action>
|
||||
|
||||
<template-output>executive_summary</template-output>
|
||||
|
||||
<action>If they mentioned existing documents (research, brainstorming, etc.):
|
||||
|
||||
- Load and analyze these materials
|
||||
- Extract key themes and insights
|
||||
- Reference these naturally in conversation: "I see from your research that..."
|
||||
- Use these to accelerate discovery, not repeat questions</action>
|
||||
|
||||
<template-output>initial_vision</template-output>
|
||||
</step>
|
||||
|
||||
<step n="14" goal="Compile supporting materials">
|
||||
<action>If research documents were provided, create a summary of key findings</action>
|
||||
<action>Document any stakeholder input received during the process</action>
|
||||
<action>Compile list of reference documents and resources</action>
|
||||
<step n="2" goal="Discover the problem worth solving">
|
||||
<action>Guide problem discovery through natural conversation
|
||||
|
||||
<template-output>research_summary</template-output>
|
||||
<template-output>stakeholder_input</template-output>
|
||||
<template-output>references</template-output>
|
||||
</step>
|
||||
DON'T ask: "What problem does this solve?"
|
||||
|
||||
<step n="15" goal="Final review and handoff">
|
||||
<action>Generate the complete product brief document</action>
|
||||
<action>Review all sections for completeness and consistency</action>
|
||||
<action>Flag any areas that need PM attention with [PM-TODO] tags</action>
|
||||
DO explore conversationally based on their context:
|
||||
|
||||
<ask>The product brief is complete! Would you like to:
|
||||
For hobby projects:
|
||||
|
||||
1. Review the entire document
|
||||
2. Make final adjustments
|
||||
3. Generate an executive summary version (3-page limit)
|
||||
4. Save and prepare for handoff to PM
|
||||
- "What's annoying you that this would fix?"
|
||||
- "What would this make easier or more fun?"
|
||||
- "Show me what the experience is like today without this"
|
||||
|
||||
This brief will serve as the primary input for creating the Product Requirements Document (PRD).</ask>
|
||||
For business ventures:
|
||||
|
||||
<check if="user chooses option 3 (executive summary)">
|
||||
<action>Create condensed 3-page executive brief focusing on: problem statement, proposed solution, target users, MVP scope, financial impact, and strategic alignment</action>
|
||||
<action>Save as: {output_folder}/product-brief-executive-{{project_name}}-{{date}}.md</action>
|
||||
- "Walk me through the frustration your users face today"
|
||||
- "What's the cost of this problem - time, money, opportunities?"
|
||||
- "Who's suffering most from this? Tell me about them"
|
||||
- "What solutions have people tried? Why aren't they working?"
|
||||
|
||||
For enterprise:
|
||||
|
||||
- "What's driving the need for this internally?"
|
||||
- "Which teams/processes are most affected?"
|
||||
- "What's the business impact of not solving this?"
|
||||
- "Are there compliance or strategic drivers?"
|
||||
|
||||
Listen for depth cues:
|
||||
|
||||
- Brief answers → dig deeper with follow-ups
|
||||
- Detailed passion → let them flow, capture everything
|
||||
- Uncertainty → help them explore with examples
|
||||
- Multiple problems → help prioritize the core issue
|
||||
|
||||
Adapt your response:
|
||||
|
||||
- If they struggle: offer analogies, examples, frameworks
|
||||
- If they're clear: validate and push for specifics
|
||||
- If they're technical: explore implementation challenges
|
||||
- If they're business-focused: quantify impact</action>
|
||||
|
||||
<action>Immediately capture what emerges - even if preliminary</action>
|
||||
<template-output>problem_statement</template-output>
|
||||
|
||||
<check if="user mentioned metrics, costs, or business impact">
|
||||
<action>Explore the measurable impact of the problem</action>
|
||||
<template-output>problem_impact</template-output>
|
||||
</check>
|
||||
|
||||
<template-output>final_brief</template-output>
|
||||
<template-output>executive_brief</template-output>
|
||||
<check if="user mentioned current solutions or competitors">
|
||||
<action>Understand why existing solutions fall short</action>
|
||||
<template-output>existing_solutions_gaps</template-output>
|
||||
</check>
|
||||
|
||||
<action>Reflect understanding: "So the core issue is {{problem_summary}}, and {{impact_if_mentioned}}. Let me capture that..."</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Shape the solution vision">
|
||||
<action>Transition naturally from problem to solution
|
||||
|
||||
Based on their energy and context, explore:
|
||||
|
||||
For builders/makers:
|
||||
|
||||
- "How do you envision this working?"
|
||||
- "Walk me through the experience you want to create"
|
||||
- "What's the 'magic moment' when someone uses this?"
|
||||
|
||||
For business minds:
|
||||
|
||||
- "What's your unique approach to solving this?"
|
||||
- "How is this different from what exists today?"
|
||||
- "What makes this the RIGHT solution now?"
|
||||
|
||||
For enterprise:
|
||||
|
||||
- "What would success look like for the organization?"
|
||||
- "How does this fit with existing systems/processes?"
|
||||
- "What's the transformation you're enabling?"
|
||||
|
||||
Go deeper based on responses:
|
||||
|
||||
- If innovative → explore the unique angle
|
||||
- If standard → focus on execution excellence
|
||||
- If technical → discuss key capabilities
|
||||
- If user-focused → paint the journey
|
||||
|
||||
Web research when relevant:
|
||||
|
||||
- If they mention competitors → research current solutions
|
||||
- If they claim innovation → verify uniqueness
|
||||
- If they reference trends → get current data</action>
|
||||
|
||||
<action if="competitor or market mentioned">
|
||||
<WebSearch>{{competitor/market}} latest features 2024</WebSearch>
|
||||
<action>Use findings to sharpen differentiation discussion</action>
|
||||
</action>
|
||||
|
||||
<template-output>proposed_solution</template-output>
|
||||
|
||||
<check if="unique differentiation discussed">
|
||||
<template-output>key_differentiators</template-output>
|
||||
</check>
|
||||
|
||||
<action>Continue building the living document</action>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Understand the people who need this">
|
||||
<action>Discover target users through storytelling, not demographics
|
||||
|
||||
Facilitate based on project type:
|
||||
|
||||
Personal/hobby:
|
||||
|
||||
- "Who else would love this besides you?"
|
||||
- "Tell me about someone who would use this"
|
||||
- Keep it light and informal
|
||||
|
||||
Startup/business:
|
||||
|
||||
- "Describe your ideal first customer - not demographics, but their situation"
|
||||
- "What are they doing today without your solution?"
|
||||
- "What would make them say 'finally, someone gets it!'?"
|
||||
- "Are there different types of users with different needs?"
|
||||
|
||||
Enterprise:
|
||||
|
||||
- "Which roles/departments will use this?"
|
||||
- "Walk me through their current workflow"
|
||||
- "Who are the champions vs skeptics?"
|
||||
- "What about indirect stakeholders?"
|
||||
|
||||
Push beyond generic personas:
|
||||
|
||||
- Not: "busy professionals" → "Sales reps who waste 2 hours/day on data entry"
|
||||
- Not: "tech-savvy users" → "Developers who know Docker but hate configuring it"
|
||||
- Not: "small businesses" → "Shopify stores doing $10-50k/month wanting to scale"
|
||||
|
||||
For each user type that emerges:
|
||||
|
||||
- Current behavior/workflow
|
||||
- Specific frustrations
|
||||
- What they'd value most
|
||||
- Their technical comfort level</action>
|
||||
|
||||
<template-output>primary_user_segment</template-output>
|
||||
|
||||
<check if="multiple user types mentioned">
|
||||
<action>Explore secondary users only if truly different needs</action>
|
||||
<template-output>secondary_user_segment</template-output>
|
||||
</check>
|
||||
|
||||
<check if="user journey or workflow discussed">
|
||||
<template-output>user_journey</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Define what success looks like" repeat="adapt-to-context">
|
||||
<action>Explore success measures that match their context
|
||||
|
||||
For personal projects:
|
||||
|
||||
- "How will you know this is working well?"
|
||||
- "What would make you proud of this?"
|
||||
- Keep metrics simple and meaningful
|
||||
|
||||
For startups:
|
||||
|
||||
- "What metrics would convince you this is taking off?"
|
||||
- "What user behaviors show they love it?"
|
||||
- "What business metrics matter most - users, revenue, retention?"
|
||||
- Push for specific targets: "100 users" not "lots of users"
|
||||
|
||||
For enterprise:
|
||||
|
||||
- "How will the organization measure success?"
|
||||
- "What KPIs will stakeholders care about?"
|
||||
- "What are the must-hit metrics vs nice-to-haves?"
|
||||
|
||||
Only dive deep into metrics if they show interest
|
||||
Skip entirely for pure hobby projects
|
||||
Focus on what THEY care about measuring</action>
|
||||
|
||||
<check if="metrics or goals discussed">
|
||||
<template-output>success_metrics</template-output>
|
||||
|
||||
<check if="business objectives mentioned">
|
||||
<template-output>business_objectives</template-output>
|
||||
</check>
|
||||
|
||||
<check if="KPIs matter to them">
|
||||
<template-output>key_performance_indicators</template-output>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Keep the document growing with each discovery</action>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Discover the MVP scope">
|
||||
<critical>Focus on FEATURES not epics - that comes in Phase 2</critical>
|
||||
|
||||
<action>Guide MVP scoping based on their maturity
|
||||
|
||||
For experimental/hobby:
|
||||
|
||||
- "What's the ONE thing this must do to be useful?"
|
||||
- "What would make a fun first version?"
|
||||
- Embrace simplicity
|
||||
|
||||
For business ventures:
|
||||
|
||||
- "What's the smallest version that proves your hypothesis?"
|
||||
- "What features would make early adopters say 'good enough'?"
|
||||
- "What's tempting to add but would slow you down?"
|
||||
- Be ruthless about scope creep
|
||||
|
||||
For enterprise:
|
||||
|
||||
- "What's the pilot scope that demonstrates value?"
|
||||
- "Which capabilities are must-have for initial rollout?"
|
||||
- "What can we defer to Phase 2?"
|
||||
|
||||
Use this framing:
|
||||
|
||||
- Core features: "Without this, the product doesn't work"
|
||||
- Nice-to-have: "This would be great, but we can launch without it"
|
||||
- Future vision: "This is where we're headed eventually"
|
||||
|
||||
Challenge feature creep:
|
||||
|
||||
- "Do we need that for launch, or could it come later?"
|
||||
- "What if we started without that - what breaks?"
|
||||
- "Is this core to proving the concept?"</action>
|
||||
|
||||
<template-output>core_features</template-output>
|
||||
|
||||
<check if="scope creep discussed">
|
||||
<template-output>out_of_scope</template-output>
|
||||
</check>
|
||||
|
||||
<check if="future features mentioned">
|
||||
<template-output>future_vision_features</template-output>
|
||||
</check>
|
||||
|
||||
<check if="success criteria for MVP mentioned">
|
||||
<template-output>mvp_success_criteria</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Explore relevant context dimensions" repeat="until-natural-end">
|
||||
<critical>Only explore what emerges naturally - skip what doesn't matter</critical>
|
||||
|
||||
<action>Based on the conversation so far, selectively explore:
|
||||
|
||||
IF financial aspects emerged:
|
||||
|
||||
- Development investment needed
|
||||
- Revenue potential or cost savings
|
||||
- ROI timeline
|
||||
- Budget constraints
|
||||
<check if="discussed">
|
||||
<template-output>financial_considerations</template-output>
|
||||
</check>
|
||||
|
||||
IF market competition mentioned:
|
||||
|
||||
- Competitive landscape
|
||||
- Market opportunity size
|
||||
- Differentiation strategy
|
||||
- Market timing
|
||||
<check if="discussed">
|
||||
<WebSearch>{{market}} size trends 2024</WebSearch>
|
||||
<template-output>market_analysis</template-output>
|
||||
</check>
|
||||
|
||||
IF technical preferences surfaced:
|
||||
|
||||
- Platform choices (web/mobile/desktop)
|
||||
- Technology stack preferences
|
||||
- Integration needs
|
||||
- Performance requirements
|
||||
<check if="discussed">
|
||||
<template-output>technical_preferences</template-output>
|
||||
</check>
|
||||
|
||||
IF organizational context emerged:
|
||||
|
||||
- Strategic alignment
|
||||
- Stakeholder buy-in needs
|
||||
- Change management considerations
|
||||
- Compliance requirements
|
||||
<check if="discussed">
|
||||
<template-output>organizational_context</template-output>
|
||||
</check>
|
||||
|
||||
IF risks or concerns raised:
|
||||
|
||||
- Key risks and mitigation
|
||||
- Critical assumptions
|
||||
- Open questions needing research
|
||||
<check if="discussed">
|
||||
<template-output>risks_and_assumptions</template-output>
|
||||
</check>
|
||||
|
||||
IF timeline pressures mentioned:
|
||||
|
||||
- Launch timeline
|
||||
- Critical milestones
|
||||
- Dependencies
|
||||
<check if="discussed">
|
||||
<template-output>timeline_constraints</template-output>
|
||||
</check>
|
||||
|
||||
Skip anything that hasn't naturally emerged
|
||||
Don't force sections that don't fit their context</action>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Refine and complete the living document">
|
||||
<action>Review what's been captured with the user
|
||||
|
||||
"Let me show you what we've built together..."
|
||||
|
||||
Present the actual document sections created so far
|
||||
|
||||
- Not a summary, but the real content
|
||||
- Shows the document has been growing throughout
|
||||
|
||||
Ask:
|
||||
"Looking at this, what stands out as most important to you?"
|
||||
"Is there anything critical we haven't explored?"
|
||||
"Does this capture your vision?"
|
||||
|
||||
Based on their response:
|
||||
|
||||
- Refine sections that need more depth
|
||||
- Add any missing critical elements
|
||||
- Remove or simplify sections that don't matter
|
||||
- Ensure the document fits THEIR needs, not a template</action>
|
||||
|
||||
<action>Make final refinements based on feedback</action>
|
||||
<template-output>final_refinements</template-output>
|
||||
|
||||
<action>Create executive summary that captures the essence</action>
|
||||
<template-output>executive_summary</template-output>
|
||||
</step>
|
||||
<step n="9" goal="Complete and save the product brief">
|
||||
<action>The document has been building throughout our conversation
|
||||
Now ensure it's complete and well-organized</action>
|
||||
|
||||
<check if="research documents were provided">
|
||||
<action>Append summary of incorporated research</action>
|
||||
<template-output>supporting_materials</template-output>
|
||||
</check>
|
||||
|
||||
<action>Ensure the document structure makes sense for what was discovered:
|
||||
|
||||
- Hobbyist projects might be 2-3 pages focused on problem/solution/features
|
||||
- Startup ventures might be 5-7 pages with market analysis and metrics
|
||||
- Enterprise briefs might be 10+ pages with full strategic context
|
||||
|
||||
The document should reflect their world, not force their world into a template</action>
|
||||
|
||||
<ask>Your product brief is ready! Would you like to:
|
||||
|
||||
1. Review specific sections together
|
||||
2. Make any final adjustments
|
||||
3. Save and move forward
|
||||
|
||||
What feels right?</ask>
|
||||
|
||||
<action>Make any requested refinements</action>
|
||||
<template-output>final_document</template-output>
|
||||
</step>
|
||||
|
||||
<step n="16" goal="Update status file on completion" tag="workflow-status">
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "product-brief"</action>
|
||||
@@ -299,34 +484,23 @@ This brief will serve as the primary input for creating the Product Requirements
|
||||
|
||||
<output>**✅ Product Brief Complete, {user_name}!**
|
||||
|
||||
**Brief Document:**
|
||||
Your product vision has been captured in a document that reflects what matters most for your {{context_type}} project.
|
||||
|
||||
- Product brief saved to {output_folder}/bmm-product-brief-{{project_name}}-{{date}}.md
|
||||
**Document saved:** {output_folder}/bmm-product-brief-{{project_name}}-{{date}}.md
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
**Status Updated:**
|
||||
**What's next:** {{next_workflow}} ({{next_agent}} agent)
|
||||
|
||||
- Progress tracking updated: product-brief marked complete
|
||||
- Next workflow: {{next_workflow}}
|
||||
{{else}}
|
||||
**Note:** Running in standalone mode (no progress tracking)
|
||||
{{/if}}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
|
||||
- **Next workflow:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- **Optional:** Gather additional stakeholder input or run research workflows before proceeding
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
The next phase will take your brief and create the detailed planning artifacts needed for implementation.
|
||||
{{else}}
|
||||
Since no workflow is in progress:
|
||||
**Next steps:**
|
||||
|
||||
- Refer to the BMM workflow guide if unsure what to do next
|
||||
- Or run `workflow-init` to create a workflow path and get guided next steps
|
||||
- Run `workflow-init` to set up guided workflow tracking
|
||||
- Or proceed directly to the PRD workflow if you know your path
|
||||
{{/if}}
|
||||
</output>
|
||||
</step>
|
||||
|
||||
Remember: This brief captures YOUR vision. It grew from our conversation, not from a rigid template. It's ready to guide the next phase of bringing your idea to life.
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
**Status:** Draft for PM Review
|
||||
**Context:** {{context_type}}
|
||||
|
||||
---
|
||||
|
||||
@@ -12,154 +12,170 @@
|
||||
|
||||
---
|
||||
|
||||
## Problem Statement
|
||||
## Core Vision
|
||||
|
||||
### Problem Statement
|
||||
|
||||
{{problem_statement}}
|
||||
|
||||
---
|
||||
{{#if problem_impact}}
|
||||
|
||||
## Proposed Solution
|
||||
### Problem Impact
|
||||
|
||||
{{problem_impact}}
|
||||
{{/if}}
|
||||
|
||||
{{#if existing_solutions_gaps}}
|
||||
|
||||
### Why Existing Solutions Fall Short
|
||||
|
||||
{{existing_solutions_gaps}}
|
||||
{{/if}}
|
||||
|
||||
### Proposed Solution
|
||||
|
||||
{{proposed_solution}}
|
||||
|
||||
{{#if key_differentiators}}
|
||||
|
||||
### Key Differentiators
|
||||
|
||||
{{key_differentiators}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Target Users
|
||||
|
||||
### Primary User Segment
|
||||
### Primary Users
|
||||
|
||||
{{primary_user_segment}}
|
||||
|
||||
### Secondary User Segment
|
||||
{{#if secondary_user_segment}}
|
||||
|
||||
### Secondary Users
|
||||
|
||||
{{secondary_user_segment}}
|
||||
{{/if}}
|
||||
|
||||
{{#if user_journey}}
|
||||
|
||||
### User Journey
|
||||
|
||||
{{user_journey}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Goals and Success Metrics
|
||||
{{#if success_metrics}}
|
||||
|
||||
## Success Metrics
|
||||
|
||||
{{success_metrics}}
|
||||
|
||||
{{#if business_objectives}}
|
||||
|
||||
### Business Objectives
|
||||
|
||||
{{business_objectives}}
|
||||
{{/if}}
|
||||
|
||||
### User Success Metrics
|
||||
{{#if key_performance_indicators}}
|
||||
|
||||
{{user_success_metrics}}
|
||||
|
||||
### Key Performance Indicators (KPIs)
|
||||
### Key Performance Indicators
|
||||
|
||||
{{key_performance_indicators}}
|
||||
|
||||
---
|
||||
|
||||
## Strategic Alignment and Financial Impact
|
||||
|
||||
### Financial Impact
|
||||
|
||||
{{financial_impact}}
|
||||
|
||||
### Company Objectives Alignment
|
||||
|
||||
{{company_objectives_alignment}}
|
||||
|
||||
### Strategic Initiatives
|
||||
|
||||
{{strategic_initiatives}}
|
||||
{{/if}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## MVP Scope
|
||||
|
||||
### Core Features (Must Have)
|
||||
### Core Features
|
||||
|
||||
{{core_features}}
|
||||
|
||||
{{#if out_of_scope}}
|
||||
|
||||
### Out of Scope for MVP
|
||||
|
||||
{{out_of_scope}}
|
||||
{{/if}}
|
||||
|
||||
{{#if mvp_success_criteria}}
|
||||
|
||||
### MVP Success Criteria
|
||||
|
||||
{{mvp_success_criteria}}
|
||||
{{/if}}
|
||||
|
||||
{{#if future_vision_features}}
|
||||
|
||||
### Future Vision
|
||||
|
||||
{{future_vision_features}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Post-MVP Vision
|
||||
{{#if market_analysis}}
|
||||
|
||||
### Phase 2 Features
|
||||
## Market Context
|
||||
|
||||
{{phase_2_features}}
|
||||
{{market_analysis}}
|
||||
{{/if}}
|
||||
|
||||
### Long-term Vision
|
||||
{{#if financial_considerations}}
|
||||
|
||||
{{long_term_vision}}
|
||||
## Financial Considerations
|
||||
|
||||
### Expansion Opportunities
|
||||
{{financial_considerations}}
|
||||
{{/if}}
|
||||
|
||||
{{expansion_opportunities}}
|
||||
{{#if technical_preferences}}
|
||||
|
||||
## Technical Preferences
|
||||
|
||||
{{technical_preferences}}
|
||||
{{/if}}
|
||||
|
||||
{{#if organizational_context}}
|
||||
|
||||
## Organizational Context
|
||||
|
||||
{{organizational_context}}
|
||||
{{/if}}
|
||||
|
||||
{{#if risks_and_assumptions}}
|
||||
|
||||
## Risks and Assumptions
|
||||
|
||||
{{risks_and_assumptions}}
|
||||
{{/if}}
|
||||
|
||||
{{#if timeline_constraints}}
|
||||
|
||||
## Timeline
|
||||
|
||||
{{timeline_constraints}}
|
||||
{{/if}}
|
||||
|
||||
{{#if supporting_materials}}
|
||||
|
||||
## Supporting Materials
|
||||
|
||||
{{supporting_materials}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Technical Considerations
|
||||
_This Product Brief captures the vision and requirements for {{project_name}}._
|
||||
|
||||
### Platform Requirements
|
||||
_It was created through collaborative discovery and reflects the unique needs of this {{context_type}} project._
|
||||
|
||||
{{platform_requirements}}
|
||||
|
||||
### Technology Preferences
|
||||
|
||||
{{technology_preferences}}
|
||||
|
||||
### Architecture Considerations
|
||||
|
||||
{{architecture_considerations}}
|
||||
|
||||
---
|
||||
|
||||
## Constraints and Assumptions
|
||||
|
||||
### Constraints
|
||||
|
||||
{{constraints}}
|
||||
|
||||
### Key Assumptions
|
||||
|
||||
{{key_assumptions}}
|
||||
|
||||
---
|
||||
|
||||
## Risks and Open Questions
|
||||
|
||||
### Key Risks
|
||||
|
||||
{{key_risks}}
|
||||
|
||||
### Open Questions
|
||||
|
||||
{{open_questions}}
|
||||
|
||||
### Areas Needing Further Research
|
||||
|
||||
{{research_areas}}
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
### A. Research Summary
|
||||
|
||||
{{research_summary}}
|
||||
|
||||
### B. Stakeholder Input
|
||||
|
||||
{{stakeholder_input}}
|
||||
|
||||
### C. References
|
||||
|
||||
{{references}}
|
||||
|
||||
---
|
||||
|
||||
_This Product Brief serves as the foundational input for Product Requirements Document (PRD) creation._
|
||||
|
||||
_Next Steps: Handoff to Product Manager for PRD development using the `workflow prd` command._
|
||||
{{#if next_workflow}}
|
||||
_Next: {{next_workflow}} will transform this brief into detailed planning artifacts._
|
||||
{{else}}
|
||||
_Next: Use the PRD workflow to create detailed product requirements from this brief._
|
||||
{{/if}}
|
||||
|
||||
Reference in New Issue
Block a user