How to Write Product Requirements Iteratively

Teresa Torres argues that most product requirements are poor because teams finish writing them too early and start building before the solution has been iterated on. She recommends treating requirements like writing: begin with a deliberately rough first draft, then repeatedly test the solution against the original problem, simplify it by questioning every component, and define how success will be measured. She adds that letting the idea rest overnight and talking it through with others (engineers, designers, real customers) surfaces what the author missed alone. The core message is that the goal is solving problems in the simplest possible way, which improves usability, lowers engineering cost, and keeps teams focused.

01Key takeaways

• Write a deliberately rough first draft of requirements to get ideas out before judging them.
• Check every iteration against the original problem and restart if the solution has drifted.
• Ask what happens if each component is removed, and cut anything that doesn't affect the core solution.
• Define a success metric upfront and remove any feature that does not move it.
• Revisit requirements after a break, since fresh eyes catch things missed the day before.
• Talk requirements through with engineers, designers, and real customers before handing them off to build.

02Key sections

Start with a terrible first draft

Borrowing from Anne Lamott, the author suggests getting ideas down quickly without self-criticism, moving from whiteboard sketches to user stories, since writing things linearly raises new issues.

Check that the solution solves the problem

Teams often drift toward appealing ideas and lose track of the original problem, so each draft should be checked against what was set out to be solved and revised or restarted if it fails.

Simplify relentlessly

Solutions tend to be complicated, and the author urges teams to question every assumption, remove components that aren't essential, and refine the solution itself rather than just the wording.

Define success and sleep on it

Identify a metric that shows whether the solution works, remove anything that doesn't move it, then wait a day so the unconscious mind can work on the problem before revisiting the same questions.

Talk it through with others

Explaining the solution aloud and getting input from different people, such as engineers for feasibility, designers for simplification, and customers for problem fit, reveals blind spots.

03From the post

“You have an idea. You write it down. Maybe you sketch it on a white board. You talk to some engineers. You write user stories. And away you go. You start building. That sounds right. Isn't that what we are all doing? It's what many of you are”

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.