如何向工程师销售 | aadil pickle --- How to sell to engineers | aadil pickle
I started coding at 13 because I liked computers and video games. 5 years later I got a job at Shopify. After working there and at some startups for 3 years, I realized I was probably not destined for a career of staring at a screen for 12 hours a day. Luckily, 2 jobs ago, I had a boss who thought I was good at talking to people, and offered me the chance to move to technical sales. I hit 200% of quata in my first 2 quarters, and felt a similar kind of "problem solving high" I do when working on a difficult technical problem. Except this time, I was programming people instead of computers.
Selling to engineers almost seems mystical to most sales people. The people who are best at it are founders who are technical themselves building solutions for a problem they have themselves. But if you're not a technical founder with deep domain knowledge and empathy, none of the many sales books will help you with engineers. It's especially daunting since engineers are a) very smart and analytical and b) more introverted than your average buyer. If you want to break through to them, you have to…
Sales people and engineers typicaly don't get along because they're often speaking different languages. Engineers are all about efficiency and focus, and sales people are professional talkers. There's going to always be some disconnect between people who optimize for being wired in alone vs. people who enjoy the dance of connecting with others.
Engineers are smart and perceptive. Your social tricks and BANT qualification frameworks and SPIN selling and making them feel their pain and double clicking sales script is all analyzed, dissected and seen though the second you open your mouth.
So, don't do any of that. Have a normal conversation. It throws them the f*ck off.
They have a problem. You might have a solution. Act as an engineer would. Try to understand the problem as deeply as possible, then recommend some ideas you think would work.
This sometimes involves mentioning a competitor's solution! Don't panic — it doesn't matter. They already know all your competitors, you mentioning them doesn't give them any new information. Engineers are generally very well read and researched. The most you can do in a sales conversation is build a rapport, teach them something new, and maybe offer some unique pricing options not available on your website. Then let the customer do their own analysis and come back to you.
Persistance and asking for the sale still apply here the same as anyone. Even when writing follow up emails, engineers know more than anyone when you're using an automated sequence. I suggest using Superhuman reminders, then an exponential backoff email frequency (1, 3, 7, 14 days then close it out). If the conversation is going well, make them an offer. Don't try to hide that you're selling them something — they already know.
Make them feel like a real person. Engineers are used to buying SaaS from a screen, but are human nonetheless. Anyone is more likely to buy from you if they like you, and the way to get an engineer to like you is by breaking the script.
Call something bullsh*t during the demo if you make a mistake. Admit when you don't know something, or if you don't have a feature they need, and offer to follow up with your team. Then actually follow up.
Every engineer has been burned by a sales person saying they promised something to a customer so they have to build it immediately. Don't be that guy that promises something you don't have.
Software engineers famously love spending 4 hours to automate something that might take them 1 hour to do manually. Sounds dumb, but scale that to tasks which repeat at some frequency and you can see the time savings add up, which is why we all do it.
36
xkcd automation
Any good engineer knows which battles to fight. If they find some software that accomplishes what they're trying to do, $500/month on the corporate card is cheap compared to 40 hours up front plus 5 hours of their time per month.
So across an org, if you can save that amount of time for each engineer, you can see how massive ACV can get. The allure of "saving 10% of an engineer's valuable time they can work on other things" is why were seeing so much [AI software purchasing](https://ramp.com/velocity/are-we-in-ai-bubble) recently.
Indie hackers love to complain about Stripe's 3% fee and hack around alternatives but anyone doing millions in revenue a month couldn't care less. No one's migrating off of stripe because it's a billing system that just works, and engineers know how much of a PITA it is to process millions of payments. Same for hosted versions of open source software.
No engineer ever complains about price if you make thier life sufficiently easier. At my last co. everyone knew we could just hop on the phone with DataDog to save 10k/month by negotiating a volume discount yet no one ever did it - it just wasn't worth the time. Engineers are know value when they see it, and aren't price min-maxxers unless they feel like they're getting ripped off[3]. Software like Datadog, Sentry, Grafana I never hear price complaints about — they just make monitoring and observaibility easier.
What people do complain a lot about are commodities. People love negotiating AWS, storage and GPU cloud bills. After a certain point, compute is just compute as long as it mostly works. More often than not, developers don't see these services as adding value but rather something they need to have and deal with whatever they get.
- *Bonus:** Make something beautiful. Engineers are very opinionated so this won't always work, and is hard to use as a selling point, but sometimes 1 service does just look and feel better than another. Like a Leica vs. a Fujifilm, sometimes people are willing to be convinced by a trial to feel what they like and don't for themselves.
When ofering a trial, make it feel special and earned. Stay hands on and set up regular touchpoints for feedback. Often you can get around objections when someone tries it out and convinces themselves they like it. Engineers prefer self-serve rather than hand-holding and will ask you questions when they need to. If you can get them to complain, you're winning. Even if they seem angry or frustrated, that's just the debugging/stress-test phase. You've only lost if you never hear from them again.
By default engineers assume all sales people are incompetent. And by default, all sales people don't know how to setup a kubernetes cluster. So in some ways, the engineers are correct.
Engineers don't think about money as much as a sales person does. They think about scalability, speed, and reliability. As long as what they're buying costs less than 25% of what they expect it to cost if they build it themselves, you'll never have any trouble on price from a company making over 10M/year. So remove your focus from what you're familiar with like deal terms, add-on services, ACV — those are all secondary. Saving money is whatever. Saving time and reducing effort are your selling points.
Think about speed not only when positioning your product, but as you engage in the sales process yourself. Quick follow up emails, quick responses, updates when things are being slow. Be a constant log of information and over communicate. Speed wins deals even more so when dealing with someone who thinks about millisecond latency for a living.
If you want to increase ACV, think about what problems might arise as the customer's company scales. Or to close, what problems would come up if the customer tried to build their own solution or use a competitor that you've already though about and addressed.
Reliabiity is about having a rock solid product, but also having rock solid communication when stuff breaks. Having a solution is always great, but whenever that's not possible, offer best-in-class observability. Engineers are used to inspecting systems freely with logs, but humans systems are by default closed-source. An engineer thinks: "If I know how it's broken I can work around it". Be a human logger. Write quick, proactive, detailed downtime notifications and error messages whenever needed post-sale. And during the sales process, same thing. Be a dev log. Every product update is an opportunity to re-engage a prospect. No one will think this is needy if that's what you're afraid of (as long as you're not actually needy).
Use the product yourself. Devs believe in dogfooding — the practice of internal staff use a product their selling internally to find bugs and improve it before releasing it. You as a sales person need to do this if you're selling to engineers. In general, it's easier to sell a product you love since you can empathize with someone's pain and joy. It's harder to do this for engineers, because there's so many edge cases with technical products, that you can't just "onboard yourself" for 2 hours once. Implementation cost is a real thing, but if you can prove to an engineer you've throught through how they can integrate, maintain and scale your product into their systems, because you've done it before, many of their objections quickly diminish. Easier said than done.
Don't take someone out of flow. Trying to talk to an engineer when they're wearing headphones is a cardinal sin. If there's that much resistance to a coworker, imagine what it's like if you're a stranger who's trying to talk them into paying thousands of dollars. As such, they're somewhat wary if you even try to schedule a sales call, since they know it's a distraction that takes them away from focus work or product meetings. Deals with engineers can be closed over email and Slack if everyone's satisfied.
Engineers are a bit like cats - don't be too loud, don't agitate them, and let them come to you.
[2] Reality doesn't matter in the buying process. Again, engineers love automating, even if it doesn't actually help anything.
[3] On the contrary, we negotiated our Hubspot contract a million times — no matter what price, CRMs always feel like a rip off, and it's sales people on both sides just trying to win.