dojo.md 0.1.0

package/courses/feature-request-handling/scenarios/level-1/prioritization-basics.yaml

@@ -0,0 +1,99 @@
+meta:
+  id: prioritization-basics
+  level: 1
+  course: feature-request-handling
+  type: output
+  description: "Learn basic feature prioritization using impact vs effort thinking and simple scoring methods"
+  tags: [feature-requests, prioritization, impact-effort, fundamentals]
+
+state: {}
+
+trigger: |
+  You're a junior PM at "HelpDesk Pro" (customer support tool, 3,000
+  customers). Your team has a sprint planning meeting tomorrow and
+  you need to recommend which features to build next quarter.
+
+  The engineering team has capacity for approximately 3 medium features
+  or 1 large + 2 small features per quarter.
+
+  Here are 8 feature requests, each with data:
+
+  Feature A: Canned response library
+  - Requested by: 340 customers (most-requested feature)
+  - Impact: Saves agents 15 min/day on average
+  - Effort: Small (2 weeks)
+  - Revenue impact: Reduces churn — most churned customers cite "too
+    slow to respond" as a reason
+
+  Feature B: AI-powered ticket routing
+  - Requested by: 45 customers (mostly enterprise)
+  - Impact: Reduces misrouted tickets by 60%
+  - Effort: Large (10 weeks)
+  - Revenue impact: Required by 3 enterprise prospects ($200K total)
+
+  Feature C: Customer satisfaction (CSAT) surveys
+  - Requested by: 180 customers
+  - Impact: Lets teams measure support quality
+  - Effort: Medium (5 weeks)
+  - Revenue impact: Table stakes — competitors all have it
+
+  Feature D: Dark mode
+  - Requested by: 520 customers (second most-requested)
+  - Impact: Cosmetic / quality of life
+  - Effort: Medium (4 weeks)
+  - Revenue impact: Minimal — unlikely to drive new sales or reduce
+    churn
+
+  Feature E: WhatsApp integration
+  - Requested by: 90 customers
+  - Impact: Opens new communication channel
+  - Effort: Medium (6 weeks)
+  - Revenue impact: Would unlock LATAM market ($500K opportunity)
+
+  Feature F: Reporting dashboard
+  - Requested by: 210 customers
+  - Impact: Lets managers track team performance
+  - Effort: Large (8 weeks)
+  - Revenue impact: Sells to managers (buying decision makers)
+
+  Feature G: Mobile app
+  - Requested by: 150 customers
+  - Impact: Agents can respond on the go
+  - Effort: Extra-large (16 weeks — not feasible this quarter)
+  - Revenue impact: High for field service companies
+
+  Feature H: Emoji reactions on tickets
+  - Requested by: 25 customers
+  - Impact: Minor quality of life
+  - Effort: Small (1 week)
+  - Revenue impact: None
+
+  Tasks:
+  1. Score each feature using a simple impact/effort framework. Show
+     your scoring and reasoning.
+
+  2. Recommend which features to build this quarter (remember: capacity
+     for ~3 medium or 1 large + 2 small). Justify your choices.
+
+  3. For the features NOT selected, write a one-sentence rationale for
+     why they didn't make the cut this quarter.
+
+  4. What additional data would you want before finalizing the decision?
+
+assertions:
+  - type: llm_judge
+    criteria: "Scoring uses multiple impact factors — considers request volume, revenue impact, competitive necessity, and effort, not just 'most requested wins'"
+    weight: 0.25
+    description: "Multi-factor scoring"
+  - type: llm_judge
+    criteria: "Feature A (canned responses) is highly ranked — high request volume, small effort, and direct churn reduction make it the best bang-for-buck"
+    weight: 0.25
+    description: "Quick wins identified"
+  - type: llm_judge
+    criteria: "Dark mode is deprioritized despite high request count — recognizes that request volume alone doesn't justify prioritization when revenue impact is minimal"
+    weight: 0.25
+    description: "Request volume isn't everything"
+  - type: llm_judge
+    criteria: "Additional data requests are smart — asks about churn correlation, customer segment breakdown, competitive timeline, or A/B testing feasibility"
+    weight: 0.25
+    description: "Smart data requests"

package/courses/feature-request-handling/scenarios/level-1/request-vs-need.yaml

@@ -0,0 +1,78 @@
+meta:
+  id: request-vs-need
+  level: 1
+  course: feature-request-handling
+  type: output
+  description: "Learn to distinguish between what customers ask for (the request) and what they actually need (the underlying problem)"
+  tags: [feature-requests, problem-discovery, user-needs, fundamentals]
+
+state: {}
+
+trigger: |
+  You're a product associate at "ShipTrack" (logistics management
+  platform, 1,500 customers). Your PM has taught you an important
+  principle: "Customers tell you solutions. Your job is to find the
+  problem."
+
+  Here are 5 customer requests. For each one, the customer is asking
+  for a specific solution, but there may be a deeper underlying need.
+
+  Request 1: "Add a button to export all shipment data to Excel."
+  Customer context: A logistics manager at a mid-size company. They
+  export data every Friday to create a weekly report for their boss.
+
+  Request 2: "Let me set up automatic email alerts when a shipment
+  is delayed by more than 2 hours."
+  Customer context: A customer support lead who gets complaints from
+  end-customers about late deliveries. They want to proactively reach
+  out before customers call in.
+
+  Request 3: "Can you make the dashboard load faster? It takes 10
+  seconds and I lose my train of thought."
+  Customer context: A dispatcher who checks the dashboard 50+ times
+  per day to monitor active shipments.
+
+  Request 4: "I want to be able to color-code my shipments by
+  customer."
+  Customer context: A small business owner who handles 5 major
+  customers and wants to quickly see which shipments belong to which
+  customer.
+
+  Request 5: "Please add integration with SAP."
+  Customer context: An enterprise operations director. Their company
+  uses SAP for everything. Currently, a team of 3 manually enters
+  ShipTrack data into SAP every day.
+
+  Tasks:
+
+  1. For each request, identify:
+     a) What the customer is asking for (the solution)
+     b) What problem they're actually trying to solve (the need)
+     c) Are there alternative solutions that might be better?
+
+  2. For Request 1, what questions would you ask the customer to
+     better understand their underlying need?
+
+  3. For Request 3, is this a feature request or a performance bug?
+     How would you categorize it?
+
+  4. Which of these 5 requests, once you understand the real need,
+     might be solved by an existing feature they don't know about?
+
+assertions:
+  - type: llm_judge
+    criteria: "Request 1 underlying need is identified — the need isn't Excel export but automated weekly reporting for their boss, which could be solved by a built-in report or scheduled email"
+    weight: 0.25
+    description: "Underlying need identified"
+  - type: llm_judge
+    criteria: "Alternative solutions are proposed — for Request 2, suggests a customer-facing tracking portal or automated SMS, not just email alerts; for Request 4, suggests filtering or grouping views"
+    weight: 0.25
+    description: "Creative alternatives proposed"
+  - type: llm_judge
+    criteria: "Request 3 is correctly identified as a performance issue — recognizes that a 10-second load time for a frequently-used dashboard is a bug/performance issue, not a feature request"
+    weight: 0.25
+    description: "Performance issue identified"
+  - type: llm_judge
+    criteria: "Discovery questions go beyond the request — for Request 1, asks about what data they include in the report, who reads it, what decisions it drives, and how often they create it"
+    weight: 0.25
+    description: "Deep discovery questions"

package/courses/feature-request-handling/scenarios/level-1/roadmap-communication-basics.yaml

@@ -0,0 +1,70 @@
+meta:
+  id: roadmap-communication-basics
+  level: 1
+  course: feature-request-handling
+  type: output
+  description: "Learn how to communicate product roadmap decisions to customers who have submitted feature requests"
+  tags: [feature-requests, roadmap, communication, fundamentals]
+
+state: {}
+
+trigger: |
+  You're a customer success associate at "EventPro" (event management
+  SaaS, 4,000 customers). The product team just published the Q2
+  roadmap, and now you need to communicate with customers who submitted
+  feature requests.
+
+  Q2 Roadmap (what's being built):
+  - Virtual event hosting (new feature)
+  - Attendee check-in mobile app (new feature)
+  - Improved reporting dashboard (enhancement)
+
+  What's NOT on the Q2 roadmap (frequently requested):
+  - Multi-language support (requested by 200 customers)
+  - Custom registration forms (requested by 150 customers)
+  - Sponsor management module (requested by 80 customers)
+
+  What was just shipped (Q1):
+  - Stripe payment integration (requested by 300 customers)
+
+  You need to write 4 different communications:
+
+  1. "We built it!" message: Write to the 300 customers who requested
+     Stripe integration letting them know it shipped.
+
+  2. "It's coming!" message: Write to customers who'll benefit from
+     Q2 features (virtual events, check-in app, reporting).
+
+  3. "Not yet" message: Write to the 200 customers who requested
+     multi-language support. It's not on Q2 but the product team
+     acknowledges it's important.
+
+  4. "Roadmap update" post: Write a brief public blog-style roadmap
+     update announcing Q2 plans.
+
+  Tasks:
+  1. Write all 4 communications
+  2. For the "we built it" message, how do you encourage customers to
+     try the new feature?
+  3. For the "not yet" message, how do you maintain hope without
+     making promises?
+  4. For the public roadmap post, what level of specificity is
+     appropriate? (Exact dates? Quarters? Vague timelines?)
+
+assertions:
+  - type: llm_judge
+    criteria: "Shipped feature message celebrates and drives adoption — thanks customers for the feedback, announces the feature, includes a link or CTA to try it, and asks for feedback"
+    weight: 0.25
+    description: "Adoption-driving ship message"
+  - type: llm_judge
+    criteria: "Not-yet message maintains trust — acknowledges the request is important, doesn't promise a specific timeline, but signals it hasn't been forgotten"
+    weight: 0.25
+    description: "Trust-maintaining not-yet message"
+  - type: llm_judge
+    criteria: "Public roadmap avoids specific dates — uses quarters or 'coming soon' rather than exact dates, protecting the team from deadline pressure while giving customers direction"
+    weight: 0.25
+    description: "Appropriately vague public roadmap"
+  - type: llm_judge
+    criteria: "Communications are differentiated by audience — the individual customer messages are personal and specific, while the public post is broader and marketing-appropriate"
+    weight: 0.25
+    description: "Audience-appropriate tone"

package/courses/feature-request-handling/scenarios/level-1/saying-no-basics.yaml

@@ -0,0 +1,72 @@
+meta:
+  id: saying-no-basics
+  level: 1
+  course: feature-request-handling
+  type: output
+  description: "Learn how to decline feature requests gracefully without damaging customer relationships"
+  tags: [feature-requests, communication, saying-no, fundamentals]
+
+state: {}
+
+trigger: |
+  You're a customer success associate at "InvoiceFlow" (invoicing SaaS,
+  800 customers). Customers frequently request features that your
+  product team has decided not to build. Your job is to communicate
+  "no" in a way that's honest but doesn't make customers feel dismissed.
+
+  Scenario 1: Cryptocurrency payments
+  A customer asks: "When are you going to support Bitcoin payments?
+  It's 2026 — every payment platform should have this."
+  Product decision: Not on the roadmap. Crypto represents <1% of B2B
+  payments and adds significant compliance complexity.
+
+  Scenario 2: White-label option
+  A customer asks: "Can I remove your branding from the invoices and
+  add my own logo? I want it to look like my own platform."
+  Product decision: This has been requested 3 times in 2 years. The
+  engineering cost is 4 weeks. Not enough demand to justify it.
+
+  Scenario 3: Custom invoice templates with code
+  A developer customer asks: "I want to write custom HTML/CSS for my
+  invoice templates. Your template editor is too limiting."
+  Product decision: This conflicts with your product philosophy of
+  simplicity. You offer 20 templates. Custom code would create support
+  burden and security risks.
+
+  Scenario 4: Integration with obscure accounting software
+  A customer asks: "Do you integrate with 'LedgerPro'? It's what we
+  use and we can't switch."
+  Product decision: LedgerPro has 200 users worldwide. You support
+  QuickBooks, Xero, and FreshBooks. Building this integration isn't
+  viable.
+
+  Tasks:
+  1. Write a response to each of the 4 scenarios that declines the
+     request while maintaining the relationship.
+
+  2. For each response, identify what technique you're using:
+     - Redirecting to existing alternatives
+     - Explaining the "why" behind the decision
+     - Validating the need without promising the solution
+     - Offering a workaround
+
+  3. Which of these 4 requests, if any, deserve to be reconsidered?
+     What would change your mind?
+
+assertions:
+  - type: llm_judge
+    criteria: "Responses don't say 'never' — uses language like 'not currently on our roadmap' or 'not something we're planning right now' rather than permanently closing the door"
+    weight: 0.25
+    description: "Door left open"
+  - type: llm_judge
+    criteria: "Each response validates the customer's need — acknowledges why they want the feature before explaining why it's not being built"
+    weight: 0.25
+    description: "Need validated before declining"
+  - type: llm_judge
+    criteria: "Workarounds are offered where possible — for white-labeling suggests higher-tier plan or custom CSS, for LedgerPro suggests API or Zapier, for crypto suggests third-party processor"
+    weight: 0.25
+    description: "Workarounds offered"
+  - type: llm_judge
+    criteria: "Reconsideration criteria are specific — identifies that white-labeling could be reconsidered if demand increases or if it becomes a competitive differentiator"
+    weight: 0.25
+    description: "Specific reconsideration criteria"

package/courses/feature-request-handling/scenarios/level-2/b2b-enterprise-requests.yaml

@@ -0,0 +1,69 @@
+meta:
+  id: b2b-enterprise-requests
+  level: 2
+  course: feature-request-handling
+  type: output
+  description: "Handle feature requests from enterprise B2B customers where contract pressure, multi-stakeholder dynamics, and revenue concentration complicate prioritization"
+  tags: [feature-requests, B2B, enterprise, contracts, intermediate]
+
+state: {}
+
+trigger: |
+  You're a PM at "DataPipe" (data integration platform, $30M ARR, 200
+  customers). Your customer base is 70% enterprise ($100K+ contracts)
+  and 30% SMB ($5K-$20K contracts).
+
+  Three enterprise situations need your attention:
+
+  Situation 1: Contract-driven feature
+  MegaCorp ($800K/year, your largest customer) is negotiating renewal.
+  Their CISO demands: "We need FedRAMP certification and SOC 2 Type II
+  compliance reporting built into the platform by Q3, or we're moving
+  to Competitor X." Your compliance roadmap has this planned for Q4.
+
+  Situation 2: Multi-stakeholder conflict
+  TechGlobal ($300K/year) has submitted feature requests from 4
+  different departments:
+  - IT: "We need SSO with our custom SAML provider" (blocking rollout)
+  - Data Team: "We need real-time streaming, not just batch processing"
+  - Finance: "We need usage-based billing reports per department"
+  - VP Engineering: "We need a GraphQL API, your REST API is outdated"
+  All are marked "critical" by the account team.
+
+  Situation 3: Small customer, big feature
+  StartupCo ($8K/year) requests a feature that would benefit 50% of
+  your customer base: "We need a visual pipeline builder — dragging
+  and dropping instead of writing YAML configs." Your support data
+  shows YAML complexity is the #1 support ticket driver.
+
+  Tasks:
+  1. How do you handle MegaCorp's demand to accelerate compliance?
+     What are the risks of saying yes? Of saying no?
+
+  2. TechGlobal has 4 "critical" requests. How do you prioritize among
+     them? What questions do you ask the account team?
+
+  3. StartupCo's $8K contract doesn't justify a major feature. But the
+     request has broad appeal. How do you balance customer size vs.
+     request quality?
+
+  4. Design a policy for handling enterprise feature requests that
+     prevents the "biggest customer always wins" trap.
+
+assertions:
+  - type: llm_judge
+    criteria: "MegaCorp analysis weighs both sides — accelerating compliance has resource cost and opportunity cost, but losing $800K/year has direct revenue impact; presents a balanced risk assessment"
+    weight: 0.25
+    description: "Balanced enterprise risk assessment"
+  - type: llm_judge
+    criteria: "TechGlobal prioritization asks about blocking impact — identifies SSO as likely highest priority because it's blocking rollout (adoption at risk), then asks which other requests affect renewal"
+    weight: 0.25
+    description: "Blocking-impact prioritization"
+  - type: llm_judge
+    criteria: "StartupCo request is evaluated on merit, not contract size — recognizes that the visual pipeline builder serves the broader customer base and shouldn't be dismissed because the requester is small"
+    weight: 0.25
+    description: "Merit over contract size"
+  - type: llm_judge
+    criteria: "Enterprise policy includes guardrails — proposes limits on custom development, evaluation criteria beyond contract value, and a process that considers total customer base impact"
+    weight: 0.25
+    description: "Guardrail enterprise policy"

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

@@ -0,0 +1,77 @@
+meta:
+  id: backlog-grooming
+  level: 2
+  course: feature-request-handling
+  type: output
+  description: "Groom a messy feature request backlog — clean up stale requests, merge duplicates, and establish an ongoing grooming cadence"
+  tags: [feature-requests, backlog, grooming, maintenance, intermediate]
+
+state: {}
+
+trigger: |
+  You're a PM at "SurveyPro" (survey creation tool, 15,000 users).
+  You've inherited a feature request backlog that hasn't been groomed
+  in 18 months. It's a mess.
+
+  Backlog stats:
+  - 847 open feature requests
+  - Oldest request: 3 years ago ("Add Zapier integration")
+  - 120 requests have 0 votes and no comments
+  - 200+ requests are duplicates (estimated)
+  - 45 requests were for features that already shipped
+  - 30 requests are from customers who churned 12+ months ago
+  - 15 requests are actually bug reports miscategorized as features
+  - The top 3 requests by votes haven't changed in 2 years
+
+  Your VP says: "This backlog is useless. Nobody trusts it, nobody
+  looks at it, and customers think we ignore them because their
+  2-year-old requests are still 'under review.' Fix it."
+
+  Specific examples from the backlog:
+
+  Request #23 (3 years old, 450 votes): "Add logic branching to
+  surveys" — This was shipped 6 months ago but the request is still
+  open.
+
+  Request #156 (2 years old, 12 votes): "Support RTL languages"
+  — Requester churned 18 months ago. 3 other customers have since
+  requested this.
+
+  Request #389 (1 year old, 0 votes): "Let me upload custom fonts"
+  — No other customers have requested this. Zero engagement.
+
+  Request #502 (8 months old, 89 votes): "Offline survey mode"
+  Request #510 (8 months old, 67 votes): "Take surveys without internet"
+  Request #523 (7 months old, 34 votes): "Survey offline capability"
+  — Three separate requests for the same thing.
+
+  Tasks:
+  1. Design the backlog cleanup plan: What categories do you sort the
+     847 requests into? What are the rules for each category?
+
+  2. Handle each of the specific examples above. What do you do with
+     Requests #23, #156, #389, #502/510/523?
+
+  3. Should you consider "backlog bankruptcy" — closing everything and
+     starting fresh? What are the pros and cons?
+
+  4. Design the ongoing grooming process so this never happens again.
+     What cadence, criteria, and automations do you put in place?
+
+assertions:
+  - type: llm_judge
+    criteria: "Cleanup categories are actionable — proposes categories like 'Close: Already shipped', 'Close: Stale (no engagement)', 'Merge: Duplicates', 'Keep: Active demand', 'Reclassify: Bug reports'"
+    weight: 0.25
+    description: "Actionable cleanup categories"
+  - type: llm_judge
+    criteria: "Specific examples handled correctly — #23 is closed with 'shipped' notification to voters, #502/510/523 are merged into one canonical request, #389 is closed or archived"
+    weight: 0.25
+    description: "Correct example handling"
+  - type: llm_judge
+    criteria: "Backlog bankruptcy is considered seriously — weighs the benefit of a clean slate against the risk of losing customer trust and historical signal"
+    weight: 0.25
+    description: "Thoughtful bankruptcy consideration"
+  - type: llm_judge
+    criteria: "Ongoing grooming cadence is specific — proposes monthly or quarterly reviews with automated stale-request policies (e.g., auto-close after 12 months with no activity)"
+    weight: 0.25
+    description: "Specific grooming cadence"

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

@@ -0,0 +1,75 @@
+meta:
+  id: competitive-feature-requests
+  level: 2
+  course: feature-request-handling
+  type: output
+  description: "Handle feature requests driven by competitive pressure — when customers say 'Competitor X has this' — without falling into the feature parity trap"
+  tags: [feature-requests, competitive, strategy, feature-parity, intermediate]
+
+state: {}
+
+trigger: |
+  You're a PM at "MailPro" (email marketing platform, $15M ARR, 8,000
+  customers). Your main competitors are "MailRival" (market leader,
+  $200M ARR) and "MailNew" (fast-growing startup, $5M ARR).
+
+  This month, you've received several competitive feature requests:
+
+  Request 1: "MailRival just launched AI subject line generation. We
+  need this too or we'll lose customers."
+  — From VP Sales. MailRival announced this at their conference last
+  week. Your sales team is panicking.
+
+  Request 2: "MailNew has a drag-and-drop email builder that's way
+  better than yours. I'm considering switching."
+  — From a $5K/year customer. You checked: MailNew's builder IS nicer.
+  Your builder hasn't been updated in 2 years.
+
+  Request 3: "Both MailRival and MailNew have SMS marketing. You're
+  the only one without it. This is becoming a table-stakes feature."
+  — From 3 enterprise prospects during sales calls.
+
+  Request 4: "MailRival charges $500/month for what you charge $200.
+  Can you add their advanced analytics features so I don't have to
+  upgrade?"
+  — From a customer who wants premium features at your price point.
+
+  Request 5: "I read that MailNew is building a customer data platform
+  (CDP). Are you building one too?"
+  — From your biggest customer ($100K/year). MailNew hasn't even
+  shipped this yet — it's a blog post about their vision.
+
+  Tasks:
+  1. For each request, classify it:
+     - Table stakes (must have to compete)
+     - Competitive advantage (would differentiate us)
+     - Feature parity trap (copying for copying's sake)
+     - Irrelevant (not our strategic direction)
+
+  2. What's the right response to Request 1? The sales team is
+     panicking about AI subject lines. Is panic justified?
+
+  3. Request 2 (better email builder) and Request 3 (SMS marketing)
+     are both competitive gaps. You can only build one this quarter.
+     Which do you choose and why?
+
+  4. How do you respond to Request 5 (CDP that hasn't shipped yet)?
+     Your customer is worried about a vaporware feature.
+
+assertions:
+  - type: llm_judge
+    criteria: "Classifications avoid knee-jerk reactions — AI subject lines might be hype (not table stakes yet), SMS is becoming table stakes (3 prospects mentioned it), better builder is a real competitive gap"
+    weight: 0.25
+    description: "Thoughtful competitive classification"
+  - type: llm_judge
+    criteria: "Sales panic is managed rationally — acknowledges the concern but proposes evaluating actual customer demand for AI subject lines before panic-building, checking if any customers have actually churned for this reason"
+    weight: 0.25
+    description: "Rational sales panic management"
+  - type: llm_judge
+    criteria: "Builder vs SMS decision uses strategic criteria — considers whether the gap is losing current customers (builder) vs blocking new sales (SMS), and which aligns with product strategy"
+    weight: 0.25
+    description: "Strategic gap prioritization"
+  - type: llm_judge
+    criteria: "Vaporware response is calm and strategic — doesn't promise to match an unshipped feature, instead focuses on current strengths and what the customer can do today"
+    weight: 0.25
+    description: "Calm vaporware response"

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

@@ -0,0 +1,72 @@
+meta:
+  id: feature-request-interviews
+  level: 2
+  course: feature-request-handling
+  type: output
+  description: "Conduct customer interviews to dig deeper into feature requests and discover the real problem behind the asked-for solution"
+  tags: [feature-requests, interviews, discovery, user-research, intermediate]
+
+state: {}
+
+trigger: |
+  You're a PM at "BookingApp" (restaurant reservation platform, 3,000
+  restaurant customers). Your top feature request this quarter is:
+  "Add a waitlist feature" — 180 restaurants have asked for it.
+
+  But your VP of Product warns: "Don't build what they ask for. Dig
+  deeper. 'Waitlist' means different things to different restaurants."
+
+  She gives you 5 customer interviews to conduct. Here are the
+  restaurant profiles and their initial request:
+
+  Restaurant A (Fine dining, 80 seats): "We need a waitlist for walk-
+  ins. On Friday nights, we turn away 30-40 people because we're full."
+
+  Restaurant B (Fast casual, 120 seats): "We need a waitlist so
+  customers know how long they'll wait. They leave when the line
+  looks long."
+
+  Restaurant C (Popular brunch spot, 60 seats): "We need a waitlist
+  integrated with our reservations. No-shows leave empty tables while
+  walk-ins are waiting outside."
+
+  Restaurant D (Bar & grill, 200 seats): "We need a waitlist because
+  we want to stop taking reservations entirely. First come, first
+  served — but organized."
+
+  Restaurant E (Small café, 20 seats): "We don't need a waitlist
+  exactly, but we want to text customers when their table is ready
+  so they can browse nearby shops."
+
+  Tasks:
+  1. For each restaurant, write 3 discovery questions that dig into
+     their real problem (not their requested solution).
+
+  2. After the interviews, what do you learn? Are these all the same
+     feature, or different features with the same name?
+
+  3. If you can only build ONE version of the waitlist, what scope
+     would satisfy the most restaurants? What trade-offs does this
+     require?
+
+  4. Restaurant D wants to eliminate reservations entirely. Should you
+     accommodate this edge case, or is it outside your product vision
+     as a reservation platform?
+
+assertions:
+  - type: llm_judge
+    criteria: "Discovery questions probe the problem, not the solution — asks about the pain point (e.g., 'What happens when you turn people away?', 'How do you handle the situation today?') rather than 'What would the waitlist look like?'"
+    weight: 0.25
+    description: "Problem-focused discovery questions"
+  - type: llm_judge
+    criteria: "Analysis identifies distinct needs — recognizes that 'waitlist' means walk-in management (A), wait time estimation (B), no-show backfill (C), queue management (D), and notification system (E)"
+    weight: 0.25
+    description: "Distinct needs from same request"
+  - type: llm_judge
+    criteria: "MVP scope makes trade-offs explicit — proposes a core feature set that covers the most common need and clearly states what's excluded and why"
+    weight: 0.25
+    description: "Explicit MVP trade-offs"
+  - type: llm_judge
+    criteria: "Restaurant D edge case is thoughtfully handled — considers whether eliminating reservations conflicts with product vision, and proposes either accommodating it or explaining why it's out of scope"
+    weight: 0.25
+    description: "Edge case strategy"