A commercial plane leaves Chicago for London. Its heading is off by five degrees at takeoff. Five degrees. Not fifty. Not fifteen. Five.
For the first twenty minutes, nobody on the plane notices. Out the window, it still looks like the right direction. The pilots are flying. The instruments are humming. Five degrees off is invisible at this stage of the flight.
3,950 miles later, the plane lands 344 miles from London, somewhere in the heart of mainland Europe. Frankfurt. Stuttgart. The Swiss border. Aviation has a rule of thumb for this called the 1-in-60 rule. One degree of heading error puts you one mile off course for every sixty miles flown. Five degrees over the Atlantic puts you in a different country.
I keep coming back to this analogy because it is the cleanest way I have found to describe what happens when a customer success team optimizes the wrong metric.
The metric moves. The outcome does not.
A document automation product I have worked with, Revver, was being deployed at an HR team that wanted to standardize new-hire document collection. The CS team was watching the dashboard. Weekly file intake went from 70 to over 100. Up and to the right. Everyone on the account felt good about the trajectory.
The CS team was tracking file volume. The customer's actual outcome lived somewhere else entirely: onboard each new employee to completion with all required documents within five days.
Rising total-files-processed does not prove that a single onboarding actually closed within five days. It can mean every onboarding is open longer. It can mean the same incomplete files keep getting re-uploaded by frustrated HR coordinators. It can mean the system is busier and nothing is finishing. The intake number moved. The actual outcome did not.
That is the plane at the twenty-minute mark. Pilots flying. Instruments humming. Five degrees off, and nobody on the account can feel it yet.
The outcome is the judge.
Every model of customer success has to be rooted in something. Most teams root theirs in something measurable, something the platform already tracks, something easy to drop onto a slide. Total files processed. Active users. Sessions per week. Time-in-app. Hours saved.
Root the model anywhere except the customer's real business outcome and the metric becomes the goal. The work bends toward moving the number, not toward delivering the outcome the number was supposed to represent. The intake chart goes up. The renewal conversation still goes sideways.
The outcome is the judge. The thing the customer is actually trying to accomplish in their business is the only measure that can hold the model in place. If the work you are doing today is improving that outcome, you are on the right track. If it is not, you are working on the wrong thing, no matter how good the dashboard looks.
A proxy is fine. A drifting proxy is not.
This is not an argument against proxy metrics. Sometimes the outcome the customer cares about cannot be measured directly. Attribution is messy. Data is incomplete. The result lives too far downstream to ever land in your dashboard cleanly. In those cases, you need a stand-in. That is normal. That is the work.
The question is whether the stand-in is tied tightly enough to the outcome that everyone in the room agrees it represents real progress.
Take an email marketing platform where the customer cares about revenue from email. You cannot attribute every dollar perfectly. So you agree on this: any purchase made within 24 hours of an email campaign hitting that subscriber's inbox counts as revenue generated by email. It is not technically 100% accurate. It is, by mutual agreement, a sufficient proxy. Everyone in the room knows what it stands for and why it is defensible.
Take a security platform where the customer cares about reducing risk. You cannot prove zero risk. So you agree on this: the number of risks identified per audit, and the percentage of those risks eliminated within a defined window. It does not prove there is no remaining risk in the system. It does, by mutual agreement, prove you are making the system safer over time.
Those are good proxies. They sit off the strict definition of the outcome by a known and accepted margin. The conversation has been had. The trade-off has been named. Everyone is bought in.
A drifting proxy is something else. Total intake when the outcome is on-time onboarding completion. Sessions per week when the outcome is sales conversion. Time-in-app when the outcome is hours saved per employee. The chart still moves up and to the right. The customer still nods in the QBR. The link from metric back to outcome has either weakened or was never confirmed in the first place, and nobody on the account has had the conversation that would surface it.
The five-degree problem shows up when a proxy has quietly drifted from the outcome, and nobody on the account is the wiser. Using a proxy is fine. Using a drifting proxy without realizing it is how accounts end up in Frankfurt.
The customer is not going to keep you on course.
This is the part most CS teams underestimate. Customers will not flag a proxy metric for you. They will not say "wait, you are celebrating intake numbers but my onboardings still take three weeks." They will not because they cannot. They are watching the plane fly. They are not the navigator.
Customers frequently mistake deploying the product for the win. They cheered when the rollout shipped. They sent the email to their team. They told their VP the project is live. As far as they are concerned, the plane took off, so the trip is going well. They are enjoying the in-flight movie.
You are flying the plane.
The CSM has to be the steward of the outcome. That stewardship is the actual job. It is the discipline of asking, every single week, whether the metric you are celebrating is actually moving the outcome the customer is paying you to deliver. It is the willingness to be the adult in the room who says "this number went up, and we still have not landed."
There is also a selfish reason to take this seriously. Even when the customer is the one who did not put in the work, did not push the org change, did not put the right people on the project, you are the one who pays for the miss. They cancel. You hold the bag. Their failure shows up as your churn, your renewal that did not land, your missed expansion. Outcome stewardship is in the customer's best interest. It is also in yours, in your team's, and in your company's. The CSM who acts like outcomes are the customer's problem is going to keep getting handed the consequences.
That stewardship is the expertise. It lives in the person on the account who is paying attention to the difference between motion and progress, and you will not find it sitting in the product or the platform on its own.
Every customer use case has an outcome.
One reason proxy metrics survive as long as they do is that teams focus on what use cases do in the system. Customers log in. They run reports. They upload files. They generate documents. The use case is treated as a repeatable task, and the metric tracks how much of that task is happening. The actual outcome at hand never enters the conversation.
At Revver, the same thing happened at first. The team thought about use cases as one shape: customers were just trying to do "repetitive document tasks," and that pattern looked the same whether the customer was an HR team or an accounting team. The logical metric, then, was to track the number of documents processed across the board.
Those are not the same use cases. Different outcomes. Different processes. Different people. The HR team is trying to onboard new employees with every required document. The accounting team is trying to close month-end without missing a contract. Same product surface, completely different definitions of done. If you track the same metric across both, you are off course in both, because the proxy is the system firing, not the work landing.
The question with every use case is the same one. What is the outcome? How does this actually impact the customer's business? Until you can answer that, all you have is a description of what the product is doing. The use case itself has not arrived yet.
The 5-degree diagnostic.
Here is the exercise to run on your own book of business this week.
Pull the top three metrics you currently report to a customer. The ones you drop into a QBR. The ones in your health score. The ones you would point at if an executive walked into the room and asked how the account was doing.
Picture the plane on its way to London. You could just as easily be reporting fuel consumption, average altitude, on-time gate departure. All of those numbers could be looking great. None of them tells you whether the plane is on course for the actual destination.
For each of those metrics on your list, ask two questions in order.
First: what business outcome is this metric supposed to measure?
Second: is the link strong enough that the customer, your team, and your leadership would all agree it actually represents progress on that outcome?
If you can answer both cleanly in a sentence each, great. You are rooted. Keep flying.
If you struggle on either one, or the best you can come up with is "well, it correlates with usage, which probably means…" you have just spotted your five degrees. Course-correct now, while you are still inside the radius. The earlier you catch a heading error, the cheaper the correction. By the time the QBR ends, by the time the renewal conversation starts, by the time the customer is shopping around, you are already in Germany and you cannot fly back.
Choosing the right metric is the expertise.
This is where the role of customer domain expertise becomes obvious. Your job is to walk into the kickoff already knowing the right metric, instead of asking the customer to invent it for you.
The metrics that matter are pulled from your most successful customers, not invented inside the kickoff meeting. You already have the pattern. Your best HR customer on Revver knows what success actually looks like for an HR onboarding team. Your best accounting customer knows what success actually looks like in their close cycle. Your job is to study those teams, lock in the metric each of them cares about, and bring that metric to every new customer with the same use case as the North Star.
In the Revver example, we already know HR teams care about onboarding new employees quickly and completely. We do not need to discover that on a kickoff call with every new HR customer. We can walk into the room and say "the metric that proves your business outcome is the percentage of new hires onboarded with all required documents within five days. That is what your best peers track. That is what we are going to track here." This is the same instinct I wrote about in Shape the Goal. Use your expertise to put the right metric in front of the customer, then walk them through owning it themselves.
That is the actual work. Look at your most successful customers in a given use case. Identify the metric that maps to the business outcome they care about. Then take the lead with every current and incoming customer in the same use case to confirm and lock in that metric. The customer should walk out of the kickoff knowing the North Star you are going to optimize against, because you brought it, not because they had to invent it.
Everything else is intake counts on a plane heading for Frankfurt.
What to do this week.
Open your last QBR deck. Find one chart you were proud of. Walk it through the diagnostic. What business outcome is this chart supposed to measure, and would the customer, your team, and your leadership all agree the link is tight enough to count as real progress? If you can answer both cleanly, you are rooted. If you cannot, you have just found your five degrees, and you have the chance to correct before the next conversation with that customer.
If you run the diagnostic on one of your accounts this week, hit reply and tell me what you found. Which metric did you assume was tied to the outcome, and turned out to be a proxy that had quietly drifted from it? The ones that surprise you are usually the ones worth correcting first.