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.
A few months ago one of my teammates was sitting on a customer call, and they were demoing their workflow for creating an event in our system, which involves choosing a start date & time, and an end date & time. The system had been engineered so that when they chose a starting date and time, the end date and time immediately jumped to the same point in time. But the system also doesn’t allow you to save an event unless the end time is after the start time. If users forgot to change the end time as well and tried to submit the form, they saw an error telling them as much.
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.
Products are built for people to use. So if you’re asked to work on a feature, it’s because an existing customer has asked for it or someone your company hopes will be a customer in the future has asked for it.
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.
Sometimes developers build cool things. Sometimes customers love the things we build. (Hopefully more than sometimes 😄) Selfishly, hearing customers in real-time and in their own words, share how excited they are about a feature you’ve worked on and how it’s made their lives easier, can feel awesome.
I’m not a fan of saying “always” or “never”, but I’m going to be bold here and say it: more empathy is never a bad thing.
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 see their teammates in other orgs at work increases their understanding of the work they do, not to mention the value it adds and the skill their teammates bring to it!
My company has a program called the “Voice of the Customer.” This is just one solution, and may not be the solution for you or your company.
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!