Post-mortem the competitor move you missed

The prospect said it casually, halfway through a demo: "But they have that now, right?"

They did. A competitor had shipped the exact integration your sales team had been using as a wedge for two quarters. It went live eleven days earlier. Nobody on your side knew.

The instinct is to fix it with more watching: add another newsletter, another Slack channel, another weekly review. That rarely works, because you don't yet know why you missed it. Engineering teams solved this problem a long time ago. When something breaks in production, they don't add more dashboards at random. They run a post-mortem: a short, blameless review that traces the failure back to a specific gap.

Competitive intelligence deserves the same discipline. Here is the playbook.

Step 1: Rebuild the timeline before anyone opines

Do this within 48 hours, while browser histories and Slack threads are still fresh. The goal is a dated list of facts, not a story.

• When did the change first become public? Check the competitor's changelog, docs, release notes, and pricing page. Use the Wayback Machine for the earliest snapshot that shows it.
• Where did it appear first? It's often not the blog post. It's frequently a docs page, a help-center article, or a new integration listing days before any announcement.
• When did your team first learn about it, and from whom? A customer, a rep, a Slack link, a churned account?
• Calculate the lag. Days between "public" and "known internally". This number is the headline of the whole review.

If the lag is under three days, you may not have a tracking problem at all, just a communication one. If it's over a week, keep going.

Step 2: Classify the miss

Every miss falls into one of four buckets, and each one has a different fix. Pick exactly one. If you find yourself picking two, pick the one that happened earliest in the chain.

• Not watched. The surface where the change appeared wasn't monitored by anyone. Classic example: you track their pricing page but not their integrations directory.
• Watched, not noticed. Someone or something was looking, but the change didn't register. A monthly manual check that happened to land before the change. A diff buried in 40 cosmetic edits.
• Noticed, not routed. Someone saw it and posted it somewhere nobody with a stake was reading. This is the failure mode from why Slack is the wrong place for competitor news.
• Routed, not acted on. The right person knew and decided it didn't matter. Sometimes that was the right call. Sometimes it wasn't.

Most teams assume their miss is "watched, not noticed" and buy a tool. In practice, "not watched" and "noticed, not routed" are far more common.

Step 3: Find the earliest public signal

This step is the one teams skip, and it's the most useful. Work backwards from the launch and ask: what was visible before the announcement?

• Job postings for roles tied to the feature (an "Integrations Engineer, Salesforce" listing four months earlier).
• Docs and API reference pages that went live ahead of marketing.
• Status page components added for a service that didn't exist yet.
• Trust or subprocessor pages listing a new vendor the feature depends on.
• Pricing page copy that quietly added a line item to a plan.

Write each one down with its date. You are not trying to prove you should have predicted the launch. You are building a list of surfaces that, for this competitor, reliably move first. That list is worth more than the post-mortem itself.

Step 4: Score the cost honestly

A post-mortem without a cost estimate turns into a ritual. Keep it rough and keep it short.

• Deals touched. Open opportunities where the competitor was in the evaluation during the lag window.
• Messaging exposure. Any battle card, landing page, or sales script that claimed they didn't have the thing. Those claims were false for eleven days, and every rep who used them lost a little credibility.
• Roadmap exposure. Did your own team start, prioritize, or deprioritize anything during the window based on stale assumptions?

If the honest answer is "one deal, no lasting harm", say so and keep the fix small. Not every miss deserves a new process. Some deserve a shrug and a note.

Step 5: Change one thing, and give it an owner

The output of the review is a single change, with a name next to it and a date to check whether it worked. One. Not a list of eight improvements that will all quietly die.

Match the fix to the classification from Step 2:

• Not watched → add the surfaces from Step 3 to your monitoring for this competitor. If you track more than a handful of rivals, this is where continuous monitoring earns its keep. Seeto, for example, watches public pages like changelogs, docs, pricing, and integration listings, and reports each diff as a separate change event, so a new integration doesn't wait for someone's monthly pass. It won't tell you what the change means. That's still your job.
• Watched, not noticed → reduce noise before adding coverage. Decide which changes deserve an alert and mute the rest.
• Noticed, not routed → name a destination. A specific person, a specific doc, a source link attached to every claim, as in every competitor claim needs a source link.
• Routed, not acted on → nothing to fix in tracking. Revisit the decision rule instead.

Put a check-in on the calendar 30 days out. The only question at that meeting: if the same competitor did the same thing tomorrow, how many days would the lag be?

Keep the archive

Store each post-mortem in one place: timeline, classification, earliest signal, cost, fix. After four or five of them, patterns show up that no single review reveals. Maybe one competitor always leaks through job posts. Maybe your misses cluster around one surface you've never watched.

The goal was never a lag of zero. It's a lag you chose on purpose.