Point of View (POV) Questions

Purpose

Systematically explore multiple stakeholder perspectives on a validated need through structured questioning across five dimensions (WHO, WHAT, WHERE/WHEN, WHY, HOW), revealing alternative problem framings and avoiding premature convergence on single perspective. POV questions prevent "solutionitis"—jumping to solutions before fully understanding problem from diverse viewpoints.

Effective problem definition requires seeing need through multiple lenses: primary user, secondary stakeholders, different user types, organizational perspectives. POV questions provide comprehensive question framework ensuring no critical perspective overlooked.

When to Use:

• Multi-stakeholder problems (affects users, managers, operations, customers, partners)
• Before defining success criteria or boundaries—ensures framing informed by diverse perspectives
• Complex organizational contexts (B2B, healthcare, education) where multiple perspectives interact
• Risk of single-perspective bias (team has strong assumptions about problem framing)
• Need structured workshop activity for stakeholder alignment
• A1.2 discovery included diverse user types—need to synthesize perspectives

When NOT to Use:

• Single-stakeholder problems (consumer product for individual use)—perspective already clear
• Time-constrained projects (<1 week)—POV workshop takes 90-120 minutes
• Problem well-understood with clear framing—don't need exploration
• Team already aligned on perspective (rare, but if genuinely true, skip)

Prerequisites:

• Validated user need (A1.3 Step 1)—POV questions refine framing, not discover initial need
• A1.2 evidence base (interviews, observations)—answers to POV questions must be evidence-based
• Cross-functional workshop participants (diverse perspectives essential)
• 90-120 minutes workshop time
• POV questions worksheet (complete question set provided below)

Quality Criteria

1. Evidence-based answers: Responses cite A1.2 data, not speculation

2. Perspective diversity: Workshop surfaced multiple framings, not just one

3. Divergence acknowledged: If stakeholders frame problem differently, documented (not forced into false consensus)

4. Surprising insights: At least 2-3 answers challenged team assumptions (if everything confirmed existing beliefs, insufficient exploration)

5. Solution-generative: Selected framing suggests clear solution direction

6. Actionable specificity: Answers specific enough to inform design (not vague abstractions)

Complete Procedure

Preparation (Before Workshop)

1. Prepare POV Question Framework

Create six-question canvas (whiteboard or digital board):

2. Prepare Input Materials

• A1.2 validated need statement (1 page)
• User type segmentation (if completed in A1.2)
• Key evidence excerpts (5-10 compelling quotes/observations)
• Stakeholder list with roles

3. Schedule Workshop

• Duration: 2-3 hours
• Participants: 4-8 people (product, engineering, design, business, domain experts)
• Send pre-read 2-3 days before: A1.2 validated need statement and evidence summary

Workshop Execution

SECTION 1: Context Setting (15 minutes)

[0-5 min] Review validated need

Present A1.2 validated need statement and evidence snapshot. Brief recap assuming participants read pre-work.

[5-10 min] Introduce POV framework

Explain purpose: "Different stakeholders naturally frame problems differently. Before committing to single framing, we'll explore multiple perspectives using six POV dimensions—who, what, where, when, why, how. This prevents narrow framing and surfaces assumptions."

[10-15 min] Set workshop norms

• Divergent thinking: Generate multiple framings before converging
• Defer judgment: All perspectives valid during exploration
• Evidence-grounded: Frame based on A1.2 data, not speculation
• Challenge assumptions: Explicitly surface implicit beliefs about problem

SECTION 2: Explore Each POV Dimension (90 minutes—15 min per dimension)

For each of six dimensions (WHO, WHAT, WHERE, WHEN, WHY, HOW), follow structured exploration:

Process per dimension (15 minutes):

1. [0-3 min] Silent individual brainstorm itemize
2. Each participant writes responses to dimension questions on sticky notes
3. One response per note
4. Cite evidence where possible ("P03 said...") itemize
5. [3-10 min] Round-robin sharing and clustering itemize
6. Participants share notes, place on wall/board under dimension
7. Facilitator clusters similar responses
8. Note divergent perspectives—different stakeholders answering same question differently itemize
9. [10-15 min] Synthesis and insight capture itemize
10. Facilitator summarizes patterns: "We see three answers to 'who'—Type A users, Type B users, and downstream stakeholders"
11. Document divergent framings: "Engineering frames as technical obstacle, users frame as workflow obstacle"
12. Capture assumptions surfaced: "We're assuming need exists only in Context X—do we have evidence it occurs in Y?" itemize

Detailed guidance per dimension:

WHO Dimension (15 minutes)

Key questions to explore:

• Who experiences this need? (Primary users—from A1.2 segmentation)
• Who else is affected? (Secondary users, stakeholders, beneficiaries)
• Who defines success? (Whose criteria matter for validation?)
• Whose perspective dominates our framing? (Frame awareness)

Common insights:

• Multi-stakeholder revelation: Need affects more parties than initially recognized
• User type prioritization: Different user types experience need with different intensity—who do we design for first?
• Success authority: Users vs. managers may define "solved" differently

Example (Sales Forecast Confidence):

• WHO experiences: Sales managers (primary), individual sellers (secondary), VPs (tertiary)
• WHO affected: Revenue operations, finance (use forecasts), customers (impacted by sandbag behavior)
• WHO defines success: Managers (accuracy) vs. VPs (team confidence) vs. Finance (predictability)—divergent framings revealed

WHAT Dimension (15 minutes)

Key questions:

• What is user trying to accomplish? (Goal, not task)
• What obstacles prevent accomplishment? (Barriers)
• What does success look like? (Outcome definition—preview of success criteria)
• What is real need vs. stated request? (Distinguish symptoms from needs)

Common insights:

• Goal clarification: Users state tactical tasks but underlying goal is strategic outcome
• Multiple obstacles: Single need may have several barriers—which is root?
• Feature request vs. need: Users say "I want feature X" but underlying need is "accomplish Y"

Example:

• WHAT trying to do: "Assess deal close likelihood" (surface) vs. "Submit accurate forecast with confidence" (deeper goal)
• WHAT obstacles: Lack of data, lack of frameworks, lack of validation
• WHAT success looks like: Confidence (emotional), accuracy (functional), credibility with VP (social)

WHERE Dimension (15 minutes)

Key questions:

• Where does need arise? (Physical location, digital context)
• Where in workflow does obstacle occur? (Process stage)
• Where is need most intense? (High-impact contexts)
• Where does need NOT occur? (Negative space reveals boundary conditions)

Common insights:

• Context dependency: Need manifests differently across locations/platforms
• Workflow pinpointing: Clarifies exactly where intervention needed
• Negative space: Understanding where problem doesn't occur reveals causal factors

Example:

• WHERE arises: Weekly forecast prep (Sunday PM/Monday AM), CRM interface, manager's desk
• WHERE in workflow: Assessment stage (between data gathering and forecast submission)
• WHERE most intense: High-stakes deals, quarter-end, new managers
• WHERE NOT: When manager has multi-year relationship with client (past pattern predicts)

WHEN Dimension (15 minutes)

Key questions:

• When does need manifest? (Temporal patterns—time of day, week, quarter)
• When most acute? (Critical moments, peak intensity)
• When did need first arise? (Historical context—always existed or recent?)
• When will need change? (Future evolution, sustainability of solution)

Common insights:

• Temporal triggers: Identifies moments for intervention
• Historical evolution: Recent need suggests market/tech change, longstanding need suggests structural issue
• Future-proofing: Anticipates how need may evolve

Example:

• WHEN manifests: Sunday evening (prep), Monday morning (submission deadline), quarter-end (high stakes)
• WHEN acute: First forecast with new VP (credibility pressure), after several misses (loss of confidence)
• WHEN arose: Past 3-5 years as deal complexity increased, CRM didn't evolve
• WHEN changes: If market shifts to product-led growth (shorter cycles), need may diminish

WHY Dimension (15 minutes)

Key questions:

• Why does need exist? (Root cause hypothesis—preview of Step 3)
• Why does user care about solving? (Motivation—job security, performance, values)
• Why now? (Urgency, timing factors)
• Why hasn't been solved? (Barriers to past solutions)

Common insights:

• Multi-level causation: Proximate cause vs. deep root cause
• Motivation clarity: Functional need vs. emotional/social drivers
• Solution barriers: Understanding why past attempts failed informs design

Example:

• WHY exists: CRM lacks health indicators (proximate) → Org never defined "deal health" (deeper)
• WHY cares: Job performance (promotion), stress reduction (well-being), team credibility (social)
• WHY now: New VP demanding accuracy, competitors w/ better forecasting creating pressure
• WHY unsolved: Past solutions focused on aggregation not individual assessment

HOW Dimension (15 minutes)

Key questions:

• How do users currently cope? (Workarounds reveal need intensity)
• How would users know need is satisfied? (Success criteria)
• How does need vary across contexts? (Situational nuances)
• How might we reframe problem? (Alternative framings)

Common insights:

• Workaround sophistication: Elaborate workarounds signal high need intensity and provide solution design clues
• Success criteria preview: Begins defining validation criteria for Step 5
• Contextual variation: Reveals whether single solution viable or need context-specific approaches
• Reframing opportunities: "How might we" thinking begins solution-neutral problem reframing

Example:

• HOW cope: Manual tracking in spreadsheets (time-intensive), reliance on seller gut-feel (unreliable), conservative estimates (defensive sandbagging)
• HOW know satisfied: Can assess deal in 5 minutes with evidence, feel confident submitting forecast, VP validates accuracy over time
• HOW varies: Enterprise deals need different signals than SMB deals
• HOW reframe: "Forecast anxiety" → "Evidence-based deal assessment" (shifts from emotion to capability)

SECTION 3: Synthesis and Framing Options (30 minutes)

[105-120 min] Identify alternative framings

Review all six dimensions. Look for distinct ways to frame the problem based on different WHO, WHAT, WHERE emphases.

Framing exercise:

Create 2-4 alternative problem statements, each emphasizing different dimension or stakeholder perspective:

quote Framing 1 (User-centric): "Sales managers lack confidence in deal assessments because they rely on gut-feel without data-validated health signals"

Framing 2 (Process-centric): "Weekly forecast preparation lacks structured assessment framework, creating anxiety and defensive behavior"

Framing 3 (Organizational-centric): "Organization hasn't defined 'deal health,' leaving managers to invent individual assessment criteria"

Framing 4 (Outcome-centric): "Forecasts are inaccurate and managers are stressed because CRM shows deal stage but not closure probability" quote

[120-135 min] Evaluate framings

For each framing option, assess:

• Evidence alignment: How well does this framing match A1.2 data?
• Solution-generative: Does this framing suggest clear solution directions?
• Stakeholder resonance: Which stakeholders does this framing privilege? Do users/key stakeholders recognize themselves in this framing?
• Comprehensiveness: Does this capture full scope of need or narrow slice?
• Actionability: Can we address problem as framed within our capability?

[135-150 min] Select primary framing with rationale

Team consensus on primary framing for A1.3, documented with:

• Selected problem statement framing
• Rationale: Why this framing chosen (criteria assessment)
• Alternative framings considered: Document others explored (transparency)
• Assumptions to validate: Explicit list of assumptions embedded in chosen framing

[150-165 min] Draft initial problem statement

Using selected framing, draft initial problem statement following format:

quote [User type] struggle to [action] when [context] because [immediate obstacle], preventing [goal] and resulting in [consequences]. quote

This becomes input to A1.3 Step 3 (Root Cause Analysis).

Post-Workshop Documentation

Within 24 hours, document:

1. POV Canvas export: Photograph or export digital board showing all six dimensions
2. Framing options document (2-3 pages): itemize
3. Alternative framings explored (2-4 options)
4. Evaluation criteria and assessment
5. Selected framing with rationale
6. Assumptions embedded in selected framing itemize
7. Initial problem statement: 1-paragraph framing for Step 3
8. Open questions: Issues requiring further investigation

Quality Criteria

1. All six dimensions explored: Each POV dimension has documented responses

2. Evidence-grounded: Responses cite A1.2 data, not speculation

• ✗ Poor: "Users probably struggle because..."
• ✓ Good: "P03, P07, P11 reported struggling because..." [cited]

3. Divergent perspectives surfaced: Multiple stakeholder viewpoints documented, not single consensus

4. Alternative framings generated: At least 2-3 distinct problem framings explored

5. Framing selection justified: Chosen framing has explicit rationale based on criteria

6. Assumptions explicit: Embedded assumptions in chosen framing documented for validation

7. Actionable problem statement: Output framing suggests clear next steps for root cause analysis

Complete POV Question Set

Five dimensions with 25+ questions total. During workshop, don't attempt to answer all—select 12-15 most relevant.

WHO Questions (6 questions)

1. Who experiences this need most acutely?

• Purpose: Identify primary user type(s) for whom need is most intense or frequent
• Example answer: "Mid-level sales managers (7-25 reps)—more acute than VPs (delegated) or individual sellers (simpler deals)"

2. Who else is affected by this need, even if they don't directly experience it?

• Purpose: Identify secondary stakeholders, ripple effects
• Example: "Sales reps (affected by manager's forecast anxiety → micromanagement), Sales ops (must consolidate inaccurate forecasts), CFO (budgeting relies on forecasts)"

3. For whom is solving this need mission-critical vs. nice-to-have?

• Purpose: Distinguish core users from peripheral—who can't live without solution?
• Example: "Mission-critical for managers (performance evaluated on forecast accuracy); Nice-to-have for ops (affects their work but not primary pain point)"

4. Who benefits most if this need is addressed?

• Purpose: May differ from who experiences need—reveals value distribution
• Example: "Managers benefit (reduced anxiety), but CFO/leadership may benefit more (better planning, resource allocation)"

5. Who might resist solving this need, and why?

• Purpose: Identify stakeholders with conflicting interests or fears
• Example: "Sales reps resist if solution increases forecast visibility (fear increased accountability/micromanagement)"

6. Whose perspective have we NOT heard yet that we should?

• Purpose: Identify blind spots in A1.2 research
• Example: "Haven't interviewed sales ops who aggregate forecasts—they may have different view on problem causes"

WHAT Questions (6 questions)

7. What is the user fundamentally trying to accomplish? (Job-to-be-done)

• Purpose: Reframe need in terms of higher-order goal, not surface activity
• Example: Surface: "Prepare weekly forecast"; Higher-order: "Commit to achievable targets that preserve team morale and maintain leadership trust"

8. What does success/progress look like from the user's perspective?

• Purpose: Understand user's definition of progress, not team's assumptions
• Example: "Success isn't 100% accuracy (impossible), it's 'confidence I'm in the right ballpark and won't be blindsided'"

9. What prevents the user from accomplishing this today?

• Purpose: Identify obstacles—connects to root cause analysis (Step 3)
• Example: "Lack of structured signals, gut-feel unreliable, CRM shows activity not outcomes"

10. What workarounds or hacks do users employ to cope?

• Purpose: Workarounds reveal both problem severity and potential solution directions
• Example: "Manual spreadsheets tracking deal signals, Sunday night 'gut check' calls with reps, defensive sandbagging"

11. What does 'good enough' look like? (Not perfect—minimum viable success)

• Purpose: Set realistic success bar, avoid perfectionism
• Example: "Good enough = 80% confidence in quarterly number (±10%), not 100% deal-level precision"

12. What other jobs is this need related to or dependent on?

• Purpose: Understand need ecosystem—isolated or interconnected?
• Example: "Related to pipeline management job (earlier stage), performance review job (uses forecast accuracy), team coaching job (uses deal health for coaching moments)"

WHERE/WHEN Questions (6 questions)

13. Where (physically or digitally) does this need arise?

• Purpose: Understand context—informs solution delivery mechanism
• Example: "Desktop CRM at office desk (weekly prep), conference room (forecast review meeting), occasionally laptop at home (Sunday evening prep)"

14. When (frequency and timing) does this need occur?

• Purpose: Temporal pattern—constant, periodic, event-triggered?
• Example: "Weekly (Monday forecast call), heightened end-of-quarter, acute Sunday evening before Monday meeting"

15. Under what circumstances is this need most intense or urgent?

• Purpose: Identify peak need moments—may be highest-leverage intervention points
• Example: "Most intense: End-of-quarter (high stakes), After surprise deal losses (confidence shaken), New manager onboarding (inexperience)"

16. What triggers or precedes this need?

• Purpose: Understand causality and opportunity for proactive intervention
• Example: "Trigger: Monday morning forecast meeting reminder, Sales rep asks 'what should I forecast for deal X?'"

17. What contextual factors amplify or reduce need intensity?

• Purpose: Environmental moderators—when is need worse/better?
• Example: "Amplified by: Large deal uncertainty (>$100K deals), new products (no historical data), rep turnover. Reduced by: Stable deals with long history"

18. Are there negative cases—situations where need doesn't occur despite similar context?

• Purpose: Identify protective factors, edge cases, exceptions
• Example: "Managers with <5 deals don't experience anxiety (can track individually); Enterprise managers (>$1M deals) have analyst support"

WHY Questions (4 questions)

19. Why can't users accomplish this with existing tools/resources?

• Purpose: Understand capability gap—what's missing?
• Example: "Existing CRM shows activity (calls, emails) not outcomes (deal health), so can't assess risk from CRM data"

20. Why does this need exist at all? (Could situation be different?)

• Purpose: Question assumptions—is need inevitable or artifact of current system?
• Example: "Need exists because forecasting process demands precision CRM can't support. Alternative: Change process to tolerate uncertainty (but leadership unlikely to accept)"

21. Why hasn't this need been addressed already?

• Purpose: Understand barriers—technical, organizational, economic
• Example: "CRM vendors prioritize activity tracking (usage metrics) over outcome prediction (harder technically, less visible ROI)"

22. Why is this need more intense for some users than others?

• Purpose: Segmentation insight—user type differences
• Example: "More intense for: newer managers (lack pattern recognition), complex product sellers (more variables), managers with high rep turnover (less relationship continuity)"

HOW Questions (5 questions)

23. How would users know if this need was satisfied?

• Purpose: Success criteria from user perspective—observable indicators
• Example: "Would know satisfied if: Sleep better Sunday night, Spend <30min on forecast (not 2 hours), Forecast within 10% of actual 80%+ of time"

24. How do users currently cope or work around this need?

• Purpose: Overlap with Q10 but focuses on mechanisms, not just listing workarounds
• Example: "Cope by: Over-communicating with reps (daily check-ins), Manual spreadsheet tracking, Defensive sandbagging (psychological safety)"

25. How much time, effort, or cost does this need currently impose?

• Purpose: Quantify burden—informs value proposition
• Example: "Time: 2-3 hours/week per manager (120-150 hours/year), Stress: subjective but interferes with weekend, Opportunity cost: time not spent coaching reps"

26. How does addressing this need affect users' other goals or responsibilities?

• Purpose: Interconnections, potential trade-offs
• Example: "Addressing forecast confidence enables: More time for rep coaching (primary responsibility), Better pipeline management (related goal), Reduced Sunday work (work-life balance)"

27. How does this need create value beyond the immediate user?

• Purpose: Broader impact, organizational value, justifies investment
• Example: "Value beyond manager: Leadership better resource allocation (hiring, inventory), CFO improved financial planning, Sales ops reduced forecast consolidation effort"

Workshop Procedure

Preparation

1. Select 12-15 most relevant questions

Don't attempt all 27—overwhelming and many won't apply. Select based on:

• Problem complexity (complex problems need more questions)
• Stakeholder diversity (multi-stakeholder problems emphasize WHO questions)
• Uncertainty areas (if unclear WHERE/WHEN, prioritize those questions)

Create workshop worksheet with selected questions.

2. Prepare evidence packet

For each participant:

• Validated need statement
• A1.2 synthesis (key themes, quotes, user types)
• POV questions worksheet

Distribute 2-3 days prior for pre-reading.

Workshop Execution (90-120 minutes)

SECTION 1: Individual Reflection (20 minutes)

[0-5 min] Context review

Facilitator briefly recaps validated need and A1.2 key findings.

[5-25 min] Silent individual answering

Participants individually answer selected 12-15 questions on worksheet. Work silently—prevents groupthink, allows diverse perspectives to emerge.

Emphasize: Base answers on A1.2 evidence (quote interviews/observations), not assumptions.

SECTION 2: Round-Robin Sharing (40 minutes)

For each question, go around table:

• Each person shares their answer (1-2 min each)
• Facilitator captures on whiteboard/digital doc
• No debate yet—just collect perspectives

If 6 participants × 12 questions: can't do all (72 shares, too long). Instead:

• For each question, 2-3 volunteers share (not everyone)
• Facilitator asks "Anyone have substantially different answer?" (surface divergence)

SECTION 3: Pattern Identification and Frame Candidates (30 minutes)

[65-80 min] Identify recurring themes

Review collected answers. Look for:

• Divergent perspectives: Do different stakeholders frame problem differently? (E.g., managers see as confidence issue, reps see as pressure issue)
• Surprising insights: Answers that challenged team assumptions
• High-intensity moments: Contexts/circumstances where need peaks
• Hidden stakeholders: WHO questions revealed unrecognized affected parties

[80-95 min] Generate alternative problem framings

Based on patterns, create 2-4 alternative "Point of View" statements:

POV statement format: "[Stakeholder] needs [unexpected insight] because [surprising why]"

Example candidates from sales forecast case:

POV Candidate 1 (Manager lens): "Sales managers need confidence in forecast precision because their performance is judged on accuracy and current gut-feel approaches don't provide defendable rationale"

POV Candidate 2 (Organization lens): "Organizations need managers to reliably commit to achievable forecasts because downstream planning (hiring, inventory, investor guidance) depends on reliability, not just best-effort guesses"

POV Candidate 3 (Sales rep lens): "Sales reps need managers who forecast accurately because inaccurate forecasts → pressure and micromanagement → reduced autonomy and morale"

Each framing suggests different solution direction:

• POV 1 → Solution focuses on manager confidence (signals, validation)
• POV 2 → Solution focuses on organizational planning (reliability, commitment mechanisms)
• POV 3 → Solution focuses on team dynamics (transparency, autonomy preservation)

SECTION 4: Select Primary Framing (20 minutes)

[95-105 min] Evaluate framings

For each candidate POV, assess:

• Evidence strength: How well-supported by A1.2? (strong/moderate/weak)
• Solution-generative: Does this framing suggest clear solution direction?
• Strategic fit: Alignment with organizational priorities?
• Leverage: Addressing this framing → high impact?

[105-115 min] Vote and select

Dot voting or discussion to select:

• Primary framing: Will drive solution design (Step 5)
• Secondary framing: Consider as constraint or secondary success criteria

Example: Select POV 1 (manager confidence) as primary, acknowledge POV 2 (organizational planning) as success criteria—solution must provide manager confidence AND improve organizational forecast reliability.

Documentation

Create POV workshop summary (2-3 pages):

• Questions asked and answers collected
• Patterns identified
• Alternative framing candidates
• Selected primary framing with rationale
• How framing informs boundary definition and success criteria

Tools and Resources

POV Questions Worksheet:

• Template with selected 12-15 questions
• Answer space for each question
• Evidence citation field (interview/observation source)

Workshop materials:

• Printed worksheets (or digital Google Doc/Notion)
• Whiteboard or Miro board for capturing shared answers
• Sticky notes for pattern clustering

Sample Size / Duration

Participants: 5-8 people

• Cross-functional (product, design, engineering, business, operations)
• Include A1.2 researchers (evidence access)
• Include stakeholder representatives (if possible)—e.g., sales manager if building for sales

Duration:

• Pre-work: 30 minutes (review evidence packet)
• Workshop: 90-120 minutes
• Documentation: 1-2 hours
• Total: 3-4 hours (workshop facilitator)

Common Challenges and Solutions

Challenge 1: Answers devolve into solutioning

Symptoms:

• Answer format: "User needs [solution]" instead of "User needs [goal/outcome]"
• Example: "User needs better dashboard" (solution) vs. "User needs confidence through visible progress" (goal)

Solutions:

• Facilitator intervention: "That's a solution idea—but what underlying need does it address? What is user trying to accomplish?"
• Reframe questions: Instead of "What do users need?" ask "What are users trying to accomplish?"

Challenge 2: Groupthink—everyone agrees, no divergence

Symptoms:

• Round-robin sharing reveals identical answers
• No debate, no alternative perspectives
• Risk of confirmation bias

Solutions:

• Enforce silent individual phase (prevents early convergence)
• Devil's advocate: Assign someone to argue alternative framing
• Invite outsider: Include participant not involved in A1.2 (fresh perspective)

Challenge 3: Vague, abstract answers not grounded in evidence

Symptoms:

• Answer: "Users need better experience" (meaningless)
• No specificity, could apply to any problem
• No evidence citations

Solutions:

• Probe for specificity: "What specifically about experience? Give example from A1.2."
• Evidence requirement: "Which interview or observation supports this answer?"

Example: Sales Forecast Confidence (Selected Questions and Answers)

WHO Questions:

Q1: Who experiences most acutely?

• Answer: Mid-market B2B sales managers (7-25 reps)—more intense than VPs (delegate) or sellers (simpler deals)
• Evidence: A1.2: 12/15 mid-market managers reported anxiety; enterprise VPs said "my team handles details"

Q2: Who else affected?

• Answer: Sales reps (micromanagement from anxious manager), CFO (budget planning), Sales ops (consolidation effort)
• Evidence: Interview P03 (rep): "Manager checks in 3x/day when nervous about forecast"

WHAT Questions:

Q7: Fundamentally trying to accomplish?

• Answer: Commit to achievable forecast that maintains team trust and leadership confidence (not just "make accurate prediction")
• Evidence: Interview P05 (manager): "It's about credibility—if I miss forecast, team loses faith and VP questions my judgment"

Q11: What is "good enough"?

• Answer: ±10% quarterly accuracy, 80% confidence level—not perfection
• Evidence: Interview P08: "I don't need to be perfect, just consistently in the ballpark"

WHERE/WHEN Questions:

Q15: Most intense circumstances?

• Answer: (1) End-of-quarter (high stakes), (2) After recent miss (confidence shaken), (3) Large deal uncertainty (>$100K deals)
• Evidence: Interview P11: "End of Q, I'm a wreck"; Observation: P06 visibly anxious discussing $250K deal

WHY Questions:

Q19: Why can't accomplish with existing tools?

• Answer: CRM shows activity (calls, emails) not outcomes (deal health/risk)—can't assess probability from activity metrics
• Evidence: CRM screenshots: stage and amount only; Interview P09: "CRM tells me what happened, not what will happen"

HOW Questions:

Q23: How would users know satisfied?

• Answer: (1) Sleep better Sunday night, (2) Forecast prep <30min (not 2 hours), (3) Confidence defending forecast to VP, (4) Accuracy within 10% consistently
• Evidence: Interview P07: "Success is not dreading Monday morning forecast call"

Alternative Framings Generated:

POV 1 (Manager): Managers need confidence in deal assessments because current gut-feel can't be defended to leadership

POV 2 (Organization): Organization needs reliable forecasts because downstream planning depends on accuracy, not guesses

POV 3 (Rep): Reps need managers with forecast confidence because anxious managers micromanage

Selected: POV 1 (Manager lens)

Rationale: Strongest A1.2 evidence (all 15 managers described confidence issue), Solution-generative (confidence → signals, validation, data), Strategic fit (manager productivity priority)

POV 2 acknowledged as success criteria—solution must improve confidence AND organizational forecast reliability.

Point of View (POV) Questions method:pov-questions

Used in: • A1.3 Step 1 (Initial problem framing) ~ Related Activities: • A2 (Reframing during ideation) • Any activity requiring perspective exploration

Tools and Resources

Physical workshop:

• Large wall space or 6 poster boards (one per dimension)
• Sticky notes (single color for responses)
• Markers for facilitation annotations
• Camera for documentation

Digital workshop:

• Miro, Mural, or FigJam with six-section canvas
• Video conferencing for remote participants
• Collaborative editing enabled

Template downloads:

• POV Question Canvas (six dimensions with guiding questions)
• Framing evaluation rubric
• Problem statement template

Sample Size / Duration

Participants: 4-8 people

• Essential: Product owner, domain expert, A1.3 lead
• Recommended: Engineering lead, design lead, user researcher
• Optional: Business stakeholder, operations representative
• Avoid: >10 people (becomes unwieldy)

Duration:

• Workshop: 2.5-3 hours (15 min × 6 dimensions + 30 min synthesis)
• Pre-work: 30 minutes (reviewing A1.2 materials)
• Post-workshop documentation: 2-3 hours
• Total: 5-6 hours (primarily facilitator time)

Common Challenges and Solutions

Challenge 1: Convergence too early—team latches onto first framing

Symptoms:

• Discussion dominated by single perspective
• Alternative framings dismissed quickly
• Group consensus emerges in first 30 minutes

Solutions:

• Enforce divergent phase: Facilitator blocks convergence until all dimensions explored
• Devil's advocate: Assign someone to argue for alternative framings
• Silent brainstorm: Individual idea generation before group discussion prevents groupthink
• Mandatory alternatives: Require at least 3 framings before selecting

Challenge 2: Speculation replaces evidence

Symptoms:

• Responses based on assumptions ("users probably...")
• A1.2 data not referenced
• Framings reflect team preferences rather than user reality

Solutions:

• Evidence requirement: Each response must cite A1.2 source
• A1.2 materials visible: Display key quotes, user segments during workshop
• Flag speculation: Mark assumptions for validation, distinguish from evidence-based claims
• User researcher presence: Person with deepest A1.2 knowledge participates, corrects misinterpretations

Challenge 3: Too abstract—framings not actionable

Symptoms:

• Problem statements vague ("Users need better experience")
• No clear solution direction
• Selected framing too high-level to guide root cause analysis

Solutions:

• Specificity test: For each framing, ask "Can we design a solution from this?" If unclear, refine
• Concrete examples: Link framing to specific A1.2 examples—does framing explain observed behaviors?
• Actionability criterion: Add to evaluation rubric—score framings on actionability

Challenge 4: Stakeholder disagreement on framing

Symptoms:

• Engineering frames as technical problem, product frames as user experience problem
• Cannot reach consensus on single framing
• Different functions advocate for different framings

Solutions:

• Multi-framing approach: Explicitly acknowledge that problem has multiple valid framings—document all
• Primary + secondary: Select primary framing for A1.3 focus while acknowledging secondary framings as alternative lenses
• Framing hierarchy: Frame problem at multiple levels—tactical (execution), strategic (outcome), systemic (organizational)
• Defer resolution: If persistent disagreement, document divergence and let root cause analysis (Step 3) provide clarity

Example: Sales Forecast Confidence

Context: A1.2 validated that B2B sales managers struggle with forecast confidence

POV Exploration Results:

Alternative Framings Generated:

1. User-centric: "Sales managers lack confidence assessing deals because they rely on gut-feel without data validation"
2. Process-centric: "Weekly forecast preparation lacks structured assessment framework, creating anxiety"
3. Organizational: "Organization hasn't defined 'deal health,' leaving managers to invent criteria"
4. System-centric: "CRM shows stage not health, preventing evidence-based probability assessment"

Selected Framing: Organizational-system hybrid

Rationale:

• Evidence alignment: Strong—multiple interviews cited lack of standards
• Solution-generative: Yes—suggests defining health framework + surfacing indicators
• Stakeholder resonance: Users and managers recognized this immediately
• Comprehensiveness: Captures both organizational (no definition) and system (CRM limitations) dimensions
• Actionability: Within project scope—can define framework and build features

Initial Problem Statement:

"Mid-market B2B sales managers struggle to confidently assess which deals will close this quarter when preparing weekly forecasts 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, forecast anxiety, and defensive sandbagging."

This problem statement feeds into Step 3 (Root Cause Analysis) with clear direction for investigation.