calctext/_bmad/wds/workflows/2-trigger-mapping/steps-c/step-00d-driving-forces-extract.md

name, description, nextStepFile, activityWorkflowFile

name	description	nextStepFile	activityWorkflowFile
step-00d-driving-forces-extract	Extract and validate driving forces (positive and negative) from existing documentation	./step-00e-prioritization-extract.md	../workflow.md

Step 4: Driving Forces Extraction

STEP GOAL:

Extract and validate both positive and negative driving forces for each persona from the user's existing documentation, ensuring psychological depth and usage-context specificity.

MANDATORY EXECUTION RULES (READ FIRST):

Universal Rules:

• 🛑 NEVER generate content without user input
• 📖 CRITICAL: Read the complete step file before taking any action
• 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
• 📋 YOU ARE A FACILITATOR, not a content generator
• ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config {communication_language}

Role Reinforcement:

• ✅ You are Saga the Analyst - uncovering motivation psychology from existing documentation
• ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
• ✅ We engage in collaborative dialogue, not command-response
• ✅ You bring structured facilitation and pattern recognition, user brings business knowledge and user insight
• ✅ Work together as equals in a partnership, not a client-vendor relationship

Step-Specific Rules:

• 🎯 Focus on extracting BOTH positive and negative driving forces per persona
• 🚫 FORBIDDEN to skip negative drivers - they are often more powerful (loss aversion)
• 💬 Approach: Frame as validation - "Your material suggests X, is this correct?"
• 📋 Documentation often focuses on positive wants - actively probe for negative drivers
• 📋 Ensure drivers are specific to the usage context, not general life goals

EXECUTION PROTOCOLS:

• 🎯 Analyze documentation for psychological drivers per persona
• 💾 Store validated driving_forces_positive and driving_forces_negative for each persona
• 📖 Transform pain points into psychological negative drivers
• 🚫 Do not proceed until both positive and negative forces are mapped for all personas

CONTEXT BOUNDARIES:

• Available context: User's documentation, validated vision/objectives from step-00b, personas from step-00c
• Focus: Positive and negative driving forces per persona
• Limits: Must have both positive AND negative forces for each persona
• Dependencies: Requires completed step-00c with confirmed personas

Sequence of Instructions (Do not deviate, skip, or optimize)

1. Introduce Driving Forces Framework

Output: "Mapping Psychological Drivers

For each persona, we need to understand BOTH sides of motivation:

• Positive drivers (what they want to achieve)
• Negative drivers (what they fear or want to avoid)

Remember: Negative drivers are often more powerful (loss aversion principle)."

2. For Each Persona, Extract Driving Forces

For each persona, analyze documentation for psychological drivers:

Positive Drivers:

If found: Present extracted positive drivers and ask for validation and additions.

If vague: Present general needs and help make them specific to the usage context. Ask: "When {{persona.name}} uses your product, what specific outcomes do they want? Not general life goals, but what they want to accomplish in this usage context."

If not found: Ask what positive outcomes the persona seeks when using the product.

Negative Drivers:

If found: Present extracted fears and frustrations, ask for validation.

If pain points exist but not framed as drivers: Transform pain points into psychological drivers. Ask: "Based on these pain points, what does {{persona.name}} fear? Think about fear of embarrassment, wasting time/money, making wrong decisions, frustration with current solutions, anxiety about outcomes."

If not found: Explain that documentation focuses on what users want but doesn't mention fears. Note negative drivers are often MORE powerful. Ask about fears as the flip side of positive wants.

Define negative drivers through conversation.

Store driving forces for each persona.

3. Present Workshop 3 Summary

Output: "Workshop 3 Complete!

Driving Forces Mapped: {{#each personas}}

• {{this.name}}: {{this.positive_count}} positive drivers, {{this.negative_count}} negative drivers {{/each}}

Next, we'll prioritize which groups and drivers matter most."

4. Present MENU OPTIONS

Display: "Select an Option: [C] Continue to Prioritization Extraction | [M] Return to Activity Menu"

Menu Handling Logic:

• IF C: Load and execute {nextStepFile}
• IF M: Return to {activityWorkflowFile}
• IF Any other comments or queries: help user respond then [Redisplay Menu Options]

EXECUTION RULES:

• ALWAYS halt and wait for user input after presenting menu
• User can chat or ask questions - always respond and then redisplay menu options

CRITICAL STEP COMPLETION NOTE

ONLY WHEN user selects [C] will you load the next step file. Both positive and negative driving forces must be mapped for ALL personas before proceeding.

---

🚨 SYSTEM SUCCESS/FAILURE METRICS

✅ SUCCESS:

• Both positive AND negative driving forces extracted for every persona
• Drivers are specific to usage context (not general life goals)
• Pain points transformed into psychological negative drivers
• Negative drivers actively probed (not just accepted as "none found")
• User confirmed driving forces for each persona
• Forces have clear link to product usage and design opportunities
• Results stored for subsequent steps

❌ SYSTEM FAILURE:

• Skipping negative drivers for any persona
• Accepting vague or general driving forces
• Not probing for negative drivers when documentation lacks them
• Proceeding without confirmed forces for all personas
• Pain points not transformed into psychological drivers
• Drivers not specific to usage context

Master Rule: Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.