At the risk of butchering an analogy, imagine a family hiring a builder to extend their house to create a bigger kitchen.
They've been planning for a while and they finally have the funds together, a deadline, and a clear idea of what they want.
- A wall here.
- Doors onto the side path.
- A bigger kitchen at the back.
The builder looks at the plan and can see the problems. The wall will block most of the natural light. The doors will technically open, but the path outside will be too narrow to use properly. The kitchen will be bigger on paper, but darker and more awkward than the one they already have.
The family seem sure, so the builder says:
“Yep, we can do that.”
The work starts. The builder gets paid. The family only really understand the problem when they are standing in the finished kitchen wondering why it feels worse.
The builder followed the brief but they failed the client.
What's my point?
I’m seeing versions of this behaviour too often on some digital transformation projects.
A client asks for a feature, a workflow, a dashboard, a report, or another step in a process. The delivery team can see the weak assumption, the awkward user journey, the edge case, or the thing that will obviously frustrate people once it goes live.
But this is where some teams lose their nerve.
They can see the problem and they know the brief is flawed. They know the work will probably land badly with users.
But challenging the client feels uncomfortable, so the concern gets softened, parked, or dressed up as a “risk to monitor”.
“Yep, we can do that...”
Why does this happen?
I think this happens for a few reasons.
Some of it is commercial. When the client is paying the bill, it can feel safer to be agreeable than useful. Some suppliers learn to treat challenge as a commercial risk, so they save their strongest opinions for internal meetings where they cannot help the client.
Some of it is leadership. The people close enough to see the problem may not feel senior enough to challenge it, while the people senior enough to challenge it are often too far from the detail. Some teams have plenty of delivery management and very little product leadership. The team keeps delivering, tickets get closed, the roadmap stays tidy, and nobody quite owns the question of whether this is still the right thing to build.
And sometimes the stakeholders and delivery team are simply too far away from the real-world consequences to the users. The client gets the milestone. The supplier gets paid. The users get the workaround.
Speak up early and often
Of course clients should own the decisions: they hold the budget, the priorities and the trade-offs. But a delivery team that only ever says yes is not really offering valuable expertise.
Good teams do more than take the order. They stick their neck out early enough for it to matter.
They say:
“We can build what you’ve asked for. But before we do, we need to talk about what we think it might break.”
Yes, that conversation might be awkward and that's okay.
Better an awkward conversation now than an expensive mistake users have to live with later.
