When Customers Say No: The Unexpected Door Solution Architects Should Never Ignore
Disclaimer: This content reflects my personal opinions, not those of any organizations I am or have been affiliated with. Code samples are provided for illustration purposes only, use with caution and test thoroughly before deployment.
“Sorry, but that just won’t work for our organization.”
Ever been in a customer meeting where the conversation seems to hit a brick wall? As a solution architect, you pitch your best cloud strategy, only to be met with a polite—sometimes not-so-polite—rejection. Most folks would pack up and move on. But what if this is the moment you should lean in and ask… why?
Why Objections Are Your Secret Weapon
Welcome to the first episode of my series on soft skills for anyone in a customer-facing technical role: solution architects, sales engineers, account managers, sales reps, and tech leads who want to truly understand their customers. If you think technical skills are the hard part, think again. Those are easy to learn. It’s the soft skills, like handling objections, that separate good architects from great ones. After four years in the trenches, I’ve learned that every “no” is a door waiting to be opened.
The Power of Counter-Questions
When a customer objects, your instinct might be to defend your solution. Instead, try asking questions. There are two reasons for this:
- Understand the real objection: Use the “5 Whys” technique to dig deeper. Ask “Why?” up to five times to uncover the root cause. Sometimes, what sounds like a technical objection is actually a business or organizational issue.
- Gather information: The more you know about their context, the better you can tailor your next proposal. Don’t walk away empty-handed. Uncover some information that will help you understand this customer better and see the overall picture of their organization. Later when opportunities pop up, you can better grasp it.
Understand the Real Objection
Here’s a realistic exchange from a cloud migration pitch:
Architect: “We recommend moving your workloads to a managed Kubernetes service for scalability and reliability.”
Customer: “That won’t work for us. Our compliance team says cloud isn’t secure enough.”
Architect: “Can you share more about those security concerns? What specific risks are you worried about?”
Customer: “Mostly data residency. We can’t store sensitive data outside our country.”
Architect: “If data residency could be guaranteed, would cloud be an option?”
Customer: “Possibly, but our apps also rely on legacy systems that aren’t cloud-ready.”
Architect: “What makes those systems hard to migrate? Is it technical debt, vendor lock-in, or something else?”
Notice how the initial objection (“cloud isn’t secure”) was actually about data residency and legacy integration, a classic XY problem. By asking questions, you uncover the real blockers.
Walk Away with Important Information
Here is another example, with a bit more drama:
First meeting: Architect and App Dev Team
App Dev Team: “Nothing you said would work for us, we only want to build our own AI stack.”
Architect: “So, what’s driving your push to build your own AI stack?”
App Dev Team: “Honestly, every time we propose something, the platform team shoots it down. We’re tired of waiting for approvals. If we build our own, we control everything.”
Architect: “Is it just about control, or are there features you’re missing?”
App Dev Team: “We need AutoML. The platform team’s AWS setup is too rigid. We’re blocked at every turn.”
Architect: “If you could get AutoML on AWS, with less friction, would you consider it?”
App Dev Team: “If it means fewer roadblocks, yes. But I doubt the platform team will ever agree.”
Second meeting: Architect and Platform Team
Platform Team: “Everyone needs to use our platform-team approved components. Period.”
Architect: “The app dev team is frustrated. They feel blocked and want to go their own way. What’s your perspective?”
Platform Team: “We’re just trying to keep things standardized and secure. If every team does their own thing, it’s chaos.”
Architect: “What if you could offer AWS’s managed AutoML as a shared service? It’s compliant, increases AWS usage, and gives the app team what they want.”
Platform Team: “If it’s AWS native and fits our standards, we can support it. We want teams to use AWS more, but within our guardrails.”
Architect: “Great. Let’s set up managed AutoML on AWS, document it, and let the platform team offer it internally.”
This scenario highlights how technical objections are often symptoms of deeper organizational friction. The app development team’s desire to build their own AI stack wasn’t just about technology, it was a reaction to repeated pushback from the platform team. By asking targeted questions and listening to both sides, the architect uncovered the real barrier: a lack of trust and alignment. Instead of forcing a solution, the architect reframed the conversation around shared goals, like increasing AWS usage and maintaining standards. The result was a win for both teams: the app dev team got the automation they needed, the platform team retained control and compliance, and the organization moved closer to its cloud strategy. This is the power of handling objections with curiosity and empathy.
Discovery Over Selling
The goal of these meetings isn’t to close a deal on the spot. It’s to learn. The more information you gather, the more likely you’ll find a solution that truly fits. Sometimes, the problem the customer describes isn’t the one you need to solve.
Next time you feel the meeting winding down, resist the urge to retreat. Ask one more “why.” It might sound awkward, but it’s your chance to turn a rejection into a relationship.
