Say what the solution must deliver, not what it is.

A well-defined problem is written in outcomes, never in the thing you want to build. Told through the 1902 machine that cooled the world by refusing to be about cold.

In the summer of 1902, a printing plant in Brooklyn could not do its job. It ran color work, and each sheet went through the press several times, once per ink. Between passes the humidity shifted, the paper swelled and shrank, and the colors landed a hair out of register. Fuzzy pictures. Ruined runs. They handed the problem to a young engineer at a heating company named Willis Carrier.

He could have defined the problem the obvious way: the plant is hot in summer, so cool it down. Almost everyone would have. Instead he did the one thing this entire piece is about. He wrote down what any solution would have to deliver, and discovered the goal was not temperature at all. The problem, Carrier found, was not the heat. It was the humidity.

A problem is stated in outcomes, not in the thing you build.

This is not a slogan. It is the oldest rule in disciplined problem solving. A good problem statement, write Conn and McLean in Bulletproof Problem Solving, is “expressed in outcomes, not activities or intermediate outputs.” It is specific, it is bounded, and it is deliberately not narrow enough to smuggle a favorite solution inside it. Herbert Simon framed the whole discipline that way: solving starts by representing the problem, and the representation decides what you can even see.

The Problems Worth Solving formula puts it in one sentence: How can we help [who] do [the job to be done] under [these circumstances] in order to [the outcome]? There is no product in that sentence. No feature, no technology, no tube, no app. And after the who and the job and the circumstance comes the load-bearing question: what must the solution deliver - which pains relieved, which gains achieved. That is a job-to-be-done stated as a capability, not a spec sheet.

This does not say what the solution is. It says what it needs to be able to do. If any point is hyper-critical to understand, this is the one.

Cold air was the accident. Dew point was the point.

Carrier defined the deliverable as a capability: hold the moisture in the air steady enough that the paper keeps its dimensions. Hit a target dew point. Nothing on the market in 1902 did that; ventilation moved and chilled air, but nobody could set and hold its water content. So he built a machine straight at the requirement: pass the air over coils chilled to a calculated dew point, let the excess water condense out, hold the humidity constant. Cold air fell out as a side effect. That side effect became modern air conditioning, an industry the printing requirement never dreamed of.

Define the problem as “make a cold box” and you get a cold box. Define what it must deliver, and you can get an industry. The proof is documented: contemporary accounts confirm the problem was the humidity, not the heat, and NIST’s own lithography research later fixed the requirement in numbers: to keep color in register, control relative humidity to within a few percent.

The gap is where you invent.

Once the problem names what the solution must deliver, the prior art stops being a wall and becomes a map. You lay what already exists next to what the problem demands, and the distance between them is not a threat. It is the assignment. That gap is exactly where invention lives, and you cannot even see the gap until the requirement is written down.

mRNA had to evade the body and still be read.

For thirty years, synthetic messenger RNA worked in a test tube and was useless in a body. Injected, it set off the innate immune system and shut down. Katalin Karikó and Drew Weissman did not start by designing a molecule. They wrote the requirement, the well-defined problem stated as a capability:

Evade and translate. No existing mRNA delivered both, and that gap was the whole problem. The answer fell out of the requirement: swap uridine for a modified nucleoside, pseudouridine, and the mRNA goes quiet to the immune system while translating better than before. That one substitution, aimed exactly at the written spec, is why the COVID vaccines exist and why the work won the 2023 Nobel Prize in Medicine. The problem definition did not describe the invention. It demanded it into being.

The same test, in miniature.

You do not need a Nobel to use this. Three quick reads of “what must it deliver”:

• Value proposition. You replace a fine phone every year, but keep a fine laptop for a decade. Nobody handed you a reason to switch the laptop that was powerful enough. What a solution must deliver is a reason to change, not a feature.
• The initial market. Cancer drugs begin with patients who have no other hope, then move to the mass (Thiel’s point: start where the value proposition is most powerful, not where the market is biggest).
• The real competitor. The only labor-scheduling software of its era did not lose to rival software; it lost to a nurse with pencil and paper (a Mullins road-test staple: beat what people actually do today).

You are protecting a solution, not defining a problem, when:

The reverse-engineering primer

Here is my pitch. Reverse-engineer it. Do not accept it at face value, and do not help me build anything yet.

"I want to build a productivity app. Honestly I think a billion people could use it, everyone has this problem. It has a clean design and some AI in it, and I have already started building. I do not really know who my first customer is, but the market is huge and mine is better than what is out there."

Work backward from this pitch to the problem I never actually stated. Grill me until we have:
1. A well-defined problem written in OUTCOMES, not features: how can we help [who] do [the job] under [these circumstances] in order to [the outcome]?
2. What the solution must DELIVER (the pains relieved, the gains achieved) - stated as capabilities, not as the app.
3. Only then, the solution the problem actually demands - which may not be the app I started with.