Customer Awareness as a Developer

Without customers, developers don’t have jobs.

Nothing like a massive generalization to kick things off, but I think it’s true (or if you don’t currently have customers, you’re probably looking for them!). A customer is someone who uses the software you write, which can look like a lot of different things, from businesses or individuals who pay you for your product, other developers that use your tools, or even people within your own company that use them to do their jobs.

For developers to build a product that customers will use and love, it’s important that someone understand their needs and pain points, how they’re using the product now and how they want to use it in the future. In large organizations, there are product managers and product designers and UX researchers and the like whose full time job it is to keep a pulse on this. Smaller companies, on the other hand, often haven’t hired for these roles yet.

Even if your company does have people in these roles, as mine does, I’ve found value in continuing to periodically observe conversations that our customer success or salespeople are having with our prospects and customers. Here are some thoughts on the value I’ve gotten out of it, as well as a brief overview of my company’s “Voice of the Customer” program.

Quick wins for the customer

So my teammate put up a pull request that changed about 5 lines of code, so that when a user chooses a start time for an event, the end time immediately gets set to one hour later (the time period was chosen by doing a quick look in the database to see what the most common length was for an event). Users can still change this, of course, but in some number of cases, we save the users from a few extra clicks, and we always save them from the error, unless they manually & intentionally change the end date to something different.

The moral of the story here is: this was such a small inconvenience for users that our customer success folks would likely have never opened a ticket to have developers change it, but when one saw the small amount of friction it caused, they were able to take the initiative to do a fairly small amount of work to make our customer’s lives better. We can only do this if we are there to see the friction.

Context for why you’re doing the work you’re doing

Many companies also build more future-looking features because they have reason to think that a profile of individual or company that they hope to sell to in the future would be interested in it, or more likely to buy if it existed.

While it’s possible to do our work as developers well without this context, having it can often lead to better design decisions, code that is better future-proofed. Additional context is rarely a bad thing.

See the impact of your work


Empathy for your users.

But also: empathy for your teammates. Developers often seem to see their own work as more valuable, or at least requiring more skill, than the work of their less technical teammates. I’ve found that having folks , increases their understanding of the work the other orgs within their company do, not to mention the value it adds and the skill their teammates bring to it!

“Voice of the Customer” Program

Every quarter, everyone in the company sits in on one prospect phone call and one customer phone call (salespeople don’t need to sit in on additional prospect phone calls beyond their own, and customer success folks don’t need to sit in on additional customer phone calls beyond their own).

You’re never required to participate in the calls beyond observing (I usually don’t), though it sometimes becomes worth doing — if a customer has a technical question that their customer success manager would otherwise have to open a ticket and get back to the customer about, but you know the answer to, why not speak up? If a salesperson is in conversation with a company that builds a tool the dev team uses and loves, why not say so?

If you’re concerned about buy-in for something like this, I have anecdotal evidence that people seem to find it useful: after each call they participate in, everyone fills out a short reflection form (really short, it takes ~2 minutes to fill out). One of the questions on it is “Was this a worthwhile use of your time?” I looked at responses over the past two quarters, and the responses from everyone, company-wide, was unanimously, “Yes.”

Even if your company doesn’t have or isn’t interested in starting something like this, there’s no reason you as an individual couldn’t ask a customer success or salesperson if they would mind you shadowing one or more of their phone calls — in my experience, they’re pretty excited to have developers interested in their work and would be happy to have you!

Senior Software Engineer |

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store