Skip to content

Everyone should talk to customers – even engineers

What drives software startup product development is feedback. After all, the point of a startup is to learn what folks will pay for (money, time or attention) and to do so before you run out of money yourself.

The business listens in on sales calls and customer calls, recording them and throwing them into AI to summarize and distill them down to improvements and adjustments those teams can make.

And product managers might listen to those calls, too.

And then product managers filter that feedback down to sprints and tickets and roadmap slides – when things are working right.

Sometimes those tickets and sprints and roadmap slides instead come from somebody’s intuition, their guesses, their bets.

And then that ticket lands on an engineer’s desk in a planning session – and then an entire process begins with your best engineers asking questions to try to get back to the beginning – to what’s the core problem we’re trying to solve.

You can short-circuit almost all of this with one simple change:

Put your engineers on customer and prospect calls.

Don’t just attach a recorded Zoom to a ticket (though, that’s better than nothing!), or email a recorded Gong (even the best intentioned won’t watch it) – actually put them on the call from the start.

Yes, you will be taking them away from their keyboards for a bit – but doing so saves so much time later. The context they can gain makes the work definitions come much easier later because you empower the engineers to make decisions about which corners can be cut to solve the customer pain or problem – because they know that pain or problem firsthand.

You might also get resistance from the other side – from the engineers themselves.

Some of us are would-be misanthropes that like to pretend we like working in dark basements with noise-canceling headphones and a hoodie over our head. To be fair, when we need to get shit done, this might be true (and is an awful lot of fun from time to time with the right soundtrack).

One of the biggest drivers of job satisfaction for an engineer, however, is knowing that what they are working on matters. Hearing firsthand from a customer provides that meaning to the ticket that lands on their desk later.

Even with that benefit, it’s still another meeting – something a wide swath of engineering talent also reflexively hates.

So, a technique I’ve used repeatedly is to set expectations.

“I don’t need you to interact on the call. You don’t need to turn your video on or even come off mute typically. You can do other work while you listen in.”

My goal was to get them on the call – only to soak up context. For some, that’s all they’ll get out of it – knowing that there are indeed humans with problems at the other end of their work.

Some, though, will go beyond that minimum. They’ll spot problems that can be easily fixed – the unexpected ways a demo snags, or the hare-brained ways customers use the product – and generate tickets of their own. Or fix things alongside their regular work – “while I’m here …”

This added context – knowing who your customer is and what they’re using or what they’re buying – also makes the hackathons we talked about recently become much more productive.

Engineers like problems to solve – and customer and prospect calls are filled with problems.

Some other things to think about if you start this practice with your engineering squad:

1. Remember it’s a meeting: There are rules for when to schedule a meeting with engineers. Each meeting has the chance to interrupt flow – the state where engineers can crank out three weeks of work in three uninterrupted hours. So, pick calls that are right before or after lunch, or the start of the day.
2. Not all calls: Your engineers are not your Account Executives or Customer Success Managers, you don’t need them on every call. Pick and choose the calls that are relevant to a feature they might be working on or are scheduled to work on, or with a customer that’s a power user of something they worked on in the past.
3. Not all engineers, all the time: The quota is one engineer on a call (barring an acute customer issue which requires team debugging or a show of force). So, if you have an entire team of engineers working on a feature, you can spread them out among customers and prospects over time.
4. Keep it easy: The other quota is how often do you want engineers on these calls. I shoot once a week, but by introducing it, you might have better luck with once a month. Aside: this project also tends to align very well with goal setting frameworks like OKRs or EOS rocks if you need such things.
5. Don’t put expectations on it: This is a case of results coming later. Not every call is going to feel like a good or worthwhile experience. Some calls involve angry or disengaged customers or prospects – they can’t all be winners. Do the work, and eventually, you’ll get a hit.

Leave a Reply

Your email address will not be published. Required fields are marked *