A ticket lands in the backlog. "Add an export-to-CSV button on the reports page." Two lines. A product owner signed it off. An engineer picks it up, ships it in a day, closes it, and feels good.
Three weeks later the same customer asks for a second button. Then a filter on the export. Then a scheduled email of the export. Nobody stops to ask why a customer wants a spreadsheet of data they already see on screen.
Here's the answer, when someone finally asks: the finance lead copies the numbers into a monthly board report, by hand, and the totals on the reports page don't match the invoices. The CSV was never the problem. The CSV was the customer's guess at a fix.
The stated issue is almost never the real issue. And most engineering teams I've worked with are built to solve the stated one as fast as possible.
Your Team Solves Problems Fine. It Diagnoses Them Badly.
Thomas Wedell-Wedellsborg surveyed 106 C-suite executives from 91 companies in 17 countries for his Harvard Business Review piece on solving the right problems. 85% agreed their organizations were bad at problem diagnosis. 87% agreed this flaw carried significant costs.
Read those numbers again. The people at the top of the org chart admit the machine works... on the wrong inputs.
His best-known example is the slow elevator. Tenants complain to the building owner: "The elevator is too slow!" The tenants have already framed the problem, so every solution points at a faster motor or a new lift. Reframe it as "the wait is annoying" and a cheaper answer appears. Put a mirror next to the doors. People stop noticing the wait.
The mirror does nothing to the elevator. It solves the real issue.
Software People Even Named It
Engineers know this pattern so well we gave it a name. The XY problem is asking about your attempted solution rather than your actual problem. Someone wants X, decides Y will get them there, gets stuck on Y, and asks for help with Y. Everyone burns time helping with Y until the truth comes out.
The classic example on the site: someone asks how to grab the last three characters of a filename. The helper asks why three. The person wants the file extension. Not every extension has three characters, so the "fix" they asked for would have broken on the first .jpeg.
Eric S. Raymond flagged this decades ago in How To Ask Questions The Smart Way, warning against questions shaped like "How do I use X to do Y?" because they presuppose a method before anyone checks the goal.
Here's what bugs me. We teach junior engineers to spot the XY problem on Stack Overflow. Then we hand them a backlog full of XY problems written by product managers, sales, and customers, and we measure them on velocity.
Every Ticket Is a Solution in Disguise
Look at your backlog right now. Count the tickets written as a problem. Then count the ones written as a solution.
- "Add a retry to the payment call." (What fails, how often, and who notices?)
- "Make the dashboard load faster." (Faster for whom? Which number are they waiting for?)
- "Build a Slack integration." (What decision do people want to make sooner?)
- "We need microservices." (What hurts about the monolith today?)
Each one hides a real issue behind someone's preferred fix. Your team ships the fix, the real issue survives, and it comes back wearing a new ticket number.
I'd go further. A backlog full of solution-shaped tickets is a sign your engineers aren't trusted to think. Somebody upstream did the diagnosis, badly, and passed down the prescription.
ORACLE Puts the Real Issue Second for a Reason
Gillian Jones-Williams joined me on Corey-osity Unleashed and walked through the ORACLE coaching model she uses with leaders. Here's my shorthand for each step:
- Outcome... what do you want?
- Real issue... what's in the way?
- Alternatives... what have you tried, and what else is on the table?
- Creative ideas... what haven't you considered?
- Likelihood... which option will you commit to?
- Execute... what happens next, and when?
Notice the order. Outcome first, then the real issue, and only then options. Most engineering conversations run it backwards. They start at Execute ("when will it ship?"), skip to Alternatives ("should we use a queue?"), and never touch the R at all.
Gillian's model forces you to slow down to speed up. The two minutes spent asking "what's in the way?" save the three weeks of follow-up tickets.
I wrote before about how your one-to-ones turn into status meetings when managers stop coaching. The same thing happens to refinement sessions. They become estimation meetings for solutions nobody questioned.
Five Questions to Ask Before Anyone Writes Code
You don't need a new framework or a two-day workshop. You need a habit. Before a ticket moves into a sprint, someone on the team asks these questions out loud:
1. "What happens if we never build this?"
If the answer is "nothing much," you found a solution looking for a problem. If the answer is "finance misreports revenue to the board," you found the real issue, and it's bigger than a CSV button.
2. "Who feels the pain, and when?"
Get to a person and a moment. "Users" is not a person. "The on-call engineer at 2am when the payment retry fails silently" is.
3. "What have they already tried?"
This is Gillian's A, and it matters more than it looks. People rarely bring you their first attempt. They bring you the request left over after their own fixes failed. Ask what they tried and you learn what the problem isn't.
4. "If we fixed this perfectly, what would they do next?"
The CSV customer would paste numbers into a board report. Now you know the outcome. The report might be the product.
5. "Write the problem in one sentence with no solution in it."
Wedell-Wedellsborg recommends writing it down as a full sentence starting with "The problem is..." Bullet points let you hide. Sentences force you to commit. If the sentence contains the words "add," "build," or "migrate," try again.
"We Don't Have Time for This"
You'll hear this. Usually from the person under the most delivery pressure.
Here's my answer. You have time to build the wrong thing, ship it, field the complaint, write the follow-up ticket, and build a second wrong thing. You have time for all of it. You don't have time for five questions?
Speed on the wrong problem isn't speed. It's motion. Your cycle time looks great. Your customer still copies numbers by hand.
There's a fair pushback here too. Not every ticket needs an interrogation. A typo fix is a typo fix. Use judgment. Save the questions for anything bigger than a day of work, anything a customer asked for by name, and anything you've seen come back twice.
The Engineer Who Asks Why Isn't Slowing You Down
Every team has one. The engineer who reads a ticket and comes back with "what are they trying to do?" Some managers treat this person as friction.
I treat them as the cheapest quality control in the building.
If you want more of them, reward the question in public. When someone's "why" kills a week of pointless work, say so in standup. When a reframe turns a big build into a small config change, celebrate it louder than a launch. Your team learns what you praise.
I wrote about asking five engineers what the team is for and counting the different answers. Try the same test on your next three tickets. Ask five people "what problem does this solve?" If you get five answers, you don't have a ticket. You have a guess.
Your Move
Pick one ticket in your current sprint. Before anyone writes another line of code, sit down with whoever asked for it and ask two questions: "What do you want to happen?" and "What's in the way?"
Then listen. Don't solve. Not yet.
What would your backlog look like if every ticket started with the real issue instead of the stated one?