Two ways of thinking in product
In his review of Waldrop's book "Complexity" Cedric Chin highlights research by Professor Saras D. Sarasvathy which contrasts 2 ways of thinking:
Causal reasoning
Effectual reasoning
What are these ways of thinking, and how do they map to product?
1. Causal (predictive) reasoning is a mechanistic worldview that states the future is predictable given the right variables. In this worldview, we take an end-state in mind and then reach it by selecting between given means.
In product we have learned that this kind of predictive reasoning is fraught with risk. If we lock in a too specific end-state (like a feature), we close ourselves to more fruitful possibilities that arise on the way and we run the risk of our assumptions being wrong.
In many ways, causal reasoning seems to be the antithesis to agile. It’s waterfall thinking: Time-based roadmaps, high-fidelity solution specs, estimations, output-driven product strategy. All of these methods place an emphasis on predicting the future and then working towards achieving that future.
2. Effectual reasoning is the other worldview. The word 'effectual' is the inverse of the word 'causal'. It says that "you cannot predict what will happen in the future" and this means that "you must learn to act without prediction.” It's staying open to new variables, and continuously reimagining new ends.
Examples of methods that aim to be conducive to effectual reasoning by assuming the predictability of the future to a lesser extent:
OKR's leave room for many different solutions (ends) by bounding on outcome rather than output
Shapeups 'high-level' pitches leave a broader margin for product teams to figure out the details during development (rather than before it)
Agile's emphasis on small stories and cycle times pushes for a more continuous reimagining of the product (rather than locking in the future)
Note: No method or framework is inherently causal or effectual. It is definitely possible to have a time-based roadmap and agree that these are all just guesses and we can be flexible about them. Just like OKR's are frequently (ab)used to enforce certain outputs. Some methods are just more conducive to keeping options open.
Mapping this to product
Effectual reasoning seems to map strongly to what is mostly advocated for in Product. It's almost like the author is describing waterfall vs agile (emphasis mine):
Unlike causal reasoning that comes to life through careful planning and subsequent execution, effectual reasoning lives and breathes execution. Plans are made, and unmade and revised and recast through action and interaction with others on a daily basis. - Sarasvathy
So does this mean one type of thinking is better than the other, or should they be intermingled?
It is important to point out though that the same person can use both causal and effectual reasoning at different times depending on what circumstances call for. In fact, the best entrepreneurs are capable of both and do use both modes well. But they prefer effectual reasoning over causal reasoning in the early stages of a new venture... - Sarasvathy
So it's not that one type of thinking is better. Both modes can be applied depending on the circumstance. Which begs the question: When to use which?