The word “Strategy” appears in almost every planning deck I’ve ever seen. To borrow from The Princess Bride: “You keep using that word. I do not think it means what you think it means.”
Most of the time, it means goals. “Our strategy is to grow NRR to 120%.” That’s a target. “Our strategy is to improve onboarding.” That’s a project. Neither is strategy. A wish list with a header isn’t a strategy — it’s a hope with formatting.
Richard Rumelt’s definition is the sharpest one I’ve found. In Good Strategy Bad Strategy, he breaks it into three components: diagnosis, guiding policy, and coherent actions. Dave Kellogg adds a fourth, sitting between diagnosis and guiding policy: beliefs. The addition matters, and I’ll explain why.
Together, the four look like this:
- Diagnosis — what is the actual problem, stated precisely enough to be wrong
- Beliefs — what assumptions does your proposed solution depend on
- Guiding policy — the approach that addresses the diagnosed problem, given those beliefs
- Coherent actions — the specific things you will do (and not do) that execute the policy
Most CS ops and GTM ops teams get to guiding policy and coherent actions without ever doing the first two. That’s why their strategies don’t hold. Because they don’t know the original reason or purpose; their actions are detached from the why.
The Part Everyone Skips
Diagnosis is hard because it requires naming the real problem. Not the symptom you can see in a dashboard, and not the problem that’s politically safe to name.
“NRR is declining” is not a diagnosis. It’s a measurement. The diagnosis lives underneath: why is NRR declining, for which customers, because of what breakdown in product fit, sales motion, or post-sale execution?
Most teams skip diagnosis for an obvious reason: it takes time and it produces discomfort…and it is also hard work! A real diagnosis names something specific enough that people might disagree with it. That’s the point. If your diagnosis isn’t precise enough to argue with, you haven’t diagnosed anything. You’ve described a direction to look.
Kellogg’s beliefs layer is where teams get honest about what they’re assuming. A guiding policy is always a bet. The beliefs step forces you to name what that bet depends on. If you believe SMB customers can be retained through product-led digital motions rather than high-touch CSM coverage, write it down. Now it’s testable. Now you can be wrong. That’s the standard.
Without naming beliefs explicitly, you end up with a guiding policy that can’t be evaluated, because nobody ever agreed on what assumptions it was built on.
In Practice
At GitLab, the SMB churn problem was real and largely invisible.
The diagnosis: product limitations were preventing the team from scaling SMB support efficiently, retention targets were unclear, and the signup experience was creating adoption gaps before CSMs could even intervene. Not “SMB churn is too high.” The specific mechanisms creating it.
The beliefs: SMB retention could be managed scientifically — through data and forecasting — rather than through heroic individual CSM effort. The right metric, tracked rigorously, would surface risk before it became loss.
The guiding policy: prioritize selectively, use a scientific methodology to identify churn risk early, and forecast to prevent rather than react.
The coherent actions: establish a North Star metric, identify the top five churn reasons, build feedback loops that connected customer signals back to product and to the CSMs who could act on them.
That’s a strategy. A diagnosis that named the actual mechanism, beliefs that were explicit enough to test, a policy that responded to the diagnosis, and actions that pointed in the same direction. Not a list of things someone wanted to do anyway.
The Renewal Operations function I built at GitLab ran the same logic. The diagnosis wasn’t “renewals need attention.” It was that we had no segmentation model, no taxonomy for why deals were being lost, no motion for the 120 days leading into a renewal, and no clear ownership between AEs and CSMs. Every one of those was a specific, named problem. The guiding policy was to build infrastructure that treated renewal as a managed motion, not an event. The coherent actions followed: build the segmentation model, create the loss-code taxonomy, establish the 120-day motion, define DRI ownership.
The PROVE health engine came from the same kind of diagnosis. Before it existed, 80%+ of churn risk across the customer base was invisible. CSMs were operating on sentiment, not signal. The system we built was the coherent action.
GitLab sustained 130%+ NRR through this period. That’s what happens when the operations infrastructure is built from a real strategy rather than a goals list.
Before You Write Yours
Owner: The Strategy DRI will be owned by the lead, with the support of the director. GitLab operates under the premise of a Manager of One — the expectation that every leader owns their domain without requiring top-down direction. Know who that person is before you start.
Before drafting your strategy, understand where it sits in the organizational hierarchy:
- What is the company’s mission and overall strategy?
- What is your division’s vision and strategy?
- What does your department own within that?
Then answer these questions:
- What high-level objectives align with organizational goals?
- What defines success over the next 12–18 months?
- What are the 1–3 priorities that matter most in that window?
- How will you measure progress?
- What twenty things do you need to say no to?
That last one matters as much as the others. Strategy is knowing what you’re pursuing so you know when and to whom to say no.
The Test
Write your diagnosis in one sentence. It should name the actual problem — specific enough that someone could disagree with it. “Retention is low” doesn’t qualify. “SMB accounts in their first 90 days are churning because they never reach the activation threshold that correlates with renewal, and we have no motion designed to intervene in that window” qualifies.
If you can write that sentence, you have a diagnosis. If you can’t, you don’t have a strategy yet. You have a direction — and directions are easier to write, easier to present, and almost impossible to execute against.
The hard work is in the diagnosis. Everything else follows from it, or it doesn’t.
References
Jeff Beaumont 