dojo.md 0.1.0

package/courses/feature-request-handling/scenarios/level-2/feature-request-metrics.yaml

@@ -0,0 +1,66 @@
+meta:
+  id: feature-request-metrics
+  level: 2
+  course: feature-request-handling
+  type: output
+  description: "Set up metrics and tracking to measure the effectiveness of your feature request handling process"
+  tags: [feature-requests, metrics, tracking, process, intermediate]
+
+state: {}
+
+trigger: |
+  You're a PM at "ProjectPro" (project management tool, $25M ARR).
+  Your VP asks: "We handle hundreds of feature requests a month, but
+  we have no idea if we're doing a good job. What should we measure?"
+
+  Current state (no metrics):
+  - 300 feature requests filed monthly
+  - No tracking of request-to-ship time
+  - No measurement of customer satisfaction with request handling
+  - No way to know if shipped features were actually requested
+  - No connection between requests and retention/churn data
+
+  You pull some raw data:
+  - 3,200 total open feature requests
+  - Average request age: 14 months
+  - Last 10 shipped features: 6 were customer-requested, 4 were
+    internally-driven
+  - 200 requests were closed in the last quarter (40 shipped, 80
+    declined, 80 auto-closed as stale)
+  - Customer satisfaction with "how we handle feedback": 3.2/5
+
+  You know that the industry benchmark for customer-to-feature
+  influence rate is 40-60% (percentage of shipped features that
+  originated from customer requests).
+
+  Tasks:
+  1. Define 6-8 key metrics for the feature request process. For each
+     metric, specify: What it measures, how to calculate it, what a
+     good target is, and why it matters.
+
+  2. Looking at the raw data, what's the current health of the process?
+     What's working and what's broken?
+
+  3. The VP asks: "If we improve these metrics, does it actually
+     improve business outcomes?" How do you connect feature request
+     metrics to revenue, retention, and NPS?
+
+  4. Design a monthly dashboard that the VP can review in 5 minutes.
+
+assertions:
+  - type: llm_judge
+    criteria: "Metrics cover the full lifecycle — includes intake metrics (volume, categorization), processing metrics (time to triage, time to decision), outcome metrics (shipped rate, customer satisfaction), and business metrics (feature-influenced retention)"
+    weight: 0.25
+    description: "Full-lifecycle metrics"
+  - type: llm_judge
+    criteria: "Current state diagnosis is specific — identifies that 14-month average age and 3,200 open requests signal a broken process, and 60% customer-to-feature rate is acceptable but satisfaction is low"
+    weight: 0.25
+    description: "Specific current state diagnosis"
+  - type: llm_judge
+    criteria: "Business outcome connection is quantified — proposes tracking whether customers whose requests were shipped have higher retention than those whose requests were declined"
+    weight: 0.25
+    description: "Quantified business connection"
+  - type: llm_judge
+    criteria: "Dashboard is concise — proposes 4-6 key metrics on a single view that tells a story, not 20 charts that overwhelm"
+    weight: 0.25
+    description: "Concise dashboard design"

package/courses/feature-request-handling/scenarios/level-2/feature-request-shift-simulation.yaml

@@ -0,0 +1,80 @@
+meta:
+  id: feature-request-shift-simulation
+  level: 2
+  course: feature-request-handling
+  type: output
+  description: "Handle a realistic day of feature request triage with time pressure, competing priorities, and incomplete information"
+  tags: [feature-requests, simulation, triage, time-pressure, intermediate]
+
+state: {}
+
+trigger: |
+  You're the PM on feature request triage duty at "ShopFlow"
+  (e-commerce platform, 12,000 merchants). You have 4 hours this
+  morning to process the incoming request queue before sprint planning
+  at 1 PM. You need to triage each request and prepare your
+  recommendations.
+
+  Queue (18 requests in order received):
+
+  9:00 AM batch:
+  1. "Add Apple Pay support" — from 3 merchants this week
+  2. "Allow negative inventory (for pre-orders)" — from 1 merchant
+  3. "Multi-currency checkout" — from enterprise prospect ($100K/yr)
+  4. "Fix the search — searching for 'women's shoes' returns men's" —
+     sounds like a bug, filed as feature request
+
+  9:30 AM batch:
+  5. "Add a TikTok Shop integration" — from merchant and VP Sales
+  6. "Custom checkout fields (gift messages, etc.)" — from 8 merchants
+  7. "Our checkout page needs to be faster" — no specifics given
+  8. "Add product bundles" — from 12 merchants over past 3 months
+
+  10:00 AM batch:
+  9. "URGENT: We need volume discounts NOW" — angry merchant ($50K/yr)
+  10. "Add a customer loyalty program" — from small merchant ($1K/yr)
+  11. "Support for digital product delivery (e-books, courses)" — new
+      market segment, 5 requests this month
+  12. "Make the admin dashboard mobile-friendly" — from 6 merchants
+
+  10:30 AM batch:
+  13. "AI product descriptions" — CEO saw a competitor announce this
+  14. "Subscription/recurring billing" — from 4 merchants
+  15. "Better shipping rate calculator" — from 20+ merchants (top req)
+  16. "Integration with [obscure inventory tool]" — from 1 merchant
+  17. "Our customer wants to pay with cryptocurrency" — from 1 merchant
+  18. "URGENT: duplicate order bug — customer charged twice" — from
+      merchant with screenshot evidence
+
+  Tasks:
+  1. Triage all 18 items: For each, decide — feature request (prioritize
+     for sprint planning), bug (route to engineering), need more info
+     (what questions?), decline (not on strategy), or merge with
+     existing.
+
+  2. From the feature requests, pick your top 3 recommendations for
+     sprint planning. Justify with data from the queue.
+
+  3. Items #9 and #18 are marked URGENT. How do you handle each?
+     (One is genuinely urgent, one is customer frustration.)
+
+  4. You have 18 requests in 4 hours. What's your process for
+     efficient triage without sacrificing quality?
+
+assertions:
+  - type: llm_judge
+    criteria: "Bug vs feature distinction is correct — #4 (search returning wrong results) and #18 (duplicate charges) are routed to engineering as bugs, not kept in the feature queue"
+    weight: 0.25
+    description: "Correct bug routing"
+  - type: llm_judge
+    criteria: "URGENT handling differentiates — #18 (duplicate charges) is a genuine emergency requiring immediate engineering escalation, while #9 (volume discounts) is frustration, not urgency"
+    weight: 0.25
+    description: "Urgency differentiation"
+  - type: llm_judge
+    criteria: "Sprint recommendations are data-backed — top picks reference request volume (shipping calculator: 20+), revenue potential (multi-currency: $100K prospect), or market timing (TikTok Shop)"
+    weight: 0.25
+    description: "Data-backed sprint recommendations"
+  - type: llm_judge
+    criteria: "Triage process is time-efficient — proposes a quick-scan approach (categorize in 2 minutes each, deep-dive only on the top candidates) to handle 18 items in 4 hours"
+    weight: 0.25
+    description: "Efficient triage process"

package/courses/feature-request-handling/scenarios/level-2/internal-vs-external-requests.yaml

@@ -0,0 +1,69 @@
+meta:
+  id: internal-vs-external-requests
+  level: 2
+  course: feature-request-handling
+  type: output
+  description: "Navigate the tension between internal feature requests from leadership/engineering and external requests from customers"
+  tags: [feature-requests, internal, external, stakeholders, intermediate]
+
+state: {}
+
+trigger: |
+  You're a PM at "ReportHub" (business reporting SaaS, $20M ARR, 5,000
+  customers). Feature requests come from two very different sources,
+  and they frequently conflict.
+
+  External requests (from customers):
+  1. "We need better chart customization — colors, fonts, sizes" (320
+     requests, #1 most requested)
+  2. "Please add Salesforce integration" (180 requests)
+  3. "We need a mobile-friendly report viewer" (150 requests)
+
+  Internal requests (from your team):
+  4. CEO: "We need to add AI-generated insights. Every competitor is
+     talking about AI. This is existential." (No customer has asked
+     for this.)
+  5. CTO: "We need to migrate from our monolith to microservices.
+     It's slowing down all development." (Customers don't see this
+     directly.)
+  6. VP Sales: "We need a self-serve trial. I'm losing 40% of
+     prospects because they want to try before they buy." (Prospects
+     aren't customers yet, so this doesn't show in customer requests.)
+  7. Head of Design: "Our UI is from 2021. We need a full redesign.
+     It looks dated compared to competitors." (Some customers agree,
+     others say "don't change it.")
+
+  Budget for next 2 quarters: capacity for 4 major features.
+
+  Tasks:
+  1. Evaluate all 7 requests. Which 4 do you recommend for the next
+     2 quarters?
+
+  2. The CEO's AI request has zero customer demand but strong executive
+     conviction. How do you handle requests from powerful stakeholders
+     that don't align with customer data?
+
+  3. The CTO's microservices migration is invisible to customers but
+     would speed up all future development by 30%. How do you factor
+     infrastructure work into feature prioritization?
+
+  4. Design a process that gives both internal and external voices
+     appropriate weight without letting either dominate.
+
+assertions:
+  - type: llm_judge
+    criteria: "Selection balances internal and external — doesn't only pick customer-requested features (ignoring strategic needs) or only pick leadership requests (ignoring customers)"
+    weight: 0.25
+    description: "Balanced internal/external selection"
+  - type: llm_judge
+    criteria: "CEO AI request is handled diplomatically — doesn't dismiss it but proposes validating demand first (customer interviews, prototype, spike) before committing full resources"
+    weight: 0.25
+    description: "Diplomatic executive handling"
+  - type: llm_judge
+    criteria: "Infrastructure work is valued — recognizes microservices migration as a force multiplier that accelerates all future features, even though customers don't see it"
+    weight: 0.25
+    description: "Infrastructure value recognized"
+  - type: llm_judge
+    criteria: "Process design prevents loudest-voice-wins — proposes a framework where requests are evaluated on shared criteria regardless of source"
+    weight: 0.25
+    description: "Source-agnostic evaluation process"

package/courses/feature-request-handling/scenarios/level-2/kano-model-analysis.yaml

@@ -0,0 +1,92 @@
+meta:
+  id: kano-model-analysis
+  level: 2
+  course: feature-request-handling
+  type: output
+  description: "Apply the Kano model to categorize feature requests as basic needs, performance needs, or delighters to inform prioritization strategy"
+  tags: [feature-requests, Kano, satisfaction, categorization, intermediate]
+
+state: {}
+
+trigger: |
+  You're a product manager at "FitTrack" (fitness tracking app, 100,000
+  users). You've conducted a Kano survey where users rated how they'd
+  feel if a feature was present (functional question) and absent
+  (dysfunctional question).
+
+  The Kano model categories:
+  - Must-be (Basic): Expected. Absence = dissatisfaction. Presence ≠
+    satisfaction. (Like seatbelts in a car.)
+  - One-dimensional (Performance): More = better. Linear relationship
+    with satisfaction. (Like fuel efficiency.)
+  - Attractive (Delighter): Not expected. Presence = delight. Absence
+    ≠ dissatisfaction. (Like heated seats.)
+  - Indifferent: Users don't care either way.
+  - Reverse: Some users actively don't want this feature.
+
+  Survey results for 10 feature requests:
+
+  1. Crash fixes (app crashes 2x/week for 30% of users)
+     If present: Expected | If absent: Very frustrated
+
+  2. Faster sync speed (currently 15 seconds)
+     If present: Happy | If absent: Unhappy
+
+  3. Social workout challenges with friends
+     If present: Excited | If absent: Neutral
+
+  4. Apple Health / Google Fit integration
+     If present: Expected | If absent: Frustrated
+
+  5. AI-generated personalized workout plans
+     If present: Very excited | If absent: Neutral
+
+  6. Heart rate zone training alerts
+     If present: Happy | If absent: Slightly unhappy
+
+  7. Data export to CSV
+     If present: Neutral | If absent: Neutral
+
+  8. Gamification (badges, streaks, leaderboards)
+     If present: Mixed (some excited, some annoyed) | If absent: Neutral
+
+  9. GPS route tracking for outdoor runs
+     If present: Happy | If absent: Unhappy
+
+  10. Motivational push notifications
+      If present: Mixed (some like it, some find it annoying) |
+      If absent: Neutral
+
+  Tasks:
+  1. Classify each feature into a Kano category and explain your
+     reasoning.
+
+  2. Based on the Kano analysis, what's the optimal build order?
+     (Hint: Must-be first, then Performance, then Delighters)
+
+  3. Feature 8 (gamification) and Feature 10 (motivational notifications)
+     got "mixed" reactions — some users love them, others hate them.
+     How do you handle features that are Attractive for some users
+     but Reverse for others?
+
+  4. Feature 5 (AI workout plans) is a delighter today. But in 12
+     months, every competitor might have it. How does the Kano
+     category shift over time?
+
+assertions:
+  - type: llm_judge
+    criteria: "Classifications are correct — crash fixes and Apple Health are Must-be, sync speed and GPS are One-dimensional, AI workouts and social challenges are Attractive, CSV export is Indifferent"
+    weight: 0.25
+    description: "Correct Kano classifications"
+  - type: llm_judge
+    criteria: "Build order follows Kano logic — Must-be features (crash fixes, integration) come first because their absence causes dissatisfaction, even though they don't 'delight'"
+    weight: 0.25
+    description: "Kano-driven build order"
+  - type: llm_judge
+    criteria: "Mixed-reaction features get a nuanced approach — proposes making gamification optional/configurable or segment-targeted rather than forcing it on all users"
+    weight: 0.25
+    description: "Nuanced mixed-reaction handling"
+  - type: llm_judge
+    criteria: "Kano decay is explained — recognizes that today's Delighters become tomorrow's Must-be features as competitors adopt them and user expectations rise"
+    weight: 0.25
+    description: "Kano category decay understood"

package/courses/feature-request-handling/scenarios/level-2/rice-framework-application.yaml

@@ -0,0 +1,87 @@
+meta:
+  id: rice-framework-application
+  level: 2
+  course: feature-request-handling
+  type: output
+  description: "Apply the RICE prioritization framework to score and rank feature requests with quantified reach, impact, confidence, and effort"
+  tags: [feature-requests, RICE, prioritization, scoring, intermediate]
+
+state: {}
+
+trigger: |
+  You're a PM at "CloudDocs" (document collaboration SaaS, 20,000
+  users, $8M ARR). Your VP of Product has standardized on the RICE
+  framework for all prioritization decisions.
+
+  RICE scoring:
+  - Reach: How many users per quarter will this affect?
+  - Impact: How much will it move the needle? (3=Massive, 2=High,
+    1=Medium, 0.5=Low, 0.25=Minimal)
+  - Confidence: How sure are you? (100%=High, 80%=Medium, 50%=Low)
+  - Effort: Person-months to build
+  - Score = (Reach × Impact × Confidence) / Effort
+
+  Score these 8 feature requests:
+
+  Feature 1: Real-time co-editing
+  Data: Requested by 60% of users in last survey. Top reason prospects
+  don't convert. Would affect all 20,000 users. Effort: 6 person-months.
+  You're 80% confident it will significantly increase conversions.
+
+  Feature 2: Offline mode
+  Data: Requested by 2,000 users. Field workers who need docs without
+  internet. Effort: 4 person-months. You're 50% confident on the
+  technical approach.
+
+  Feature 3: Advanced permissions (role-based access)
+  Data: Required by 15 enterprise prospects worth $500K combined.
+  Affects ~3,000 enterprise users. Effort: 3 person-months. High
+  confidence (well-understood problem).
+
+  Feature 4: Template gallery
+  Data: 8,000 users use templates monthly. Better gallery could
+  increase template usage by 30%. Effort: 1.5 person-months. High
+  confidence.
+
+  Feature 5: Version comparison (diff view)
+  Data: 5,000 users request this. Common in competitive products.
+  Effort: 2 person-months. Medium confidence (UI complexity unknown).
+
+  Feature 6: AI writing assistant
+  Data: 12,000 users would try it. Trending feature in market. Effort:
+  5 person-months. Low confidence (AI quality uncertain, competitive
+  landscape shifting).
+
+  Feature 7: Mobile app redesign
+  Data: 6,000 mobile users, 2.1 star rating on App Store. Effort:
+  4 person-months. High confidence (clear problems to fix).
+
+  Feature 8: Slack integration
+  Data: 4,000 users on Slack, reduces context switching. Effort:
+  1 person-month. High confidence (well-documented API).
+
+  Tasks:
+  1. Score all 8 features using RICE. Show your calculations.
+  2. Rank them by RICE score and recommend the top 3 for next quarter.
+  3. Feature 6 (AI assistant) scores poorly due to low confidence.
+     How do you handle a feature where the market is moving fast but
+     you're not confident in the approach?
+  4. What are RICE's limitations? When would you override the score?
+
+assertions:
+  - type: llm_judge
+    criteria: "RICE calculations are shown and consistent — each feature has explicit Reach, Impact, Confidence, Effort values with the formula applied correctly"
+    weight: 0.25
+    description: "Correct RICE calculations"
+  - type: llm_judge
+    criteria: "Slack integration scores well — high confidence, low effort (1 month), decent reach (4,000) makes it a high RICE-score quick win"
+    weight: 0.25
+    description: "Quick wins identified via RICE"
+  - type: llm_judge
+    criteria: "AI assistant strategy addresses low confidence — proposes a spike, prototype, or phased approach to increase confidence before committing full effort, rather than just deprioritizing it"
+    weight: 0.25
+    description: "Low-confidence feature strategy"
+  - type: llm_judge
+    criteria: "RICE limitations are identified — mentions that revenue impact, strategic importance, and competitive urgency aren't captured in standard RICE, and proposes when to override"
+    weight: 0.25
+    description: "RICE limitations identified"

package/courses/feature-request-handling/scenarios/level-2/saying-no-to-big-customers.yaml

@@ -0,0 +1,69 @@
+meta:
+  id: saying-no-to-big-customers
+  level: 2
+  course: feature-request-handling
+  type: output
+  description: "Navigate the difficult situation of declining feature requests from high-value enterprise customers without jeopardizing the relationship or contract"
+  tags: [feature-requests, enterprise, saying-no, relationship, intermediate]
+
+state: {}
+
+trigger: |
+  You're a PM at "SecureVault" (data security platform, $60M ARR).
+  Your top 3 customers each represent significant revenue and each
+  has a feature request that conflicts with your product strategy.
+
+  Customer 1: "GlobalBank" ($2M/year, 8% of ARR)
+  Request: "Build a custom on-premise deployment option. Our board
+  won't allow any data in the cloud."
+  Your strategy: Cloud-only SaaS. On-premise would require a separate
+  codebase, dedicated support, and 4-6 months of engineering.
+  Risk if you say no: They've started evaluating Competitor Z.
+
+  Customer 2: "HealthCo" ($1.5M/year, 6% of ARR)
+  Request: "Integrate with our proprietary legacy EHR system (no
+  public API, requires custom development)."
+  Your strategy: Standard integrations only. Custom integrations
+  would set a precedent and consume disproportionate resources.
+  Risk if you say no: Contract renewal in 90 days.
+
+  Customer 3: "RetailGiant" ($1M/year, 4% of ARR)
+  Request: "We want to white-label your platform and resell it to
+  our franchise network."
+  Your strategy: No reseller model. This would create channel conflict
+  and require a completely different pricing/support structure.
+  Risk if you say no: They represent a potential $5M expansion if
+  they deploy to franchises.
+
+  Tasks:
+  1. For each customer, analyze: Can you accommodate this request?
+     Should you? What are the true costs beyond engineering time?
+
+  2. Write the "no" communication for Customer 1 (GlobalBank). You're
+     declining their #1 request while they're evaluating a competitor.
+
+  3. Customer 2 (HealthCo) has a renewal in 90 days. How do you say
+     "no" to the integration while keeping the renewal on track?
+     What alternatives can you offer?
+
+  4. Customer 3 (RetailGiant) represents $5M in potential expansion.
+     At what point does the revenue opportunity justify changing your
+     product strategy? How do you evaluate this?
+
+assertions:
+  - type: llm_judge
+    criteria: "Cost analysis goes beyond engineering — identifies that on-premise would create ongoing operational burden, custom integration sets a precedent, and white-labeling creates channel conflict"
+    weight: 0.25
+    description: "Beyond-engineering cost analysis"
+  - type: llm_judge
+    criteria: "GlobalBank response is firm but relationship-preserving — doesn't promise on-premise but offers alternatives (private cloud, dedicated tenant, compliance certifications) that address the underlying need"
+    weight: 0.25
+    description: "Firm but relationship-preserving"
+  - type: llm_judge
+    criteria: "HealthCo renewal strategy is proactive — proposes a conversation about what IS on the roadmap, explores workarounds (middleware, API development partnership), and addresses the renewal timeline directly"
+    weight: 0.25
+    description: "Proactive renewal strategy"
+  - type: llm_judge
+    criteria: "RetailGiant evaluation has a framework — proposes criteria for when revenue opportunity justifies strategy change (e.g., minimum commitment, market validation, alignment with long-term vision)"
+    weight: 0.25
+    description: "Strategy-change evaluation framework"

package/courses/feature-request-handling/scenarios/level-3/advanced-prioritization-shift.yaml

@@ -0,0 +1,71 @@
+meta:
+  id: advanced-prioritization-shift
+  level: 3
+  course: feature-request-handling
+  type: output
+  description: "Handle an advanced feature prioritization shift where strategic context changes mid-cycle, requiring rapid reprioritization"
+  tags: [feature-requests, reprioritization, strategic-shift, advanced]
+
+state: {}
+
+trigger: |
+  You're a senior PM at "CloudCRM" ($90M ARR, 12,000 customers). It's
+  the start of Q2 and you've just finalized the quarterly roadmap.
+  Then everything changes in one week.
+
+  Your approved Q2 roadmap:
+  1. Advanced email sequences (customer requested, 8 weeks)
+  2. LinkedIn Sales Navigator integration (sales team, 4 weeks)
+  3. Custom reporting builder (enterprise, 6 weeks)
+  4. Performance optimization sprint (engineering, 2 weeks)
+
+  Week 1 changes:
+
+  Monday: A major competitor (30% market share) announces they're
+  being acquired by Microsoft. This will give them deep Office 365
+  integration. Your CTO says: "Our Office integration is basic. We
+  need to accelerate this or we'll lose customers."
+
+  Wednesday: Your largest customer ($3M/year, 8% of ARR) announces
+  they're evaluating alternatives because your API doesn't support
+  their new workflow requirements. Their contract renews in 90 days.
+
+  Thursday: Apple announces a new privacy feature in iOS that will
+  break email open tracking — the foundation of your email sequences
+  feature (roadmap item #1).
+
+  Friday: The CEO reads a Goldman Sachs report predicting that "AI
+  CRM" will be a $50B market by 2028. She says: "We need an AI
+  strategy. What can we ship in Q2?"
+
+  Tasks:
+  1. How do you triage these 4 disruptions? Which ones actually
+     require roadmap changes and which are noise?
+
+  2. Propose the revised Q2 roadmap. What stays, what goes, what's
+     new? Justify each change.
+
+  3. The team is demoralized — they just committed to a plan that's
+     now changing. How do you communicate the reprioritization without
+     creating a culture of "roadmaps don't matter"?
+
+  4. How do you prevent reactive planning from becoming the norm?
+     Design a framework for evaluating mid-cycle disruptions.
+
+assertions:
+  - type: llm_judge
+    criteria: "Triage separates signal from noise — the largest customer churn risk and Apple privacy change are concrete threats requiring action, while the competitor acquisition and CEO AI interest need evaluation before reacting"
+    weight: 0.25
+    description: "Signal vs noise triage"
+  - type: llm_judge
+    criteria: "Revised roadmap preserves some stability — doesn't throw out the entire plan but makes targeted swaps, keeping team morale and execution momentum"
+    weight: 0.25
+    description: "Stability-preserving revision"
+  - type: llm_judge
+    criteria: "Team communication validates the original plan — explains that the plan was right with the information available, and that adapting to new information is a strength, not a failure"
+    weight: 0.25
+    description: "Morale-preserving communication"
+  - type: llm_judge
+    criteria: "Mid-cycle evaluation framework has criteria — proposes a threshold for when disruptions warrant roadmap changes (e.g., revenue at risk, competitive threat level, irreversibility) vs when to stay the course"
+    weight: 0.25
+    description: "Disruption evaluation framework"

package/courses/feature-request-handling/scenarios/level-3/cross-functional-alignment.yaml

@@ -0,0 +1,74 @@
+meta:
+  id: cross-functional-alignment
+  level: 3
+  course: feature-request-handling
+  type: output
+  description: "Align product, engineering, sales, and customer success teams on feature priorities when each team has different objectives"
+  tags: [feature-requests, cross-functional, alignment, stakeholders, advanced]
+
+state: {}
+
+trigger: |
+  You're the VP of Product at "WorkflowPro" (workflow automation
+  platform, $80M ARR, 200 engineers, 5,000 customers). The quarterly
+  planning meeting is in one week, and every department has submitted
+  their feature priorities. They don't align.
+
+  Sales priorities (VP Sales: "Revenue is the only metric that matters"):
+  1. Salesforce CRM integration (would close $3M in pipeline)
+  2. Enterprise SSO (5 prospects require it for security compliance)
+  3. Custom reporting for executives (sales demo differentiator)
+
+  Customer Success priorities (VP CS: "Retention saves more than acquisition"):
+  1. Workflow templates library (would reduce onboarding time by 40%)
+  2. In-app guidance / tooltips (top support ticket driver)
+  3. Usage analytics dashboard (help CS identify at-risk accounts)
+
+  Engineering priorities (CTO: "We need to fix the foundation"):
+  1. API refactoring (current API limits integrations, blocks 3 features)
+  2. Performance optimization (dashboard load times increasing 10%/month)
+  3. Automated testing infrastructure (releases taking 3x longer)
+
+  Product priorities (you, based on customer research):
+  1. AI workflow builder (biggest market opportunity, $20M TAM)
+  2. Mobile app (fastest growing request, market shifting to mobile)
+  3. Marketplace for custom integrations (ecosystem play)
+
+  The CEO says: "I don't want politics. I want a plan that makes
+  everyone feel heard but prioritizes what matters most for the
+  business. You have 200 engineers and can do roughly 8 major features
+  this year."
+
+  Tasks:
+  1. Evaluate all 12 priorities: Score each on revenue impact, retention
+     impact, strategic importance, and feasibility. Produce a unified
+     ranking.
+
+  2. Select 8 features for the year. How do you ensure each department
+     sees their priorities represented without just picking 2 from each?
+
+  3. The CTO's infrastructure work (API refactoring, performance,
+     testing) is invisible to customers but enables future features.
+     How much capacity should you reserve for this? Justify to the CEO.
+
+  4. Write the all-hands communication that announces the plan. How
+     do you frame it so the Sales VP doesn't feel their priorities
+     were dismissed?
+
+assertions:
+  - type: llm_judge
+    criteria: "Unified ranking uses consistent criteria — all 12 features are scored on the same dimensions rather than each department's features being evaluated differently"
+    weight: 0.25
+    description: "Consistent cross-functional scoring"
+  - type: llm_judge
+    criteria: "Infrastructure gets dedicated capacity — proposes reserving 20-30% of engineering capacity for CTO's priorities (API, performance, testing) as enablers for everything else"
+    weight: 0.25
+    description: "Infrastructure capacity reserved"
+  - type: llm_judge
+    criteria: "Selection balances present and future — includes both immediate revenue drivers (Salesforce integration) and strategic investments (AI workflow builder), explaining the balance"
+    weight: 0.25
+    description: "Present vs future balanced"
+  - type: llm_judge
+    criteria: "Communication frames choices positively — explains what IS being built and why, not what was rejected, connecting each chosen feature to company goals"
+    weight: 0.25
+    description: "Positive framing communication"