Problem Definition Brief Template

Purpose

Synthesize all A1.3 outputs into comprehensive Problem Definition Brief (10-15 pages) that documents validated need, root causes, boundaries, success criteria, and stakeholder alignment—providing authoritative reference for downstream activities (A1.4, A2, A6-A7), governance decisions, and organizational knowledge management.

The Problem Definition Brief serves multiple audiences:

• A1.4/A2 teams: Complete problem context for exploration and ideation
• I2 Governance: Executive summary for approval decisions
• B5 Knowledge Mgmt: Organizational learning archive
• I1 Portfolio: Scope and resource tracking
• A6-A7 Validation: Success criteria reference for testing

Document Structure

Section 1: Executive Summary (1-2 pages)

Purpose: Standalone summary for executives and governance

Content:

• Problem Statement (1 paragraph): Precise need definition following format: "[User type] need to [goal] but experience [obstacle] because [root cause], resulting in [consequences]. This manifests in [context]."
• Root Cause Summary (3-4 sentences): Why need exists, supported by evidence
• Scope Boundaries (bullet list): itemize
• In-scope: [user types, functions, contexts, root causes addressed]
• Out-of-scope: [explicitly excluded elements]
• Expansion criteria: [triggers for future scope extension] itemize
• Top Success Criteria (3-5 criteria): How we'll know need is satisfied itemize
• Functional: [measurable task outcomes]
• Emotional: [user feelings/confidence]
• Social: [perception/trust/collaboration] itemize
• Recommendation: Advance to A1.4 (Need Exploration) OR Advance to A2 (Ideation) with rationale
• Key Assumptions: 2-3 most critical assumptions requiring validation

Section 2: A1.2 Validation Summary (1 page)

Purpose: Context from prior validation work

Content:

• Need prevalence: [percentage, user count, frequency]
• Need intensity: [severity assessment, workaround burden]
• User types identified: [2×2 segmentation or personas]
• A1.2 validation verdict: [advance decision basis]
• Research methods employed: [interviews (n=X), observations (n=Y), etc.]
• Key evidence: [3-5 compelling quotes or observed behaviors]

Section 3: Need Statement (1 page)

Purpose: Authoritative problem definition

Content:

• Standard Format Need Statement: quote [User type] need to [goal] but experience [obstacle] because [root cause], resulting in [consequences]. This manifests in [context]. quote
• Need Decomposition: itemize
• Who: [User type with characteristics]
• What (goal): [What user trying to accomplish]
• What (obstacle): [What prevents accomplishment]
• Why (root cause): [Underlying cause—elaborated in Section 4]
• Consequences: [Impact of unmet need—functional, emotional, social]
• Context: [Where, when, under what conditions need manifests] itemize
• Need Intensity Assessment: [High/Medium/Low with evidence]
• Need Urgency: [Time-sensitive factors, market/competitive pressure]

Section 4: Root Cause Analysis (2-3 pages)

Purpose: Document why need exists

Content:

• Root Cause Narrative (1-2 pages): Explanation of causal logic itemize
• Proximate symptoms: [Observable manifestations]
• Intermediate causes: [Contributing factors]
• Root cause(s): [Fundamental underlying cause(s)]
• Causal chain: [How proximate symptoms trace to root] itemize
• Root Cause Visual (diagram): Five Whys chain, How-Why Ladder, or Ishikawa diagram
• Supporting Evidence (bulleted list): itemize
• A1.2 quotes demonstrating causal links
• Observed behaviors showing symptoms
• Artifacts (screenshots, documents) revealing causes itemize
• Validation Notes: itemize
• Counterfactual test result: "If [root cause] eliminated, would need disappear? [Yes/No with reasoning]"
• Stakeholder validation: "[Expert names/roles] confirmed root cause aligns with their experience"
• Alternative causes considered: [Other causal hypotheses explored and why rejected/deprioritized] itemize
• Root Cause Categorization: itemize
• Addressable causes (in-scope): [2-4 high-leverage causes team can solve]
• Constraint causes (accept as given): [Causes outside control—regulatory, cultural, market]
• Deferred causes (future/parallel): [Addressable but lower priority or requires capabilities not yet developed] itemize

Section 5: Boundary Definition (1-2 pages)

Purpose: Define what's in-scope vs. out-of-scope

Content:

• Boundary Canvas Visual: Four-quadrant canvas showing boundaries
• Quadrant 1: User/Stakeholder Boundaries itemize
• In-scope user types: [Which user types from A1.2 segmentation]
• Out-of-scope user types: [Excluded user types with rationale]
• Expansion criteria: [Conditions for adding user types—e.g., "Add Type X when Y achieved"] itemize
• Quadrant 2: Functional Boundaries itemize
• In-scope functions: [Which workflow stages, job functions addressed]
• Out-of-scope functions: [Excluded functions with rationale]
• Expansion criteria: [Conditions for expanding functional scope] itemize
• Quadrant 3: Contextual Boundaries itemize
• In-scope contexts: [Temporal, environmental, circumstantial, social contexts]
• Out-of-scope contexts: [Excluded contexts with rationale]
• Expansion criteria: [Conditions for expanding contextual scope] itemize
• Quadrant 4: Root Cause Boundaries itemize
• Addressable causes (in-scope): [2-4 causes team will solve]
• Constraint causes: [Causes accepted as given]
• Deferred causes: [Causes for future/parallel efforts]
• Expansion criteria: [Conditions for addressing deferred causes] itemize
• Boundary Rationale (paragraph per quadrant): Why these boundaries chosen—strategic fit, feasibility, leverage, evidence
• Scope Coherence Statement (1 paragraph): How boundaries form coherent whole addressing validated need

Section 6: Success Criteria (1-2 pages)

Purpose: Define how we'll know need is satisfied

Content:

• Success Criteria Matrix: TABLE0
• Criterion Prioritization: itemize
• Must-have criteria: [Non-negotiable for need satisfaction]
• Nice-to-have criteria: [Enhance satisfaction but not essential] itemize
• Evidence Linkage (table or narrative): itemize
• For each criterion, cite A1.2 evidence showing users articulated this dimension
• Example: "FC1 traced to P03, P07, P11 quotes about needing [specific outcome]" itemize
• Measurement Methods Detail: itemize
• For each criterion, specify how measured in A6-A7
• Functional: [Task completion rates, time-to-task, accuracy metrics, observation protocols]
• Emotional: [Pre-post surveys, confidence scales, qualitative interviews, sentiment analysis]
• Social: [Stakeholder feedback, perception surveys, trust indicators, collaboration metrics] itemize
• Success Threshold Definition: itemize
• What constitutes "passing" validation? [X
• Minimum viable satisfaction: [Floor for advancement to A7 or launch] itemize

Section 7: Stakeholder Alignment (1 page)

Purpose: Document stakeholder engagement and consensus

Content:

• Stakeholder Map: List of all stakeholders involved in A1.3 itemize
• Product: [Names, roles]
• Engineering: [Names, roles]
• Design: [Names, roles]
• Business: [Names, roles]
• Domain experts: [Names, roles] itemize
• Workshop Participation Record: itemize
• Step 1 (POV Questions): [Attendees, date]
• Step 3 (Root Cause): [Attendees, date]
• Step 4 (Boundaries): [Attendees, date]
• Step 5 (Success Criteria): [Attendees, date] itemize
• Alignment Summary: itemize
• Consensus areas: [Problem framing, root causes, boundaries, criteria where strong agreement]
• Divergent views: [Areas where stakeholders disagreed, how resolved or documented]
• Unresolved questions: [Issues requiring further discussion or governance decision] itemize
• Approval Record: itemize
• Product owner approval: [Name, date, signature]
• Technical lead approval: [Name, date, signature]
• Business stakeholder approval: [Name, date, signature]
• Governance approval (if required): [Name, date, decision] itemize

Section 8: Assumptions and Open Questions (1 page)

Purpose: Explicit articulation of uncertainties

Content:

• Key Assumptions (numbered list): itemize
• Assumptions embedded in problem definition that require validation
• Format: "We assume [assumption]. Evidence: [supporting data]. Risk if false: [consequence]."
• Example: "We assume managers experience this need weekly (not monthly). Evidence: A1.2 diary studies showed weekly forecasting. Risk if false: Solution may be over-engineered for actual frequency." itemize
• Open Questions (numbered list): itemize
• Unanswered questions requiring investigation in A1.4, A2, or A6
• Format: "Q: [Question]? Impact: [Why this matters]. Next step: [How to resolve]."
• Example: "Q: Do enterprise VPs (>100 reps) experience similar need? Impact: Boundary expansion decision. Next step: Conduct 3-5 VP interviews in A1.4." itemize
• Conditions That Would Invalidate Problem Definition: itemize
• Explicit list of scenarios that would require returning to A1.2 or A1.3
• Example: "If A2 ideation reveals root cause is technically unaddressable, return to Step 3 to explore alternative causes"
• Example: "If A6 validation shows success criteria don't correlate with user satisfaction, revisit Step 5" itemize
• Dependencies and Constraints: itemize
• External dependencies: [Requires access to X data, collaboration with Y team]
• Resource constraints: [Budget, timeline, capability limitations acknowledged]
• Technical constraints: [Platform limitations, integration requirements] itemize

Supporting Materials (Appendices)

Include as appendices to main brief:

• Appendix A: A1.2 Research Summary (key quotes, observation highlights, user segmentation)
• Appendix B: Workshop Documentation (POV canvas export, boundary canvas export, success criteria workshop notes)
• Appendix C: Root Cause Analysis Visuals (full-size diagrams—Five Whys, How-Why Ladder, or Ishikawa)
• Appendix D: Evidence Compilation (interview transcript excerpts organized by theme, observation field notes excerpts)

Formatting and Presentation

Document formatting:

• 10-15 pages main body (not including appendices)
• Professional formatting: headers, footers, page numbers
• Table of contents with section links
• Executive summary as page 1 (can be extracted as standalone)
• Consistent terminology throughout (define terms in glossary if needed)

Visual design:

• Use diagrams, tables, and visual breakout boxes for key content
• Color-code: Addressable causes (green), constraints (red), deferred (yellow)
• Include photos of physical workshop artifacts if applicable
• Ensure all visuals are high-resolution and legible

Accessibility:

• PDF format for distribution and archiving
• Editable source (Word, Google Docs) stored in project repository
• Version control: Document version number and last updated date
• Change log if brief is revised post-initial publication

Distribution and Usage

Primary distribution:

• A1.4 Need Exploration team (if multi-dimensional analysis required)
• A2 Ideation team (if proceeding directly to solution generation)
• I2 Governance (for approval decisions)
• B5 Knowledge Management (archive for organizational learning)
• I1 Portfolio Management (scope and resource tracking)

Companion governance presentation:

Create 5-7 slide deck summarizing brief for governance review:

1. Slide 1: Problem statement + root cause (1-liner each)
2. Slide 2: A1.2 validation summary (prevalence, intensity, user types)
3. Slide 3: Root cause analysis (visual diagram + 3-sentence explanation)
4. Slide 4: Boundary definition (four-quadrant canvas)
5. Slide 5: Success criteria (top 5 criteria with measurement methods)
6. Slide 6: Recommendation + key assumptions
7. Slide 7: Next steps (A1.4 or A2) + resource requirements

Quality Checklist

Before finalizing Problem Definition Brief, verify:

• [] All 8 sections complete with required content
• [] Executive summary is standalone—can be read independently
• [] Evidence citations throughout—no unsupported claims
• [] Internal consistency—root causes, boundaries, success criteria align
• [] Visuals clear and high-resolution
• [] Stakeholder review completed—comments addressed
• [] Approvals obtained—signature or email confirmation
• [] Governance presentation prepared
• [] Brief archived in B5 Knowledge Management with metadata tags
• [] Distribution list identified and brief shared

Example: Sales Forecast Confidence Brief Outline

Executive Summary:

Problem Statement: Mid-market B2B sales managers (7-25 reps) need to assess which deals will close this quarter but experience forecast anxiety because the organization hasn't defined "deal health" and CRM systems show deal stage but not closure probability indicators, preventing evidence-based assessment and resulting in gut-feel predictions and defensive sandbagging. This manifests most acutely during Sunday evening/Monday morning weekly forecast preparation.

Root Cause: Organization lacks standardized deal health framework—no defined indicators of deal strength, risk factors, or closure probability markers—leaving managers to invent individual assessment criteria using gut-feel.

Boundaries: In-scope—mid-market managers, individual deal assessment, weekly forecast prep context, addressing "lack of health framework" and "CRM shows stage not health" root causes. Out-of-scope—enterprise VPs, forecast aggregation, in-meeting defense, mobile contexts.

Top Success Criteria: (FC1) Manager assesses deal closure probability within 5 minutes using evidence; (EC1) Manager feels confident submitting forecast; (SC1) VP validates manager's accuracy over time, building trust.

Recommendation: Advance to A2 Ideation. Root cause is clear, boundaries defined, success criteria established. No multi-dimensional exploration (A1.4) required.

[Remaining sections follow template structure above...]