Every requirement that arrives in your team’s backlog contains a hidden assumption. The assumption is that the person who wrote the requirement already knows what the customer needs and how to deliver it. The team’s job is to implement what was specified.
That assumption is wrong more often than anyone admits. And the teams that never question it are the ones that ship features nobody uses, deliver projects on time that don’t produce results, and wonder why their product owner feels the need to specify every detail before the engineers can begin.
The fix is one question. Asked before anything else. Asked every time.
Who is the customer, and how do they get value out of this change?
What That Question Actually Does
Most requirement conversations start with the what. What needs to be built. What the acceptance criteria are. What the definition of done looks like. The engineers who ask good questions ask about edge cases, dependencies, technical constraints.
Nobody asks about the customer.
Not because they don’t care — because the format of the requirement doesn’t invite it. The ticket says build this. The story says as a user I want this. The implicit message is that the customer value question has already been answered upstream, and the team’s job starts where that answer ends.
But the customer value question has almost never been fully answered. It has been assumed. Leadership decided what to build based on what they believe the customer needs. The product owner translated that belief into a requirement. The requirement arrived at the team as a specification.
At no point did anyone ask the people closest to the system — the engineers who know how it actually works, what it can do, what it has done before — whether the specified solution is the best path to the customer value everyone claims to be working toward.
Asking who is the customer and how do they get value reopens that conversation at the point where it can still be acted on.
What Happens When Nobody Asks
When engineers skip the customer value question and go straight to implementation, a specific and predictable pattern emerges.
The team becomes order takers. Not because they chose to be. Because the format of the work trained them to be. A requirement arrives. It specifies what to build. The engineers figure out how to build it. Nobody asks why.
The product owner feels this and responds to it. When engineers never ask about customer value, the product owner concludes — reasonably — that the team cannot be trusted to make decisions about value. So they start specifying more. More detail in the requirements. More prescriptive acceptance criteria. More oversight during implementation. More review before anything ships.
This makes the order-taking worse. The more the product owner specifies, the less the engineers have to think. The less they think, the more the product owner has to specify. The cycle compounds.
The team that never asks the customer value question ends up in a relationship with their product owner that looks like a contractor relationship. Here is the statement of work. Build it exactly as specified. Come back when it is done.
That is not a product team. That is an outsourced development shop with the overhead of Agile ceremonies.
The Vendor and Tool Problem
The clearest version of this plays out when leadership decides on a tool or vendor without any input from the engineering team.
It happens constantly in large organizations. A business problem gets identified. Procurement gets involved. A vendor gets selected. A contract gets signed. And then the engineering team gets told: implement this tool.
Two ways of receiving that requirement produce completely different outcomes.
The first way: Tell me exactly what I need to build to implement this tool.
This approach treats the tool as the destination. The team maps out the full implementation, figures out all the dependencies, builds everything the tool requires, and ships it when the entire implementation is complete. Value arrives at the end — if it arrives at all. If the tool turns out not to solve the problem the way everyone hoped, that discovery comes after all the work is done.
The second way: How will this tool provide value to the customer, and what is the smallest thing we can build to start delivering that value?
This approach treats the tool as a means to an end. The team asks what the customer actually needs from this tool, identifies the piece of the implementation that delivers the most important part of that value first, and ships that. Then the next piece. Then the next.
Value starts arriving before the full implementation is complete. If the tool turns out to have problems — if it does not behave the way the vendor said it would, if the customer does not respond to it the way leadership expected — the team finds out early, while there is still time to adjust.
The requirement was the same in both cases. The question changed everything about how it was approached.
What the Product Owner’s Job Becomes
When engineers ask the customer value question consistently — when it becomes the first thing they do with every requirement — something changes in the team’s relationship with their product owner.
The product owner stops needing to specify everything.
Not because they decide to step back. Because the engineers are doing the thinking that the product owner was doing on their behalf. The engineers are asking about the customer. They are connecting the requirement to the outcome. They are making decisions about how to deliver value rather than waiting to be told.
The product owner’s job shifts from order-giver to subject matter expert. They stop writing requirements that contain all the answers and start having conversations that share all the context. The engineers take that context and figure out the best path forward.
That shift does not happen because someone announced a new process. It happens because the engineers started asking one question that changed the nature of every conversation that followed.
How to Introduce It
If your team is not currently asking this question, you cannot introduce it by announcing it. Telling engineers to ask about customer value in refinement is the same as telling passive engineers to speak up — it lands in an environment that has not changed, from a manager who may or may not still be there in six months, and produces a nod followed by the same behavior as before.
You introduce it by asking it yourself. Every time. In every refinement session. Out loud, so everyone can hear the question and the answer.
Who is the customer for this story, and how do they get value from this change?
Ask it before anyone talks about implementation. Ask it when a new epic gets broken down. Ask it when a vendor tool gets handed to the team. Ask it until the engineers start asking it before you do.
That is the moment the question has become part of how the team works — not a technique the manager uses, but a habit the team has internalized. The requirement arrives. Someone asks the customer value question. The conversation that follows is different from the one it would have been.
Everything that comes after that conversation is better for it.
Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems is available now. Get it here →
Paid subscriptions are open at danielholt.substack.com.
Use code AUGUST20 for 20% off a paid subscription or the book through August 31.
Top comments (0)