Developers, Get on That Customer Call

Many articles have been written to discuss whether developers should interact directly with customers (1, 2) or not (3). There are also different types of customer interactions. At Tableau, we have Dev-hosted programs like Customers in the (Virtual) Office, user research studies, etc., where developers can interact with customers. Your company may run similar programs. These programs are usually well promoted and well received by both customers and developers. There is, however, a type of customer interaction that has been underrated but one where developers can have an outsized impact on both the customer and the product, especially for enterprise software products like Tableau.

I am referring to those calls where developers help the customer to deploy the product to their environment. From a product development point of view, problems that surface in these calls are challenges to integrating your product with other components in the customer’s environment. Since this is a blog post for developers, let’s call these “integration calls”. Some integration calls are consultations where customers need to know certain things to determine their deployment strategy. Most, however, are debugging calls where we help customers identify the root cause blocking their effort. Developers should be familiar with these challenges to expand the product’s integration capabilities. From a business perspective, I hope this flywheel can help you visualize the impact of being in such calls.

At Tableau Mobile, we have been in numerous integration calls since we first released the Tableau Server companion app back in 2012. The app supports Tableau Server on-premise and Tableau Online deployments. At the beginning of our mobile journey, the phrase we heard a lot was that customer X could not sign in from the mobile app. We tested the app, and it worked on our test servers, lots of them, so how could that be? As we jumped on those calls and started peeling back layers of the onion, we discovered that enterprise environments are indeed a different beast with custom-made armor and weapons pointing at each other. We learned and gained many insights such as perimeter vs. zero-trust security, IDP-specific quirks, device browser for authentication, varieties of SSO, EMM, etc. Most are unique to mobile, some extend to all client applications (e.g., Tableau Desktop, Tableau Prep, Tableau Web App, etc.), and most apply to both on-premise and cloud deployments. More importantly, we have been applying these learnings to expand the app’s integration capabilities over time.

To be clear, this is not to say that we support every customer request that comes our way. We often have to generalize the request, and some custom configurations do not make sense for us to support. Ultimately, these are business decisions that should happen with a clear understanding of the requirements, costs, and benefits. It is still good for developers to learn about such use cases and provide alternatives for customers to move forward with.

We should also acknowledge that integration calls can be stressful. Naturally, being in an integration call involves understanding the customer’s environment, something that you may not have prior knowledge about. Live debugging in front of customers with limited data is a daunting task, as is being expected to be a Subject Matter Expert (SME) in an area where you may not be. Today, I want to share some of the practices that we have developed over time to have productive integration calls, especially those where you have to debug with customers.

1. Identify the right set of people to be on the call

A development team usually has multiple responsibilities and not everyone is an expert in all of them. There are also times when you need people from multiple teams to be on the call. For example, we have instances where an issue reported as a mobile issue turned out to be a SAML misconfiguration on the server side. Mobile developers likely would not be able to guide the customer as well as the relevant server developer would. On the other hand, configuration issues are something that tech support is familiar with. These nuances are usually opaque to customers. Being in a call where you are expected to be an SME for something that you are not is awkward, a waste of time for everyone, and erodes the customer’s trust. As a developer, what you can do to minimize this is to ask the person scheduling the call to get sufficient context from the customer ahead of time. This context should help you to identify who should be in the call.

2. Identify the best context for you

You should also know what context is useful for you to triage/debug and help the customer help you. Identify what context you need and iterate on that context over time. This is arguably a step 0. Initially, we only asked for the application log, but over time we expanded our context to include a screenshot or video capture of the user experience and a network trace if necessary. Your context likely comes in a different form. When possible, make it easy for customers to provide the context. For example, Tableau Mobile provides an in-app mechanism to send the application log to us. There will also be times when you only get an email thread with the customer, especially for consultation calls. In this case, you may want to have a set of questions to ask in your first call to fill up your context or perhaps guide the customer to collect the context during the call.

3. Sync up internally before the call

Once you have enough context, get familiar with the context and have your questions and/or answers ready before the call. This will give you an idea of what the conversation might be and what it would take to make progress. One practice that we found helpful is to sync up among the internal parties before the customer call. This can be between the developers or with the account manager, solution engineer, or tech support if it makes sense. Getting more people on the same page helps keep the customer conversation on the right track.

4. Listen and be patient

This is more of a mindset to be in when you are on the call. The unspoken thing about a customer call is that when it gets to the developers, the customer has already gone through layers of support and very likely has frustration regarding the product. Their understanding of the problem may differ from yours, but their frustration is real. Let the customer talk and describe their problem. This will allow you to learn about their environment and confirm your understanding of the problem. Then you can slowly guide the customer to get on the same page with you. Using terminology that the customer used usually helps.

5. I do not know, but I will follow up

There will be times when you do not have the answer to the question/problem. The customer conversation during a call may get past the initial problem you had prepared for and into an area where you are not an expert. It is okay to say that you do not know about X, but you can always offer to follow up. This can be in the form of finding the right internal person for the question, analyzing the log files to find the root cause, etc. A genuine willingness to help can go a long way with customers.

6. Retrospect

This is probably the most overlooked step as people naturally celebrate after solving a problem. But, it is not productive for developers to be in multiple calls about the same problem over and over again. You will not have the time to build the next version of your product. One type of outcome from your retrospective could be to improve the product to handle the root cause. This is a more likely outcome at the beginning of your product journey than it is later on. Another type of outcome is identifying patterns for the problem and writing a playbook for tech support/solution engineers to detect and solve the same problem independently. A misconfiguration in the customer environment is the kind of problem that is perfect for a playbook. Notably, this is where organizational alignment between dev, support, and sales can yield an amplified benefit.

Customer calls are not a one-size-fits-all type of problem. As with any practice, try it out and customize it to be yours. As a developer, I hope you can see the value of participating in integration calls and have learned a thing or two to help your next call be more productive. Please share a comment if you have suggestions that others would find useful.