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

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.