How to know when a competitor launches a new feature

You usually find out a competitor shipped something the same way every time: a prospect mentions it on a call, a customer asks whether you have it too, or a teammate forwards a newsletter three weeks late.

The feature was announced publicly the day it launched. The changelog entry, the release note, the "what's new" post were all sitting there. Nobody on your side was looking, so the first thing to tell you was the market, and by then the conversation was already about catching up.

The problem is not access. Almost every launch a competitor makes is announced somewhere public. The trouble is that those announcements live in four or five different places per competitor, they update on no schedule, and most of what gets published does not matter to you. A tooltip copy change and a brand-new integration land on the same page with the same formatting, so watching all of it by hand means either checking constantly and burning time on nothing, or checking rarely and missing the one launch that actually moves a deal.

Where do competitors actually announce a new feature?

Not every source is worth the same attention. Rank them by how certain the signal is that something real shipped, and you spend your time where it pays.

• Changelog. The highest-certainty source. A dated entry is a factual record that a specific thing shipped, and for an active competitor it updates weekly, sometimes daily. Start here.
• Release notes. The same class of signal, often with version numbers and more detail on what changed. Frequently the same page as the changelog, sometimes a separate one.
• Product blog or "what's new" post. Richer on positioning and intent, but weaker on timing, since a post can trail the actual rollout by days or lead it as a teaser. Good for the why, less reliable for the when.
• Product-update email. Only the changes the competitor chose to highlight, delivered on their schedule, and only if you are subscribed. Useful as a backstop, not a primary source.
• App store release notes. For a mobile-first competitor this is sometimes the only place a change surfaces, but the text is often vague ("bug fixes and improvements"), so it confirms activity more than substance.

The pattern is consistent: changelogs and release notes are where a launch becomes a dated fact, and everything below them is either slower or softer. If you only have time to watch one surface per competitor, watch that one. The mechanics of doing that without burning your week are covered in how to track a competitor changelog without checking it every day.

A step-by-step for catching a launch the day it ships

1. List your real competitors. Keep it to the three to five whose moves actually show up in your deals, not everyone in the category.
2. For each one, find the highest-certainty surface. Look for a changelog or release-notes page first. If there is none, fall back to the product blog, then the update email, then app store notes.
3. Record every URL in one place. A single list you actually revisit beats five bookmarks scattered across browsers.
4. Set a tight check interval. Daily, not weekly. A launch you learn about a day late is still actionable; one you learn about a month late is a lost deal.
5. Filter for shipped features, not noise. A reworded heading or a fresh screenshot is not a launch. You are looking for a dated entry that says something is now available.
6. Write down three things for each real launch: what shipped, whether it reaches your deals, and what you should do about it. If it does not touch your buyers, note that and move on.
7. Push the confirmed change into wherever your team acts on it. Sales usually needs it first, which is why it belongs on a battlecard your reps trust. Keeping that current is its own discipline, covered in how to build a competitor battlecard that stays up to date.

A short worked example

Say you watch three competitors. On a Tuesday, one of them posts a changelog entry: a native integration with a tool your shared buyers already use. Under the by-hand version of this, nobody checks the page that day, a prospect brings it up on a call the following week, and you are answering cold.

Under the process above, you see the entry the day it lands. You write the three lines. What shipped is the integration. Why it matters is that it removes a manual step two of your open deals were weighing. What to do next is brief your reps with a one-line reframe and flag those two accounts before your next calls. The launch is the same either way. The difference is you walk into the call ready instead of hearing about the feature during it.

Change detection is not the same as knowing what shipped

This is where the usual tools break down, and it is worth being precise about why. A generic page-change monitor watches a URL and fires on any diff, so a reworded heading pings you exactly as loudly as a shipped feature, and the real signal drowns. That is change detection: the page is different from yesterday. It cannot tell you whether the difference matters.

An RSS reader, or a manual subscription to the update email, has the opposite problem. It hands you the entry but no judgment. You still have to read every one, decide whether it reaches your deals, and work out what to do, which is the exact work you did not have time for in the first place.

The practical fix sits between those two. Watch the surfaces where launches actually get announced, changelogs and release notes first, on a tight interval instead of an occasional check, and have every entry arrive already interpreted rather than raw. That is what Presagon does: it reads the sources for you and delivers each real launch as an alert that already says what shipped, why it matters to your specific product, and what to do next. The copy edits stay quiet. The launch that moves a deal reaches you the day it ships.

That is the difference between hearing about a launch in time to respond and hearing about it from the customer who already switched.