#35 A Tech Sales Guide: Stop Selling Technicalities, Start Selling Outcomes
As engineers, we love our technical solutions, but business leaders speak a different language. Learn how to turn your technical proposals into outcomes that the business cares about.
Picture this: A meeting room full of business leaders. A software expert walks in, excited to share ideas that could help the company grow.
We must extract part of our modular monolith to a microservice and move to Kubernetes. This way we can easily handle traffic spikes in the Appointment Scheduling module.
That was it. The moment he used technical terms like "modular monolith," their eyes rolled over. His chance to get support for changes vanished in seconds.
The thing you need to be aware of
Most often - in about 90% of cases from my experience - business people don't care about technical terms like cloud platforms, databases, microservices, or system architecture. What catches their attention are numbers that directly matter to the business:
How much can we reduce our monthly operating costs?
Can we cut customer delivery time from 2 days to 2 hours?
How many new customers can we handle without hiring more staff?
What is the return on investment, and how soon will we see it?
How much revenue are we losing due to current system limitations?
These questions about costs, speed, and business growth are what business leaders care about. How we achieve it - whether through Kubernetes, microservices, or any other technical solution - is why they hired us - software engineers - in the first place.
Think of it like hiring a builder to renovate your house. You care about:
How much will it cost?
When will it be finished?
Will it increase your property value?
You don't need to know about the specific brand of power tools, types of screws, or construction techniques. You trust the builder's expertise to choose the right tools and methods. That is their job.
Selling outcomes, not technicalities
Having all of the above in your mind, always try to find the outcome of your change and sell it. Here are some examples:
Scenario 1 - The current monthly operating costs of the cloud are $100,000
Don't get caught in the trap of explaining technical details about switching services and databases. Instead, focus on the bottom line: "Our solution can cut operating costs in half, saving $50,000 every month."
Now comes the most important part - the investment cost. Let's look at two scenarios:
If the migration costs $1 million, you will need 20 months just to break even ($50,000 × 20 months = $1 million). For an application that is only planned to run for 1.5 years, this would be a poor investment.
But change the numbers, and the story changes dramatically. If migration costs only $50,000, or if your application will run for 10 years, suddenly you are looking at substantial long-term savings.
Scenario 2 - Our customers complain about delivery time
When proposing a solution to speed up delivery, many engineers would dive into technical details, listing all the components and systems we need to change. This is a common mistake.
Instead, focus on the business impact: We can reduce delivery time by at least 25%. In real terms, this means cutting down from 4 days to 3 days per delivery. The implementation will cost between $10,000 and $30,000.
This kind of communication gives business leaders exactly what they need - a clear picture of improvement (X% faster delivery) and cost (Y dollars). Even if you can't provide exact costs (and let's be honest, who can? 😄), having a rough range - whether it is thousands, tens of thousands, or hundreds of thousands - gives them enough information to make a business decision.
Scenario 3 - One of the components will reach the end of support in May next year
Avoid the common technical trap of discussing security vulnerabilities like supply chain attacks. These terms mean little to business leaders and don't convey urgency.
Instead, focus on the business risk: "We must complete this migration by January. After that date, we lose official support, which creates a serious risk of customer data theft and exposure."
This message hits home because it translates a technical deadline into real business consequences. Data breaches mean lawsuits, damaged reputation, lost customers, and potential regulatory fines. No business leader wants to explain to customers why their data was compromised because we missed a critical deadline.
Here are a few other examples presented as one-liners:
“We need to implement proper caching mechanisms” → “We can reduce customer wait times from 3 seconds to under 1 second”
“Our system needs horizontal scaling and load balancing” → “We can handle Black Friday sales peaks without website crashes, preventing $100K in lost sales”
“We should migrate to a newer version of the payment gateway API” → “We are losing $5,000 monthly in declined transactions that newer payment systems would approve”
“Our logging and monitoring infrastructure needs improvement” → “We can detect and fix problems before customers notice them, reducing support tickets by 30%”
“The authentication system needs to be refactored” → “We can cut customer login time from 7 to 1 second, reducing shopping cart abandonment rate by 15%”
As engineers, we are passionate about our solutions. We see the technical beauty and understand why upgrading this database or refactoring that code is "obviously" important. But when we talk in technical terms, we speak a foreign language to business stakeholders. Then we get frustrated when they don't see the "obvious" benefits. And they get frustrated because they can't understand the jargon. A lose-lose situation.
Don’t sell refactoring
When it comes to refactoring, less talk is often better. Instead of explicitly asking for "refactoring time," simply include it in your regular feature development estimates. When you say "This feature will be delivered in this sprint", that time already includes necessary code improvements.
For larger refactoring efforts (like replacing major components), don't sell it as refactoring at all. Find the business value and lead with that. “We found an issue in our application and have an option to get rid of it. If we do it:”
"This change will cut our response times in half"
"We can reduce error rates by 30%"
"This will allow us to add new features twice as fast"
"We will cut our monthly cloud costs by 25%"
Can you see how different this communication is? No explicit mention of “refactoring”. It is the same work, but entirely different framing. You are not hiding the refactoring - you are simply focusing on what matters to the business. That is it.
What is your biggest challenge when explaining technical solutions to non-technical people?
Budibase saves architects and engineers 100s of hours building apps and automating workflows securely.