When starting a Customer Education program from scratch, particularly at smaller software companies, the world around you may appear to be in chaos. The product team wants nothing to do with you. You have no seat at the table. Your weeks might alternate between feeling like a pirate and a peasant.
Despite having a solution (training) that can positively impact so many business critical KPIs, you can’t figure out how to connect it to any major initiatives. And when you do, it is nearly impossible to generate enough momentum to have your proposals survive into production.
So what is causing this?
The chaos you are experiencing is most likely caused by a single issue:
There is no GTM process.
The factory
“GTM” is shorthand for “Go-To-Market” and is often run by a collaboration between the product and marketing teams. It is the path that products follow from inception through to delivery and growth. To give you an analogy, consider an automobile assembly line.
Parts are loaded on the conveyor belt.
Robots piece them together.
And somewhere down the line the completed cars roll off.
Go-to-market isn’t the thing being built and it isn’t robots or parts. It is the path everything follows down the line. When this process is absent in an org, chaos ensues. Work gets done through brutal power struggles, which makes it difficult to get any transparency. The customer is often completely absent from the development of solutions because opening things up to the outside would only allow others to scrutinize or make changes.
Without a GTM process defined and implemented, the world in your organization likely resembles walls with closed doors. Maybe even moats. And occasionally when you knock on a door you might get shot with an arrow.
When you are building a Customer Education function, often you end up having to build a GTM process along the way. Because customer education is basically a tool that goes at each phase of production and assesses how to improve the customer experience to impact & reduce the instance of broken shit coming off the line.
“Broken shit” can mean different things to different companies. It might be people churning or a lack of customer satisfaction. There are a lot of variants of when this translates into SaaS.
Why Support Tickets Matter
So what does this have to do with support tickets?
I’ll extend the analogy of the car assembly line to explain:
What the product team does when there is no GTM process is effectively build cars that come off the production line that are missing doors, windows, and wheels. They don’t meet the functional requirements of the customer. When people use your solution and it doesn’t meet their requirements, they submit support tickets. The tickets are a signal that things are broken or confusing.
If you haven’t already, you should read The Machine That Changed The World that describes how Toyota redesigned the manufacturing processes of American car companies back in the 1950s. It does a better job of explaining this than I ever could, but I’ll summarize here.
The American manufacturers had very poor mechanisms for evaluating the production process along their assembly line. What resulted was a lot of cars needing “rework” after they ended up in the lot at the end of the line. This rework was handled by people going around and identifying issues, making a ticket, and then having people fix them before shipping the cars off to dealerships.
What the Toyota folks did was analyze the entire process and look for places where changes would eliminate rework. The question was: How do we change the process so that it results in fewer downstream mistakes.
Customer Education seeks to do this same thing. It is a magic wrench you can apply to different phases of production to increase customer satisfaction and reduce bad things like churn.
And one of the simplest ways of measuring what you’re doing is by watching what changes do to the support ticket type and volume.
What might come as some surprise is that many software companies don’t measure support tickets with this intention, and so they literally don’t know they are shipping broken shit.
Even if they are measuring support tickets, without a defined GTM process, when you bring up a desire to identify common issues you inevitably start hurting people’s egos. Either you’re calling Product’s baby ugly or you’re meddling in Support Ops.
The difference that a GTM process brings to an org is transformational. It means turning the whole ethos around and instead of feeling threatened by transparency, you turn ticket issues into an obsession. There is something really magical when you find yourself in a zoom meeting with a cross functional team, looking at support ticket issues and collectively thinking about what tests to run upstream to see if you can hand grenade those issues into oblivion.
What is a Go To Market Process?
Functionally, a GTM process is a way to connect the origination of a feature to the outcome it is seeking to deliver. That might be revenue growth or new user adoption or upsells. Think of it as a piece of string that is tied at one end to the product roadmap and at the other to a delighted customer getting value from the solution. And the GTM process is a little silver ring that you walk down that entire length of string from the beginning to the end. If it’s broken or knotted anywhere, you’ll know.
One of the first things you can do is attach cans to each end of the string. The ends need to be able to speak to one another. And importantly, your job is going to be helping them learn each other’s language.
At one end of the line is the Product team. They are the headwaters of all things. They originate features and wield a significant amount of power, both because of the impact they have but also because they are at the start. Because they’re first, every decision that comes afterwards is a function of their choices.
As a lowly Customer Education professional, the goal should be to understand the product team’s Roadmap and the associated process around building it. The roadmap is usually a document or webpage that describes month by month, week by week, what is going to get built. It is written to translate ideas from product into work by engineers. And it often is guarded by skeptical product managers because when they share it with people, it has a way of getting into the hands of sales folks.
You aren’t really asking for the roadmap itself. What is more important is understanding in a detailed way how it is developed. Inside this process of building the roadmap, you will be able to see all the priorities and decisions, personalities and perspectives that serve to define your company. The product roadmap development process is a proxy for the culture you’re in.
Take note of whether there are any places in the process where Voice of Customer (VOC) or customer use cases are leveraged. These are pieces of the roadmap puzzle where you can insert data from the other end of the line.
Let’s go down to the far end of the line now, to the Support and Success teams. This world will resemble the greasy engine room of a submarine. Yes, we’re taking on water. Yes, we know it.
I always ask two questions of this team:
What is the process for handling tickets
What categories or tags are used to classify tickets
The first objective is to really get a handle on how tickets are escalated. I do this because I want to understand the teams and people involved. I want to learn the language they use. Think of yourself as exploring a wild tribe and with your notebook out, write down everything they say. Ask them what makes the sun go up and down in their world. These teams are responsible for 80% of the revenue of the company and it helps to know how to hold a wrench or a flashlight when you’re down in their gears.
The second objective is to understand the classification of tickets. Prepare yourself as there might not be any (gasp). This is actually a great opportunity because you get to help build a system. It’s actually harder to switch from one categorization structure to another than to start from scratch.
The categories of tickets and the naming convention used will be the basis for your data collection. Remember the assembly line? Find out how they organize the broken pieces. Is there a way to identify all tickets related to missing doors? Sometimes the Support team leader will have an incredibly detailed naming convention and others will be very general. Learn the structure they use for classification as it is your starting point for understanding the common issues that develop during production. For each issue type, you’ll eventually ask: What makes this broken thing happen?
Once the ends are documented, you have the basis for a GTM process. You can now carry issues at the end of a process to the beginning and start asking important questions about why things happen the way they do.
The transformation
You know you're on the right path when you notice that people start getting excited when the basement catches fire. You know why? Because unlike before, they can now see it and control it. With this control, you can actually start fires and see what happens without worrying that the whole building is going to go up. This iterative, cohort-based process management is how you go from cars with no windows to solar-powered space ships.
I’ll be honest with you: Even if you have a fully functioning Go To Market process, the customer education function will likely still be impoverished. It doesn’t necessarily make Customer Education a powerhouse, but it gives education functions a reason to be at the table. Why? Because you are a magic wrench that fixes a lot of the big underlying issues in production. Communication and knowledge transfer are foundational issues in any organization. It doesn’t matter if you’re building battleships or bathtubs, it’s all the same.
So how do you get a seat at the table?
Well, what a GTM process does is changes how you can look at “the table.” Instead of decisions about development happening at one big round table in a closed room, the GTM process becomes a conveyor belt that runs from one table to the next. Team get to deploy their power over their piece of the puzzle, but the organization becomes aligned to a feedback cycle that runs from an idea in a product leaders’ head to the application used by the customer.
Customer Education isn’t there to run the table. It’s there to help move things along and ensure it leads to the best possible outcomes. The GTM process owner is likely either a Product Marketing leader or a Product Manager. It might even be an Operations Director. These people are your friends. They will love you because they love magic wrenches.
They also appreciate it when they can see data about broken things. Why? Because they know the alternative is not being able to see what is broken. They recognize that broken stuff is a fact of life and it should be obsessed over, not feared.
Recap of advice in this article
Here’s some practical things you can do to help elevate your role in a software organization as well as help facilitate the development of a GTM process:
Develop awareness of your company’s Product Roadmap and the process by which it is developed
Develop awareness of your company’s Support ticket escalation process and how tickets are categorized (naming convention, tags, etc)
Setup interviews with mid-level people in Marketing, Support, Sales, Customer Success, Product, and Front End Engineering. Ask them how they typically get or share insights from customers.
Ask your Demand Gen leader (in marketing) about “who owns the Go To Market process.” They might say no one. Find out who does GTM-like activities. Take this person to lunch.
Find out who owns the Knowledge Base and see if you can get “on-site search” data. Compare this to tickets. Do some analysis and share it with the Support Ticket leader. They’ll think you’re smart and probably want to be your friend.
Thanks to Abbie Bowen for inspiring this article.