One word to save months of development
Since the introduction of 5 whys, we know how effective asking “why” is to uncover root causes behind a problem. While in theory everybody agrees it’s important, in practice, it is tempting to jump straight into fixing the problem instead. And when you do that, things typically go wrong in two ways: treating symptoms without addressing the root cause or treating a wrong root cause.
Treating symptoms without addressing the root cause
While it can be immediately helpful, it’s not sustainable long term. If you have a headache, taking paracetamol once is a good idea. If the headache continues, you’d want to see a doctor who can look beyond painkillers into what is causing the pain.
Why should it be different for product development? A team noticing users struggle to find an element on a page has an obvious option: to make the element more prominent.
Were they to figure out why it’s happening, they would discover the underlying problem — the page is too busy. Unknowingly, they would make it worse by giving a visual boost to the element.
Ask why one more time, and you’ll discover the underlying structural problem that too many teams are adding content to the same page without coordinating.
Treating a wrong root cause
Now say a doctor, upon your headache complaints, prescribes you chemotherapy without proper tests or diagnosis. You run away, file a complaint, and never come back.
Yet, with product development, jumping into ideation on how to address an issue without looking for its causes happens every day.
Some real-life examples from my past include:
- Senior stakeholder coming to a team with “Customers don’t use our app, we need to redesign it.”
- Team-lead coming up with the “Team is slow, we need to refactor our code base.”
In both cases, making assumptions instead of understanding root causes produced inadequate solutions:
Customers don’t use our app → [usability is bad] → we need to redesign it. Investigating why has revealed that customers simply couldn’t log in.
The team is slow → [code is messy]→ let’s do refactoring. Asking why the team is slow would have revealed a lack of trust in the product and understanding of a roadmap.
This type of mistake can cost hours or months of development, depending on how far off and how ambitious the solution to the wrong problem is. Even when the team recognizes the mistake, sunken cost bias might stop them from pivoting on time.
And it can be avoided by asking a few magic why’s on time.
