What problem framing is and why it matters
Problem framing is the act of deciding what question you're answering before you start building answers. It sounds obvious — of course you should understand the problem first. But in practice, most product teams skip straight to solutions. Someone says "we need a dashboard," and the team starts designing a dashboard without asking: what decision will this dashboard help someone make? What's the cost of not having it? Is a dashboard even the right solution?
The framing you choose determines everything that follows. "Users are leaving after the first session" frames the problem around retention and implies solutions like better onboarding. "Users don't understand what our product does" frames the same symptom around positioning and implies solutions like clearer messaging or a different landing page. Both framings are legitimate. But they lead to completely different roadmaps, and only one is right for your situation.
Opportunity sizing is the complement to framing: once you've defined a problem worth solving, how big is the prize? Sizing prevents two common mistakes — investing heavily in a problem that affects 200 users when another problem affects 20,000, and dismissing a small-seeming problem that's actually the gateway to a massive market.
Why this matters for your projects
The most expensive product mistake isn't building something poorly — it's building the right thing for the wrong problem, or solving the right problem at the wrong scale. Problem framing is cheap (a few hours of structured thinking) and dramatically reduces the risk of wasted engineering effort. Every week spent building the wrong thing is a week you could have spent building the right one. Framing first is how you protect your team's most scarce resource: their time.
Framing vs. solutioning
A common failure mode: someone presents a "problem" that's actually a solution wearing a problem's clothes. "We need to add bulk actions to the admin panel" is a solution. The problem might be: "Admins spend 40 minutes per day on repetitive individual actions." That reframing opens up alternatives — bulk actions, yes, but also automation rules, better defaults, or removing the need for admin action entirely.
The test for whether you're framing or solutioning: does your statement describe a user's situation (framing) or a product change (solutioning)? "Users can't find the export button" is framing. "Move the export button to the top nav" is solutioning. Stay in framing mode until you've evaluated the problem's size, urgency, and fit with your strategy.
One-way and two-way door decisions
Jeff Bezos distinguishes between one-way doors (irreversible or very costly to reverse) and two-way doors (easily reversible). Most product decisions are two-way doors — you can ship, learn, and change direction. These don't need heavy framing; lightweight experimentation is enough.
One-way doors — entering a new market, committing to a platform migration, signing a multi-year partnership, sunsetting a product — deserve rigorous framing and sizing. The cost of getting these wrong is months or years of wasted effort. Most of this topic applies to one-way door decisions. For two-way doors, use lighter versions of these tools.
Problem framing methods
Problem Statement Template Core Method
Use when: Starting any initiative — before discovery research, before roadmap planning, before writing requirements.
A good problem statement is specific, evidence-based, and solution-agnostic. It describes the current situation, identifies who's affected, quantifies the impact, and explains why the status quo is unacceptable.
Five Whys Root-Cause Analysis Diagnostic
Use when: A symptom is clear but the underlying cause isn't. Prevents solving symptoms instead of causes.
Start with the observable problem and ask "why?" five times, each answer becoming the subject of the next question. The technique forces you past surface-level explanations to structural causes.
Example: Why are users churning after the trial? → They don't see value in 14 days. → Why? → They never complete setup. → Why? → Setup requires connecting a data source, which needs engineering help. → Why? → Our API docs assume technical knowledge the buyer doesn't have. → Why? → We designed for the technical evaluator, but the buyer is a marketing manager.
The root cause — misalignment between the buyer persona and the setup experience — suggests a completely different solution than "extend the trial" or "add setup reminders."
Common mistake
Five Whys can lead you to a single root cause when the real situation involves multiple contributing factors. Use it to generate hypotheses, not to declare definitive answers. Validate your root cause with data before committing to a solution direction.
Scope Hammering Scoping Tool
Use when: An initiative feels too big, too vague, or too ambitious for the time and resources available. You need to cut it down to something achievable.
Scope hammering is the deliberate process of reducing scope until a project fits the time, team, and risk tolerance you have. It's not about removing features — it's about narrowing the problem until the smallest valuable version is clear.
Start with the full vision
Write the maximalist version. "A complete analytics dashboard with custom reports, real-time data, alerts, and team sharing." This is probably 6 months of work.
Ask: "What's the smallest version that delivers value?"
Cut until only the core remains. "A single pre-built report showing yesterday's key metrics." This might be 2 weeks of work. The question isn't "is this impressive?" but "does this solve someone's problem?"
Define the sequence
Arrange the cut pieces into phases. Phase 1: pre-built report. Phase 2: add custom date ranges. Phase 3: add custom metrics. Each phase is independently valuable and shippable.
Opportunity Canvas Evaluation Framework
Use when: You have multiple potential problems or initiatives and need to decide which one to pursue. Also useful for presenting a proposed initiative to stakeholders.
Opportunity sizing methods
TAM / SAM / SOM Market Sizing
Use when: Evaluating a new market, pitching to investors, or deciding whether an opportunity is worth pursuing at all.
Three concentric circles of market size, each more realistic than the last.
TAM — Total Addressable Market
The total revenue opportunity if you had 100% market share. This is the theoretical ceiling. "The global project management software market is $7.5B." Useful for investors; not useful for prioritization.
SAM — Serviceable Addressable Market
The portion of TAM that your product can realistically serve given your go-to-market, pricing, geography, and capabilities. "Project management for remote-first tech companies in North America: $800M." This is the arena you're playing in.
SOM — Serviceable Obtainable Market
The portion of SAM you can realistically capture in the next 1–3 years given competition, brand awareness, and sales capacity. "We can capture 2% of our SAM in 18 months: $16M ARR." This is the number that should drive resource allocation.
Practical tip
Bottom-up sizing is more credible than top-down. Instead of "the market is $7.5B and we'll get 1%," calculate: "There are 50,000 companies that fit our ICP, 30% have the problem we solve, our average contract is $12K/year, and we can close 5% in year one = $9M." Investors and executives trust bottom-up because it shows you understand the specific mechanics of your market.
Fermi Estimation Quick Sizing
Use when: You need a rough order-of-magnitude estimate quickly and don't have time for detailed market research. Also useful for sanity-checking more detailed analyses.
Named after physicist Enrico Fermi, this technique breaks an impossible-seeming question into smaller, estimable components. The beauty is that errors in individual estimates tend to cancel out, producing a surprisingly reasonable final number.
Example: "How many B2B SaaS companies in the US would pay for our product?"
Total US businesses: ~30M. Percentage that are B2B: ~40% = 12M. Percentage using SaaS: ~60% = 7.2M. Percentage with 10–500 employees (our target): ~15% = 1.08M. Percentage with the problem we solve: ~20% = 216K. Percentage willing to pay $200+/month: ~10% = 21,600 companies. At $200/month average = $52M annual revenue opportunity.
Is this exact? No. Is it the right order of magnitude? Probably. And it took 10 minutes, not 10 days.
Impact / Effort Matrix Prioritization
Use when: Comparing multiple opportunities and need a quick visual framework for prioritization conversations.
A 2×2 grid with Impact (high/low) on the Y-axis and Effort (high/low) on the X-axis. Plot each opportunity and the quadrants tell you what to do:
High impact, low effort = Quick wins. Do these first. They're rare and valuable.
High impact, high effort = Strategic bets. Plan these carefully. They're your big moves.
Low impact, low effort = Fill-ins. Do when you have slack capacity. Don't prioritize them.
Low impact, high effort = Time sinks. Don't do these. This is where feature requests from loud customers often land.
Common mistake
Teams overestimate impact and underestimate effort for ideas they're emotionally attached to. Calibrate by looking at past projects: how did the actual impact compare to the predicted impact? Most teams discover they consistently over-promise on impact by 2–3×. Apply that correction factor.
Templates and checklists
- Problem described as a user situation, not a product change
- Affected users identified and quantified (not "users" — which users?)
- Impact estimated with data, not intuition
- At least one root cause hypothesis articulated
- Current alternatives mapped (competitors, workarounds, doing nothing)
- Strategic alignment checked against product principles
- Scope hammered down to a Phase 1 that's independently valuable
- Success criteria defined with specific metrics and thresholds
- One-way vs. two-way door classified — effort matches reversibility
- Stakeholders aligned on the problem before discussing solutions
Real-world examples
Case study
Slack: Reframing from "chat tool" to "reduce email overload"
Slack's early framing wasn't "build a better chat app" — that problem frames the solution as competing with HipChat and IRC. Instead, Stewart Butterfield framed the problem as: "Knowledge workers spend 28% of their workweek managing email, and most of those emails are internal coordination that doesn't need the formality of email."
This reframing changed everything. It sized the opportunity differently (all internal email, not just chat users), identified different competitors (email itself, not chat apps), and shaped the product differently (channels for context, threading for organization, integrations to pull work into one place). The problem framing created a market category rather than entering an existing one.
Case study
Dropbox: The Fermi estimate that justified the product
Drew Houston's early sizing for Dropbox was essentially a Fermi estimation: there are X million knowledge workers. Y% work across multiple devices. Z% of those have experienced the pain of lost or out-of-sync files. At $10/month, that's a market of $N billion. The estimate was rough, but it was enough to justify building and enough to convince early investors that the opportunity was large.
Critically, Houston also framed the problem correctly: not "people need cloud storage" (too technical, too abstract) but "people need their stuff everywhere, and it should just work." This framing expanded the market beyond tech-savvy early adopters to anyone with files on more than one device.
Case study
Basecamp: Scope hammering as competitive strategy
Basecamp (originally 37signals) made scope hammering a core product philosophy. While competitors like Microsoft Project and Jira added features to serve every possible use case, Basecamp repeatedly asked: "What's the simplest version of project management that helps a small team stay organized?" Then they built only that.
The result: a product that deliberately lacks Gantt charts, resource allocation, time tracking, and sprint planning. Each exclusion was a deliberate scope decision based on the framing: "Small teams (under 20 people) need to know what's happening, what's due, and where to discuss it. Everything else is overhead." This radical scope discipline became a competitive advantage — Basecamp is the anti-complexity choice in a market drowning in complexity.
Common pitfalls
Solution-first framing
"We need to build a mobile app" is a solution masquerading as a problem. The problem might be: "Users can't complete critical tasks when they're away from their desk." That framing opens up solutions beyond a native app — responsive web, progressive web app, SMS notifications, or even redesigning the workflow so it doesn't require the task at all.
Sizing theater
TAM/SAM/SOM calculations that use impressively precise numbers to justify a predetermined conclusion. If your total addressable market is exactly $4,372,500,000, you've spent time on false precision. Sizing should produce order-of-magnitude clarity ($5B? $500M? $50M?), not precise revenue forecasts. The question is "is this opportunity big enough to matter?" — not "what's the exact market size to the dollar?"
Framing too broadly
"Users are dissatisfied with our product" is a framing so broad it's useless. Dissatisfied with what? Which users? Compared to what? The narrower the framing, the more actionable the solutions. "Enterprise users on the Teams plan are dissatisfied with report generation speed, which causes them to export to Excel" is a framing you can actually act on.
Skipping framing because the solution is "obvious"
The most dangerous problems are the ones where the solution seems obvious. "Obviously we need to add dark mode" — but is the problem that users want dark mode, or that the interface causes eye strain during extended use? The latter might be solved with better contrast ratios, adjustable font sizes, or a "focus mode" that reduces visual noise. Obvious solutions short-circuit the thinking that produces better solutions.
When to frame problems formally
Decision guidance
Use formal framing when: Starting a new initiative that will take more than 2 weeks of engineering time. Evaluating a new market or product direction. Multiple stakeholders disagree about what to build. You need to justify resource allocation to leadership. The problem is ambiguous and multiple root causes are plausible.
Skip formal framing when: The problem is well-understood, the solution is validated, and the effort is small (two-way door). You're fixing a known bug. You're iterating on a feature that already has clear success metrics. The team has strong shared context from recent research.
Adapt when: You're a solo PM or early-stage team. Use the problem statement template and a quick Fermi estimate. Skip the full opportunity canvas. Write the framing in 30 minutes, not 3 days. The goal is structured thinking, not documentation for its own sake.
Connected topics in your library
Appendix
Extended material on advanced framing techniques, organizational dynamics, and sizing in uncertain markets.