Monitor the competitive landscape for a long research program
Track competing development programs and organize evidence for long-term planning discussions.
How this works
Track competing development programs and organize evidence for long-term planning discussions. Long development timelines make competitive planning vulnerable to stale status labels and overconfident launch forecasts. The same program may be described differently in a registry, publication, and company announcement, each referring to a different date or milestone.
Maintain a dated program-level evidence table for a defined research area. Normalize terminology carefully and keep planned, initiated, completed, and reported milestones distinct. Timing scenarios are explicit planning assumptions for specialist review, not predictions of clinical success or commercial launch.
Before you start
Research scope
Define the relevant indication, mechanism, population, and decision horizon.
Evidence sources
Identify accessible registries, publications, and company materials.
Specialist review
Assign owners for scientific interpretation and planning assumptions.
Prepare the inputs
- program_registry
- Required
Program IDs and aliases
Resolve renamed assets and sponsor changes.
- public_evidence
- Required
Dated records
Retain the exact source version and event date.
- stage_taxonomy
- Required
Defined milestones
Do not treat announcement language as a verified stage transition.
- planning_horizon
- Required
Date range
Specify what decisions the watch informs.
- prior_snapshot
- Required
Program history
Preserve changes rather than overwrite them.
Implementation, step by step
Define comparable programs
- Map the scope to explicit inclusion and exclusion criteria.
- Separate programs that differ materially in population or intended use.
Checkpoint: A reviewed watch list.
Collect dated evidence
- Retrieve current accessible records and relevant publications.
- Record source date, event date, and retrieval date separately.
Checkpoint: A traceable evidence inventory.
Normalize program status
- Resolve aliases and map documented milestones into the agreed taxonomy.
- Preserve conflicting statuses and planned dates instead of silently choosing one.
Checkpoint: A normalized program table.
Identify material changes
- Compare with the prior snapshot for new evidence, delays, discontinuations, or ownership changes.
- Require support for a status change; page disappearance alone is insufficient.
Checkpoint: A verified change log.
Build timing scenarios
- Describe alternative milestone paths using explicit assumptions and dependencies.
- Avoid assigning precise success probabilities without an approved model and evidence.
Checkpoint: A scenario brief with uncertainty.
Review planning implications
- Have specialists assess scientific comparability and the relevance of each change.
- Record which planning assumptions changed and which remain unresolved.
Checkpoint: An expert-reviewed landscape update.
Decisions along the way
Sources disagree on status
Show both dates and definitions and seek specialist resolution.
A milestone date is company guidance
Label it planned or projected, not completed.
A program changes indication or owner
Maintain identity links while reviewing whether it remains comparable.
What you will produce
program-watch.csv
CSVSupports longitudinal monitoring.
Include: program_id · scope · stage · event_date · source_ref · status_conflict · change
competitive-timing-brief.md
MarkdownInforms planning discussions without overstating certainty.
Include: material_changes · scenarios · assumptions · expert_questions
Check the result
- Verify stage changes against original records.
- Check aliases do not create duplicate programs.
- Preserve planned versus observed milestones.
- Review scenario assumptions with qualified specialists.
When something goes wrong
A registry update is delayed
Note the lag and retain other evidence without treating it as a definitive correction.
Translation alters a technical stage
Preserve the original term and request specialist review.
A forecast is presented as a date certain
Replace it with an explicit conditional scenario.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Update a competitive watch for a research area.
Inputs
Synthetic example. Synthetic P1 has a registry start date in March; a later announcement says recruitment is planned for June. P2 reports a completed milestone.
Expected result
Synthetic expected result. Flag the conflicting P1 timing for review and distinguish it from P2's reported completion. Do not infer either program's eventual approval.
Run a small pilot
Start small
A small program set across two update cycles.
Record the baseline
Record researcher time and material changes missed by manual monitoring.
Agree success criteria
Agree provenance completeness and status-classification accuracy.
Stop or revise
Stop planning conclusions when identity or milestone interpretation remains unresolved.
Keep the scope clear
- This organizes evidence; it does not establish clinical safety or efficacy.
- A landscape update alone does not authorize investment, acquisition, or program changes.
Check before using
Future launch timing is uncertain. This supports expert planning and does not validate a scientific program or justify an investment decision on its own.
Business activities
- Research customers and markets
- Plan products and business changes
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Defined research area · Public program and trial information · Decision horizon
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow