They came to cancel. Here is what they told us.
The stated objection was delivery speed. The real one was loss of agency.
Cost of that fix: high, and it would not have worked.
Cost of that fix: a change in the engagement model, not in headcount.
Five stakeholders, five different versions of the same frustration.
In enterprise, there is no sample of thirty interviews and no second attempt. There is a buying committee, each member measured on something different, and one conversation to get it right.
And the fix had to cost almost nothing on either side. Not more developers, not a bigger contract, not a new tool for them to learn. Just a different place for the client to stand inside a process that already existed.
Nothing about the product changed. The account was saved on positioning and process.
Four moves that made the difference.
None of them were product decisions. All four are what a product marketer does when an account is at risk.
The setup.
Enterprise retention conversations usually get handled as a commercial problem. The client threatens to leave, someone offers a discount or a delivery guarantee, and the account either survives on worse terms or leaves anyway.
The more useful way to treat a departing client is as the highest-quality research subject available. They match the ICP by definition, they have used the product under real conditions, and unlike a prospect they have no reason left to be polite. What they say on the way out is the least filtered feedback a company will ever receive.
But the thing they say is rarely the thing that is wrong. Stated objections cluster around whatever is measurable and socially acceptable to complain about: timelines, price, scope. The actual reason a relationship breaks is usually further underneath, and it is almost never something the client volunteers unprompted. Finding the gap between the two is the difference between saving an account and negotiating the terms of losing it.
What had to be true.
Local Coursera — one of the three leading EdTech platforms in Russia, winner of the "Made in Russia" award.
The client was the Russian Export Center's Export School, a state institution running export training programmes nationally. Universarium had built their learning platform, and the engagement was our largest account, worth approximately $1M.
Mid-contract, they signalled they were leaving. What they said, across several conversations, came down to five complaints: change requests took too long to land, by the time features shipped the requirement had moved on, they had no control over which task got picked up next, they could not predict how long anything would take, and our prioritisation logic was opaque to them.
Taken at face value, that reads as a delivery problem, and the obvious response is to promise more speed. But four of those five complaints are not about speed at all. They are about control, predictability, and trust in decision-making. The client had been placed outside the process and was being handed outcomes at intervals they did not choose. The frustration was showing up as a complaint about timelines because timelines are the part you can point at.
That distinction mattered commercially. Promising faster delivery would have committed us to something expensive, probably unachievable, and beside the point. The account was not at risk because the work was slow. It was at risk because the client had stopped feeling like a participant in their own product.
The second half of the problem was the audience. This was a buying committee inside a government institution, not a single decision-maker. Different people were accountable for different things, and there was one shot at the diagnosis before the renewal decision got made.
How it moved.
What I actually did.
I started by mapping who was actually in the room. In a government institution the person who signs is rarely the person who feels the pain, and the person who feels the pain is rarely the one who can save the contract. I identified who was accountable for what, then interviewed them separately rather than convening one meeting. Group settings flatten disagreement, and the disagreement was where the information was.
I did not ask what they wanted. I asked what happened the last time a change request went badly, and walked each incident backwards. The pattern repeated: a request would go in, disappear into our process, and reappear weeks later as a delivered feature that no longer matched the need. Nobody on the client side could see what happened in between, influence the order of work, or explain to their own leadership why a given item had been chosen.
That reframed the problem. The complaint was arriving as "too slow." The mechanism underneath was that the client had no visibility into prioritisation and no way to intervene while intervening was still cheap. Under a waterfall structure, the only feedback point was delivery, and by delivery the cost of change was already high. The client was not experiencing slowness. They were experiencing irrelevance to their own project.
Before proposing anything, I played that diagnosis back to them and watched for recognition. They confirmed it in their own words. That mattered more than the solution did, because it moved the conversation from a negotiation to a shared problem.
The proposal was a change to the engagement model rather than to the product or the team. Two-week cycles with the client inside the review loop. Prioritisation done jointly and visibly, so they could see the queue and reorder it. A predictable rhythm that made timelines legible instead of promised.
The presentation was built as a direct mapping. Each of their five original complaints appeared on the page, with the specific mechanism that answered it next to it. "It is not obvious how you prioritise" was answered by a shared, visible backlog they helped order. "We do not know how long things take" was answered by a fixed cadence they could plan against. "By the time you deliver it is outdated" was answered by a two-week loop that made a stale requirement structurally impossible.
Nothing in that proposal promised faster delivery, and the delivery pace did not materially change. The account was retained on the strength of restored agency.
Worth naming what this fix was not. The product did not change. The engineering team did not change. The delivery pace did not materially change, and I never promised that it would. The contract value stayed the same. What changed was where the client stood in the process, how the work was made visible to them, and how the relationship was framed.
That was deliberate, and the cost was a design constraint rather than a lucky outcome. During a cancellation conversation, a proposal that requires the vendor to add headcount reads as an admission of understaffing, and a proposal that requires the client to adopt new process reads as extra work handed to the party who is already unhappy. The fix had to be close to free on both sides to be signable at all.
They renewed for a year. The platform is still in production today.
Waterfall
Every phase locks the next. The client sees product once — at the end.
Agile
Plan → Build → Review → Adjust, every two weeks. The client is inside the loop.
The client, and the platform still running
Measurable outcomes.
- Retained a ~$1M account that had already signalled departure, with a one-year renewal
- Identified that four of the client's five stated complaints were about control and visibility rather than delivery speed, which changed what the fix had to be
- Repositioned the engagement model to put the client inside prioritisation, without adding headcount or promising faster delivery
- Mapped every original complaint to a specific mechanism in the renewal proposal, which is what produced stakeholder buy-in
- Platform remained in production for roughly a decade with no rebuild, and the client never replaced it
The stack behind it.
Run this interview before the client is leaving, not after. Everything that surfaced in those conversations was knowable months earlier. Nothing had changed suddenly; frustration had accumulated quietly until it reached the threshold of a cancellation conversation. A standing quarterly account health interview, asking the same question about the last change request that went badly, would have caught it while it was cheap. I treated loss interviews as a rescue tool. They work better as a routine one.
Instrument the thing they actually complained about. The client said prioritisation was opaque and timelines were unpredictable. I fixed both structurally, but I never measured either. There was no baseline for how long a request took from submission to delivery, and no after number. I have the renewal as proof the fix worked, which is a strong outcome, but no measurement of the mechanism.
Separate what saved the account from what I believed saved it. I am confident the agency diagnosis was right, because they recognised it themselves. But the renewal also followed a period of intense senior attention on their account, and attention alone repairs relationships. I cannot fully separate the two. Naming that is more useful than claiming a clean attribution I do not have.