It’s also about asking the right people the right questions. Too often, the ones identifying issues aren’t the ones actually using the software (or whatever needs fixing). The real insights come from those who use it daily, yet they’re rarely the ones being asked.
The assumptions part is pretty spots-on, the human brain is pretty lazy, we like filtering out external information as quickly as possible, and not think from scratch about things, the first solutions we come up with are taken from previous experiences & memory which don't always fit what we're trying to solve currently. It's a safe assumption(pun unintended) that when we run out of the "easy solutions" that come to mind at first glance that's when we can really form new ideas for novel solutions (not that this is always needed).
I also think that finding the right solution comes naturally with time and experience(or from seeing the wrong things being built), and you end up naturally questioning everything you hear. and also a bit of curiosity about what the people having the problem were trying to do, trying to achieve etc.
I consider “What problem are you trying to solve?” to be one of the Power Questions. Learning to ask this question has saved me and my teams man-years of effort. It also produced much better outcomes.
This article serves as a great reminder of how important it is to dig deeper into problems before jumping to solutions. The XY problem is something many of us have encountered, whether in engineering, product development, or other areas. Asking the right questions, like ‘Why?’ can really shift how we solve problems and save valuable time. I particularly liked the analogy of running faster on the wrong path—such a simple yet powerful way to grasp the idea.
As an engineering leader, how do you encourage your team to question assumptions and make sure they’re addressing the true root cause before jumping into solutions?
I encourage my team to dig deeper by asking clarifying questions and using frameworks like the "5 Whys" to uncover the root cause. I also foster a culture where questioning assumptions is safe and valued, ensuring we fully understand problems before moving on to solutions.
It’s also about asking the right people the right questions. Too often, the ones identifying issues aren’t the ones actually using the software (or whatever needs fixing). The real insights come from those who use it daily, yet they’re rarely the ones being asked.
Great insight. We must ask the right people, normally the users, the ones using it on a daily basis.
A great article :)
The assumptions part is pretty spots-on, the human brain is pretty lazy, we like filtering out external information as quickly as possible, and not think from scratch about things, the first solutions we come up with are taken from previous experiences & memory which don't always fit what we're trying to solve currently. It's a safe assumption(pun unintended) that when we run out of the "easy solutions" that come to mind at first glance that's when we can really form new ideas for novel solutions (not that this is always needed).
I also think that finding the right solution comes naturally with time and experience(or from seeing the wrong things being built), and you end up naturally questioning everything you hear. and also a bit of curiosity about what the people having the problem were trying to do, trying to achieve etc.
Thank you for your comment. I agree with what you mentioned!
Really great article!
I consider “What problem are you trying to solve?” to be one of the Power Questions. Learning to ask this question has saved me and my teams man-years of effort. It also produced much better outcomes.
Learning to ask the right questions is a superpower.
This article serves as a great reminder of how important it is to dig deeper into problems before jumping to solutions. The XY problem is something many of us have encountered, whether in engineering, product development, or other areas. Asking the right questions, like ‘Why?’ can really shift how we solve problems and save valuable time. I particularly liked the analogy of running faster on the wrong path—such a simple yet powerful way to grasp the idea.
As an engineering leader, how do you encourage your team to question assumptions and make sure they’re addressing the true root cause before jumping into solutions?
I encourage my team to dig deeper by asking clarifying questions and using frameworks like the "5 Whys" to uncover the root cause. I also foster a culture where questioning assumptions is safe and valued, ensuring we fully understand problems before moving on to solutions.