Still on "Keeping it SIMPLE" (while recognizing complexity)
I thought of going back to this so that I could provide more insight, also with a bigger bias towards a (digital) product development context. Definitely, this is an area where some could challenge my idea of something being simple because of its inherent complexity.
But again, complexity to me is more in the realm of whether something is easy or hard, at least in terms of understanding how to accomplish the outcome. And in fact, thanks to that, we are better off approaching it in the most straightforward fashion possible. Now, there's nuance, and that shouldn't be confused with being simplistic, like just trying out the same thing over and over again.
The point is a humbling one: the more we recognize complexity, the better off we are when we are not over-engineering our actions. "Probe, sense & respond", in a nutshell.
Here's the fairly simple idea that unfortunately too often organizations out there fail to figure out how to operate effectively that way:
Start with the business results or impact you are trying to accomplish.
Figure out possible changes in behavior (outcomes) that (you believe) will drive those results.
Work out hypotheses or ideas of what you (output) could try out to unlock that outcome.
Focus on prioritizing at the outcome level, but you ain't done until business results are there.
That's the simple idea from the Outcomes Over Output book by Josh Seiden, for instance, but in fact there are other sorts of frameworks that go about it in a very similar way, after you abstract and remove all the language differences (e.g., impact mapping, opportunity tree…).
Even the other day, and I don't think was the first time I noticed the pattern and made a comment about it, I was in a meeting where it was rather clear how a whole discussion around a topic that was high stakes and hot (for several years already, apparently)—the strategic level (business results) was clear, but the move was straight to "solutioneering" (possible paths for output). A lot of clarity can be given, so teams feel empowered to solve the necessary problems by simply being much more deliberate and intentional about that key mid-part, the transition from business results to outcomes.
But there's a catch, which is exactly where the complex part of it starts. Which is that you got to keep open for learning otherwise, not feel too attached either to the outcome that was initially assumed to drive the business results, and not at all to any idea (or output) you experiment with. In fact, experimentation is a key word here… And I largely buy into an insight I once heard that "experimentation is the new planning"—I think there's a lot to that way of thinking. That can compound with the simple idea of impact → outcomes → output, and moving back and forward, like almost in a dance, focusing your priorities on the outcome you believe will drive that result and that perhaps you can measure as a leading indicator (while business results are often lagging indicators).
Keeping it simple. Keeping grinding , iterating, learning, and embracing complexity along the way. Because one of the least useful things you could do would be to add to the complexity by overcomplicating how to approach things in the first place.
By Rodrigo Sperb, feel free to connect (I only refuse invites from people clearly with an agenda to ‘coldly’ sell something to me), happy to engage and interact