What is a customer champion

Engineers are often told to “think like a customer.” But how often do we actually invite customers into our development loop?

Enter: the customer champion, a critical bridge between engineering, product, and the people we’re building for.

Simply put, a customer champion is somebody who advocates for customers when working within an organisation. It sounds paradoxical, right? Surely we should always be thinking about the customer? While this is true, explicitly referencing who you're building for in the lifecycle of development is one of the things that can make, or break what you're building.

Knowing this, it would be easy to go "this doesn't seem like an engineering problem". However as we pivot more to AI and autonomous teams within larger engineering organisations, the engineers that work on problems need to think more with a product mindset, and having a customer champion is a great opportunity to flex this way of thinking.

Customer Champions can, and should, be a strategic partner to engineering.

Who is the customer?

Before looking at the practicalities of this type of role, we need to first consider who is a customer through the lens of an engineering team. This could be quite simple, end users who use a feature you build. But there's nuance here, imagine you're on a product platform team building internal tools that enable cross service communication, who are the customers then?

It's questions like this that are really important to ensure you're building the right things for the right people

For a platform team, your customer champion might be a Staff Engineer from another squad who frequently relies on your APIs.

For external products, it might be a Customer Success Manager or a power user embedded in a beta program.

Working with other stakeholders to getting an answer to this question is the first step you should be taking here if unsure.

What do they do?

So far I've referenced a customer champion like a person who is simply tasked with representing a customer. However that's not strictly true, you could have multiple people covering different areas, you could even have an actual customer be this person, there's no real strict requirement here.

When you've identified someone who can give you insights into the particular area you're interested in, you can begin to leverage this person throughout your software development lifecycle.

Simply put, being at the very least a sounding board is a good place to start for the features you're potentially thinking of integrating.

Through the lens of software engineering

Ok great, so this is just a long way of saying "find someone who actually uses the product we build and talk to them". But there's more to it than that, with this relationship now in place you can begin to start going deeper here, and creating the space within your engineering team to get more insights into ensuring what is built today, is still relevant tomorrow, and what is built tomorrow, can be useful into the future.

Here are three ways in the past that I have felt worked well.

1. Shared discovery

   • Looking for work to uncover in your roadmap with product, you can begin to introduce things like RICE scoring to help with making sure the team are working on the most impactful things, looping in your customer champion here can really help.
   • When working together showing early prototypes or wire frames can really help uncover things you may be missing in your implementation, it also encourages engineers to think more with a product mindset.

2. Feedback loops

   • Making sure you retrospectively look at projects and releases to gauge how the customer champions feel about what's been delivered, consider internal or external NPS scores in conjunction with more concrete metrics to ensure that customer champions feel listened to, to encourage further engagement.
   • Shadowing with these customers really helps, going in without any prior bias and simply viewing how they use what you've built is a great opportunity to uncover areas that can be improved.

3. Engineering Excellence

   • Looping the feedback to really drive understand what is important in your system for customers is a great thing to leverage too
   • Think about what actually matters to customers, for example, is response time more important or actual uptime? What drives the most value for customers.
   • Use quantitative feedback from customer champions to define what good SLI's look like
   • Use them retrospectively on incidents, does this severity seem right? Do you feel the impact has been properly assessed?

Whether you're building for 10 internal engineers or 10,000 end users, customer champions help engineering teams stay focused on real world outcomes.

Treat them like an extension of the team, and let their voice shape what excellence really looks like.