Monitor a competitor launch as a sequence of evidence, not a day of headlines. Establish the prior product boundary, capture the announcement and durable documentation, verify availability and packaging, then watch maintenance and customer proof. The strategic question is what changed in the buyer's possible workflow—not how loudly the launch was promoted.
What this guide covers
- a before, launch-day, and follow-through workflow;
- availability and packaging states;
- evidence that indicates durable product commitment;
- a copyable launch-review record.
Before the launch: preserve the baseline
When a launch is expected, record the current state without predicting the result:
- product navigation and documented capabilities;
- pricing plans, allowances, and entitlements;
- relevant integrations and workflow boundaries;
- current target audience and promise;
- related jobs, partner pages, or trust controls;
- the buyer decision that could be affected.
Without a comparable baseline, a launch can establish a new current state but not an exact movement.
Launch day: classify every claim
Official changelogs such as the Cursor changelog, GitHub Changelog, and n8n release notes are useful direct records. They vary in scope and detail. For every material claim, record:
- what was announced;
- availability: announced, preview, waitlist, limited, or generally available;
- eligible plan, role, region, platform, or account;
- documented limitation;
- primary workflow and terminal outcome;
- source date and observation time.
Do not translate “launching” into “available to all users.”
Inspect the durable product surface
A launch is stronger when the capability is represented beyond the announcement:
| Surface | What it can establish |
|---|---|
| Documentation | configuration, limits, permissions, failure behavior |
| Pricing/plan page | commercial entitlement and entry motion |
| Product navigation | integration into the normal experience |
| API/reference | programmatic boundary and operational detail |
| Trust/admin docs | governance and enterprise scope |
| Status page | named operational component or disclosed incident handling |
A public status page can show whether a component is separately recognized, but the absence of a component name does not prove it is unsupported or unreliable.
Determine the product movement
Classify the launch:
- feature extension: improves an existing step;
- workflow expansion: owns an additional step or outcome;
- control-point movement: becomes the trigger, orchestrator, approval layer, or system of record;
- commercial expansion: opens a new plan, unit, segment, or sales motion;
- distribution expansion: enters another product, marketplace, or partner path;
- proof expansion: adds enterprise controls, reliability commitments, or outcome evidence.
More than one can apply. The classification should cite exact sources and a buyer consequence.
Run the 7/30/90-day follow-through
Seven days
Recheck availability, documentation, plan boundaries, and reversals. Identify whether early limitations became clear.
Thirty days
Look for maintenance releases, templates, integrations, customer examples, administrative controls, and stable navigation. Update the buyer-workflow comparison.
Ninety days
Review whether the launch altered deals, product decisions, or the category boundary. Record “no observed consequence” when appropriate. Do not infer adoption from continued marketing alone.
Copyable launch checklist
# Launch review — [company / product]
## Baseline
- observed before:
- existing workflow boundary:
- current commercial boundary:
- decision at risk:
## Launch evidence
| Claim | Source | Availability | Plan/scope | Limitation | Confidence |
|---|---|---|---|---|---|
| | | | | | |
## Movement
- feature / workflow / control / commercial / distribution / proof:
- affected buyer and job:
- plausible implication:
- alternatives and unknowns:
## Follow-through
- 7-day review:
- 30-day review:
- 90-day outcome:
## Decision
Owner:
Review requested:
Due:
No-action condition:Decide proportionately
A direct workflow and segment overlap may justify customer research or a roadmap review. A shallow adjacent feature may need only sales guidance. A loud launch with no usable product state may remain a watch item. Avoid copying the visible feature before understanding the buyer job and control point.
Use EXVIV companies, markets, and Evidence Compare to establish the context; use the monitoring guide and startup CI operating system to assign follow-through.
Related EXVIV research
Sources and further reading
Method note
Launch materials prove that public claims were made. They do not independently establish adoption, performance, customer value, durability, or private product intent.