Your competitor watcher just gave notice

A product marketer at a Series B company left in March. She had watched four competitors for two years. Her replacement inherited a Notion page with a competitor table, three battlecards, and a bookmark folder. Six weeks later, one of those competitors quietly moved its cheapest paid tier from $29 to $49 and dropped seats from unlimited to five. Nobody noticed until a rep lost a deal on price and asked why the battlecard said $29.

Nothing was lost, exactly. The page was still there. What left was the part that was never written down: which of the four actually mattered, which pages she checked and how often, and what she had learned to ignore.

Handoffs get planned for code and customers. Competitive coverage usually gets a link dump. Here is the week that fixes it.

Step 1 — Get the roster out of their head, with reasons

Start with the list, but do not accept the list as-is. For each competitor on it, ask the departing person to answer three things out loud while someone types:

• Why is this one on the list? "We lose deals to them" and "they showed up in a G2 category" are very different reasons with very different follow-up.
• When did we last actually encounter them? A name that has not appeared in a deal, a support ticket, or a search result in nine months is a candidate for removal, not for handoff. We wrote about that decay in the competitor we stopped competing with.
• Who is missing? The most valuable answer of the week is usually a name they were about to add and never did.

Expect the list to get shorter. A roster of nine that becomes five is a better handoff than a roster of nine passed on intact.

Step 2 — Recover the sources, not the summaries

The Notion page is the output. The handoff needs the inputs. Walk through each competitor and capture:

• The exact URLs watched: pricing, changelog, docs index, careers, status page, security or trust page, the two or three blog categories that matter.
• Accounts and logins already created — free-tier accounts, newsletter subscriptions, community memberships, review-site alerts. These are frequently in a personal inbox and vanish with the person.
• Saved searches, RSS feeds, and any alert rules, with the account they live in.
• Anything manual: "I check their careers page the first Monday of the month" is a real process that exists only in a habit.

This is also the step where the mechanical half of the job should stop depending on a person. Seeto monitors public surfaces continuously and surfaces diffs as discrete change events, so a successor inherits a running change record from day one instead of starting the clock over. It will not tell you which of those changes matters — that is what the rest of this week is for.

Step 3 — Walk the last four real changes together

Abstract knowledge does not transfer. Specific cases do. Pull the four most recent competitor changes that led to an internal action and have the departing person narrate each one:

• What did they see, and on which surface?
• What made it worth escalating, when a dozen other changes that month were not?
• Who did they tell, and what happened next?

Do the same with one change that turned out to be nothing. Learning the shape of a false alarm is as useful as learning the shape of a signal — the failure patterns in six ways a competitor diff lies to you are much easier to recognize once you have watched someone dismiss one in real time.

Step 4 — Write down the ignore list

Every experienced watcher has a private set of rules about what not to react to. These never make it into documentation because they feel like nothing. Ask directly:

• Which surfaces change constantly and mean nothing? (Marketing hero copy, most job postings, blog cadence.)
• Which changes look small but always matter? (A single word in a pricing tier's seat limit. A new region on a trust page.)
• Which competitor announcements are habitually ahead of the product by a quarter or more?

Write these as plain sentences in the same doc as the roster. Ten lines is enough. Without them, the successor spends their first two months escalating noise and burning the credibility they will need later.

Step 5 — Hand over the standing outputs by name

Coverage exists to feed something. Find every artifact the departing person maintained or contributed to, and name a new owner for each one before the last day:

• Battlecards and their review cadence — these decay faster than anything else, as in why battlecards go stale.
• Any recurring update: a Slack post, a section of a monthly report, a slide in the QBR deck.
• Standing questions from sales or support that were routed to them informally. This is the sneakiest one; it lives entirely in DMs.

If an output has no new owner, kill it deliberately rather than letting it die quietly. A discontinued monthly update is a decision. One that simply stops appearing is a gap nobody notices for a quarter.

Step 6 — Run one full cycle with the successor driving

On the last day of the handoff week, the successor does the job and the departing person watches without touching anything. They check the surfaces, triage what changed, decide what is worth telling anyone, and write the update.

The corrections that come out of this hour are the highest-value part of the entire week. It is where you find out that the pricing page has a second URL for annual billing, that the changelog RSS feed is three weeks behind the actual changelog, and that the competitor everyone worries about has not shipped anything in five months.

Two weeks after the last day, have the successor re-baseline the whole roster from scratch, the way you would for a name you had just added — the checklist in six things to baseline when you add a competitor works exactly as well for an inherited one.

The handoff is not finished when the doc is updated. It is finished when someone else has already used it to make a call.