The Feynman Technique is a method pioneered by the famous physicist, Richard Feynman, to quickly learn about a new field or domain. It has four steps:

1. Study
2. Teach
3. Identify gaps
4. Simplify

When reviewing requirements from Product Management (PM), I have found this technique invaluable to quickly come up to speed on new areas of the product.

Also, what’s awesome about using the Feynman Technique this way is that our domain isn’t fixed! Every great engineer I have worked with has not been a passive consumer of requirements and simply accepted or rejected user stories. Rather, they have been played an integral part in shaping requirements and improved on them in a meaningful way.

The (slightly modified) Feynman Technique encourages and facilitates this process.

1. Study

Initially, we’ll read the Product Requirements Document (PRD) and user stories that we have received from PM, attend story times, and ask questions.

2. Summarize

When I am ready to start thinking about a solution, I always start by summarizing the relevant requirements (which becomes the beginning of my design document). I find this:

• Clarifies your understanding
• Displays to reviewers of your document that you thoroughly understand the problem
• Teaches your audience what problem your solution is solving

3. Identify Gaps

After we have summarized the requirements, we can identify gaps in our knowledge of the proposed product’s behavior. These gaps could be because we missed the information, or it could simply be missing from the requirements. It’s also useful to note any inconsistencies we might find.

We can then meet with PM to clarify and flag any missing information or contradictions.

4. Reflect

Now that we have gathered all of the information, we can reflect on it.

Product

• What problem is PM trying to solve for our users with these requirements?
• How does this fit into the broader roadmap? Are we rowing in the same direction as other engineering teams?
• How does this integrate with the surrounding ecosystem? Will this cause problems in other areas of the product?
• Is there something oddly specific in the requirements that is obscuring a more general concept?
• What aspects of the requirements do we anticipate changing? What do we need a longer roadmap on?

Business

• Is this a pivot? What’s the rationale?
• Is this strategic or tactical? Are we building a new line of business or are we allowing sales to counter a competitor’s new marketing materials?

Technical

• What are the implied technical constraints? Can we live with them?
• Where do we anticipate the risk? Can we mitigate it in some way?

5. Influence

After reflecting, we can note any broader concerns we may have had and raise them with PM, propose alternative solutions to the problem PM is trying to solve, and prepare arguments to help sell our colleagues on our ideas.

Conclusion

I find that using this technique leads to better engagement with PM and the product itself, and helps one become aware of 2nd or 3rd order affects implied by the requirements. Likewise, I believe the best engineers avoid mistakes far more often than their colleagues, and this technique can help us identify those mistakes.

Next time you are reviewing requirements, give it a shot.