90% of the battle is won when we solve the XY Problem in Product Management
--
The XY problem is something that happens in our daily life. Although I recognise this but did not expect the high number of occurrence when I become a product manager. When I can identify the XY problem while chatting with users, stakeholders, and developer it greatly reduces the time spent on creating a solution.
XY Problem is about having X problem but asked help for Y instead. Usually, because he/she thinks that Y will solve X. This usually leads to wasted time and effort.
This link discusses the XY problem in the context of a technical problem. I notice this tend to happen to developers across different experience. Sometimes we become so absorbed into solving Y that we fail to step out of the box and rethink for a better solution.
Example of XY Problem
During customer interview, a common question tends to be something along the line: What do you think can be improved?
Imagine a PM in a Car manufacturer company talking to the customer A:
PM: Hey MR. A, thanks for purchasing with Model C1.0 from us. After 3 months of driving, how do you feel about it?
A: Hey, its been really good. Driving been really smooth and the leather seat is awesome. I do wish that the speaker in the car could be louder thou.
PM: Oh, what about it?
A: I adjusted the volume to the maximum but sometimes still have problems hearing the song clearly.
We could have stopped here, introduce a C1.1 model with louder speaker, but does that really solve the user problem? It is always better to investigate further.
PM: That is interesting Mr. A. Are you always on the loudest volume?
A: Not really, While driving in town, I tend to keep it on the recommended average setting. But while driving to work, I have to drive past a stretch of under construction sites, then I turn the volume to the loudest, but is still not loud enough.
There, we found out about the real problem, Mr. A has an issue with the soundproof for the car rather than the speaker. He just thinks that having a louder speaker would help solve the issue, therefore, he suggested that. This is just an example. Most of the time, it is more challenging and the conversation could continue to and fro before being able to draw any valuable conclusion.
XP Problem that happened recently at work
XY problems also happen commonly in our daily life. Recently, a colleague came over to ask me a question.
“Hey Zac, is it possible to introduce a real-time notification feature to our mobile app.”
I am a little confuse as we already have the ability to send the push notification to our users. But we do have a large database and have a complex requirement to run for users to determine if they should receive the push notification. So, it can take 20–30min for all users to receive from the time of trigger. Before understanding further, I went on a 10+ min of explanation of how our push notification is design and why it takes so long to send out the push notification but it is actually real-time.
Being a really nice colleague, she didn’t stop me and allow me to fully explain myself. But after I notice that it doesn’t seem to be the answer she was looking for, I probe further. Then I find out that what she actually wanted was to have an alert feature for users who are close to the point of redemption to their first rewards to refer a friend and earn points. It is a very valid suggestion because we wanted to encourage users to refer their friends and being close to redemption actually would entice them more to refer their friends.
Because she wasn’t as technical savvy, she uses the term real-time notification instead of alert or pops up while users are using the app. It is also my bad that I didn’t treat her as a normal user and assumed what is being asked.
If I could have spotted that there is a potential XY problem here, I would have asked more like what I would usually do during a user interview. We both could have save up to 10+ min of our time to do something more valuable.
Being a product manager my role is to ensure the right problem is defined so we can formulate a plan to solve it. Many times people are generally nice and provide a suggestion that they think is the solution for us. Unfortunately, more often than not there is other better alternative. Only by truly identifying the problem then we could tackle the root cost correctly.
How to detect and solve it
I noticed that most of the time, people tend to start off the conversation like this
- do you think we can do …
- Is it difficult to provide …
- How long will it take to do …
- We need help to build …
All these phrases are actually asking a question towards the solution (Y) rather than the problem (X). I pay attention closely to the way the conversation is started now so I could identify if users are actually asking for Y. Most of the time, it takes a few to and fro conversation to truly figure out the X problem that user has.
I feel that all this extra effort and time took to figure the X is well worth it. In the long run, we can prevent building the wrong feature or even product that we thought is what the user really wanted!
Thanks for reading! If you like it, please hit 👏👏👏
In the day, I am a technical product lead. At night, I am a maker, engineer, and designer. I enjoy learning and building new things about tech, products, and startup. You can find me on Twitteror on my blog.
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +383,380 people.
Subscribe to receive our top stories here.
