A road leads toward the edge of a cliff, passing signposts labeled "Speed," "AI Tools," "Automation," and "More Output," while a final sign asks, "Are we solving the right problem?" under a calm, overcast sky.

Two conversations, one question: what matters more than speed

Two conversations this month had nothing to do with each other on the surface. One took place in a sales meeting about an AI initiative. The other happened while a product owner walked a room of users through a new system. Both left me with the same observation: speed to an answer is worthless if the question underneath it is wrong.

The first conversation. A prospective client wanted to discuss how AI tooling could dramatically increase his team’s delivery speed. He’d read the claims, seen the demos, and wanted to know how fast his organisation could adopt them.

I asked him what problem he was trying to solve. He described a backlog that kept growing despite the team shipping constantly.

“So the team’s fast,” I said. “Is it building the right things?”

He paused. He didn’t know. Nobody had asked that question in months, because the AI conversation had absorbed all the attention that should have gone into figuring out what actually mattered to build.

No AI model, however capable, replaces the discipline of establishing the right problem before optimising the speed of solving it. A team can generate code, tests, and deployments at extraordinary velocity and still be moving further from value with every sprint. Technical productivity and business value sit on different axes, and conflating them is an old mistake wearing new tooling.

💬 Want more conversations like this one?

Conversations lands once a month, straight from the room. Real client and prospect exchanges, anonymised, each built around a moment where listening changed the outcome.

The second conversation. This one happened in a room, not a pitch. A product owner was presenting a new system to its future users. One by one, users raised edge cases: situations the system didn’t handle, workflows it broke, exceptions it ignored.

The product owner’s answer, each time, was some version of: “I understand, but management wants this to be the norm.”

The users kept talking. Slowly, without anyone declaring it, the room’s understanding shifted. The “edge cases” weren’t edge cases. They were the actual shape of the work, and the system had been built for a simplified version of it that didn’t exist on the floor.

I recognise this pattern from enough rooms now: a policy answer overriding a reality answer, followed by that reality reasserting itself anyway, usually at a worse moment than a presentation.

Both conversations point to the same underlying lesson. No level of AI sophistication, and no amount of management conviction, substitutes for listening to the people closest to the problem before deciding how fast to move on the solution. Speed matters. It’s just not the first question.

This is the first entry in Conversations, a new series drawn from real exchanges with clients and prospects — anonymised, and each built around a moment where listening changed the outcome.

If either of these conversations sounds familiar in your own organisation, let’s talk about how to make sure your team is solving the right problem before it optimises for speed. Reach out today, and we’ll start with what’s actually happening on the ground


Discover more from The Software Coach

Subscribe to get the latest posts sent to your email.

Leave a Comment

Your email address will not be published. Required fields are marked *