Who are you building for?

As a company scales it’s easy for teams to lose sight of who they’re building for.

With siloed teams and a lack of communication, customer empathy becomes so diluted that it’s just another poster on the wall. But for today’s software companies, customer support teams can keep everyone intimately connected to the problem you’re solving.

Provided they’re set up in the right way, they can make sure the right kind of features are on your roadmap, and the right kind of insights are driving your research team. At the Berlin stop of our Inside Intercom World Tour, I recently discussed how to scale a company while keeping customer experience at its heart.

Prefer a written account? You’ll find a written version of my talk below.

A world of asynchronous communication

Imagine a successful and growing company. If you asked the founder of that company who they’re building for, they’ll be able to answer you quickly and concisely. That’s because the genesis of a new product always involves solving some problem better or more cheaply than ever before.

Good solutions require an intimate understanding of the problem you’re solving, but perhaps more importantly, the people that you’re actually solving it for. What would happen if you ask an engineer at that same company who they were building it for? Would they have the same answer? How about a few of the company’s customers? If you told them the founder’s answer, would those customers agree with that answer or would they laugh in your face?

I think this simple example highlights the question that’s at the heart of scaling a successful business today – how do you build a company where every employee remains intimately connected to both the problem you’re solving, but more importantly, to the customers that you’re solving it for?

Let’s take a step back to ask why we even have to ask a question like this in the first place. In the past, nearly all businesses were small. Most, in fact, were run by just a single family, and you learned the business, its mission and its values because you grew up immersed in it. You knew your customers really well because they were your friends and your neighbors.

Even after industrialization moved us into offices, we still used asynchronous communication methods to do business; either seeing each other face-to-face and shaking hands or using the phone.

But the internet changed everything. Suddenly, you could market and sell to millions at one end, and receive support requests or questions from tens of thousands of people on the other, asynchronously and completely independent of the time of day or day of the week.

It’s not that businesses intentionally set out to forget that customers matter. It’s just that we somehow tricked ourselves into thinking that we could operate differently at internet scale than we have for millennia at human scale. We somehow forgot that without any customers, we don’t have a business in the first place.

The products we build exist to solve specific problems. They exist to make our customers’ lives easier or more enjoyable. But how do you begin to do that in a really human way at internet scale? For me, it starts with customer experience.

Customer experience = perception, product + people

I define customer experience in 3 key components – perception, product, and people. Perception is all about how your current and potential customers perceive your company and your brand.

With your potential customers, as they move closer to signing up to your actual product, those perceptions will become expectations. With your current customers, the way you operate and the way you do business will determine whether you’re building an army of evangelists for your brand or an army of detractors.

For product, ask yourself the following questions.

• How does it feel to actually use your product?
• Is it simple or is it complex?
• Is it an uphill battle or is it effortless?
• Does it even solve the problem that you’ve set out to solve in the first place?

And for people, ask yourself the following.

• Are the interactions your customers having with your team productive?
• Can you communicate personally and concisely?
• Can you fix issues quickly?
• Can you actually take feedback from customers and use it in an effective way?

A bad product supported well is a really bad customer experience. No amount of lipstick is going to make your pig fly. I think that’s pretty clear to all of us.

But a good product supported badly is still a bad customer experience. It’s impossible to separate our expectations and the people we interact with from the actual product itself.

In short, your support team gets to define how good or bad people think your product is.

Bridging the gap

Jeff Bezos once said: “The best customer service is if the customer doesn’t need to call you, doesn’t need to talk to you. It just works.” Of course, this describes a state you’re never going to reach. But it’s our job to try to bridge the gap between our current reality and the one that Jeff envisioned for Amazon.

It’s incredibly important to understand you’re never going to arrive at a place where none of your customers reach out to you and nor would you want to. You have to think of it more as a practice, one where you’re applying constant gentle pressure towards continuously improving your product based on your customers’ feedback.

Where do you begin? No matter what stage your company is at, it’s critical you build a tightly coupled feedback loop that ensures feedback from your customers is getting to the people that actually build and support your product.

In the early days of a startup, product support and research are generally done by one or just a few people, usually the founders. But by necessity, as you grow your product and your business, you’re going to have to separate these into different teams. Even with the best intentions, a lot of times growth means siloed teams with a fundamental lack of communication.

To counteract this silo effect, it’s critical you have processes in place that force people to color outside the lines of their specific area of the organization. Product can’t be allowed to live in an ivory tower, building whatever strikes their fancy.

Your customer support team has to cultivate the long view and really understand that your product vision is built one iteration at a time and not compiled of a jumble of customer anecdotes. Your research team needs to be the glue that binds these two teams together and funnels all that great customer data from your customer support team into actionable insights for your product team.

Product meet support

How do you ensure the product team is being continually brought back to your customers in a way that isn’t just academic? At Intercom we use something called Customer Day. The idea is simple. Designers, engineers, or product managers put down your normal tools and join the customer support team on the frontline for a day. It’s been an eye-opening way to keep the product team, but also every other team in the company, connected to our customers.

What’s most important is that everyone that does a Customer Day is forced to interact directly with our customers. Whether it’s a little hit of dopamine you get when you close a successful conversation or the raw, painful experience of having to deal with an angry customer, I really feel strongly that the Customer Day program has led to a much more balanced roadmap, better designs, and much more careful coding.

A high performing support team can only exist within the fabric of your product. Without a fundamental understanding of the problem you’re trying to solve, and a framework they can use to dig in the customer feedback, it’s really easy for a customer support team, and especially one at a fast growing company, to become apologists.

Applying Jobs-to-be-Done to customer support

Peter Drucker famously said, “The customer rarely buys what the business thinks it sells him”. He goes on to be much more explicit and says, “One reason for this is that nobody actually pays for a product. What is paid for is satisfaction.”

On the support team at Intercom, we use the Jobs-to-be-Done framework to help us discover what it is our customers are trying to use our product to actually do. In effect, we’re trying to create that satisfaction that Drucker talks about.

The Jobs-to-be-Done framework is a way of thinking about exactly that – the jobs a customer is trying to use your product to achieve. In a nutshell, it’s the idea that a to-do list app on your iPhone and a Post-It note are actually competing products. Both exist to help you remember to do something you need to do.

We spend a lot of time and energy hiring these insatiably curious people that are very product-minded for our support team. But we then doubled down on that by starting with Jobs-to-be-Done from the very, very beginning and relating that to every area of our product as they deepen their knowledge.

The result is really powerful. It gives everybody a lens through which they can think about the questions they’re going to ask customers and ensure they are asking the right ones. But it also allows them to unpack and clearly articulate what are the underlying motivations customers have in using our products.

Acting on customer insights

Let’s say you’ve hired a great support team and they’re now producing mountains of raw data from all of the conversations they’re having with your customers. But how do you actually generate key insights out of thousands or tens of thousands of conversations? A solid qualitative research team is the key to weaponizing this data.

At Intercom the support team uses tags to categorize both the type of question asked, but also what area of the product it relates to. Our research team then further refines these groupings using the Jobs-to-be-Done framework.

As the number of conversations that we’ve handled week to week has grown from several hundred to many thousands, we’ve had to become a lot smarter about what to look at and when. A simple example of this is looking for large changes in the frequency of the type of conversations we’re having with customers. For example, if you see a big a change in tagging for certain features, that’s an area you should be digging into more.

Another example of this is digging directly into feature request for a very specific part of the product. A lot of people make the mistake of only asking how many users are asking for a certain feature. But much more important questions to continue asking are:

• How many of those users are paying us?
• What percentage of our user base does that represent?
• And what’s the actual dollar value of those customers when we dig into more detail about them?

When you ask questions like this, you’re left with a much more complete picture about what you might want to put on your roadmap and crucially why you’d want to put it on your roadmap.

Staying connected at internet-scale

Back to our original question – how do you build an internet-scale company where every employee remains intimately connected to both the problem you’re solving but also the people that you’re solving it for? Here’s few ways you can do thta

1. Build a support team that deeply understands the context of your product and knows how to ask the right questions, and then how to convey that information effectively.
2. Build a research team that can take all that raw data and condense it into real key actionable insight for your product team.
3. Build a product team who can take those key insights along with their awareness and empathy for customers and plan the right roadmap.

Simple, right?

Interested in joining our team? The Customer Support team is hiring!