Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

(WIP) Discovery Brief EXAMPLE

Example Feature “RouteWise Navigator”

 

Set basic document hygiene.

  • Use a problem-oriented codename (avoid solution bias).

  • Update Version every material edit (v0.x while in Discovery).

  • List Authors + Contributors for follow-ups.

Clear metadata lets stakeholders verify recency and ownership at a glance.

Date: May 12, 2025

Version: 0.2 (Discovery Phase)

Contributors: [Product Manager Name, Customer or Stakeholder Names]

The Problem & Our Current Understanding

What to write: One crisp problem statement (“who, what pain, why now”) supported by evidence (quotes, metrics, logs).
Why it matters: If the pain isn’t compelling, we stop here; the brief’s job is to prove the problem is real, urgent, and valuable.

The problem statement should evolve as you create this document and be a strong enough representation of the problem to stand on its own.

  • Problem Statement: Dispatchers at mid-sized courier companies (5-50 drivers) spend an average of 2-4 hours daily manually planning and adjusting routes for hundreds of daily shipments. This process is highly susceptible to human error, relies on tribal knowledge, and often results in suboptimal routes.

Target Users & Context

What: Primary persona profile + environment constraints (devices, regulations, chaos level, etc.)
Why: Grounds later UX/design choices and prevents ivory-tower assumptions. Must reflect insights from ≥ 5 user interviews to pass the gate.

  • Primary User: Dispatchers at mid-sized courier companies (5-50 drivers) primarily handling last-mile deliveries in urban/suburban environments.

    • Characteristics: Often multitasking, under time pressure, moderate tech-savviness (comfortable with web apps, but not power users of complex software), deep knowledge of their local area but struggle with systemic optimization.

    • Environment: Noisy, interruption-driven office; needs quick access to information and ability to make rapid adjustments.

What: 1–2 JTBD in first-person “When… I want… so that…”.
Why: Anchors scope; everything downstream must trace back to these jobs. (Include any secondary jobs in the Opportunity Canvas, not here.)

  • Current Pains & Impact:

    • Inefficiency: "It's a frantic puzzle every morning. I'm constantly juggling new orders, driver availability, and traffic, often redoing work." - Dispatcher, Alpha Couriers (Discovery Interview)

    • High Operational Costs: Leads to an estimated 15-25% excess mileage and fuel consumption, increased overtime pay for drivers due to inefficient sequencing, and higher vehicle maintenance.

    • Limited Scalability: Difficulty handling peak demand or business growth without hiring more dispatch staff, increasing overhead significantly.

    • Driver Frustration: Drivers experience uneven workloads, confusing route changes, and longer-than-necessary days, impacting morale and retention.

    • Customer Dissatisfaction: Inefficient routes can lead to missed delivery windows or delays, negatively impacting end-customer satisfaction.

What: How users hack around the problem today (sheets, sticky notes, side systems).
Why: Reveals MVP hooks and integration constraints; strong signal of unmet need.

  • Current Workarounds: Dispatchers use a combination of spreadsheets, Google Maps for individual routes, whiteboards, and constant phone calls/messaging with drivers. This lacks a centralized, optimized view.

What: Roles affected downstream and what they care about (KPIs, compliance, driver morale, etc.).
Why: Prevents blind-spots in launch communications and success metrics.

  • Secondary Stakeholders:

    • Operations Managers (concerned with costs, efficiency, KPIs)

    • Drivers (concerned with route clarity, workload, on-time performance)

Key Objectives & Success Metrics (FY2025 Q3-Q4)

 

What: 2–3 qualitative Objectives each with 1–3 quantifiable KRs (leading & lagging).
Verify metrics are measurable with existing telemetry or note the instrumentation plan.
Why: Defines “done” before solutioning and connects to product OKRs reviewed in quarterly business reviews.

  • Objective 1: Validate that RouteWise Navigator solves a critical planning pain point for dispatchers.

    • KR1: Achieve a Customer Satisfaction (CSAT) score of >75% from Beta users on "ease of planning" and "time saved."

    • KR2: Beta users successfully plan >80% of their daily routes using RouteWise Navigator within 4 weeks of adoption.

    • KR3: Gather qualitative feedback from at least 10 Beta dispatchers confirming the tool addresses their top 3 routing frustrations.

  • Objective 2: Demonstrate measurable efficiency gains for courier companies.

    • KR1 (Leading): Reduce average planning time per 100 shipments by 50% for Beta users (compared to their manual baseline) by end of Beta.

    • KR2 (Lagging, Post-Beta projection): Project a 10-15% reduction in reported mileage/fuel usage for routes planned with RouteWise Navigator, based on Beta customer data and simulations.

    • KR3 (Leading): Reduce the number of manual route adjustments needed post-initial plan by 30% for Beta users.

  • Objective 3: Prepare for successful market launch.

    • KR1: Secure 5 paid pilot customers by end of Q4 2025.

    • KR2: Define and validate core pricing model based on Beta feedback and value demonstrated.

Hypotheses & Assumptions

What: Primary opportunity hypothesis plus a bullet list of high-risk assumptions.
Why: Makes bets explicit; these drive the Validation Plan’s first experiments.

  • Opportunity Hypothesis: By providing an intelligent, automated route planning and optimization tool, we can significantly reduce the manual effort and cognitive load on dispatchers, enabling them to create more efficient routes faster. This will unlock direct cost savings, improve service reliability, and allow companies to scale operations more effectively.

  • Desired Future State for Dispatchers:

    • "I want to feel confident that my routes are the best possible, planned in minutes, not hours."

    • "I want to easily accommodate changes and see the impact immediately."

    • "I want the system to help me make smart decisions, so I can focus on exceptions and driver support."

  • Desired Business Impact: Reduced fuel & labor costs, increased delivery capacity with the same fleet, improved on-time delivery rates.

Key Risks & Assumptions

What: Top adoption, technical, data-quality, or commercial risks with one-line mitigations or spikes.
Why: Surfaces landmines early and lets leadership judge appetite for further spend.

  • Risk: Dispatchers may resist adopting a new tool if it doesn't seamlessly integrate with their existing (often informal) workflows or if they don't trust the "black box" of automation. (Mitigation: High-touch Beta, focus on explainability, allow manual overrides).

  • Risk: Variability in customer data quality (addresses, time windows) might hinder optimization effectiveness. (Mitigation: Define data requirements, build in validation/error handling).

  • Risk: Perceived complexity or steep learning curve. (Mitigation: Focus on intuitive UX, guided onboarding).

  • Assumption: Customers are willing to share operational data needed for optimization and to measure success.

  • Assumption: The core benefits (cost/time savings) are compelling enough to drive adoption and willingness to pay.

Discovery Partners & Interested Customers

What: Org names, contact(s), and current status (contacted / scheduled / LOI).
Why: Demonstrates a ready “lab” for interviews and Beta, boosting the Confidence score in WSJF-RICE.

  • Dropoff (Active discussions, expressed strong interest in reducing planning time - Rachael)

  • Capstone Logistics (Todd indicated pain with scaling current manual system)

  • Corporate Couriers - BC (Potential Beta, using interim solution now)

Validation Plan (Next 4-6 Weeks)

What: Table or bullets covering:

  1. Learning goals (which assumptions / unknowns).

  2. Activities (interviews, prototype tests, data pull).

  3. Success signals (pass/fail criteria).

  4. Owner & ETA for each activity.

Why: Turns the brief into action; progress here is how we raise Confidence ≥ 2, the exit requirement for the Discover stage.

  • Goal: Validate core problem, JTBD, and value proposition with target users. Test usability of low-fidelity prototypes.

  • Activities:

    • Conduct 5-7 additional in-depth interviews with dispatchers from "Interested Customers" list and new prospects, focusing on JTBD and current pain quantification.

    • Develop low-fidelity wireframes/clickable prototypes of the 3-step workflow.

    • Conduct usability testing sessions (5-8 users) with prototypes to assess clarity, ease of use, and identify friction points.

    • Survey Beta participants pre-Beta to establish baseline metrics for planning time and perceived efficiency.

  • Key Questions to Answer:

    • Do dispatchers agree with our articulation of their JTBD?

    • Which specific pain points are most severe and offer the biggest opportunity for improvement?

    • Is the proposed 3-step workflow conceptually understood and seen as helpful?

    • What are the minimum critical features needed for an MVP to test our core value hypothesis in Beta?