Five Movie and TV Scenes That Explain the Problem-First Method Better Than a Framework

The fastest way to build the wrong thing is to fall in love with the solution too early.

That is the core idea behind the Problem-First Method.

Before you build, pitch, plan, hire, automate, redesign, or “AI-enable” anything, you have to understand the problem clearly enough that the right solution becomes almost obvious.

Some of the best examples of this do not come from business books. They come from movies and TV.

Here are five scenes that capture problem-first thinking especially well.

1. Moneyball: “What’s the problem?”

In Moneyball, Billy Beane’s scouts think the problem is obvious. (watch the scene)

They lost star players. So they need to replace star players.

That framing sends them straight into feature-parity thinking:

• “He had power.”
• “He looked like a ballplayer.”
• “He had the right swing.”
• “He had the right presence.”

But Billy reframes the problem.

The Oakland A’s do not need to replace famous players. They need to replace the production those players created. More specifically, they need to buy wins with less money than everyone else.

That changes everything.

Once the problem shifts from “replace these players” to “find undervalued ways to create runs,” the solution space opens up.

That is classic problem-first work.

A solution-first team asks:

How do we get another version of what we lost?

A problem-first team asks:

What outcome did that thing actually produce, and is there another way to get it?

This is why Moneyball is probably the cleanest business example of the Problem-First Method. It shows the danger of optimizing for proxies: reputation, appearance, tradition, intuition. The real problem was hiding underneath all of that.

Product teams do this constantly.

• A customer asks for a dashboard, but the real problem is lack of confidence.
• A sales team asks for a feature, but the real problem is unclear positioning.
• An ops team asks for automation, but the real problem is inconsistent process.

The requested solution is not always wrong. But it is almost always incomplete.

Billy Beane’s genius was not just using data. It was refusing the first problem frame.

2. Apollo 13: Square peg, round hole

The famous Apollo 13 CO2 scrubber scene is problem-first thinking under extreme pressure. (watch the scene)

The astronauts are running out of breathable air. The engineers on the ground cannot design an ideal solution. They cannot send new parts. They cannot ask for more time.

So the problem becomes brutally specific:

We need to make this square filter fit into this round opening using only the materials already available on the spacecraft.

That specificity is the whole lesson.

They do not begin with a clever invention. They begin with the actual constraint.

• What is failing?
• What materials exist?
• What cannot be changed?
• What outcome matters most?

Only after those questions are clear does the solution emerge.

This is one of the best examples of constraint-driven innovation. The constraint is not a side detail. The constraint is the problem.

That matters because teams often define problems in a way that quietly ignores reality.

“We need a better onboarding experience.”

• Okay, but for whom?
• New admins? New clinicians? Billing teams?
• Do we have engineering capacity?
• Can support absorb the change?
• Does the user have five minutes or fifty?
• Is the real issue education, workflow, trust, or timing?

A vague problem creates vague solutions.

Apollo 13 works because the problem is concrete enough to solve. Not “fix the spacecraft.” Not “improve the air system.” Not “innovate under pressure.”

Make this fit into that using only these things before they suffocate.

That is problem clarity.

3. Silicon Valley: Middle-out compression

In Silicon Valley, Richard initially thinks Pied Piper is a music app. (watch the scene)

That is the product. That is the thing he is building. That is the visible solution.

But the real value is somewhere else.

The breakthrough is not the music app. The breakthrough is the compression technology underneath it.

That is what makes the “middle-out” compression moment such a strong problem-first example. Richard discovers that the important problem is not music discovery or music rights or music distribution. The important problem is data compression at scale.

The product was pointing at a deeper problem.

This happens all the time in startups.

A team builds a tool for one use case, then realizes the underlying capability is more valuable than the original wrapper. Or a customer asks for one workflow, but the deeper pattern applies across many workflows. Or the first version of a product is less important than the hidden infrastructure created along the way.

The problem-first move is being willing to ask:

What problem are we actually solving better than anyone else?

Not:

What did we originally say this product was?

That distinction matters.

Teams often stay attached to their first solution because it has a name, a deck, a roadmap, and a sunk cost. But the market does not care what you thought you were building. It cares what problem you actually solve.

Pied Piper becomes interesting when the team realizes the real problem is bigger than the original product.

That is a powerful lesson for product teams: sometimes the problem you are solving is hiding underneath the thing you are building.

4. Ford v Ferrari: The car needs to finish

In Ford v Ferrari, the obvious problem seems simple: (watch the scene)

Build a faster car.

That is the visible metric. That is what executives understand. That is what looks good in a meeting. Speed is easy to sell.

But Le Mans is not a drag race. It is a 24-hour endurance race.

That means the real problem is not just:

How do we make the car faster?

The real problem is:

How do we build a car that can perform under extreme stress long enough to finish?

That reframing changes the work.

Now the team has to think about brakes, heat, handling, reliability, driver fatigue, pit strategy, and the way the entire system behaves over time.

The brake problem is especially useful as a product lesson.

Everyone wants to talk about acceleration. Nobody wants to talk about stopping. But if the brakes fail, the speed does not matter.

That is a perfect metaphor for teams that optimize the flashy part of the product while ignoring the operational constraint that will actually determine success.

A product team might focus on:

• A more impressive demo.
• A slicker interface.
• A bigger launch.
• A more exciting feature.
• A stronger sales story.

But the binding constraint might be something less glamorous:

• Implementation is too slow.
• Billing rules are too complex.
• Support cannot explain the workflow.
• Users do not trust the output.
• The edge cases break the process.
• The system works in a demo but not in real life.

That is the Ford v Ferrari lesson.

The thing that wins the race may not be the thing that looks most impressive on the spec sheet.

Problem-first teams ask:

What actually prevents this from succeeding in the real world?

Not:

What will look best in the presentation?

The car does not just need to be fast.

The car needs to finish.

5. The Martian: “Science the hell out of this”

In The Martian, Mark Watney is stranded on Mars. (watch the scene)

That is too big to solve.

“Get home” is not an actionable problem. It is a desired outcome.

So Watney breaks the impossible into smaller problems.

• Food.
• Water.
• Communication.
• Energy.
• Time.

Each problem has constraints. Each constraint suggests a different solution. He does not solve Mars. He solves the next bottleneck.

That is what makes The Martian such a good example of problem sequencing.

A solution-first version of the story would be:

How do I build a rescue plan?

A problem-first version is:

What kills me first?

That question creates priority.

This is where many teams struggle. They do not just jump to solutions. They jump to the most exciting problem instead of the most urgent or important one.

• They redesign the interface when the workflow is broken.
• They add AI when the data is messy.
• They build reporting when the source process is inconsistent.
• They automate before they understand the exception cases.

Watney survives because he sequences correctly. He solves food before comfort. Communication before coordination. Energy before movement. Each solved problem creates the conditions to solve the next one.

That is a useful reminder for teams: problem-first does not mean analyzing forever. It means understanding the next real constraint clearly enough to act.

Why these five work together

Each scene shows a different part of the Problem-First Method.

• Moneyball is about reframing the problem.
• Apollo 13 is about constraints.
• Silicon Valley is about discovering the deeper problem beneath the product.
• Ford v Ferrari is about finding the real-world constraint that matters most.
• The Martian is about sequencing problems instead of trying to solve everything at once.

Together, they show why problem-first thinking is not just a business framework. It is a discipline.

• You slow down before you build.
• You question the first framing.
• You look for the real constraint.
• You pay attention to what actually breaks under pressure.
• You solve the next problem, not every problem.

The mistake smart teams make is rarely that they cannot build.

It is that they build before they understand what is actually broken.