- Causal reasoning
- Effectual reasoning
These 2 ways of thinking map surprisingly well to the opposing styles in product (waterfall vs agile). What does this say about product thinking?
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. 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. But many of us have learned the hard way that this often doesn't work.
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 are more conducive to effectual reasoning (and assume 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 that 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 we are advocating for in Product management. 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
It's not that one type of thinking is better, but in open-ended problems (like product discovery) leaning towards effectual reasoning is probably a good bet.
- What does this say about different product management methods and frameworks?
- How conducive are the processes and structures in your organization to effectual reasoning?
- How do you usually think?