Tool Evaluation
Part of Marketing technology roadmaps
Separating a vendor's roadmap promise from a shipping feature
Distinguish planned, preview, rolling-out and available software features before depending on a vendor promise in a marketing roadmap.
Treat a vendor roadmap item as a possible future option until you establish the feature is available to your organisation and performs the task you need. A release date, a preview and a sales explanation are different kinds of evidence. Keep those differences visible in the buying decision and your own roadmap.
Ask what state the feature is in
Request the exact product, edition, region or account conditions, current release state and date of the supplier's latest update. Terminology varies by supplier, so ask what each label means. Microsoft, for example, distinguishes a feature in development from one rolling out and one launched in its Microsoft AI at Work Roadmap.
On that roadmap, “rolling out” does not mean every applicable customer has the feature. Microsoft also says its Azure DevOps roadmap dates are current plans subject to change.
A preview may help learning, but its behaviour or availability may change. Even when a supplier calls a feature launched, check whether the proposed edition, settings, roles and connected products support the intended task. Ask for documentation and an account-specific answer before placing the feature on a campaign's critical path.
Vendor Feature Release States: Understanding Microsoft's Roadmap Terminology
- In DevelopmentFeature is being built; not available to customers.
- Rolling OutFeature is being gradually released to customers; not yet available to all.
- LaunchedFeature is generally available, but may depend on edition, region or account settings.
Keep an evidence ladder
| Supplier statement | What it establishes | Next evidence to request |
|---|---|---|
| Roadmap entry | The supplier has described an intended direction or time frame | Current status and conditions for availability |
| Sales explanation | The proposed use has been discussed | Written scope in the offered edition |
| Release documentation | The supplier describes a released capability | Entitlements, limits and setup requirements |
| Action shown in an account | Behaviour in that account and configuration | Whether the offered setup can complete your task |
A demonstration in a supplier's prepared account does not prove the feature works with your data or permissions. If the decision depends on that, define a later check using safe sample information and the intended user role.
Evidence Levels for Vendor Feature Claims
- Supplier Statement (Roadmap Entry)
- Indicates intended direction or time frame; not confirmation of availability.
- Sales Explanation
- Discussed use case; requires written scope in offered edition.
- Release Documentation
- Describes a released capability; includes entitlements, limits and setup needs.
- Action in Account
- Confirmed behaviour under your configuration and permissions.
Make the plan resilient to a slip
Write the business task beside the promised feature. Name the existing route or narrower alternative that can meet the task if the release arrives later, changes scope or needs more setup than expected. If there is no acceptable fallback, record the proposed purchase or launch as conditional. Review the proposed agreement against the capability actually offered, not a slide describing future work.
Suppose a proposed reporting tool promises an automated correction feed for the next campaign cycle. The team can ask for the release record, edition and field behaviour. Until those are established, plan the campaign report around a confirmed route and keep the feed as a separate later decision.
Record each open promise with an owner, last verified date, supplier evidence, dependency and decision date. Recheck it when the supplier changes the status. Move the feature into the committed delivery plan only when the evidence required for the organisation's use is in hand.
