← Patterns

Solve the Meta-Problem

Pattern · design-philosophy

Core Concept

When you’re stuck on a hard problem, the real problem is usually your process, not your goal. Reframe the problem so that your solution helps you learn faster rather than trying to solve the end-goal directly.

“The problem is we don’t understand the problem.” — Paul MacCready

MacCready won the Kremer Prize (human-powered flight) not by building a better airplane, but by reframing: instead of “how do I build a plane that flies?”, he asked “how do I build a plane that can be rebuilt in hours, not months?” This collapsed the iteration cycle from years to days. He flew 3-4 different planes in a single day. Six months later, he won a prize that had gone unclaimed for 18 years.

The Pattern

The trap: teams pursue a difficult goal by building their best guess, testing it, learning one thing, and rebuilding from scratch. The cycle is so long that they can’t iterate meaningfully. They mistake slow progress for inherent difficulty.

The reframe: don’t solve the goal problem — solve the iteration-speed problem. Once you can try things cheaply, the goal problem solves itself through rapid empirical learning.

The test: if your problem requires a magnum opus, you are solving the wrong problem. Any approach that demands getting it right the first time is a process problem in disguise.

Where It Applies

Product development (WCP):

• The non-consumption playbook is partly this pattern: instead of “build the perfect PM tool,” the reframe is “build something an agent can read/write to in one session, then iterate from real usage.” Ship fast, learn from real agent behavior, rebuild.
• The job map’s “Gap” columns are the conjecture. The PostHog instrumentation is the empirical grounding. Without measurement, we’re building planes on theory.

Engineering leadership:

• “How do I ship the perfect architecture?” → “How do I build something I can change in a day?” — this is why vertical slices, feature flags, and CI/CD matter. They’re iteration infrastructure.
• This connects to AI-Ready-Engineering: code health and testing infrastructure are the “Mylar and aluminum tubing” — they make the rebuild cheap.

Show Notes:

• The Validate-Before-Building pattern is the discovery version: don’t build the product, build the cheapest test of whether anyone wants it. Same reframe — solve for learning speed, not product completeness.

Personal OS:

• The OS’s Use-Equals-Build principle is this pattern applied to knowledge systems: don’t design the perfect knowledge architecture, build one you can restructure in hours through normal use.

Relationship to Adjacent Patterns

The MacCready Story (Full)

1959: Henry Kremer offers £50,000 for human-powered flight (figure eight around markers half-mile apart). Dozens of teams spend years building planes on theory. Each test flight produces one data point and a pile of wreckage. 18 years pass.

Paul MacCready reframes: the problem isn’t flight — it’s that the rebuild cycle takes a year. He builds with Mylar, aluminum tubing, and wire — materials that can be repaired in hours. First plane doesn’t work (too flimsy). Doesn’t matter. He flies 3-4 different configurations per day. Six months later, the Gossamer Condor flies 2,172 meters and wins the prize. A year after that, the Gossamer Albatross crosses the English Channel.

Source: You-Are-Solving-The-Wrong-Problem (Aza Raskin, via Alan Kay)

Cross-References

• You-Are-Solving-The-Wrong-Problem — Source article
• Right-Problem-Leverage — Adjacent: problem selection vs. problem reformulation
• Validate-Before-Building — Discovery instantiation
• Iteration-Speed-Is-The-Strategy — Operational corollary
• Use-Equals-Build — Knowledge-system instantiation
• Galls-Law — Systems-design instantiation