Which client conversation did I spend years avoiding?

Which client conversation did I avoid for years?

The one where I tell a client that the thing they have asked me to build will not solve the problem they described. Not that it is badly specified. That it is the wrong work. Under a fixed fee, saying that out loud usually costs me money, which is exactly why it took me so long to start saying it.

Every other difficult conversation is easier than this one. A late deadline has a fix. A bug has a fix. A disagreement about a colour has a fix. Telling someone their plan is aimed at the wrong target means questioning a decision they probably defended internally before they ever contacted me.

I price fixed fee, with most projects landing between one thousand and ten thousand dollars. That structure makes the incentive uncomfortably clear. The path of least resistance is to build what was asked for, invoice it, and let the outcome be someone else's problem.

Why is it so tempting to avoid?

Because avoiding it is profitable in the short run and invisible in the long run. You get paid, the client gets the thing they wanted, and nobody has an argument. The failure shows up months later, by which point the cause is unrecoverable.

There is also a status problem. A client who has already decided what they want does not always experience a challenge as expertise. Sometimes it lands as the contractor being difficult, and that is a real professional risk rather than an imagined one.

And there is the simplest reason of all, which is that I might be wrong. I see one slice of a business. They see all of it. The possibility that my objection is based on incomplete information is genuine, and it makes silence feel like humility rather than cowardice.

What does avoiding it actually cost?

It costs the relationship, eventually. The project ships, it does not do what the client hoped, and the conclusion they draw is that the work did not deliver. They are not wrong about that, even though they specified it.

It also costs the referral. Across more than 70 projects for more than 25 clients over more than six years, the work that generated the most onward introductions was never the work that was simply executed to spec. It was the work where something changed during the engagement because I said something inconvenient early.

The quieter cost is to my own judgement. If I build things I do not believe in, I stop being able to tell the difference between a project I think will work and a project I have simply agreed to. That is the part that is genuinely hard to recover.

What changed my mind?

An engineering habit I had left behind. I trained in aeronautical engineering, where you are taught to state failure modes explicitly before anything is built, and where saying "this will fail under these conditions" is a professional obligation rather than an opinion.

Somewhere in moving into client work I had absorbed the idea that the brief was the requirement. It is not. The brief is one person's proposed solution to a problem, and treating it as immovable means the actual requirement never gets examined by anyone.

Once I framed it that way, the conversation stopped feeling like a confrontation and started feeling like part of the job. Nobody thinks it is rude for an engineer to identify a load the structure cannot carry.

How do I open the conversation now?

I restate their goal in my own words, and ask whether I have it right. Almost every version of this conversation gets easier if the first thing on the table is their objective rather than my objection.

Then I say plainly what I think will happen if we build what is specified, and why. Not softened, not buried in caveats, but also not delivered as a verdict on their competence. The sentence I use is close to: here is what I think this will and will not do for the goal you just described.

What I avoid is presenting an alternative immediately. If I lead with my own idea, the conversation becomes a comparison of two proposals and my motives look self serving. If I lead with the gap, we are both looking at the same problem.

What do you do when the client disagrees?

You write down the disagreement and then you build what they asked for. It is their business and their money. What is not acceptable is building it while privately believing it will fail and saying nothing, because that is the version where nobody learns anything.

Recording it matters more than winning it. If the work ships and my concern turns out to be wrong, I want to know that, because it recalibrates my judgement for the next project. If it turns out to be right, the record is what makes the next conversation productive rather than accusatory.

I have been wrong often enough that this is not a rhetorical position. Being wrong in writing is uncomfortable and useful, and I have written about the other side of that in admitting I was wrong to a client.

When should you walk away instead?

When the gap is not about approach but about what is possible. If a client wants a guarantee nobody can honestly give, the conversation is not a design disagreement, it is a mismatch about reality, and no amount of tactful framing fixes it.

The clearest version of this is a promise about rankings or results that depends on systems neither of us controls. That is a hard no rather than a discussion, and I have set out how I handle it in what I say when a client wants guaranteed rankings.

Walking away is rarer than people assume, though. Most of the time the disagreement is about sequence rather than substance, and the honest version of the conversation surfaces that within twenty minutes.

Does having this conversation cost you work?

Sometimes, and it is worth being honest about that rather than pretending candour always pays. Some enquiries end after this conversation. A few of those were going to be bad projects, and a few of them I probably could have done well.

What has changed is that I no longer treat losing the project as the worst outcome. Delivering something I believe will not work, and then having my name on it, is worse. That calculation only works because I have enough enquiries to be able to make it, which is a privilege earned over years rather than a principle available on day one.

The related discipline is not chasing every enquiry in the first place, which shapes who I end up having these conversations with. I have written about that in why I stopped replying to every enquiry immediately.

How do you make it part of the process rather than a confrontation?

Put it before the contract. If the first substantive conversation is about the goal rather than the deliverable, the challenge happens when it is cheap, when nobody has committed, and when the client experiences it as diligence.

That is what discovery is actually for. Not gathering requirements, but testing whether the requested work and the stated goal are the same thing. Discovery that only collects specifications has skipped the hard part.

The practical version is to ask what would have to be true for this project to be judged a success in six months, and to ask it before anything is scoped. If the answer does not connect to the deliverable on the table, you have found the conversation, and you have found it at the right time.

What should you do next?

Look at your current projects and ask, for each one, whether you actually believe it will achieve what the client thinks it will. If there is one where the honest answer is no, that is the conversation waiting for you.

Have it now rather than at delivery. It is a bad conversation at week two and a much worse one at week twelve, and the only variable that changes in between is how much has been spent.

If you are in the middle of one of these and want to think through how to say it, reach out. Working out the right sentence is often the whole difficulty, and it helps to say it to someone else first.