In Product Management there’s a technique called the 5 Whys which is used to get to heart of issues. For instance, if your website goes down, you might ask:
- Why did the website go down? Because too many people went at once.
- Why can’t our website handle that sort of traffic? Because we only have one server in Chicago.
- Why don’t we have multiple servers? Because no one wants to set that up.
- Why doesn’t anybody want to do that? Because we don’t have the right infrastructure to easily transfer everything to AWS or a similar system.
- How do we get the right infrastructure in place and make that happen? We hire an infrastructure expert to guide us.
It’s a great system for many issues, but I think just as great is the 1 Why.
Simply put, it’s not just taking an issue and digging down. There’s a tendency to reserve that line of thinking for big events, like site downtime, or massive costly mistakes.
To be truly effective you need to constantly question everything, especially the little things. You don’t necessarily have to spend the time breaking down all of the Whys as long as you’re asking the first one.
At one company I’ve worked at, there were so many systems in place that were inexplicable. There was a process built out for manual password resets, but no one had asked why it was there.
I asked. It turned out there were some severe bugs hindering the self service flow on certain devices. When I identified them with the help of Product and Engineering, we were able to almost completely eliminate the need for the manual reset flow. This saved countless hours of customers’ time and the team’s time.
Similarly, I took the same approach to other issues and patterns that surfaced from customer interaction.
I think that’s why it’s also helpful to hire regularly, and to take new hires on a thorough onboarding process. Every time someone comes in, they’re going to bring a perspective that hasn’t been entrenched in your processes, and able to say “wait, what?” to something that may be accepted by the rest of the team.