Problem Framing

Problem Framing

Overview

The way you frame a problem determines the range of solutions you can see. A narrow frame leads to narrow solutions. This skill teaches techniques to reframe problems — expanding the solution space, getting teams unstuck, and finding breakthrough approaches.

When to Use

• The team is arguing about solutions but hasn't agreed on the problem
• All obvious solutions have been tried and failed
• Stakeholders are blocking each other with different frames
• You want to find innovative approaches, not just incremental improvements
• Don't use for: well-understood execution problems where reframing adds noise

Instructions

1. Surface the Current Frame

Ask: "What's the problem we're trying to solve?" Have each stakeholder answer independently. Compare the frames:

• Narrow frame: "We need a better onboarding screen"
• Broader frame: "Users don't reach the 'aha moment' quickly enough"
• Widest frame: "Our activation rate is 30%, below the 60% benchmark"

The narrower the frame, the more it prescribes a solution. Surface this.

2. Apply Reframing Techniques

Technique 1: The Five Whys Ask "why" five times to expand the frame:

1. "Users aren't completing onboarding" → "Why?"
2. "They don't understand the value" → "Why?"
3. "They skip the tutorial because it's too long" → "Why?"
4. "They're busy and want immediate value" → "Why?"
5. "They haven't committed to the product yet" → Real frame: "We're asking for time investment before demonstrating value"

Technique 2: Flip the Frame Turn the problem around:

• From: "How do we get users to complete onboarding?"
• To: "How do we deliver value before onboarding is complete?"
• To: "How do we eliminate the need for onboarding?"

Technique 3: Change the Subject

• From: "How can we make our search better?"
• To: "How can users find what they need without searching?"
• To: "How can the information come to them?"

Technique 4: Expand the Constraints

• What if we had unlimited budget? → frees from resource thinking
• What if we had zero budget? → forces creativity
• What if we had to solve it in one week? → forces prioritization
• What if users had to pay $100/month? → forces value thinking

Technique 5: The Question Ladder Move up or down the abstraction ladder:

• Concrete: "How do we reduce form fields from 12 to 5?"
• Mid-level: "How do we reduce signup friction?"
• Abstract: "How do we earn users' trust to share their data?"

3. Choose the Best Frame

A good frame is one that:

• Everyone agrees "yes, that's the real problem"
• Opens up more solution possibilities than the current frame
• Can be validated (you can test whether solving it matters)
• Is specific enough to be actionable

4. Test the New Frame

Before committing, validate:

• Does this frame resonate with users? (not just stakeholders)
• If we solve this frame, does the original pain go away?
• Does this frame lead to measurably different solutions?

Sample Output

Original frame: "How do we make our notification settings page easier to use?" After reframing:

• 5 Whys → "Users get too many irrelevant notifications and turn them all off"
• Flip → "How do we send fewer, better notifications so users don't need settings?"
• Change subject → "How do we let users decide their notification preferences in the moment, not in a settings page?"

Resulting solution: Instead of a settings page redesign, build in-context notification controls — an "unmute this conversation" button in the notification itself. Eliminates the need for a settings page entirely.

Common Pitfalls

1. Assuming your frame is correct — Your first framing of a problem is rarely the best one
2. Skipping to solutions — Teams want to solve, not explore. Force the reframing step
3. Losing specificity — "Make users happy" is too broad. Find the right level of abstraction
4. Frame imposed by authority — If the most senior person says "the problem is X," others won't reframe. Use anonymous framing exercises
5. Analysis paralysis — Reframing is a 30-minute exercise, not a 2-week project

Verification Checklist

• [ ] Current frame surfaced from all stakeholders
• [ ] At least 2 reframing techniques applied
• [ ] New frame agreed upon by team
• [ ] New frame is testable (can validate)
• [ ] Original problem is still addressed by the new frame

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: uthumany
• Source: uthumany/uthy-legacy-os
• License: MIT
• Homepage: https://uthumany.github.io/uthy-legacy-os/

Install and usage instructions live in the source repository linked above.