How Hard Should You Push? | Customers, Etc

Imagine you’re a sales engineer working hard to get a deal across the finish line. The account executive (salesperson) has just sent over the terms of the contract, which will be negotiated in the coming weeks. Your role as product expert is mostly complete, but you want to be ready in case any unforeseen problems arise.

When reviewing the prospective customer’s trial account, you notice something wrong with their data. The prospect hasn’t noticed the anomaly—yet—but it could potentially represent a significant bug. You’re worried it could jeopardize the deal if the prospect discovers the issue at the 11th hour, so you get ready to raise the issue with the product team. At this point, you’re faced with a question:

How hard should you push? 

When you make your escalation request—whether it be a JIRA ticket, an email, a Slack message, etc.—how much weight should you put behind this issue to try to influence the product team to look into it? The product team has limited resources, and presumably they can’t work on everything, so how do you know how hard you should press for the team’s attention on this issue vs all the other things they could potentially be working on.

What makes this an interesting question is that every team is different in how they push to get things done. Teams have different motivations, which will affect what they push for.

Sales is going to push for issues affecting deals that are most likely to close, and there’s of course increased urgency with deals further along in the pipeline. Because incentives matter, salespeople are going to ask for more of the product team’s attention when more of their commission is on the line.

The customer experience (CX) team is going to push to address pain of current paying customers. Sometimes this will mean advocating for bug fixes for the largest paying customers, while other times it will mean pushing for the fixes that affect lots of customers, regardless or how much they’re paying.

Most of the ways we push aren’t entirely conscious. For people who have been in their respective roles long enough, you can start to feel what you push for. But where feeling falls short or perhaps when feelings aren’t aligned across various roles and functions, there’s a need for strategy to help guide how and what to push for.

We talked about strategy at length earlier in this newsletter (parts 1, 2, 3, and 4) and it comes into play when figuring out how to push for customer issues in different parts of the business. By clarifying strategy, people working in different parts of the organization will have a better sense of what tradeoffs are being made to better align activities. This helps individual contributors and managers know the rough boundaries on where (and if) to push.

Let’s take an easy example. If you’re a software company that serves customers at scale, you’re going to be hesitant to dedicate precious engineering resources to write custom code for individual customers. That’s part of your strategy. Any resource spent working on code for just one customer is a resource not aligned with your strategy of building a scalable product for many customers. If this is clear, then the sales team will know not to push for deals where the prospective customer is asking for bespoke code from your company’s engineers. It’s not part of the strategy, so sales isn’t going to push for it. 

The other reason strategy matters is that it helps the product team set expectations with internal stakeholders as to where it’s prioritizing its attention. 

For example, let’s say the product is experiencing a lot of bugs after a recent release, which, perhaps inconveniently for the product team, is also generating a lot of positive buzz. While the support team is filing issues on behalf of paying customers, sales engineers are asking for help with technical evaluations to get more prospective customers across the finish line. The product team is feeling the pressure and can’t keep up. What’s the strategy to guide decision-making?

There’s not necessarily a right strategy here, but there needs to be a strategy. Should the product team pause on tech evaluations and focus on bug fixes? Or should the product team instead focus on getting deals across the finish line while finding workarounds for existing customers? Each strategy will have trade-offs, but at least if the business can agree on a strategy, different teams within the business can clearly align activities. For example, if the business decides the product team should assist in tech evaluations only on deals above $100,000, the sales team might focus energy on smaller deals that are less complex rather than push for a resource they know they’re not going to get.

When the strategy is clear, that drives a need for clarity in each part of the business that may wish to push for the product team’s attention.

Here’s a quick anecdote from FullStory. A few months back, one of the engineering teams was struggling to keep up with all of the requests from the support team. We’d ping engineers on Clubhouse cards asking for updates to ongoing issues, but there wasn’t time to get to all the requests. The engineering organization could have pulled in engineers from other teams, but there was a clear strategy that there was only so much engineering attention to work on our requests—engineers were needed elsewhere for new product development—so something had to give with the way we were asking for engineers’ attention.

One day while working on an issue for a customer, rather than ping engineering once again for an update, I decided to spend a little more time re-familiarizing myself with the history of the ticket. It turns out this had been a trial customer who had experienced a bug a couple months prior. Engineering hadn’t had time to take a look, so we hadn’t been in touch with the customer for weeks. When I looked up the customer’s account, it turns out their trial was expired. Here we were, continuing to ask for the engineering team’s attention, for a customer that didn’t even exist. Oof.

While I’m ashamed to admit we got to that state, that experience drove us to overhaul our practices on the support engineering team. We started adding more details to our requests to engineering, including, yes, whether or not the customer actually exists. These additional details began to guide prioritization and over time, we got a much clearer sense that we were focusing on what really mattered, not just spinning our wheels trying to stay on top of internal communication.

It’s okay to push for your customers and prospective customers—that’s your job, regardless of where you fit into the customer’s journey. However, as resources become scarce, you can expect the business to clarify its strategy, which will ultimately guide you on where and how to push on behalf of customers.

In last week’s newsletter, I reflected on the hope I have for the customer service industry based on my experience at Stella Summit 2020. Their recordings are now available online.