Chapter 49: Dual-Track Discovery/Delivery

1. Executive Summary

Dual-track discovery/delivery separates continuous learning from production execution, enabling B2B IT services teams to validate assumptions before committing engineering resources. This operational model runs parallel streams: discovery focuses on de-risking through research, prototyping, and validation; delivery builds and ships validated solutions. For enterprise software organizations, dual-track prevents costly pivots, reduces time-to-value, and aligns cross-functional teams around evidence-based decisions. Organizations practicing dual-track see 40-60% fewer post-launch feature pivots, 30% faster time-to-market on validated concepts, and significantly higher customer satisfaction scores. The investment is minimal—primarily time allocation and process discipline—but the return manifests in reduced waste, higher confidence, and products that solve actual customer problems rather than assumed ones.

2. Definitions & Scope

Dual-Track Development: An operational framework where product teams run two parallel, interconnected work streams—discovery and delivery—with discovery always staying ahead to validate assumptions before delivery commits resources.

Discovery Track: The continuous process of identifying problems, understanding customer contexts, generating solution hypotheses, and validating assumptions through research, prototyping, and testing. Discovery output is validated learning, not production code.

Delivery Track: The engineering and design implementation of validated solutions. Delivery teams build, test, and ship production-ready features based on evidence from discovery.

Key Distinctions:

• Discovery explores "should we build this?" while delivery answers "how do we build this well?"
• Discovery embraces uncertainty and rapid iteration; delivery optimizes for quality and reliability
• Discovery involves lightweight prototypes and research; delivery produces production-grade systems
• Discovery timebox is days to weeks; delivery timebox is sprints to quarters

Scope: This chapter covers how B2B IT services organizations implement dual-track across product teams, integrate discovery with agile delivery, allocate resources, manage handoffs, and maintain continuous learning loops while shipping production software.

3. Customer Jobs & Pain Map

4. Framework / Model

The Dual-Track Model

The dual-track model operates as two synchronized conveyor belts moving at different speeds:

DISCOVERY TRACK (2-4 weeks ahead)
┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Opportunity│───▶│  Solution   │───▶│  Validation │───▶│  Readiness  │
│  Framing    │    │  Exploration│    │  Testing    │    │  Handoff    │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
      │                   │                   │                   │
      │ Customer          │ Prototypes        │ Test             │ Validated
      │ Interviews        │ Design Sprint     │ Results          │ Design +
      │ Data Analysis     │ Technical Spikes  │ Success Metrics  │ Acceptance
      │ Problem Framing   │ Alternatives      │ User Feedback    │ Criteria
      │                   │                   │                   │
      └───────────────────┴───────────────────┴───────────────────┘
                                 ▼
                         VALIDATION GATE
                                 ▼
DELIVERY TRACK (Production pace)
┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Backlog    │───▶│  Sprint     │───▶│  Release    │───▶│  Measure    │
│  Refinement │    │  Execution  │    │  Deploy     │    │  Learn      │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
      │                   │                   │                   │
      │ Story Writing     │ Development       │ Production Code  │ Analytics
      │ Estimation        │ Code Review       │ Monitoring       │ User Feedback
      │ Dependency        │ Testing           │ Documentation    │ Success Metrics
      │ Mapping           │ Integration       │ Release Notes    │ Iteration Input

Core Principles:

1. Lead Time Offset: Discovery stays 2-4 weeks ahead of delivery, creating a validated backlog buffer
2. Continuous Flow: Discovery never stops; as delivery ships, discovery explores next opportunities
3. Evidence-Based Gates: Solutions only move to delivery after passing validation criteria
4. Feedback Loops: Delivery metrics feed back into discovery to validate assumptions and surface new opportunities
5. Shared Ownership: Product managers, designers, and engineers participate in both tracks (different capacity allocation)

Resource Allocation (typical B2B product team):

• Product Manager: 60% discovery, 40% delivery
• Product Designer: 70% discovery, 30% delivery
• Engineering Lead: 20% discovery, 80% delivery
• Engineers: 10% discovery, 90% delivery
• Customer Success: 30% discovery participation (input/validation)

5. Implementation Playbook

0-30 Days: Foundation

Week 1-2: Establish the Model

• Define team structure: Identify core discovery team (PM, designer, 1-2 engineers) and delivery team (full engineering squad)
• Set discovery cadence: Schedule recurring discovery activities:
  • Weekly discovery sync (1 hour): Review learnings, plan experiments
  • Bi-weekly validation reviews: Share research findings with broader team
  • Monthly discovery retrospective: Assess what's working/not working
• Create validation criteria template: Define what "validated" means for your context:

  ## Discovery Validation Checklist
  - [ ] Problem validated with 5+ customers in target segment
  - [ ] Prototype tested with 3+ users showing 70%+ task success
  - [ ] Technical feasibility confirmed (spike completed)
  - [ ] Success metrics defined and measurable in production
  - [ ] Legal/compliance review completed (if applicable)
  - [ ] Business case validated (estimated ROI positive)
  - [ ] Accepted by delivery team (capacity, dependencies clear)
  

• Audit current backlog: Tag items as "validated" vs. "assumed" to baseline current state

Week 3-4: Run First Discovery Cycle

• Select initial opportunity: Choose a medium-sized feature currently in backlog (not trivial, not mission-critical)
• Frame the problem: Run problem framing workshop:
  • Who experiences this problem? (specific personas/roles)
  • What job are they trying to do? (JTBD framework)
  • What's broken about current state? (specific pain points)
  • What does success look like? (measurable outcomes)
• Conduct research: Schedule 5-8 customer interviews or usability tests
• Prototype rapidly: Create low-fidelity prototype (Figma, InVision, or coded clickthrough)
• Test and validate: Run validation sessions, gather evidence
• Document learnings: Create discovery brief with findings, decisions, open questions
• Hand off to delivery: Present validated solution in sprint planning with acceptance criteria

30-90 Days: Scale and Refine

Establish Pipeline Visibility

• Create discovery board: Parallel kanban board tracking discovery initiatives:

  Opportunity Backlog | Researching | Prototyping | Validating | Validated | Delivered
  

• Implement weekly discovery standups: Quick sync on what's being learned, blockers, next tests
• Build discovery repository: Centralized location (Confluence, Notion) for:
  • Research findings and interview notes
  • Prototype links and test results
  • Decision logs and rationale
  • Metrics definitions and success criteria

Integrate with Delivery Rituals

• Sprint planning enhancement: Discovery team previews validated items ready for pickup
• Backlog refinement: Discovery shares in-flight learnings to inform upcoming work
• Sprint review: Show discovery prototypes alongside shipped features
• Retrospectives: Assess discovery-delivery handoff quality

Build Discovery Muscle

• Train team on research methods: Workshops on interviewing, usability testing, data analysis
• Create research recruiting pipeline: Establish Beta/research program with willing customers
• Develop prototype templates: Reusable design system components for rapid prototyping
• Run technical spikes: Engineers explore feasibility on complex concepts before full design

Measure and Iterate

• Track dual-track health metrics (see Section 8)
• Retrospect on discovery process monthly
• Adjust lead time offset based on team velocity
• Refine validation criteria based on what actually predicts success

Common 30-90 Day Challenges:

• Discovery feels like overhead: Reframe as de-risking investment; track avoided waste
• Delivery outpaces discovery: Adjust capacity allocation or scope discovery narrower
• Unclear handoff points: Codify "definition of validated" and gate criteria
• Engineers resist discovery work: Start with technical spikes they value, expand gradually

6. Design & Engineering Guidance

For Product Designers

Discovery-Phase Design

• Prioritize speed over polish: Use low-fidelity wireframes, paper prototypes, or clickable mockups
• Design for learning, not production: Focus on testing specific hypotheses, not pixel-perfect UI
• Create assumption maps: Document what you're assuming vs. what needs validation
• Build prototype libraries: Maintain reusable component sets for rapid assembly
• Test early and often: 3-5 user tests can validate/invalidate most UX hypotheses

Discovery-to-Delivery Transition

• Refine validated designs: Bring prototypes to production quality only after validation
• Document design decisions: Capture rationale in design system or handoff docs
• Define edge cases: Discovery uncovers happy paths; delivery needs complete specifications
• Collaborate on implementation: Participate in sprint planning and provide real-time guidance

Example Design Spike (3-day cycle):

Day 1: Problem research + low-fi wireframes (5-8 screens)
Day 2: Clickable prototype in Figma/InVision
Day 3: 3-5 user tests, synthesis, decision documentation

For Engineering Teams

Discovery-Phase Engineering

• Run technical spikes: Time-boxed (2-4 hours) investigations to assess feasibility:

  # Example: Spike to test real-time sync feasibility
  # Goal: Can we sync 10k+ records with <200ms latency?
  
  import asyncio
  import time
  from websocket_client import WSClient
  
  async def test_bulk_sync(record_count=10000):
      """Spike: Test websocket sync performance"""
      start = time.time()
      client = WSClient('ws://staging.api.example.com/sync')
  
      # Simulate bulk record update
      await client.send({
          'action': 'bulk_update',
          'records': [{'id': i, 'status': 'updated'} for i in range(record_count)]
      })
  
      response = await client.receive()
      elapsed = (time.time() - start) * 1000
  
      print(f"Synced {record_count} records in {elapsed}ms")
      return elapsed < 200  # Success criteria
  
  # Result: 10k records = 450ms (FAIL)
  # Decision: Need different approach (batch chunking or polling)
  

• Prototype with throwaway code: Discovery code doesn't need production quality; prioritize speed
• Assess architecture implications: Will this solution create tech debt? What's the migration path?
• Identify integration risks: What systems are involved? What could break?

Delivery-Phase Engineering

• Expect validated inputs: Push back on unvalidated work entering delivery backlog
• Refine estimates with context: Discovery provides context that improves estimation accuracy
• Build for production quality: Unlike discovery, delivery code must meet all standards:
  • Test coverage (unit, integration, e2e)
  • Security review
  • Performance optimization
  • Observability (logging, monitoring)
  • Documentation
• Measure success criteria: Instrument code to track metrics defined in discovery

Discovery Participation Model:

• Engineering lead: Joins discovery meetings, reviews prototypes, runs complex spikes
• Engineers (rotating): 1-2 engineers participate in discovery each sprint (10% capacity)
• Full squad: Reviews discovery findings in sprint planning

7. Back-Office & Ops Integration

Dual-track isn't just for customer-facing products—back-office and operational tools benefit enormously from discovery.

Admin Tools & Internal Software

Why Discovery Matters: Internal users (CS agents, finance ops, IT admins) suffer from tools built on assumptions just like external customers. Their feedback is easier to access but often ignored.

Discovery Activities:

• Shadow internal users: Observe CS agents handling support tickets, finance processing invoices
• Run internal usability tests: Test admin UI prototypes with actual ops teams
• Analyze operational metrics: Where do workflows break down? What takes longest?
• Interview power users: Identify workarounds, pain points, feature gaps

Example: SaaS billing admin portal discovery

• Problem: Finance team manually reconciles 200+ invoices/month due to poor bulk editing
• Discovery: Shadowed finance team, identified 5 common bulk operations
• Prototype: Built clickable bulk-edit UI, tested with 3 finance users
• Validation: Reduced test task time by 60%, validated acceptance criteria
• Delivery: Shipped bulk edit feature, measured 70% reduction in manual reconciliation time

Customer Success & Support Tools

Discovery Integration:

• CS team as research partners: CS participates in discovery, shares customer insights
• Support ticket analysis: Mine support data for patterns indicating UX problems
• Beta program coordination: CS helps recruit research participants from customer base
• Feedback loops: CS validates whether shipped features actually solve reported problems

Validation Criteria for CS Tools:

• Time-to-resolution improvement
• Reduction in escalations
• Agent satisfaction scores
• Customer satisfaction post-interaction

DevOps & Platform Engineering

Discovery for Infrastructure:

• Developer experience research: Interview engineers using internal platforms
• Observability gap analysis: What's invisible that should be visible?
• Incident post-mortems: What tooling gaps contributed to incidents?
• Prototype developer portals: Test self-service flows before building

Example Discovery Question: "Should we build a multi-tenant deployment dashboard?"

• Research: Interview 8 engineers managing deployments
• Finding: Engineers use CLI 90% of time; dashboard only needed for stakeholder reporting
• Pivot: Build lightweight reporting API instead of full dashboard (80% less effort)

8. Metrics That Matter

Leading Indicators (measure these weekly):

• Number of customer conversations conducted
• Prototypes tested
• Validation experiments completed
• Technical spikes finished

Lagging Indicators (measure monthly/quarterly):

• Feature success rate
• Customer satisfaction with new features
• Engineering rework %
• Time-to-value improvement

Dashboard Example (weekly discovery health check):

┌─────────────────────────────────────────────────────┐
│ Discovery Pipeline Health - Week of Oct 5          │
├─────────────────────────────────────────────────────┤
│ Lead Time Offset:        3.2 weeks  ✓              │
│ Items in Discovery:      4 (optimal)                │
│ Validated this Week:     2 items                    │
│ Customer Interviews:     6 (target: 5+)  ✓         │
│ Prototypes Tested:       3                          │
│ Validation Pass Rate:    67% (target: 60-80%) ✓   │
│ Team Participation:      58% (target: 60%) ⚠       │
├─────────────────────────────────────────────────────┤
│ Action Needed: Increase eng participation in       │
│ discovery activities (only 2/6 engineers active)   │
└─────────────────────────────────────────────────────┘

9. AI Considerations

AI capabilities are transforming dual-track workflows, accelerating discovery and improving validation quality.

AI-Assisted Discovery

Research Synthesis

• Use case: Analyze customer interview transcripts, support tickets, sales calls
• Tools: GPT-4, Claude for qualitative data analysis
• Example prompt:

  Analyze these 8 customer interview transcripts and identify:
  1. Top 3 recurring pain points
  2. Jobs customers are trying to accomplish
  3. Workarounds they've created
  4. Suggested solution themes
  
  [Paste transcripts]
  

• Benefit: Hours of manual synthesis reduced to minutes; pattern recognition across large datasets

Prototype Generation

• Use case: Generate UI mockups, code prototypes, API designs from descriptions
• Tools: v0.dev, Cursor, GitHub Copilot
• Example: "Generate a React component for bulk invoice editing with select-all, filter, and batch update capabilities"
• Benefit: Faster prototype iteration, test more alternatives

User Research Planning

• Use case: Generate discussion guides, survey questions, usability test scripts
• Example prompt:

  Create a user interview discussion guide for:
  - Target: CFOs at mid-market SaaS companies
  - Topic: Financial reporting workflow pain points
  - Goal: Validate need for custom dashboard builder
  - Length: 30-minute interview
  

AI-Enhanced Validation

Sentiment Analysis

• Use case: Analyze user feedback, review comments, beta program feedback at scale
• Implementation: Process feedback through sentiment analysis API

  # Example: Analyze beta user feedback sentiment
  import openai
  
  def analyze_feedback_sentiment(feedback_list):
      prompt = f"""
      Analyze sentiment and extract key themes from this beta user feedback:
  
      {'\n'.join(feedback_list)}
  
      Provide:
      1. Overall sentiment score (1-10)
      2. Top 3 positive themes
      3. Top 3 negative themes
      4. Validation confidence (should we ship?)
      """
  
      response = openai.ChatCompletion.create(
          model="gpt-4",
          messages=[{"role": "user", "content": prompt}]
      )
      return response.choices[0].message.content
  

Predictive Analytics

• Use case: Predict feature adoption likelihood based on historical patterns
• Data inputs: Past feature characteristics, validation test results, customer segment data
• Output: Probability score that feature will meet adoption targets

Automated Usability Scoring

• Use case: AI-powered heatmap analysis, session recording insights
• Tools: FullStory, Hotjar with AI analysis layers
• Benefit: Identify usability issues in prototypes without manual review

AI Workflow Integration

Discovery-to-Delivery Handoff

• Use case: Auto-generate user stories from discovery documentation
• Example:

  # Discovery Brief → User Stories (AI-generated)
  
  Input: Discovery brief with problem statement, validation results, acceptance criteria
  Output: Formatted user stories ready for backlog
  
  Story 1:
  As a finance manager, I want to bulk-edit invoice statuses so that I can process month-end reconciliation in minutes instead of hours.
  
  Acceptance Criteria:
  - User can select multiple invoices via checkboxes
  - Bulk actions include: approve, reject, flag for review
  - Confirmation dialog prevents accidental actions
  - Action completes in <3 seconds for up to 500 invoices
  
  Technical Notes: [from discovery spike]
  - Use optimistic UI updates
  - Backend batch API endpoint required
  - Consider rate limiting for large batches
  

Risk: Over-reliance on AI can replace human customer empathy. Use AI to augment discovery, not replace customer conversations.

10. Risk & Anti-Patterns

Top 5 Risks & Anti-Patterns to Avoid

1. Discovery Theater

• What it is: Going through discovery motions without actually influencing decisions; discovery becomes a checkbox rather than true learning
• Symptoms: Teams "validate" solutions already built; discovery findings ignored if they conflict with stakeholder preferences; research participants cherry-picked to confirm biases
• Impact: Wasted discovery effort, false confidence, same problems as no discovery
• Mitigation: Establish clear kill criteria; celebrate killed ideas; measure how often discovery changes direction

2. Delivery Starvation

• What it is: Discovery consumes so much capacity that delivery slows to a crawl; validated backlog sits unbuilt
• Symptoms: Increasing gap between validated items and shipped features; sprint velocity declining; engineering team waiting for work
• Impact: Frustrated engineers, delayed value delivery, stakeholder loss of confidence
• Mitigation: Cap discovery at 20-30% of team capacity; maintain 1.5-2 sprint validated backlog buffer, no more

3. Perfection Paralysis

• What it is: Setting validation criteria so high that nothing ever moves to delivery; over-researching to eliminate all uncertainty
• Symptoms: Discovery items stuck in validation for weeks; endless testing cycles; "we need more data" syndrome
• Impact: Slow innovation velocity, missed market opportunities, competitor advantage
• Mitigation: Time-box discovery phases (max 3 weeks); accept 70-80% confidence threshold; embrace iterative learning post-launch

4. Handoff Hell

• What it is: Discovery and delivery operate as separate teams with poor communication; discoveries get "thrown over the wall"
• Symptoms: Engineers surprised by requirements; rework during development; "this isn't what we validated" conflicts; delivery team doesn't understand context
• Impact: Slow delivery, quality issues, team conflict, loss of discovery value
• Mitigation: Shared team ceremonies; engineers participate in discovery; discovery team available during delivery for questions

5. Enterprise Politics Override

• What it is: Executive mandates or sales commitments bypass discovery validation; HiPPO (highest paid person's opinion) trumps evidence
• Symptoms: "Strategic initiatives" skip validation; executive pet projects fast-tracked; sales contracts commit to unvalidated features
• Impact: Destroyed team morale, wasted engineering effort, products that don't solve real problems
• Mitigation: Create executive discovery review cadence; show cost of unvalidated work; negotiate "validation sprints" before commitment

Warning Signs Your Dual-Track Is Broken:

• Discovery findings don't change plans
• Team can't recall last killed idea
• Delivery team doesn't participate in discovery
• Validated backlog empty or overflowing (>3 sprints)
• Post-launch pivots exceeding 20%
• Engineers building without understanding "why"

11. Case Snapshot: Manufacturing SaaS Platform

Company: IndustryOps, a B2B SaaS platform for manufacturing operations management (500 enterprise customers, 50-person product/eng team)

Challenge: Product team shipped a major "Production Scheduler" feature after 6 months of development. Within 60 days, only 12% of customers adopted it, and those who did requested significant changes. Post-mortem revealed they built based on sales feedback and executive intuition, not customer validation. Engineering morale suffered as the team spent 4 months reworking a feature that should have been validated first.

Dual-Track Implementation:

Month 1-2: Foundation

• Formed core discovery team: 1 PM, 1 designer, 2 engineers (1 frontend, 1 backend)
• Allocated capacity: PM 60% discovery, Designer 70%, Engineers 20%
• Created validation criteria template requiring 5+ customer validations before delivery
• Selected medium-risk backlog item to pilot: "Inventory forecasting dashboard"

Month 2-3: First Discovery Cycle

• Problem framing: Interviewed 8 manufacturing ops managers about inventory challenges
• Key finding: Users didn't want forecasting algorithms (assumed need); they wanted visibility into current inventory across multiple locations with real-time alerts
• Prototype: Built Figma prototype in 3 days showing multi-location inventory view with configurable alerts
• Validation: Tested with 6 customers; 83% task success rate; strong positive feedback
• Pivot: Simplified scope from ML-powered forecasting to real-time visibility (60% less engineering effort)
• Handoff: Delivered validated design, technical spike on real-time data sync, clear acceptance criteria

Month 4-6: Scaling

• Established discovery pipeline: 4-5 opportunities in various stages at all times
• Discovery team stayed 3 weeks ahead of delivery
• Killed 2 features that failed validation (saving estimated 800 engineering hours)
• Shipped 4 validated features with average 52% adoption rate (vs. historical 18%)

Results (6 months post-implementation):

• Feature adoption rate: 18% → 52%
• Post-launch pivot rate: 35% → 8%
• Engineering rework hours: Reduced by 60%
• Customer satisfaction (NPS for new features): +12 points
• Team morale: Significantly improved (engineer quote: "We finally understand why we're building things")

Key Success Factor: Executive sponsor (VP Product) publicly celebrated killed features, reinforcing that discovery's job is learning, not confirmation. When discovery invalidated a CEO-requested feature, leadership supported the evidence-based decision.

Ongoing Practice: IndustryOps now runs quarterly "Discovery Showcases" where product teams present research findings, prototype tests, and validated roadmaps to company leadership, creating organizational alignment around evidence-based product development.

12. Checklist & Templates

Dual-Track Implementation Checklist

Setup (Week 1-2)

• Define discovery team roles and capacity allocation
• Schedule recurring discovery ceremonies (sync, reviews, retrospectives)
• Create validation criteria template for your context
• Establish discovery repository (Confluence/Notion)
• Set up discovery kanban board
• Audit current backlog for validation status
• Identify customer recruitment sources for research

Discovery Operations (Ongoing)

• Maintain 2-4 week lead time offset
• Run weekly discovery sync (review learnings, plan experiments)
• Conduct bi-weekly validation reviews with broader team
• Keep validated backlog at 1.5-2 sprint depth
• Document all discovery decisions and rationale
• Celebrate killed ideas (track avoided waste)

Per Discovery Item

• Frame problem with customer jobs/pains
• Define success metrics and validation criteria
• Conduct customer research (5+ interviews/tests)
• Create rapid prototype (low-fidelity acceptable)
• Validate with target users (3+ tests)
• Run technical feasibility spike
• Document findings in discovery brief
• Get delivery team acceptance before handoff
• Define instrumentation for post-launch measurement

Template: Discovery Brief

# Discovery Brief: [Feature Name]

## Opportunity
**Problem Statement**: [What customer problem are we solving?]
**Customer Job**: [What job is the customer trying to do?]
**Target Segment**: [Which customers experience this problem?]
**Strategic Alignment**: [How does this support business goals?]

## Research Conducted
- Customer interviews: [X interviews with Y personas]
- Usability tests: [X tests with Y participants]
- Data analysis: [Metrics/analytics reviewed]
- Competitive analysis: [If applicable]

## Key Findings
1. [Finding 1 with supporting evidence]
2. [Finding 2 with supporting evidence]
3. [Finding 3 with supporting evidence]

## Validated Solution
**Approach**: [Describe the validated solution]
**Prototype**: [Link to tested prototype]
**Test Results**: [Success rate, user feedback, sentiment]

## Success Metrics
- **Primary**: [Main metric to move, target]
- **Secondary**: [Supporting metrics]
- **Instrumentation**: [How we'll measure]

## Acceptance Criteria
- [ ] [User story 1 acceptance criteria]
- [ ] [User story 2 acceptance criteria]
- [ ] [Non-functional requirements]

## Technical Considerations
- **Feasibility**: [Spike results, technical approach]
- **Dependencies**: [Systems, teams, data needed]
- **Risks**: [Technical risks identified]

## Decision Log
- **Options Considered**: [Alternatives evaluated]
- **Decision**: [Chosen approach]
- **Rationale**: [Why this approach vs. alternatives]

## Open Questions
- [Question 1 - owner - target resolution date]
- [Question 2 - owner - target resolution date]

## Validation Checklist
- [ ] Problem validated with 5+ target customers
- [ ] Prototype tested with 3+ users (>70% success)
- [ ] Technical feasibility confirmed
- [ ] Success metrics defined and measurable
- [ ] Legal/compliance cleared (if needed)
- [ ] Business case positive (estimated ROI)
- [ ] Delivery team acceptance

**Status**: [Validated / Needs More Research / Killed]
**Next Steps**: [Handoff to delivery / Additional research needed]

Template: Validation Test Plan

# Validation Test Plan: [Feature Name]

## Test Objective
[What specific hypothesis are we testing?]

## Participants
- **Target**: [Persona/role, company size, segment]
- **Recruitment**: [How we'll recruit]
- **Number**: [X participants]
- **Incentive**: [If applicable]

## Test Method
- [ ] Moderated usability test
- [ ] Unmoderated remote test
- [ ] Customer interview
- [ ] A/B test
- [ ] Beta program
- [ ] Other: _______

## Test Materials
- Prototype: [Link]
- Discussion guide: [Link]
- Pre-test screener: [Link]

## Test Script
1. Introduction (2 min)
2. Context questions (5 min)
3. Task 1: [Specific task] - Success criteria: [X]
4. Task 2: [Specific task] - Success criteria: [Y]
5. Task 3: [Specific task] - Success criteria: [Z]
6. Debrief questions (5 min)

## Success Criteria
- **Validation threshold**: [E.g., 70% task success + positive sentiment]
- **Kill threshold**: [E.g., <40% task success or critical usability issues]

## Analysis Plan
- Task success rates
- Time on task
- Error rates
- User sentiment (qualitative)
- Key quotes/insights

## Timeline
- Recruitment: [Dates]
- Testing: [Dates]
- Analysis: [Dates]
- Readout: [Date]

Template: Discovery Retrospective

# Discovery Retrospective - [Date]

## What's Working Well?
- [Thing 1]
- [Thing 2]

## What's Not Working?
- [Challenge 1]
- [Challenge 2]

## Metrics Review
- Discovery lead time: [X weeks] (target: 2-4)
- Validation pass rate: [X%] (target: 60-80%)
- Discovery cycle time: [X days] (target: 10-20)
- Team participation: [X%] (target: 60%+)

## Decisions
- [Decision 1: What we'll change]
- [Decision 2: What we'll try]

## Action Items
- [ ] [Action 1 - owner - due date]
- [ ] [Action 2 - owner - due date]

13. Call to Action

Next 5 Days: Start Your Dual-Track Practice

Action 1: Assess Your Current State (Day 1)

Audit your product team's current practices:

• What % of shipped features had customer validation before development?
• How many features shipped in the last 6 months have <20% adoption?
• How much engineering time was spent on post-launch pivots/rework?
• Does your team have dedicated time for discovery, or is it squeezed between delivery?

Document the cost of unvalidated work in your organization. Calculate hours wasted on low-adoption features, post-launch rework, and customer escalations from poorly designed solutions. Present this to leadership as the business case for dual-track.

Action 2: Run Your First Discovery Spike (Days 2-4)

Choose one feature currently in your backlog (medium complexity, not mission-critical). Run a compressed 3-day discovery cycle:

• Day 2: Frame the problem. Interview 2-3 customers about the pain point. Document jobs-to-be-done and current workarounds.
• Day 3: Create a rapid prototype (Figma mockup, paper sketch, or simple coded demo). Focus on testing the core assumption, not building production quality.
• Day 4: Test with 3-5 users. Did it solve their problem? Would they use it? What's missing?

Synthesize findings and present to your team. Did discovery change your understanding? Would you build it differently now? Share learnings in your next sprint planning.

Action 3: Establish Discovery Discipline (Day 5)

Based on your spike learnings, formalize your dual-track approach:

• Define discovery team: Who plays which role? What's their capacity allocation?
• Set validation criteria: What evidence is required before moving to delivery? Write it down.
• Schedule recurring ceremonies: Weekly discovery sync, bi-weekly validation reviews.
• Create first discovery brief: Document your Day 2-4 spike using the template in Section 12.
• Communicate the change: Share dual-track model with stakeholders, engineering team, and leadership. Set expectations that discovery is now part of your product development process.

Commit publicly: In your next team meeting, state your commitment to evidence-based product development and invite the team to hold you accountable.

The shift from "building faster" to "learning before building" is the highest-leverage change a B2B product team can make. Start today.