Retire the Deliverable

I.

There's a strange kind of success where the client no longer needs the thing you originally sold them.

The team learned how to do it. Or the problem changed enough that the work keeping everybody busy isn't the work that would help now.

That should be a good conversation. It gets weird when the arrangement only makes sense if we keep sending the same thing.

I think about that as an owner because we can build an agency around doing useful work and still end up protecting work that used to be useful. Nobody has to make a dishonest decision. We just keep renewing the familiar one.

II.

Consider a hypothetical weekly search report built during a website migration. The team needed to see whether important pages were disappearing from search. A frequent review made sense while the site was changing.

Months later the migration is settled. The same document still arrives. Somebody checks it and adds a little commentary because an empty commentary box looks unfinished.

Now we have a choice. We can keep improving the report. Or we can ask whether the situation that made it worth producing still exists.

Those lead to different work. Improving the report might make it easier to read. Revisiting its purpose might tell us to keep a narrow monitoring check and stop producing the weekly document altogether.

The second option can look like we're doing less even when it takes more judgment.

III.

I wouldn't use low readership as the reason to stop.

Some work matters because it catches something before anyone else needs to care. A quiet monitoring check can be useful precisely because the person paying for it rarely has to think about it.

And a client who doesn't open the report might still depend on a colleague who does. We need to understand where the work goes before figuring out whether it should disappear.

So I'd separate the document from the job. What would become harder to notice if we stopped? Who would lose information they actually use?

If the answer is meaningful, keep that protection. It might need a different format or a different frequency. If nobody can trace the work to anything beyond fulfilling the scope, we have something else to talk about.

That's more uncomfortable than adding a new chart. It's also where the recommendation starts getting useful again.

IV.

The part that takes some honesty is what happens to the money.

A recurring deliverable helps us plan the team's time. It helps the client understand what they're buying. Those are real benefits. But they can also make a task harder to question after its original job is finished.

There's an easy way around that discomfort. Replace it with a newer sounding deliverable at the same price and call the change progress.

Maybe the replacement is worth doing. I'd still want it to earn its place independently. The fact that we have a slot to fill doesn't tell us what belongs in it.

Sometimes the useful next step will be an investigation. We know the old work can shrink but we don't yet know where that time would do the most good. I'd rather be plain about that than manufacture certainty because the next invoice is coming.

V.

Stopping can teach us something too, if we make the change carefully.

For the migration example, the proposal might be to pause the weekly narrative while keeping the agreed technical checks. Tell the people using the work what is changing. Keep the previous format available for the review period.

Then watch for a decision that becomes harder to make. Does somebody start rebuilding the same report on their own? Did a useful conversation disappear along with the file?

Those would be reasons to reconsider. No immediate complaint wouldn't prove the report had no value. It would just be one observation alongside how the team is actually working.

This is why I wouldn't announce a big efficiency win the day we remove something from the calendar. Some costs take a little while to become visible. So do some benefits.

VI.

I'd like a client to be able to hear us say a piece of work can stop without waiting for the bigger package we're about to recommend.

That means being willing to leave the arrangement a little less tidy while we figure out what makes sense next. Maybe the engagement gets smaller. Maybe we move the attention somewhere it has been missing.

For TMG I'd start by looking at one recurring item and asking what had to be true when we first included it. Then check whether that is still true.

We might keep the work. At least we'd know why it's still there.