There’s a story about a man who suffers from appalling headaches. They started as a minor inconvenience, but after 20 years have worsened and now affect every part of his life: failed relationships, a series of sackings, etc., etc. So he finally goes to the doctor. After many tests, the doctor diagnoses the problem: the patient’s testicles are pressing against the base of his spine, causing pressure which leads to the headaches. There’s only one solution: castration.
The patient initially declines, but ultimately pain gets the better of him and he agrees to the surgery.
So the surgery happens and the patient feels like a new man afterwards. Without the headaches, he realises this is the restart his life needed. To celebrate and kick-start his new life and job hunt, he goes to buy a new suit.
He walks into a tailors and says he’s looking for a new suit. The tailor looks him up and down. “You’re a 44-inch chest”, he says. “Brilliant”, says our patient. “How did you know?”
“Easy”, replies the tailor. “I’ve been doing this for 40 years. And you’re a 16-inch neck”.
“Bang on”, says the man. “How about the trousers?”
“36-inch leg” says the tailor. “And a 36-inch waist”.
“Gotcha!” shouts our hero. “I’m a 34-inch waist and have been since university.”
“Oh no,” the tailor insists. “You’re a 36-inch waist. If you wear 34-inch trousers, you’ll wear 34-inch underpants. And they’ll be far too tight – they’ll compress your balls against your spine and give you terrible headaches”.
The Product Stuff
Without wishing to over-analyse an excellent Dad-joke, this is how many people approach product management. There are two issues here.
Finding the actual problem
Instead of identifying the root cause of the problem, we fix the local, obvious, issue. While this often alleviates the symptoms, it doesn’t resolve the underlying problem. Such a resolution is therefore sub-optimal and possibly even harmful in the longer term. Here, they appear to have found out the cause. But they haven’t uncovered what caused the cause.
So when we approach a problem, why don’t we always use techniques such as 5-whys to dig down to the root cause? Why do we tackle only the immediate cause?
Well, firstly it’s a tricky habit to get into. Fixing a problem is satisfying and that buzz can be obtained quickly with an immediate fix. We set our mindset on achieving small wins, failing to optimise for long-term gain. Our sprint is full, so we put in a quick fix and mark this done.
Secondly, we’re often busy, with many competing demands. Fixing a problem feels like it is detracting from our main goals. Why spend time on fixing this when there are quarterly targets to be hit? So we avoid the potential hassle of coordinating with other departments and spending time identifying a root cause by simply fixing the surface issue. It’s good enough, and we can get on with our main priorities.
The second problem is that cutting one’s balls off is quite clearly not a safe-to-fail experiment. While this resolved the immediate problem, it is an irreversible action. In the language of Chris Matts, it is most definitely a commitment rather than an option. One can imagine that at the punchline our patient would have preferred to be holding an option rather than having committed early.
The realm of product management is that of uncertainty. There are outcomes which we are tasked with moving towards, rather than a fixed set of features that we must implement. To meet these outcomes, we identify small, safe-to-fail, hypotheses that we can test to see if they move closer to our aims.
The safe-to-fail part is key. Given that we cannot have certainty in advance about which features will and what won’t move our metrics the right way, we must have the option to reverse the feature at low cost should it fail. As responsible product managers it is not acceptable to hold merely a hypothesis and yet to create a complete, fixed, product (this is the realm of mass-production). Instead, we validate the hypothesis via testing and we always have a rollback option.
So two lessons from a terrible joke.
Always check for the root cause of a problem. And be sure to run safe-to-fail experiments, rather than commitments you’ll later regret.