The first time I became aware of this problem wasn’t at work at all. In fact, this is a common problem in any sort of situation where one party is seeking help from another party. I was in Seattle with my boyfriend for Thanksgiving couple years ago. On Wednesday night, I realized mid-dinner I had forgotten to bring my toothbrush and toothpaste. I asked the waitress: “Do you know if there’s any open convenience store around here?” The waitress answered: “I don’t know. Sorry.” My boyfriend asked me. “Why did you ask about convenience store?” “Because I can buy a toothbrush there.” “Right, so why didn’t you just ask about the toothbrush?” “Umm…” “Have you heard of the XY problem?” “No…” The XY Problem — the XY Problem is asking about your attempted rather than your solution actual problem. “You are trying to solve problem **_X_** , and you think solution **_Y_** would work, but instead of asking about **_X_** when you run into trouble, you ask about **_Y_** .” The XY problem can lead to significant waste of time and energy for both the person asking for help and the person providing help. Here’s a good example related to coding from . stackexchange I’ve seen the XY problem happening more than a couple times in the past at the companies I have worked at. How do you know whether your company is experiencing this problem? In my experience, often, the consequence of this problem took the form of features that rarely or never got used, features that did not provide any learning for the company, or features that did not provide any value to the customers. I’ve seen dozens of different types of events getting tracked but never getting looked at because they were either not actionable, hard to analyze, or both. I’ve seen features worth over 1000 lines of React code get implemented, deployed to production, never getting used, and then getting completely scraped by new code within weeks. I’ve spent days on small but complicated UX requests that could have been replaced with much simpler solutions (or needn’t be there in the first place). All of these events and wasted effort happened because somewhere in the product/engineering process, the real got lost and the team shipped a feature that did not solve the real issue . why Y X I’ve indeed been guilty of that myself: not digging deep into the why before starting the implementation of something that, ultimately, had to get scraped because it didn’t solve anything. So how can you avoid this problem? I’m still young in my career and I don’t have all the wisdom. However, I do think that a product/engineering process that’s implementation-based tend to fall prone to the XY problem more often than a product/engineering process that’s problem-based. Here’s the difference. A product/engineering process that’s implementation based tends to be more linear and assembly-line like. Product owners make decisions on what features to build. Designers then come up with mockups. Only once the design is done are the engineers building the features told about the said features. What’s wrong with this workflow? For one, people down the chain don’t get a clear context into the root problem (i.e. ). If a falsey assumption (i.e. ) is made at the beginning of the chain, then everyone involved are going to blindly follow order and do . X Y Y On the other hand, in a problem-based workflow, the role of the product owner is to keep the team focused on the . Product, design, and engineering collaborate and brainstorm together to define and solve a problem. why Behind every what is a why. All the times I’ve seen the XY problem happen is because the people involved failed to live by this principle. Why are we doing this feature? Why is this feature helpful for customers? Why is this feature helpful for our own learning? If the why is not thought out or communicated clearly, that’s a recipe for over-engineered implementations that ultimately don’t solve the root problem.

Chain

Assembly

Three ways writing tech blogs has helped me become a better engineer

On designing your way to a better future

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

The most common problem I’ve seen in product/engineering process

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How to stand out from the herd

The Ten Top Cities for Highest Cloud Engineering Salaries

10 Popular Websites Built With Django

10 Best VS Code Extensions to Improve Your Productivity

11 Reasons Software Engineering Will Never Die

How to stand out from the herd

The Ten Top Cities for Highest Cloud Engineering Salaries

10 Popular Websites Built With Django

10 Best VS Code Extensions to Improve Your Productivity

11 Reasons Software Engineering Will Never Die

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps