bmad-enhanced 1.3.0 → 1.3.2

package/_bmad/bme/_vortex/workflows/lean-experiment/lean-experiment.template.md

@@ -0,0 +1,29 @@
+---
+title: "Lean Experiment: {experiment-name}"
+date: {date}
+type: lean-experiment
+status: {status}
+---
+
+# Lean Experiment: {experiment-name}
+
+## Hypothesis
+
+{hypothesis}
+
+## Experiment Design
+
+{experiment-design}
+
+## Results
+
+{results}
+
+## Decision
+
+{pivot-or-persevere}
+
+---
+
+**Created with:** BMAD-Enhanced v1.2.0
+**Workflow:** lean-experiment

package/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-01.md

@@ -0,0 +1,8 @@
+---
+step: 1
+workflow: lean-experiment
+---
+
+# Step 1
+
+[Content for step 1]

package/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-02.md

@@ -0,0 +1,8 @@
+---
+step: 2
+workflow: lean-experiment
+---
+
+# Step 2
+
+[Content for step 2]

package/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-03.md

@@ -0,0 +1,8 @@
+---
+step: 3
+workflow: lean-experiment
+---
+
+# Step 3
+
+[Content for step 3]

package/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-04.md

@@ -0,0 +1,8 @@
+---
+step: 4
+workflow: lean-experiment
+---
+
+# Step 4
+
+[Content for step 4]

package/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-05.md

@@ -0,0 +1,8 @@
+---
+step: 5
+workflow: lean-experiment
+---
+
+# Step 5
+
+[Content for step 5]

package/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-06.md

@@ -0,0 +1,8 @@
+---
+step: 6
+workflow: lean-experiment
+---
+
+# Step 6
+
+[Content for step 6]

package/_bmad/bme/_vortex/workflows/lean-experiment/validate.md

@@ -0,0 +1,30 @@
+# Validate Lean Experiment
+
+**Status:** Coming in v1.2.0
+
+**Agent:** Wade (Lean Experiments Specialist)
+
+**Stream:** Externalize
+
+## Overview
+
+This validation workflow helps you review lean experiments to ensure they're scientifically sound and focused on learning.
+
+## What Gets Validated
+
+- Is the hypothesis specific and falsifiable?
+- Is the experiment design appropriate for the hypothesis?
+- Are success criteria clear and measurable?
+- Are results documented with evidence?
+- Are learnings actionable?
+- Is the pivot/persevere decision justified?
+
+## Coming in v1.2.0
+
+This validation workflow will be available alongside the lean-experiment workflow in March 2026.
+
+## Questions?
+
+For questions or to request early access:
+- GitHub Issues: https://github.com/amalik/BMAD-Enhanced/issues
+- Tag with: `workflow:lean-experiment` and `v1.2.0`

package/_bmad/bme/_vortex/workflows/lean-experiment/workflow.md

@@ -0,0 +1,26 @@
+---
+workflow: lean-experiment
+type: step-file
+description: Execute Build-Measure-Learn cycles with hypothesis testing
+author: Wade (lean-experiments-specialist)
+version: 1.2.0
+---
+
+# Lean Experiment Workflow
+
+Execute Build-Measure-Learn cycles to validate or invalidate hypotheses.
+
+## Steps Overview
+
+1. **State Hypothesis** - What do you believe is true?
+2. **Design Experiment** - How will you test it?
+3. **Define Metrics** - What will you measure?
+4. **Run Experiment** - Execute and collect data
+5. **Analyze Results** - What did you learn?
+6. **Decide: Pivot or Persevere** - What's next?
+
+---
+
+## INITIALIZATION
+
+Load step: {project-root}/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-01-hypothesis.md

package/_bmad/bme/_vortex/workflows/lean-persona/lean-persona.template.md

@@ -0,0 +1,163 @@
+---
+title: "Lean Persona: {persona-name}"
+date: {date}
+created-by: {user-name} with Emma (contextualization-expert)
+type: lean-persona
+status: HYPOTHESIS
+version: 1.0
+---
+
+# Lean Persona: {persona-name}
+
+> **Remember:** This is a hypothesis until validated. Every insight below needs testing with real users.
+
+## Executive Summary
+
+**Job-to-be-Done:**
+{job-summary}
+
+**Riskiest Assumptions:**
+{top-3-assumptions}
+
+**Next Validation Steps:**
+{next-validation-steps}
+
+---
+
+## Job-to-be-Done
+
+### Primary Job
+{primary-job}
+
+### Context
+{job-context}
+
+### Frequency & Importance
+{job-frequency-importance}
+
+### Current Solution
+{current-solution}
+
+---
+
+## Current State Analysis
+
+### How They Solve It Today
+{current-solution-details}
+
+### Pain Points with Current Solution
+{pain-points}
+
+### Workarounds & Hacks
+{workarounds}
+
+### Cost of Current Solution
+{current-cost}
+
+---
+
+## Problem Contexts
+
+### When Does This Problem Occur?
+{problem-timing}
+
+### Where Does This Problem Occur?
+{problem-location}
+
+### Why Does This Problem Matter Now?
+{problem-urgency}
+
+### What Triggers the Need?
+{problem-triggers}
+
+---
+
+## Forces & Anxieties
+
+### Forces Pushing Toward Change
+**What makes them want to switch?**
+{push-forces}
+
+### Forces Pulling Back to Status Quo
+**What makes them hesitate?**
+{pull-forces}
+
+### Anxieties About Changing
+{anxieties}
+
+### Habits That Need Breaking
+{habits}
+
+---
+
+## Success Criteria
+
+### Desired Outcome
+{desired-outcome}
+
+### Success Metrics
+{success-metrics}
+
+### Time to Value
+{time-to-value}
+
+### Acceptable Trade-offs
+{tradeoffs}
+
+---
+
+## Assumptions to Validate
+
+### Critical Assumptions (Test First)
+{critical-assumptions}
+
+### Important Assumptions (Test Soon)
+{important-assumptions}
+
+### Nice-to-Validate (Test Later)
+{nice-to-validate}
+
+---
+
+## Validation Plan
+
+### Experiment 1: {experiment-1-name}
+- **Hypothesis:** {experiment-1-hypothesis}
+- **Method:** {experiment-1-method}
+- **Success Criteria:** {experiment-1-success}
+- **Timeline:** {experiment-1-timeline}
+
+### Experiment 2: {experiment-2-name}
+- **Hypothesis:** {experiment-2-hypothesis}
+- **Method:** {experiment-2-method}
+- **Success Criteria:** {experiment-2-success}
+- **Timeline:** {experiment-2-timeline}
+
+### Experiment 3: {experiment-3-name}
+- **Hypothesis:** {experiment-3-hypothesis}
+- **Method:** {experiment-3-method}
+- **Success Criteria:** {experiment-3-success}
+- **Timeline:** {experiment-3-timeline}
+
+---
+
+## Next Steps
+
+1. **Validate riskiest assumption first:** {riskiest-assumption}
+2. **Talk to {target-interview-count} potential users** within {timeline}
+3. **Run {experiment-type}** to test {what-youre-testing}
+4. **Decision criteria:** If {success-metric} reaches {threshold}, then {decision}
+
+---
+
+## Revision History
+
+| Date | What Changed | Why | New Assumptions |
+|------|--------------|-----|-----------------|
+| {date} | Initial creation | First hypothesis | All assumptions untested |
+
+---
+
+**Created with:** BMAD-Enhanced v1.2.0 - Vortex Framework (Contextualize Stream)
+**Agent:** Emma (Contextualization Expert)
+**Workflow:** lean-persona

package/_bmad/bme/_vortex/workflows/lean-persona/steps/step-01-define-job.md

@@ -0,0 +1,72 @@
+---
+step: 1
+workflow: lean-persona
+title: Define Job-to-be-Done
+---
+
+# Step 1: Define Job-to-be-Done
+
+Before we create a lean persona, we need to understand the fundamental job your user is trying to accomplish.
+
+## Why This Matters
+
+Jobs-to-be-done is the foundation of lean personas. People don't buy products - they "hire" solutions to get a job done. Understanding the job helps us:
+- Focus on behavior, not demographics
+- Identify what truly matters to users
+- Find better competing solutions we might not have considered
+- Design value propositions that resonate
+
+## Your Task
+
+Answer these questions to define the job-to-be-done:
+
+### 1. What job is the user trying to accomplish?
+Be specific. Not "manage finances" but "ensure I don't overspend on discretionary purchases each month."
+
+### 2. Give this persona a name
+A simple identifier (e.g., "Budget-Conscious Parent", "Efficiency-Driven PM"). This is for reference, not a demographic label.
+
+### 3. How often does this job occur?
+- Daily? Weekly? Monthly? Annually?
+- Is it predictable or unpredictable?
+- How urgent is it when it arises?
+
+### 4. How important is this job to the user?
+On a scale: Mission-critical / Very important / Important / Nice-to-have
+Why does it matter to them?
+
+### 5. What evidence do you have?
+- User interviews? (how many?)
+- Surveys? Observations?
+- Analytics? Support tickets?
+- Or is this a hypothesis to validate?
+
+## Example
+
+**Persona Name:** Time-Strapped Remote Manager
+
+**Job-to-be-Done:** Keep my distributed team aligned on priorities without wasting time in status meetings.
+
+**Frequency:** Daily (checking alignment), Weekly (setting priorities)
+
+**Importance:** Mission-critical - Team misalignment directly impacts delivery and morale
+
+**Evidence:**
+- 5 user interviews with remote team managers
+- Analysis of 100+ support tickets about "meeting overload"
+- Survey of 200 remote managers (68% cited "too many meetings" as top frustration)
+- HYPOTHESIS: We believe eliminating daily standups would improve team productivity
+
+---
+
+## Your Turn
+
+Please define the job-to-be-done using the structure above.
+
+**Important:** If you're working from a hypothesis (not validated research), clearly mark assumptions. Every assumption needs a plan to validate it.
+
+## Next Step
+
+When you've defined the job and I've confirmed it's specific enough, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/lean-persona/steps/step-02-current-solution.md

package/_bmad/bme/_vortex/workflows/lean-persona/steps/step-02-current-solution.md

@@ -0,0 +1,83 @@
+---
+step: 2
+workflow: lean-persona
+title: Current Solution Analysis
+---
+
+# Step 2: Current Solution Analysis
+
+Now that we know the job, let's understand how users solve it today - and what's broken about that solution.
+
+## Why This Matters
+
+Your product isn't competing with nothing - it's competing with how users currently solve this problem. Understanding their current solution reveals:
+- What they value (they're paying with time, money, or frustration)
+- Where the opportunities are (what's broken)
+- What habits you'll need to break (switching costs)
+- How good "good enough" needs to be
+
+## Your Task
+
+Answer these questions about the current solution:
+
+### 1. How do they solve this job today?
+Describe their current approach in detail. What tools/methods/processes do they use?
+
+### 2. What are the pain points with the current solution?
+List 3-5 specific frustrations. Be concrete.
+- Not: "It's slow"
+- But: "Takes 15+ minutes to generate a weekly report that should take 2 minutes"
+
+### 3. What workarounds or hacks have they created?
+Users are creative. What unofficial solutions have they cobbled together?
+
+### 4. What does the current solution cost them?
+- Time (hours per week/month)?
+- Money (subscriptions, licenses, tools)?
+- Opportunity cost (what can't they do because of this)?
+- Frustration/stress?
+
+### 5. Why haven't they switched already?
+If it's so painful, what keeps them using the current solution?
+
+## Example
+
+**Current Solution:**
+Weekly status meetings + scattered Slack messages + Google Doc tracking sheet
+
+**Pain Points:**
+1. Status meetings take 1 hour but only 10 minutes is relevant to any individual
+2. Important updates get lost in Slack noise
+3. Google Doc always out of date - no one updates it consistently
+4. No visibility between weekly meetings if something goes off track
+
+**Workarounds:**
+- Manager manually DMs each team member daily for quick updates (adds 30 min/day)
+- Team created private #urgent-only Slack channel (but not everyone checks it)
+- Some teams use Linear/Jira but half the team ignores it
+
+**Current Cost:**
+- Time: 5 hours/week (1hr meeting + 2.5hrs prep/DMs + 1.5hrs chasing updates)
+- Money: $0 (using free tools)
+- Opportunity cost: Can't proactively spot blockers, only reactively fix problems
+- Frustration: HIGH - "I spend more time tracking work than doing work"
+
+**Why Haven't They Switched:**
+- Free tools are "good enough"
+- Tried 3 project management tools, team resisted all of them
+- Learning new tools takes time they don't have
+- Worried about making things more complicated, not simpler
+
+---
+
+## Your Turn
+
+Please analyze the current solution using the structure above.
+
+**Tip:** If users say "there is no current solution," they're wrong. There's ALWAYS a current solution, even if it's "ignore the problem" or "manually do it."
+
+## Next Step
+
+When you've analyzed the current solution, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/lean-persona/steps/step-03-problem-contexts.md

package/_bmad/bme/_vortex/workflows/lean-persona/steps/step-03-problem-contexts.md

@@ -0,0 +1,90 @@
+---
+step: 3
+workflow: lean-persona
+title: Problem Contexts
+---
+
+# Step 3: Problem Contexts
+
+Understanding WHEN, WHERE, and WHY the problem occurs helps us design solutions that fit the real context of use.
+
+## Why This Matters
+
+Context shapes behavior. A solution that works at a desk doesn't work on mobile. A solution that works when calm doesn't work when stressed. Understanding context helps us:
+- Design for the real moment of use
+- Identify hidden constraints
+- Find the triggers that make the problem urgent
+- Avoid solutions that look good in demos but fail in reality
+
+## Your Task
+
+Answer these questions about the problem context:
+
+### 1. When does this problem occur?
+- Time of day? Day of week?
+- Start of month? End of quarter?
+- During specific events or milestones?
+- Is it predictable or unpredictable?
+
+### 2. Where does this problem occur?
+- Physical location (office, home, commute, coffee shop)?
+- Digital location (which tools/platforms)?
+- State of mind (focused work, multitasking, distracted)?
+
+### 3. Why does this problem matter NOW?
+What's changed recently that makes this problem more urgent?
+- New pressures? New competitors?
+- Changing expectations? Regulatory changes?
+- Or has it always been urgent but unaddressed?
+
+### 4. What triggers the need?
+What specific event makes the user think "I need to solve this NOW"?
+
+### 5. What's happening around them?
+What else are they juggling when this problem hits?
+Other tasks? Interruptions? Deadlines?
+
+## Example
+
+**When:**
+- Every Monday morning (weekly planning)
+- Throughout the week when someone asks "What's the status on X?"
+- Friday afternoon (preparing for Monday's meeting)
+- URGENCY SPIKES: When a deadline is at risk and manager doesn't realize until it's too late
+
+**Where:**
+- Physical: Home office (80%), coffee shop/coworking (20%)
+- Digital: Bouncing between Slack, Google Docs, Linear, Figma, GitHub
+- State of mind: Usually multitasking - checking status while on calls, while reviewing work, while coding
+
+**Why NOW:**
+- Company grew from 10 to 50 people - old informal methods don't scale
+- Remote-first means can't just "walk over and ask"
+- Increased customer commitments mean missed deadlines = angry customers
+- CEO now asks weekly "Are we on track?" and manager doesn't have confident answer
+
+**Triggers:**
+- Monday morning: "What should we focus on this week?"
+- Mid-week: Slack DM asking "When will X be done?"
+- Client escalation: "Where's the feature you promised?"
+- Team member stuck: "I'm blocked, what should I work on instead?"
+
+**Context:**
+- Usually happens during already-busy times
+- Interrupts deep work to gather status
+- Manager feels reactive, not proactive
+- Team feels over-managed and interrupted
+
+---
+
+## Your Turn
+
+Please describe the problem contexts using the structure above.
+
+**Tip:** Context shapes constraints. A solution that requires focused attention won't work if the user is constantly interrupted. Design for the REAL context, not the ideal context.
+
+## Next Step
+
+When you've mapped the problem contexts, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/lean-persona/steps/step-04-forces-anxieties.md

package/_bmad/bme/_vortex/workflows/lean-persona/steps/step-04-forces-anxieties.md

@@ -0,0 +1,98 @@
+---
+step: 4
+workflow: lean-persona
+title: Forces & Anxieties
+---
+
+# Step 4: Forces & Anxieties
+
+What pushes users to change, and what holds them back? Understanding these competing forces reveals how to win (or why you might lose).
+
+## Why This Matters
+
+Users rarely switch just because a new solution is better. They switch when:
+- The push (pain of status quo) outweighs the pull (comfort of familiarity)
+- The forces pushing toward change overcome the anxieties about changing
+
+Understanding these forces helps us:
+- Design messaging that addresses anxieties
+- Reduce switching costs
+- Find the moment when change becomes inevitable
+- Avoid solving problems users don't care enough to fix
+
+## Your Task
+
+Answer these questions about forces and anxieties:
+
+### 1. What forces push them TOWARD changing?
+What specific pain points make them think "I can't keep doing it this way"?
+
+List 3-5 push forces, ranked by intensity.
+
+### 2. What forces pull them BACK to the status quo?
+What makes them say "Maybe the current way isn't so bad"?
+
+Comfort? Familiarity? Sunk cost? Team resistance?
+
+### 3. What anxieties do they have about changing?
+What are they worried will happen if they switch?
+
+- Will it make things worse?
+- Will the team resist?
+- Will I waste time learning something that doesn't work?
+- What if I pick the wrong solution?
+
+### 4. What habits need to break?
+Changing solutions means changing behavior. What daily/weekly habits are ingrained?
+
+### 5. What's the tipping point?
+At what point does the pain become unbearable enough to overcome all the resistance?
+
+## Example
+
+**Forces Pushing TOWARD Change:**
+1. **Client escalation** (HIGHEST) - Missed commitment to customer, CEO is angry
+2. **Manager anxiety** - Constant worry "Am I missing something critical?"
+3. **Team frustration** - "Stop interrupting me with status checks!"
+4. **Wasted time** - 5 hours/week just tracking (not doing) work
+5. **Lack of confidence** - Can't give honest answer to "Are we on track?"
+
+**Forces Pulling BACK:**
+1. **Free tools** - Current solution costs $0, new tool costs $$$
+2. **Team resistance** - "Not another tool! We have too many already"
+3. **Learning curve** - "I don't have time to learn a new system"
+4. **Past failures** - Tried Asana, Monday.com, ClickUp - all failed
+
+**Anxieties About Changing:**
+- "What if the team just ignores this tool like all the others?"
+- "What if it's MORE complicated than what we have now?"
+- "What if I spend money and it doesn't solve the problem?"
+- "What if it only works for 6 months then we're back to square one?"
+- "What if we lose important information during the transition?"
+
+**Habits That Need Breaking:**
+- Monday morning meetings (team expects them)
+- Daily Slack DMs for updates (manager's go-to move)
+- Google Doc tracking (everyone knows where it is)
+- "Just ask in Slack" culture
+
+**Tipping Point:**
+When one of these happens:
+- Client threatens to cancel contract due to missed deadline
+- CEO demands better visibility (manager's credibility on the line)
+- Team member quits citing "constant interruptions"
+- Manager misses something critical and it becomes a crisis
+
+---
+
+## Your Turn
+
+Please map the forces and anxieties using the structure above.
+
+**Tip:** If the forces pulling back are stronger than the forces pushing forward, your solution might not be a priority no matter how good it is. Find the tipping point.
+
+## Next Step
+
+When you've mapped forces and anxieties, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/lean-persona/steps/step-05-success-criteria.md