Every mutual success plan I've ever seen has the same disease: fourteen action items, all marked "high priority." The champion's team agrees to everything on the kickoff call, the CSM writes it all down, and three months later the renewal conversation is a shrug โ because nobody agreed on which three of those fourteen items actually determine whether this account stays.
MoSCoW fixes that. It's a forty-year-old prioritization method from software delivery โ Must have, Should have, Could have, Won't have โ and it maps almost perfectly onto success plans. The difference between a bloated action list and a plan that moves renewals isn't the number of items. It's whether the customer can point to the Musts and say, "If we don't get these, the renewal isn't happening."
Why success plans bloat
The bloat has three causes, and they're all political. First, CSMs are trained to say yes. Every request from a champion feels like relationship capital, so it lands on the plan. Second, nothing is allowed to be labeled low priority, because nobody wants to tell a stakeholder their ask is a Could. Third, the plan gets written once at kickoff and never re-sorted โ so it fossilizes around whatever mattered in week one.
The result: a plan where the one integration that blocks adoption sits next to a request for a branded login page, and both look equally important. When everything is high priority, the CSM's time gets spread across everything, the customer notices the important things moving slowly, and trust erodes exactly where you can't afford it.
MoSCoW forces the sorting conversation to happen out loud, with the customer, using shared language. That's the whole game.
The four buckets, translated for CS
Forget the software-delivery definitions. Here's what each bucket means in a success plan:
Must have โ If this doesn't happen, the customer will not renew, or will not adopt at all. The test: "If we shipped nothing else, would you still be on this call?" If the answer is no, it's a Must. Most accounts have two to four of these. If your plan has eleven Musts, you don't have eleven Musts โ you have a negotiation problem.
Should have โ Important and expected, but the account survives without them for now. The training program for power users. The second dashboard. Painful to defer, not fatal to defer.
Could have โ Nice wins that happen if capacity appears. The branded login page. The extra integration nobody's asked for twice. These live on the plan honestly labeled, which is better than the alternative โ pretending they're priorities and resenting them.
Won't have โ The most valuable bucket, and the one CSMs skip. Explicitly listing what you are not doing this cycle does two things: it kills the "I thought you were handling that" conversation before it happens, and it converts vague disappointment into an explicit, time-bounded trade. Write "Won't have (this quarter)" rather than "never," and attach the revisit date.
How to run the MoSCoW sort with a customer
Don't sort the plan alone and present it. The sorting is the value. Here's the 30-minute version that works on a shared doc or a whiteboard:
1. List everything first (10 minutes). Dump every open item, request, and loose commitment onto one list. Include the things that were only mentioned in passing โ "it'd be great ifโฆ" is where Coulds and Won'ts hide. Get to 10โ20 items. Don't categorize yet.
2. Force the Musts (10 minutes). Ask the champion: "If we could only deliver three things before the renewal, which three?" Write their answer down before debating. This is the constraint that breaks the "everything is high priority" habit. Most champions pick two or three immediately โ they know; they just never get asked.
3. Sort the rest together (10 minutes). Walk the remaining items and place each in Should, Could, or Won't-have-this-quarter. The CSM's job here is honesty, not agreeability: "That integration is a Should for you, but it's a quarter of engineering time, so it's a Could for this cycle." The customer can disagree โ that's the point. The argument is alignment.
4. Publish the sorted plan and the owners (5 minutes). Every Must and Should gets an owner on both sides and a date. Coulds get no dates โ that's what makes them Coulds. Won'ts get a revisit date. Share the doc in the same meeting, not "I'll send it over."
MoSCoW vs. the renewal timeline
The sort isn't one-and-done. Map the buckets to the renewal countdown, because priority shifts as the renewal approaches:
90 days out: All Musts should be in flight or done. If a Must is still untouched at 90 days, it's your entire week until it moves. Shoulds should have owners and dates.
60 days out: Musts done. Shoulds in progress. This is when you re-run the sort, because the customer has learned things since kickoff โ some Shoulds have become Musts (a new stakeholder, a changed budget) and some Musts turned out to be Coulds.
30 days out: The only items that should be open are Shoulds and Coulds. If a Must is open at 30 days, you're not negotiating a renewal โ you're negotiating an extension with conditions. Name that honestly with the champion.
The 60-day re-sort is the part most teams skip. Success plans aren't static documents; they're the artifact of an ongoing negotiation about what matters. Re-sorting twice a year per account takes an hour. It prevents the "but we never got X" conversation that kills more renewals than any competitor.
Handling the "everything is a Must" customer
It will happen. A champion will put nine items in Must. Three responses that work:
"Which three?" Repeat the constraint. "I hear you โ and I've got one CSM and finite engineering hours. If you had to pick three for this quarter, which three?" Constraint is kind. It gives them permission to stop performing importance.
Attach the cost. "We can do all nine, but here's what that does to the timeline on the top three โ the SSO integration slips to March." When Musts compete with each other, the sorting happens naturally.
Split the cycle. "These three are Musts for this quarter. These four become Musts for next quarter's plan, with dates." The Won't-have-this-quarter bucket exists precisely for this โ it turns a no into a sequenced yes.
What never works: silently accepting nine Musts and quietly working on three. The customer finds out at the QBR, and the conversation becomes about your credibility instead of their outcomes.
The Won't-have conversation is the trust builder
CSMs avoid the Won't list because it feels adversarial. It's the opposite. Customers don't trust vendors who say yes to everything โ they've been burned by that before. A CSM who says "we won't do this in Q4, here's why, here's when we revisit it" is the CSM who gets believed when they say "we'll get this done."
Write Won't items with three fields: the item, the reason (capacity, product direction, dependency), and the revisit trigger ("we revisit if usage of module X passes 50%"). The revisit trigger matters โ it turns a rejection into a conditional promise, and it gives the champion something to take back to their team besides "no."
Put it in the plan template today
You don't need new tooling. Take your current success plan template and add one column โ M/S/C/W โ plus a "revisit date" column for the Won'ts. At the top, add the 90/60/30 checkpoint dates and the date of the next re-sort.
Then run the 30-minute sort on your riskiest renewal this week. Not all of them โ one. You'll find that the Musts are fewer than the plan implies, the Won'ts are a relief to say out loud, and the champion leaves the call more confident than they arrived. That's what a success plan is supposed to do: not list everything, but settle what matters.
Tomorrow: the automation question every CS leader is getting wrong โ which workflows to hand to AI first, and which ones to keep human no matter how good the models get.
