convoke-agents 2.0.0

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

package/_bmad/bme/_vortex/workflows/lean-persona/steps/step-05-success-criteria.md

@@ -0,0 +1,103 @@
+---
+step: 5
+workflow: lean-persona
+title: Success Criteria
+---
+
+# Step 5: Success Criteria
+
+What does a successful solution look like? How will the user know it's working? What are they willing to trade off?
+
+## Why This Matters
+
+Success criteria help us:
+- Define measurable outcomes (not just features)
+- Avoid building the wrong thing
+- Know when we've solved the problem (or when to pivot)
+- Understand acceptable trade-offs
+
+Without clear success criteria, we risk building something users think is "nice" but never actually use.
+
+## Your Task
+
+Answer these questions about success criteria:
+
+### 1. What's the desired outcome?
+If this solution worked perfectly, what would change in the user's life/work?
+
+Be specific and measurable. Not "less stressed" but "can answer 'Are we on track?' in <30 seconds with confidence."
+
+### 2. What success metrics matter?
+How will they measure success?
+
+- Time saved?
+- Money saved?
+- Quality improved?
+- Stress reduced?
+- Confidence increased?
+
+Define the metric AND the target threshold.
+
+### 3. How quickly do they need to see value?
+- Immediate (first use)?
+- Within a week?
+- Within a month?
+- Within a quarter?
+
+What's the acceptable "time to value"?
+
+### 4. What trade-offs are acceptable?
+What are they willing to sacrifice for the desired outcome?
+
+- Pay more for time saved?
+- Accept some complexity for power?
+- Sacrifice some features for simplicity?
+- Change workflows for better results?
+
+### 5. What trade-offs are NOT acceptable?
+What are the deal-breakers?
+
+## Example
+
+**Desired Outcome:**
+"I can confidently answer 'Are we on track?' in less than 30 seconds, and proactively spot problems before they become crises."
+
+**Success Metrics:**
+1. **Time to status check:** <30 seconds (vs. current 15+ minutes)
+2. **Proactive problem detection:** Catch blockers within 24 hours (vs. current 3-5 days)
+3. **Team interruptions:** <2 per day (vs. current 10+)
+4. **Manager confidence:** Can give accurate status updates without hunting for information
+5. **Wasted time:** <1 hour/week on status (vs. current 5 hours)
+
+**Time to Value:**
+- **Week 1:** Must be easier than current solution or team won't adopt
+- **Week 2:** Should reduce daily interruptions noticeably
+- **Month 1:** Should save 2+ hours/week measurably
+- **Month 3:** Should prevent at least one "missed deadline surprise"
+
+**Acceptable Trade-offs:**
+- ✅ Pay $10-30/person/month for 4+ hours saved weekly
+- ✅ Spend 2 hours learning the tool to save 5+ hours/week ongoing
+- ✅ Change Monday meeting format (shorter, more focused)
+- ✅ Require team to update status (if it's < 5 min/day)
+
+**NOT Acceptable Trade-offs:**
+- ❌ Add MORE overhead (e.g., 15 min/day to update)
+- ❌ Replace one complicated tool with another complicated tool
+- ❌ Require team to learn completely new workflow
+- ❌ Lose historical information/context
+- ❌ Create visibility for manager but burden for team
+
+---
+
+## Your Turn
+
+Please define success criteria using the structure above.
+
+**Tip:** If you can't define measurable success criteria, you can't validate whether your solution works. "Better" and "easier" aren't measurable. "Reduces time from 15 min to 2 min" is measurable.
+
+## Next Step
+
+When you've defined success criteria, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/lean-persona/steps/step-06-synthesize.md

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

@@ -0,0 +1,129 @@
+---
+step: 6
+workflow: lean-persona
+title: Synthesize
+---
+
+# Step 6: Synthesize
+
+Now let's bring it all together into a lean persona artifact with a clear validation plan.
+
+## Why This Matters
+
+The lean persona document serves as:
+- A shared understanding of who we're building for
+- A hypothesis to validate (not a truth to assume)
+- A decision-making tool (does this feature help THIS user do THIS job?)
+- A validation roadmap (what do we test first?)
+
+## Your Task
+
+I'll create the final lean persona artifact using all the insights you've provided. But first, I need a few final pieces:
+
+### 1. Identify your 3 riskiest assumptions
+
+Look back at everything you've shared. What are the 3 things you THINK are true but haven't validated?
+
+Examples:
+- ASSUMPTION: "Users spend 5+ hours/week on status tracking"
+- ASSUMPTION: "Team members would consistently update status if it took <5 min/day"
+- ASSUMPTION: "Managers value confidence over detailed reporting"
+
+### 2. Design 3 validation experiments
+
+For each risky assumption, how will you test it?
+
+**Format for each:**
+- **Hypothesis:** If [assumption], then [observable behavior]
+- **Method:** How will you test it? (Interview? Survey? Prototype? Landing page?)
+- **Success criteria:** What would prove/disprove the hypothesis?
+- **Timeline:** When will you run this test?
+
+### 3. Decide: What will you do with the results?
+
+- If hypothesis is VALIDATED → What's next?
+- If hypothesis is INVALIDATED → Pivot or persevere?
+
+## Example
+
+**Riskiest Assumptions:**
+
+1. **ASSUMPTION:** Remote managers spend 5+ hours/week just tracking team status
+   - **Why risky:** If it's only 1-2 hours, solving this isn't high priority
+
+2. **ASSUMPTION:** Managers would pay $20/person/month to save 3+ hours/week
+   - **Why risky:** If they won't pay, we don't have a business model
+
+3. **ASSUMPTION:** Team members would update status if it's async and takes <5 min/day
+   - **Why risky:** If team won't engage, tool is useless
+
+**Validation Experiments:**
+
+**Experiment 1: Time Spent on Status**
+- **Hypothesis:** If remote managers truly spend 5+ hours/week on status, then when asked to track their time for one week, at least 70% will record 5+ hours
+- **Method:** Recruit 20 remote managers, ask them to log time spent on "status checking/reporting" for one week
+- **Success Criteria:** 14+ out of 20 (70%) log 5+ hours
+- **Timeline:** Week 1-2
+- **Decision:** If validated → proceed to experiment 2. If invalidated → re-examine problem priority
+
+**Experiment 2: Willingness to Pay**
+- **Hypothesis:** If managers value time savings, then at least 30% who see a "Save 3 hours/week for $20/person/month" landing page will give us their email
+- **Method:** Create landing page, run $500 Google Ads campaign targeting "remote team management"
+- **Success Criteria:** 30%+ conversion rate (email signup)
+- **Timeline:** Week 3-4
+- **Decision:** If validated → build prototype. If invalidated → re-examine pricing or value prop
+
+**Experiment 3: Team Engagement**
+- **Hypothesis:** If status updates take <5 minutes and are async, then at least 80% of team members will update weekly
+- **Method:** Create Google Form "status template," ask 3 pilot teams to use for 4 weeks
+- **Success Criteria:** 80%+ weekly participation rate
+- **Timeline:** Week 5-8
+- **Decision:** If validated → begin MVP development. If invalidated → explore automated status (no manual input required)
+
+---
+
+## Your Turn
+
+Please provide:
+1. Your 3 riskiest assumptions
+2. Your 3 validation experiments (using format above)
+3. Your decision criteria for each outcome
+
+## Final Step
+
+When you've provided this information, I'll:
+1. Generate your complete lean persona artifact
+2. Save it to `{output_folder}/lean-persona-{persona-name}-{date}.md`
+3. Create a validation tracking checklist
+4. Suggest next steps with Wade (lean-experiment workflow) to run your experiments
+
+**Remember:** This lean persona is a HYPOTHESIS until validated. Treat it as a bet, not a truth. Your job now is to test that bet as quickly and cheaply as possible.
+
+---
+
+## Workflow Complete
+
+After synthesis, your lean persona artifact will include:
+- Complete job-to-be-done analysis
+- Current solution pain points
+- Problem contexts and triggers
+- Forces and anxieties
+- Success criteria and metrics
+- Riskiest assumptions highlighted
+- Validation experiments ready to run
+- Revision history to track what you learn
+
+## Vortex Compass
+
+Based on what you just completed, here are your evidence-driven options:
+
+| If you learned... | Consider next... | Agent | Why |
+|---|---|---|---|
+| Riskiest assumptions identified | lean-experiment | Wade 🧪 | Test your riskiest assumption with real users |
+| User needs unclear | user-interview | Isla 🔍 | Validate persona assumptions with actual users |
+| Multiple user segments | empathy-map | Isla 🔍 | Build deeper understanding of each segment |
+
+> **Note:** These are evidence-based recommendations. You can navigate to any Vortex agent
+> at any time based on your judgment.
+
+**Or run Max's [VN] Vortex Navigation** for a full gap analysis across all streams.

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

@@ -0,0 +1,30 @@
+# Validate Lean Persona
+
+**Status:** Coming in v1.2.0
+
+**Agent:** Emma (Contextualization Expert)
+
+**Stream:** Contextualize
+
+## Overview
+
+This validation workflow helps you review lean personas against Lean Startup principles and ensure they're hypothesis-driven rather than assumption-based.
+
+## What Gets Validated
+
+- Is the job-to-be-done clearly defined?
+- Are current pain points specific and measurable?
+- Are desired outcomes testable?
+- Are assumptions explicitly stated?
+- Is there a clear validation plan?
+- Does this avoid demographic stereotypes?
+
+## Coming in v1.2.0
+
+This validation workflow will be available alongside the lean-persona workflow in March 2026.
+
+## Questions?
+
+For questions or to request early access:
+- GitHub Issues: https://github.com/amalik/convoke-agents/issues
+- Tag with: `workflow:lean-persona` and `v1.2.0`

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

@@ -0,0 +1,50 @@
+---
+workflow: lean-persona
+type: step-file
+description: Create lean user personas focused on jobs-to-be-done and problem contexts
+author: Emma (contextualization-expert)
+version: 1.2.0
+---
+
+# Create Lean Persona Workflow
+
+This workflow guides you through creating a lean user persona using Lean Startup principles.
+
+## What is a Lean Persona?
+
+A lean persona is a hypothesis-driven representation of your target user that focuses on jobs-to-be-done and problem contexts rather than demographics. Unlike traditional personas, lean personas:
+
+- **Focus on behavior, not demographics** - What they're trying to do, not who they are
+- **Are hypothesis-driven** - Every insight is an assumption until validated
+- **Link to validation** - Each assumption has a plan to test it
+- **Stay lean** - Only capture what's needed to make decisions
+
+## Workflow Structure
+
+**Step-file architecture:**
+- Just-in-time loading (each step loads only when needed)
+- Sequential enforcement (must complete step N before step N+1)
+- State tracking in frontmatter (progress preserved)
+
+## Steps Overview
+
+1. **Define Job-to-be-Done** - What is the user trying to accomplish?
+2. **Current Solution Analysis** - How do they solve this today? What are the pain points?
+3. **Problem Contexts** - When, where, and why does this problem occur?
+4. **Forces & Anxieties** - What pushes them to change? What holds them back?
+5. **Success Criteria** - What would a successful solution look like?
+6. **Synthesize** - Create the final lean persona artifact
+
+## Output
+
+**Artifact:** Lean persona markdown file in `{output_folder}/lean-persona-{persona-name}-{date}.md`
+
+**Template:** Uses [lean-persona.template.md](lean-persona.template.md)
+
+---
+
+## INITIALIZATION
+
+Load config from {project-root}/_bmad/bme/_vortex/config.yaml
+
+Load step: {project-root}/_bmad/bme/_vortex/workflows/lean-persona/steps/step-01-define-job.md