Understanding vs. Complexity

I was reading this substack the other day and the Understanding vs. Complexity chart stood out to me as very relevant to product management. This is another way to think about “ELI5”, the Feynman Technique, etc.

Stage 1

When people are new to a complex area, they tend to over-simplify everything and fail to understand the nuances of the subject. In the best case, this leads to surface-level points-of-view that don’t get into the “meat”. In the worst case, it leads to incorrect decisions (hopefully none of which are one-way doors).

People in this stage are unable to make resilient arguments, their product theses are weak, and they have not thought through second and third order considerations. Sometimes they haven’t even thought through first order considerations.

Stage 2

As the understanding of the area deepens, the appreciation for the complexity grows. Some become overwhelmed by the complexity and are unable to reason through it at all. Others get stuck in “analysis paralysis” mode and are unable to draw out the high order bits from the sea of details. In the best case, the person in this stage can make forward progress but it takes tremendous amounts of energy.

People stuck in this stage tend to produce very comprehensive artifacts: Decision review pre-reads that run to dozens of pages, stop light tables with lots of rows and columns, product theses that read like a laundry list of use cases and features.

Stage 3

The last stage is when one has such a deep understanding of a space that one can rapidly distill the most complex and thorny of issues into a simple mental model. People operating at this level regularly distill ambiguity to clarity and reduce complexity to simplicity. They grok the Pareto variables on which a decision or issue hinges and can low-pass filter the noise. Their synthesis of a complex topic will just “click” and seem “obvious” to the audience. In reality, the synthesis is not obvious at all and required an extraordinarily deep understanding of the issue.

Whatever your domain of work, you want to get to Stage 3 as quickly as possible. Unfortunately, there are no shortcuts. You necessarily have to progress through Stage 1 and Stage 2 first. The key is to be self-aware about which stage you are in. If you are in Stage 1, spend time listening and building context. If you’re new to a space, your instinct about it is probably wrong, so don’t jump to conclusions or assume you know the right answer.

If you are in Stage 2, you understand the complexities of the space. You can hold all the dimensions of the problem in your head and can examine the problem from every possible angles. You probably do not rely on instinct or “gut feel” at all, because you’ve learned through error that the correct answers are not obvious and require rigorous logical analysis.

To get to Stage 3, practice distilling issues down to their crux. Force yourself to stick to an unreasonable page or slide limit in your pre-reads. Ask yourself which criteria really move the needle on a decision. Refine the 30 second elevator pitch for a product thesis. Start to listen to your instinct again. You know you are operating in Stage 3 when your rapid gut calls match the answer from rigorous analysis.

Precision Questions

Precision questioning is a technique to motivate a person (or a team) to more fully explore a problem space. Precision questioning is broadly useful, but there are a few instances when it is my tool of choice:

  1. When you know that there is a better answer but need everyone to come along for the journey to that same conclusion.
  2. When a proposal, thesis, or analysis is “almost” there but something feels a little wrong and you can’t quite put your finger on it.

HOW TO DO IT

Break down the space: Ask questions that logically sub-divide the problem space. A variety of fields share the concept of breaking a problem space into logical structures. Binary space partition trees from computer graphics, mutually exclusive comprehensively exhaustive frameworks from management consulting, and option/criteria frameworks from product management are very similar cognitive tools. Shishir Mehrotra, CEO of Coda, calls these “Eigenquestions“.


Litmus tests: Try to find a common scenario that exposes a flaw in the reasoning. This is not about nit picking or picking extreme edge cases and going “haha! Gotcha!”. This is about choosing or designing a mainstream scenario that is a watershed point in a thesis or argument.

ELI5: Explain like I am 5. We work in complex spaces. It is easy to get caught up in our own jargon. I often catch myself saying things like “optical modulation transfer function”, “late-stage reprojection”, and “rotationally invariant feature descriptor”. Ask the presenter to explain the concept as if to a child. They might find flaws in their own reasoning without any further prompting.

What must be true for … It can be useful to enumerate what must be true for an overall thesis to be true. Then address recursively process each predicate point-by-point. This forces an explicit enumeration of unspoken assumptions all the way down to first principles.

HOW NOT TO DO IT

Do not ask “Have you thought about X?”. This is condescending. The person who did the work probably understands the space better than you do and has almost certainly thought about X. In fact, it is probably addressed in the pre-read and you didn’t bother to read the pre-read: “Why, yes. I have thought about X. My thoughts are in paragraph 2 on page 1”.

Do not drop knowledge. Precision questioning is about gaining knowledge or the group expanding its knowledge together. It is not about showing off how smart you are or how much you know. Resist the urge.