Sometimes a client proposes something that you know won't achieve their goal, or worse, will create serious problems. Maybe they want to store passwords in a spreadsheet. Maybe they want to skip testing to hit a deadline. Maybe they want an architecture that will collapse under load.
How you handle these moments determines whether you're seen as a valuable advisor or an obstruction. The goal is to redirect without dismissing, explain the risks without being alarmist, and arrive at a better solution together.
Why this matters
Handled poorly, the client feels dismissed and the relationship becomes adversarial. They might dig in on a bad idea out of stubbornness, or stop sharing ideas altogether. Handled well, they appreciate your expertise, trust deepens, and better solutions emerge.
The principles
Validate their intent before challenging their approach. They're trying to solve a real problem. Acknowledge that before explaining why their particular solution has issues.
Explain consequences, not just opinions. "That's a bad idea" is an opinion. "If we do that, here's what will happen..." is useful information that helps them decide.
Always offer an alternative. Never just say no. "Here's a better way to achieve what you're after" transforms a rejection into a recommendation.
Use questions to guide the conversation. Sometimes the best way to help someone see the problem is to ask: "How would we handle [edge case]?" Let them discover the issue rather than telling them they're wrong.
What this looks like
Client: "Let's store all user passwords in a spreadsheet so we can reset them easily."
"I understand the pain point. Password resets are frustrating for everyone. Let me explain why the spreadsheet approach would create serious problems, and then suggest something better.
The risks: storing passwords in plain text violates security regulations like GDPR. If that spreadsheet is ever accessed by malware, a disgruntled employee, or a breach, all user accounts are compromised instantly. The legal and reputational consequences would be significant.
What we should do instead: implement a secure password reset flow. Users request a reset, get a time-limited email link, and create a new password. It's industry-standard, actually easier for users than contacting support, and keeps you legally safe.
I can build this as part of the auth system with minimal additional time. Solves the same pain point without the risk. Does that work?"
Why It Works
Validates the underlying concern. Explains consequences clearly. Offers a better alternative. Frames it as protecting them.
What bad looks like
"That's a terrible idea. You can't do that."
Why It's Bad
No reasoning, no alternative, no acknowledgment of their concern. Just dismissal.
Getting better at this
- Start with validation: "I see what you're trying to solve."
- Use consequence framing: "If we do that, here's what would happen..."
- Always provide an alternative that addresses their real need.
- Ask guiding questions: "How would we handle [edge case]?"
- Stay respectful. They're intelligent, just not domain experts in your field.
How this connects
This is gentle pushback applied to technical decisions. It draws on explaining complex concepts (why the alternative is better), asking good questions (guiding them to see the issue), and instilling confidence (showing you're protecting their interests).
Things to try
- Next time a client proposes something problematic: "I see what you're trying to achieve. Let me share some concerns and suggest an alternative."
- Practice explaining consequences without sounding alarmist.
- Build a library of better alternatives for the problematic requests you encounter most often.