A Dichotomy to Manage, Not a Problem to Solve
Psychotherapist and relationship expert Esther Perel has this great framing:
"a paradox to manage, not a problem to solve.”
Many aspects of life, business, product, leadership, relationships, etc are paradoxical.
Strategy vs execution
Customer vs business impact
Explore vs exploit
Realistic vs ambitious
Take risks vs have security
etc…
The list goes on.
And this is true, especially in complex spaces, like product.
In fact, a couple of years ago, I did a brain dump on the many paradoxes of Product Management, which eventually turned into a newsletter post.
This is why there’s no ‘one-way’ to do product.
There are no silver bullets.
And why product can’t easily be distilled into a linear, step-by-step process.
I shared an example of this yesterday in the training course I was co-training for a client.
One of the participants asked whether they (Product Manager) should first create their Roadmap or should they wait for their product leader to create the roadmap for the Product Portfolio first?
My response:
“it doesn’t matter.”
Because neither exists in a vacuum.
They co-exist.
It’s “a paradox to manage, not a problem to solve.”
Whether you start at the product group level (Group PM) or with each individual product roadmap, it doesn’t matter. At some stage, you will need to chat with each other, discuss, align, and make adjustments.
This is called collaboration for those who work in environments that have forgotten about it!
The same can be said for other common questions I get like:
“Should we start with the business or customer outcome first?”
Again, it doesn’t really matter, because you need to satisfy both.
You need to solve customer problems that drive a business impact.
We need to solve customer problems that drives a business impact.Product is full of these dichotomies.
What I love about Esther’s quote is that they’re not problems for us to solve.
I get the desire for clarity and a simple formula to follow—and I wish I could give it to you—but the reality of complex spaces, they’re riddled with dichotomies and paradoxes.
I see a lot of energy going into trying to solve them.
People claim that we MUST start with the problem, not the solution.
Or that we MUST identify customer opportunities first.
Or that everything MUST go through discovery.
Complexity means that there will always be exceptions.
As the saying goes, “all models are wrong, some are useful.”
So, rather than trying to view this as a problem to solve, I’d encourage you to see it as paradoxes/dichotomies to manage.
Accept that things are paradoxical.
And focus your energy on managing it.
Rather than quickly dismissing frameworks as something that “doesn’t work in reality”.
Instead, ask yourself:
Does this make sense?
Would it make sense in my context?
What context was this designed for, and why did they make the choices they did?
If I were to do it, how might I change things?
Can I extract any first principles?
What can I learn from this approach?
How is this similar or different to what I’ve done in the past?
etc…
Of course, this means more work.
Wouldn’t a silver bullet be nice?
But welcome to complexity!
Complexity requires you to turn on those critical thinking muscles, engage that prefrontal cortex, and make your own decisions.
If you were hoping for a free ride - sorry!
