Strategy · Innovation · Venture

The Architecture of Problem FormulationHow leading institutions decide what is worth solving

Execution answers "How do we build it?" Problem formulation decides whose condition should change, what evidence would count, which boundaries matter, and whether the opportunity deserves resources at all.

  • Research synthesis
  • Updated 6 August 2026
  • 18 min read

Decision architecture4 gates

  1. 01Reframe the objectiveright question
  2. 02Specify the unmet needclear outcome
  3. 03Structure the evidencetestable logic
  4. 04Screen the asymmetryworth the bet
Main conclusion

A strong problem statement is not a sentence-writing exercise. It is a compact governance system: it names the affected people, desired outcome, evidence, boundaries, assumptions, and reason to act: while keeping the solution open long enough to learn.

The upstream decision

Why formulation changes everything downstream

Teams rarely begin with a neutral description of reality. They begin with a frame: a choice about what to notice, whom to center, which cause to investigate, and what success should mean. That choice shapes the data collected, the specialists hired, the prototype built, and the risks ignored.

Thomas Wedell-Wedellsborg's 2017 Harvard Business Review article reported a survey of 106 C-suite executives from 91 organizations in 17 countries. In that sample, 85% agreed their organizations were poor at diagnosing problems, while 87% agreed that the weakness carried significant cost. The result is best read as an executive survey (not a universal failure rate) but it captures a familiar pattern: action begins before diagnosis stabilizes. Read the HBR source.

85% / 87% Agreed their organizations struggled with problem diagnosis / agreed the weakness imposed meaningful cost, within the reported executive sample.
Formulation is a commitment mechanism

Once a team funds analysis, assigns owners, or builds a prototype, the initial frame becomes harder to challenge. The least expensive time to test the frame is before those commitments accumulate.

Comparative map

Six paradigm families, six different optimization targets

These methods are not substitutes for one another. Each protects against a different failure mode: from designing around a fictional user to scaling a market that does not exist.

Human-centered

Needfinding

Turns observations and latent user tensions into an actionable design point of view.

User + Need + Insight → POV
Clinical need

Needs-driven innovation

Defines a measurable change for a specific population without embedding a mechanism.

Problem + Population + Outcome
Structured logic

Deductive framing

Disaggregates a decision into testable branches, priorities, analyses, and recommendations.

Define → Structure → Prioritize
Cognitive shift

Reframing

Challenges the first interpretation and searches for a more useful problem to solve.

Frame → Reframe → Move forward
Venture asymmetry

Growth screening

Tests whether the pain, market, insight, timing, and advantage could support rapid growth.

Problem + Solution + Insight
Whole-system

Systems thinking

Treats interacting problems, feedback, and trade-offs as a connected "mess," not isolated parts.

Parts × interactions × purpose

US academia

Stanford's two problem-first traditions

The d.school and Stanford Biodesign both separate discovery from solution generation, but they produce different artifacts. One is optimized for generative human-centered design; the other for disciplined health-technology needs selection.

Stanford d.school

Point of View

Discovery
USER + NEED + INSIGHT = POV

The d.school's method cards describe a POV as a reframed, actionable design challenge that can generate focused "How Might We" questions. The need should be expressed as a verb, and the insight should synthesize evidence rather than repeat an obvious fact.

  • Centers a specific user rather than a broad demographic
  • Captures functional and emotional need
  • Creates a shared filter for comparing ideas
  • Stays narrow enough to guide and open enough to inspire

Stanford d.school Method Cards (PDF)

Stanford Biodesign

Need Statement

Selection
A way to [address problem] in [population] in order to [achieve outcome]

Biodesign's Identify-Invent-Implement process begins with direct observation of care and the collection of unmet needs. Its formal statement makes the affected population and desired outcome explicit while withholding the technical mechanism.

  • Solution agnostic: describe what must change, not the device or software
  • Outcome focused: select one meaningful, preferably measurable benefit
  • Scoped population: identify the group with a compelling reason to change
  • Criteria before concepts: translate evidence into requirements before ideation

Stanford Biodesign Need Statements guide (PDF)

Same principle, different bar

A d.school POV is judged by human resonance and generative power. A Biodesign need statement must also survive clinical, stakeholder, adoption, economic, regulatory, and evidence constraints. Stanford's process explicitly filters observed needs by potential impact on care and system cost before invention begins.

Comparison of Stanford d.school Point of View and Stanford Biodesign Need Statement
Dimension d.school POV Biodesign Need Statement Practical implication
Starting evidenceObservation, interview, empathy, synthesisClinical observation plus primary and secondary researchUse the evidence standard the domain can support.
Core artifactUser + need + insightProblem + population + outcomeChoose insight when ideation is the goal; choose outcome when screening is the goal.
Primary guardrailStay user-centered and generativeRemain solution-independent and measurableDo not let the first idea hide inside the problem statement.
Main riskEndless empathy without commitmentPrematurely narrow scope or requirementsSet an explicit point for converging and testing.

Strategy consulting

Structure the decision, then spend analysis selectively

Consulting methods are designed for accountable decisions under time pressure. Their strength is not a magic framework; it is the discipline of making context, logic, priority, evidence, and action explicit.

McKinsey's published discussion of its seven-step process starts with a concise problem definition, then uses logic trees to disaggregate the question. The team prioritizes branches that are both important and movable, builds a work plan appropriate to the stakes, performs analysis, synthesizes the findings, and turns them into action. McKinsey's own speakers stress that the sequence is iterative rather than rigid. McKinsey: the seven-step process.

  1. 01Define the problem and context
  2. 02Disaggregate with logic trees
  3. 03Prioritize high-impact levers
  4. 04Build the work plan
  5. 05Conduct fit-for-purpose analysis
  6. 06Synthesize the evidence
  7. 07Communicate and mobilize action
Problem brief

Boundary before branch

McKinsey-style

Before drawing a tree, settle the decision the work must enable. A useful brief records the core question, situation and complication, success criteria, deadline, scope and exclusions, stakeholders, constraints, and likely evidence sources.

  • Specific decision and decision owner
  • Measurable outcome and time horizon
  • Included and excluded solution space
  • Dependencies, uncertainties, and non-negotiables
Early hypothesis

Answer first: provisionally

Bain-style

Bain recruiting material has explicitly advised developing an early hypothesis and refining or proving it through the case. The value is allocation: a provisional answer directs the next fact request and analysis. The danger is confirmation bias, so the hypothesis must remain falsifiable.

Context → Working hypothesis → Disconfirming test → Revision

Bain application pack (PDF)

Attribution discipline

MECE trees, SMART wording, hypothesis-led analysis, and SCQA storytelling circulate across consulting practice and training. They are useful together, but no single firm owns every tool. SCQA is best treated here as a communication shell for situation, complication, question, and answer: not as proof that the answer is correct.

Cognition & systems

When the frame itself is the failure point

Analytical decomposition asks what is happening inside the current frame. Reframing asks whether another interpretation would create a more useful intervention. Systems thinking then asks what that intervention will do to the surrounding whole.

Thomas Wedell-Wedellsborg

Frame, Reframe, Move Forward

Cognitive loop
FrameState the current interpretation in a complete sentence.
ReframeGenerate alternative views of cause, stakeholder, category, or goal.
Move forwardRun the smallest test that can distinguish the frames.

The familiar slow-elevator example illustrates the shift. If the problem is "the elevator moves too slowly," the solution space contains motors and scheduling. If the problem is "the wait feels frustrating," mirrors, information, or changes to the waiting experience become legitimate. The original frame was possible; it was simply not the only useful one.

  1. Make it legitimate to challenge the first framing.
  2. Bring in people outside the immediate problem context.
  3. Write competing problem definitions in full sentences.
  4. Ask what facts, stakeholders, or constraints are missing.
  5. Try different causal categories: structural, behavioral, technical, psychological.
  6. Study bright spots where the problem is absent or less severe.
  7. Question the objective, not only the obstacle.

Thomas Wedell-Wedellsborg in Harvard Business Review

Russell Ackoff · Wharton

Problems live inside "messes"

Systems view

Ackoff used "mess" for a system of interacting problems and opportunities. The implication is severe: optimizing a department, metric, or component separately can degrade the organization as a whole because the system's behavior arises from interactions. Formulation therefore has to include feedback loops, delays, incentives, displaced costs, and second-order effects.

  • Map stakeholders as actors with goals, not static labels
  • Identify reinforcing and balancing feedback
  • Test who benefits, who absorbs cost, and where risk migrates
  • Define system-level success before local optimization

Ackoff, "whole-ing" the parts and righting the wrongs

Venture capital & startups

A problem can be real and still be a weak venture

Human need is necessary, but venture screening asks a different question: can this problem support rapid, defensible growth? That screen adds market dynamics, timing, distribution, frequency, and differentiated insight.

Y Combinator · Kevin Hale

The startup idea as a growth hypothesis

Market screen
STARTUP IDEA = PROBLEM + SOLUTION + INSIGHT

In YC's Startup School lecture, Kevin Hale frames the idea as a hypothesis explaining why a company could grow quickly. The problem describes favorable initial conditions, the solution is the experiment, and the insight explains why this team's experiment could work. YC's warning against a "solution in search of a problem" follows directly: starting with the mechanism removes the most important uncertainty from view.

PopularEnough people or organizations experience the pain.
GrowingThe affected market or behavior is expanding.
UrgentUsers seek resolution now rather than someday.
ExpensiveThe current pain or workaround consumes meaningful value.
MandatoryRegulation, workflow, or consequence makes inaction difficult.
FrequentThe problem recurs often enough to support habit and retention.

Hale gives "millions of users," markets growing around 20% annually, immediate demand, and billion-dollar aggregate cost as illustrations of ideal venture conditions. They are not universal pass/fail thresholds: a specialized enterprise problem can support a strong company with far fewer users.

YC Startup School Week 1 transcript · Watch the official lecture

Peter Thiel

Contrarian and durable

0 → 1

Zero to One adds seven company-level questions to problem selection. They ask whether the opportunity can become an enduring enterprise rather than merely an interesting product.

  • Engineering: is the advance breakthrough rather than incremental?
  • Timing: why is now the right moment?
  • Monopoly: can the company lead a focused initial market?
  • People: does the team fit the problem?
  • Distribution: how will the product reach users?
  • Durability: can the position remain defensible?
  • Secret: what important opportunity is not widely recognized?

Publisher page for Zero to One

BJ Fogg

Behavior must be possible

Adoption
B = MAP

The current Fogg Behavior Model says a behavior occurs when motivation, ability, and a prompt converge at the same moment. This is a coordination model, not a numeric multiplication formula. It helps expose a bad formulation: what looks like a motivation problem may actually be excessive friction or a missing prompt.

  • Motivation: does the person care enough at that moment?
  • Ability: is the action simple enough with available resources?
  • Prompt: is there a clear cue when action can occur?

Official Fogg Behavior Model

Comparative synthesis

Choose the method that matches the uncertainty

The most dangerous framework is not the "wrong" one in the abstract. It is a framework whose assumptions do not match the decision environment.

Strategic comparison of problem formulation frameworks
Framework family Best context Primary evidence What it optimizes Characteristic risk
Human-centered designUnknown needs and open solution spaceObservation, interviews, behavioral patternsResonance and generative insightDiscovery without commercial or operational convergence
Clinical needs findingRegulated, high-stakes health innovationClinical observation, research, stakeholder economicsMeasurable unmet need and adoption valueOverconstraining the need before enough evidence exists
Structured consultingKnown industry, bounded decision, available dataOperational and financial analysisClarity, priority, speed, accountable actionA clean tree built on a false frame
Cognitive reframingChronic problem, entrenched assumptions, groupthinkAlternative perspectives and exceptionsA more useful problem definitionPermanent divergence without a decision test
Venture screeningHigh-growth startup or investment selectionMarket behavior, growth, pain, timing, insightAsymmetric, defensible growthRejecting valuable but non-venture-scale problems
Systems thinkingInterdependent stakeholders and feedback loopsRelationships, incentives, dynamics, second-order effectsWhole-system viabilityComplexity that delays any tractable intervention

Divergence 01

Emergent discovery vs. deductive structure

Use discovery while stakeholder need and causal structure remain uncertain. Move to logic trees once the decision boundary is credible enough to divide without hiding the unknowns.

Divergence 02

Solution agnosticism vs. answer first

Keep the problem mechanism-free when the design space is novel. Use an early hypothesis when the domain is mature enough for a provisional answer to save analysis: and specify what would disconfirm it.

Executive application

A four-gate governance pipeline

The frameworks become more useful when sequenced. This pipeline moves from questioning the frame to committing analytical and engineering resources.

01

Reframe the objective

Write the current frame. Invite an outsider. Ask what is missing, examine bright spots, change causal categories, and test whether the stated objective is actually the desired outcome.

02

Specify the unmet need

Use solution-agnostic syntax to name the problem, affected population, and one measurable outcome. Record the observation or evidence behind each term.

03

Structure the decision

Define success, scope, exclusions, owner, deadline, constraints, dependencies, and evidence. Disaggregate the question, prioritize movable levers, and form falsifiable hypotheses.

04

Screen impact and asymmetry

Check urgency, frequency, cost, market growth, distribution, team fit, defensibility, behavior change, system effects, and the cost of being wrong before funding the solution.

The one-page problem brief

If a team cannot fill this page with evidence and explicit uncertainty, it is not ready to commit substantial build resources.

Decision
What decision must be made, by whom, and by what date?
Current frame
What is the full problem statement, and which alternative frames were considered?
Need statement
What change is needed, for which population, to achieve which measurable outcome?
Evidence
Which observations, interviews, data, and counterexamples support or challenge the need?
Boundaries
What is in scope, out of scope, constrained, mandatory, or ethically non-negotiable?
System map
Who gains, who bears cost, and which feedback loops or second-order effects matter?
Working hypothesis
What do we currently believe, and what finding would cause us to revise or stop?
Worth-solving screen
What makes the outcome important, urgent, adoptable, scalable, or strategically asymmetric?
Next test
What is the smallest reversible action that most reduces uncertainty?
The stop rule

Do not ask whether the team likes the idea. Ask whether new evidence reduced the central uncertainty. If it did not, redesign the test, reframe the problem, or stop allocating resources.

Source notes

Primary and author-origin sources

The comparison above distinguishes institutional documentation from cross-framework synthesis. Thresholds and named tools should be used as decision prompts, not universal laws.

  1. Stanford d.school, Method Cards: POV Madlib, POV Want Ad, Critical Reading Checklist (PDF)
  2. Stanford Mussallem Center for Biodesign, Biodesign Innovation Process
  3. Stanford Biodesign, Scoping and Finalizing Your Need Statement (PDF)
  4. McKinsey & Company, How to master the seven-step problem-solving process
  5. Bain & Company, Application Pack: structured cases and early hypotheses (PDF)
  6. Thomas Wedell-Wedellsborg, Are You Solving the Right Problems?, Harvard Business Review
  7. Russell L. Ackoff, "whole-ing" the parts and righting the wrongs, Systems Research
  8. Y Combinator, Startup School Week 1: Kevin Hale on evaluating startup ideas
  9. Peter Thiel with Blake Masters, Zero to One, publisher record
  10. BJ Fogg, official Fogg Behavior Model (B=MAP)