Why engineers build the wrong thing (and how to stop it)

Every engineering team has stories like this.

A customer joins a call and mentions in passing "the export feature is really painful." A founder or PM jots it down, creates a ticket called "Improve export functionality," and moves on with their day. Two weeks later, an engineer ships an export that's twice as fast. The customer thanks them for the update... but says that wasn't what they meant at all — they wanted a different file format instead.

Nobody lied. Nobody was incompetent. The customer said X, the PM heard Y, the engineer assumed Z, and three weeks of work solved a problem nobody had.

It happens on almost every team with an engineering backlog. Most teams shrug it off as the cost of moving quickly.

They shouldn't.

The natural inclination when a sprint ships the wrong thing is to blame communication. "We need better standups." "The PM should have been clearer." "The customer should have been more specific."

But each of these failures almost always happens at a very specific point in the process — when the request moves from customer language into a ticket.

Customers speak ambiguously by necessity. They know the symptoms of their problem, not the solution. They'll say "it's slow" when they mean "queries time out on files larger than 50MB." They say "I want more control" when they mean "I need to restrict export permissions based on user role." They say "the onboarding is confusing" when they mean "the invite button was invisible to me."

When you put that messy language directly into a ticket, the ticket inherits that ambiguity. An engineer reading "Improve export functionality" cannot build what the customer wants without making assumptions. They'll assume what they think is most likely, build it, and ship it. If they guessed wrong, no one finds out until demo day.

This is the point where the customer's intent dies. And almost no team has a process for ensuring it doesn't.

Let's dig into what actually happens when an engineer reads an underspecified ticket.

They usually won't ask for clarification because no engineer wants to ask questions that might imply they don't know their job. They'll make an assumption about what to build and keep the sprint moving.

The assumptions they make will generally be reasonable ones. If the ticket says "users want faster load times" they'll optimise the slowest query. If it says "improve the dashboard" they'll clean up the layout. If it says "fix the onboarding flow" they'll add tooltips.

Each of those examples are technically correct ways to interpret those tickets. But none of them guarantee they've built what the customer actually wanted.

The danger isn't in engineers making assumptions. It's in engineers making assumptions silently. There's no hurdle in the middle of the process where someone stops and asks "wait, what problem are we actually trying to solve?" Someone makes an assumption about the ticket, it gets baked into the build, and no one double checks it until the customer sees the result.

I've helped teams write and use tickets for years. After looking at enough teams, three failure modes keep coming up.

• —Undefined scope. The ticket only describes a problem, not what's in scope or out. "Improve the permissions system" can mean anything from adding one new role to rebuilding your entire access control layer. An engineer will make a judgment call on what that means. The PM had something else in mind.
• —Unmeasurable success criteria. The ticket states the goal ("make this faster") but not what faster actually means. There's no objective way to determine if the ticket was completed because there was no measurable "done" definition. The engineer ships something, calls it complete, and the PM realizes they had a much higher bar in mind.
• —Missing user context. Similar to undefined scope, the ticket doesn't describe who this change impacts or what those users are trying to do. Building for customer segment A vs B will lead to different decisions. If "this affects enterprise customers performing bulk uploads of 40+ records" isn't clear from the ticket body, the engineer may unintentionally optimize for the common case.

The danger in each of these bullet points is that they're invisible when someone writes the ticket. They only become visible weeks later when you ship something that doesn't solve the right problem.

The solution is not more meetings. It's not having engineers attend more PM check-ins. Heck, it's not even longer tickets.

The solution is a simple, systematic check anyone on your team can do on every ticket before it ever enters a sprint — one that forces them to ask the questions your engineers should be asking if they weren't afraid to speak up.

Here are the questions you absolutely must answer about every ticket:

• —Does it have enough defined scope that two engineers would build the same thing? If not, what details are missing?
• —Does it have a measurable definition of done? Can someone verify if the ticket is complete without asking the PM?
• —Can you point to which users this ticket impacts and what those users are trying to accomplish? Would an engineer building for a different user segment make different choices?
• —Are there any technical assumptions implicitly made by the ticket? Does the ticket implicitly assume a technical implementation that wasn't stated?

These are straightforward questions. Asking them before the sprint begins is the dividing line between teams that build the right thing and teams that build the wrong thing.

The teams that do this religiously — that treat ambiguous tickets like bugs to fix before the sprint starts instead of problems to debug after they ship — have drastically lower rework rates. They build faster because they don't spend a week making something that just needs to be thrown away.

Here's one final gap most teams overlook.

Once teams start catching ticket ambiguity and only write better tickets, they never check to see whether what got shipped actually satisfied the customer's request. The ticket gets marked complete, the sprint closes, and everyone forgets about it. No one asks: did this actually fix the problem the customer described?

This matters because what the customer said and what the customer needs are two different things. It's totally possible to filter out every last bit of ambiguity from the ticket and build exactly what was specified, only for it to not actually address the customer's problem. The only way to know you solved the right problem is to close the loop.

Teams that close that loop — that connect the thing a customer said all the way through to whether it fixed their problem — improve faster than teams that don't. They quickly get better at translating customer requests into tickets. Their tickets get tighter. Their sprints get cleaner. Their rework decreases.

And the teams who never close that loop repeat the same translation mistakes over and over again, sprint after sprint, because no one ever tells them they got it wrong.

Engineers build the wrong thing because some customer said one thing and engineers built something else.

More specifically, engineers build the wrong thing because the translation layer between what your customers say and what your engineers build is full of holes.

And those holes exist because nobody owns it.

Closing those holes doesn't require better engineers. It doesn't require better customers. It just requires a repeatable process for catching ticket ambiguity before it enters your sprint and closing the loop when you ship.

That process doesn't have to be complex. But it has to exist.

Specc is designed to do exactly this — take raw customer feedback, structure it into tickets, catch ambiguity before it reaches engineering, then close the loop when you ship.

Give it a free try at speccapp.com