The Renewal Clock

Getting the dates is not a project. They live in the CRM, or in the signed contracts sitting in a folder, or in the finance system that invoices against them. Pull them once, or set a loop that looks them up, or create a custom property that gets populated straight from the contract PDFs. It is a ninety-second task with the tools on your laptop right now, and this chapter's prompt does it. The obstacle was never difficulty. It just has to occur to you to do it, and in most product organizations it never has.

One mechanical detail, because it moves your whole calendar: the date that governs the account is usually not the renewal date. It's the notification deadline, the day by which the customer must tell you they're leaving, written into the contract thirty, sixty, or ninety days ahead of the renewal itself. Every plan you make should count backward from that earlier date. A team that discovers an unhappy account two weeks before renewal has often already lost it two weeks after it was decided.

I was talking recently with a very senior revenue-operations leader, the kind of person companies bring in to get to the next level, and I asked what he actually does when he lands. One of his signature moves: he shows them how to build a renewal pipeline. Not a better one. Their first one. Companies at real scale, running recurring revenue, tracking new business in exquisite detail, with no pipeline at all for the revenue they already have and are quietly scheduled to lose. If go-to-market may not have this view, product certainly doesn't, so build your own. Run it off to the side if you have to: every account in your area, renewal date, notification deadline, dollar value, usage trend. The point of the side view is simple: product never gets caught flat. No fire drill about an account you've never heard of, no awkward chart at a leadership meeting you didn't see coming two quarters earlier.

Once you have the dates, a rhythm becomes available that changes the relationship between product and CS entirely. Ninety days before a batch of renewals, send CS the update they didn't ask for: here are the bugs we resolved that these accounts reported, the features they requested and where each stands, the engineering activity relevant to next month's renewal conversations. Then the question that does the real work: what did we miss?

Now run it in the other direction. Your renewal view flags an account where a key user's activity has gone to zero. You walk it to the CSM ninety days out instead of discovering it together in the postmortem. The first thing you'll hear is thank you. The second thing, a few days later, is the story: Maria, who bought the product and championed it, left the company, and the CSM has already done a call with the account to take its temperature. The account needs to be rethought around the new people in the room. Good. Was that call recorded? Then it goes into customer memory with everything else, and every loop, brief, and view your team runs knows about Maria's departure from that moment on, without anyone writing a status update.

Notice what happened to the fire drill. It didn't get handled well; it stopped existing. The CSM who used to arrive at your desk with an emergency now arrives with a plan and a request for help, which is a different conversation in every way that matters. Chapter 9's rule: CSMs are not alarm bells. A rhythm like this one is how you compensate structurally instead of hoping the next understatement comes with a raised voice. The stakes run two quarters deep: the account you catch at ninety days is the fire drill you don't run at thirty, and the awkward chart nobody has to explain at the leadership meeting a hundred and eighty days from now.

The pattern compounds the same way it did with sales in Chapter 7: once you're useful inside their clock, the world starts bringing product high-grade information, pre-sorted, in a form you can turn directly into motivation for engineers. You still apply your editorial judgment, your standards, your taste. In fact you'll use more of them, because you're working from a dimensional picture of the account instead of a secondhand anecdote, and the distance between what you know and what you choose to put in front of the team is where the craft lives.

Which brings us to the payoff scene, the most concrete picture in this course of what all the plumbing is for.

You want your team to build something. You believe in it, and the tech lead is polite about it, which is how tech leads say no. The old move is to escalate, or to schedule a meeting, or to write a longer document. The new move is to tell the whole story, because now you can.

You send the tech lead the ticket with three customer logos attached. Headphones come off. You add the renewal dates on two of those accounts, the new annual contract value on the third, and the ICP segment they belong to. Then you attach three short video clips from the calls, and in one of them the customer says it plainly: I always assumed you had this. I'm on the hook here, and if you can't do it I have to go buy something, or I'm going to look like an idiot at my offsite next quarter.

You will never have to talk about that ticket again. It will be done tomorrow. The engineers you've been trying to motivate with prioritized backlogs will run through drywall for a customer with a face, a date, and a number, and the credit that comes back when it ships (Chapter 2's economy of coolness, running at full speed) makes the next one easier. We joke at Day.ai that the drywall bill is the one line item nobody minds.

Two cautions so the scene stays repeatable. Spend it on the asks you actually believe in; a channel that carries this much force dulls fast if you use it for everything. And once the team has felt it, you can loosen your grip: feed engineers the work item and the evidence and let them fill in the gaps themselves, because an engineer who has watched one of those clips designs for the person in it without being told to.

Will builds the whole loop on camera, from raw contracts to the scheduled early-warning brief, in this chapter's video.

1. List the ten accounts that matter most to your product area. Beside each, write its renewal date from memory. Guess where you have to; a blank is an answer too.
2. Run the prompt, and put the table it hands back somewhere you will see it weekly: your tracker, a pinned doc, your calendar.
3. Send the note it drafts for the nearest renewal to that account's CSM, ninety days ahead if you still can, ending on one question: what did we miss?
4. Pick one thing you believe your team should build. Tell your tech lead its whole story with the logos, the dollars, the renewal dates, and the customer's own words the prompt pulls together.

Paste this into whatever AI you work in, ideally one connected to your company's material: Claude Code in a company-brain folder, Cowork, Codex, or similar. Have your ten accounts and guessed dates written down before you start.

Product managers and product leaders at any recurring-revenue company, which is nearly everyone eventually.