The customer voice is important

As engineers, we work with a variety of folks who represent and champion the customer. But that's not to say that they all do so fairly and without bias.

Sometimes, it can feel like you're arguing with a brick wall. How many times have you rushed out a feature or update that solves an "urgent" customer requirement, only to discover it was a minor inconvenience for less than 10 individual users? How about those "deal breakers" that push something off the roadmap designed to serve the wider customer base, only for that one super important customer who'd have otherwise churned, to never actually use it?

These are experiences that every engineer has encountered, or certainly will encounter before long if you're brand new to the industry. So what's the deal? Aren't we there to serve our customers? Why does it feel like our time is wasted on these pointless "important" tasks?

Here's how I see it: the customer voice is important, but we should apply our own level of basic critical thinking instead of simply taking them at face value.

Reality check

Products are there to serve multiple customers in a way that aligns as closely as possible to the majority of those customers' needs. It's important to realise that it's almost impossible for a product to serve every customer's needs completely and perfectly.

The whole thing is a balancing act; each customer wants to feel like they're the sole focus of the product, and most are happy to feed in an endless stream of preferences, opinions, demands, and problems. It's the task of the internal teams to manage it all and find the happy path that satisfies the vast majority, instead of favouring a few at the expense of the rest.

But what happens when this balance isn't met? Or worse, what happens when a company forgets that its customers are actually important? Well, let's look at some recent goings on with GitHub and Microsoft.

Getting it wrong

When AI really took off, GitHub binned the vast majority of its roadmap to focus on AI features. Companies need to adapt; there's no getting around that. But, the whole roadmap?! That was very frustrating, and it's left their platform with a lot of rough edges that many of us were already getting sick of waiting for them to address. A big one for me was service tokens. It's very common to have personal access tokens used across CI pipelines, which subsequently break when the person who generated them leaves the company and loses access to the repos. Service tokens were supposed to fix that, but like the rest of their planned features, they were binned off, and now we're left with a lot of immaturity in a supposedly enterprise platform.

Now, Copilot is a perfectly decent product. I use it to aid in development, even let it do a first-pass review on some PRs before I send them out to the team. Do I need it to write commit messages? No. Do I need it to write PR and issue descriptions? No. Do I need it to group changes contextually in PR diffs? No...that's what commits already do, geniuses. Do you know what we do need, though? A product that works properly.

By going all-in on AI, GitHub left many other parts of its product sorely lacking, and Actions is a prime example. As engineers, we want CI to be reliable, fast, and flexible. Yet, GitHub's investment in Actions has been so chronically poor that Zig decided to move off GitHub entirely. This was such a high-profile move that just a few days later, GitHub released a blog talking about the future of Actions. Coincidence? Absolutely not, they were compelled to do something, even if they weren't directly addressing the Zig move.

It turns out that GitHub have been quietly re-architecting the entire Actions infrastructure all along. How convenient that Zig very considerately gave them this opportunity to tell the world about it.

It boils down to a complete failure to listen to their customers. We want to ship quickly and reliably. AI helps to a point, but it has to be tied to a dependable, resilient, scalable platform. It doesn't paper over the shortcomings of the product itself. GitHub's customer success managers, account representatives, and community representatives have been getting flooded with these sorts of requests. This shows a clear breakdown somewhere in their process. Either this feedback went nowhere, the product team was ignoring it, or the executive team was overriding it.

And it's quite clear why this non-AI feedback is getting ignored. Microsoft, the company that's seemingly baffled about its customers not liking its crappy AI features. It's the same pattern seen at GitHub (which Microsoft owns): a flood of feedback about problems with the product that they're building AI into. Is it really so hard to grasp that if the product doesn't work properly, AI isn't going to fix it? At best, it provides a workaround for these issues.

Don't panic

Ignoring customers is one thing. But the balance can also tip in the other direction, where we start listening to customers too much, and every bit of feedback gets escalated internally as a critical requirement or churn risk. This situation can grind the product to a halt.

Attitudes like this lead to rushed one-off features hidden behind flags that only a single customer has enabled, burdening the engineering team. These sorts of additions slow down future development, because now there's this swathe of typically fragile code the team has to work around whenever they're making changes or enhancements in that area. Your engineering team is now having to spend time troubleshooting and fixing test failures for a feature that's enabled for a single customer, while trying to deploy an improvement that benefits all of your other customers.

We've all experienced knee-jerk reactions in our own lives, and in many cases, we'll regret it very quickly afterwards. It's no different to dealing with customers, let's just take a minute and collect ourselves. Is a customer really at risk of churning because they can't customise the colour of the nav bar? Of course not, but we can work together internally to give them a reasonable timeline within which they'll be able to, with the result that engineers can continue to focus on their current features, and the customer feels heard.