How to Solve It: A Practical Reading Note on Pólya’s Four-Phase Method

Expanded September 2026: The original post was one sentence. This revision turns it into a practical reading note without inventing a personal reading diary or quoting the book at length.

George Pólya’s How to Solve It is a 1945 book about mathematical problem solving, but its durable contribution is broader: it makes the normally hidden work between “I do not know” and “I have a defensible answer” easier to examine. Princeton University Press describes the book as an introduction to heuristics—the methods of discovery and invention—and notes that it has remained in print since 1945 across many translations.

Choose an edition—or borrow first

This note is about the method, so it does not depend on a particular pagination. If you want a copy, use the ISBN rather than the cover image:

Publication, price, and availability vary by country. For lawful access before buying, check your local or university library; Open Library’s edition record can help locate a copy and shows borrowing only when it is available for that edition and region.

Readers who prefer independent bookshops can check the ordinary, untracked Bookshop.org US listing or Bookshop.org UK listing. The US and UK stores are separate regional services. These are not affiliate links, and this post currently earns no commission from them.

The famous outline has four phases:

  1. understand the problem;
  2. devise a plan;
  3. carry out the plan;
  4. look back.

The list is easy to memorize and easy to underestimate. Its value does not come from treating four headings as a guaranteed algorithm. It comes from the questions inside each phase and from the permission to move backward when a plan exposes a misunderstanding.

1. Understand the problem

Before calculating or coding, state the problem in a form that could be checked by someone else.

Ask:

  • What is unknown?
  • What facts, inputs, and constraints are given?
  • Which terms are ambiguous?
  • What would count as a correct result?
  • Can I draw a diagram, construct a small example, or restate the task in my own words?

This phase prevents a common failure: producing a technically valid answer to the wrong question. “Make the program faster” is not yet a testable problem. “Reduce the median processing time for this fixed dataset from 12 seconds to under 8 seconds without changing output” is much closer.

The output of this phase should be a short problem statement, knowns and unknowns, constraints, and a success check.

2. Devise a plan

A plan is a promising route, not a prediction of success. Pólya’s heuristics include looking for a related problem, considering a simpler case, introducing useful notation, drawing an auxiliary element, decomposing the goal, and working backward from the desired result.

For practical work, create more than one candidate when possible:

  • reproduce the failure on the smallest input;
  • compare a working case with a failing case;
  • isolate one stage of a larger pipeline;
  • work backward from the expected output;
  • replace a complex component with a controlled substitute;
  • search for an invariant that should remain true.

Then choose the cheapest plan that can eliminate the most uncertainty. A five-minute diagnostic that disproves a theory is often more valuable than an hour spent implementing it.

3. Carry out the plan

Execution requires discipline. Write down assumptions, make one interpretable change at a time, and check each intermediate result. If a step does not follow, stop and repair the reasoning instead of hiding the gap inside more work.

In software, that means keeping the failing input, capturing the exact error, adding a focused check, and changing one variable. In mathematics, it means justifying each transformation and checking that a theorem’s conditions actually hold. In research, it means separating observation from inference and recording enough context to reproduce the result.

When the plan fails, the failure is evidence. Return to the first two phases with the new constraint rather than repeating the same attempt more forcefully.

4. Look back

The fourth phase is what turns a solved instance into reusable knowledge.

Check:

  • Does the answer satisfy the original conditions?
  • Can it be verified by a second method or a limiting case?
  • Which assumption was essential?
  • Is there a simpler explanation?
  • Can the method solve a broader class of problems?
  • What test, note, or tool would prevent the same confusion next time?

A repaired bug should become a regression test. A completed derivation should be checked by substitution, dimensions, or an independent route. A successful workflow should become a small checklist rather than remain an anecdote.

A worked example: a batch job silently skips files

Suppose a program receives ten files but produces eight outputs.

Understand: Record the exact input list, expected one-to-one mapping, output directory, log, exit status, and the two missing names. “Sometimes it skips files” is replaced by a reproducible statement.

Plan: Compare one processed and one missing file; reduce the batch to those two; inspect filtering, filename parsing, and per-file exceptions; work backward from the output-writing stage.

Carry out: Add stage-level counts, run the two-file case, and change only one suspected condition. The evidence may show that uppercase extensions fail a case-sensitive filter.

Look back: Normalize extensions, add tests for mixed case and unusual names, confirm all ten outputs, and document the input rule. The fix now protects future batches instead of merely rescuing one run.

The example is not from Pólya’s book; it shows how the same phases transfer to technical maintenance.

What the framework does not do

The four phases do not replace subject knowledge, evidence, creativity, or judgment. A well-structured plan can still start from false data. Some problems have several acceptable answers; others are constrained by ethics, law, cost, or uncertainty rather than a single mathematical proof.

The framework is also not strictly linear. Understanding improves while testing a plan, and looking back can reveal that the original question was framed badly. The loop is a feature, not a defect.

A compact worksheet

Problem:
Desired result and success check:
Known facts:
Unknowns:
Constraints:

Candidate plans:
Cheapest informative test:

Steps and observations:
Assumptions disproved:

Verification:
Simpler explanation:
Reusable test, note, or tool:
Next question:

This habit fits the Lazying.Art idea well: reduce repeated friction by turning one hard-won solution into a clear artifact that another person—or your future self—can reuse. The open projects are places where those artifacts become code, documentation, and tools.

Original 2018 note

The complete original post was one sentence:

This book introduced a way to analyze problems and develop solutions.

References

Leave a Reply