Do your software engineers talk to customers regularly? Here's how to make it happen.
If you’re at an early stage in your startup journey, everyone out of necessity probably does some form of customer support.
They did at my SaaS company, Proposify.
Having the people building the product speak directly to the market with no filter, they learn what customers value and how they use the product.
They also hear firsthand about any bugs or usability issues that seem unimportant until a customer is yelling at them about it to their face.
All of this helps you achieve product-market fit.
Over time, this gets pushed to the back burner as you build out a dedicated support team and engineers get busy working on critical ‘keeping the lights on’ activity.
This all makes sense on paper, but over a long period of time, your engineering team will become disconnected from the customer.
Development cycles become longer as teams try to account for every possible use case.
They make a lot more guesses at what customers want and take too long to learn their guesses are wrong.
Over time your product will stagnate because the engineering team is mostly concerned with scaling work, improving the process, refactoring, and repaying technical debt— all of which are important and necessary, but none of it gets noticed by customers and it won’t grow the business.
This causes unhealthy friction with the sales and customer teams who are on the front lines hearing what customers value but not seeing the product evolve with the market.
The two engineering metrics that matter
I learned from David Cancel - founder of Drift and former product leader at Hubspot - how he measures product teams.
He doesn’t care about traditional engineering metrics like lifecycle or burndown charts or anything like that.
He only cares about two things:
How often does the product team talk to customers?
How often do they ship code to the production environment?
A minimum weekly call with a customer ensures they are taking the pulse of the customer on a regular basis and feeling their pain directly to empathize with their struggles. I’ve seen engineers light up when a customer describes a challenge they can easily fix.
Shipping to production multiple times a day is the other important metric because it ensures teams are releasing small improvements that add up over time, and the learning cycle is short. Instead of taking three months to build the wrong thing, they can learn in a day or a week and pivot quickly.
If you’re not doing this today, start now.
Know that you will receive pushback from your engineers.
How to get your engineers to actually talk to customers
The common reason to not talk to customers is that “this isn’t a good use of expensive engineering time.”
The real reason is that it’s uncomfortable and difficult for most engineers.
How do you get around this objection?
Well, you as the CEO can yell and threaten them, but that will require you to stay on top of them every week and probably won’t lead to having a healthy culture.
Instead, ask yourself how you change any kind of human behavior.
Thankfully, BJ Fogg has already done this for us.
The Fogg behavior model outlines three factors:
How motivated is the person?
How easy is it for them to do?
Is there a prompt at the right moment?
For example, we’ll put up with a complex piece of software if we’re motivated enough. If you’ve ever struggled to get your cash out of an ATM you already know this.
But if you’re not motivated enough and it’s hard, you’re just not going to bother.
If you can increase the motivation AND increase the ease, then a trigger or prompt will work and people will change their behavior.
Back to how this relates to engineers talking to customers, I worked with our team to create a system.
Motivation: I spoke with the engineers to explain why it’s critical to talk to customers directly. Some were believers, others weren’t, but I encouraged them to give it a shot before they make up their minds.
Ease: Finding customers and booking calls is a pain, so I worked with our customer success leadership team to create a simple system to make it easy for engineers to join calls.
We made a Slack channel for the CS and sales folks to announce customer calls that were happening and invite them to join. It was as simple as an engineer clicking an emoji and accepting a calendar invite.
Prompt: With these elements in place, I created a spreadsheet showing everyone’s name and how many customers they had spoken to each week. This created visibility and accountability.
Every Friday, Colin, our director of engineering, posted a Slack reminder to update the spreadsheet.
This system increased motivation since no one wanted to be the one with a zero next to their name. Since they could see some were sitting in on multiple calls each week it created some healthy competition.
To add some gamification, I told the department that if we had 100% of the team have at least one conversation in a week, I’d send them all pizzas. It added a fun little bit of motivation.
Within weeks everyone within engineering and QA were regularly sitting in on customer meetings.
The results
Two months later I stumbled upon an email that one of our customer success managers had sent to a customer. It said:
“Things are running like a lean and mean machine. I’ve seen more improvements happen in two months than I had previously seen happen over the course of six+ months.”
There were other factors involved here, and it included a lot of additional effort on people and process that my engineering leaders had been working on for months, but it was clear validation that the customer touchpoints were making an impact.
If you’re not doing this today, I highly recommend giving it a shot.
If you’re not at product-market fit yet, it’s an essential ingredient in finding it.
I’m working on a course to help founders reach product-market fit faster. If this sounds like something you may be interested in, hit “reply” and let me know.
I’d love to learn more about what you would want to see.