# Product Roadmap Communication

> Communicates a roadmap with commitment level attached to every item — committed, planned, or exploratory — using date precision that matches actual confidence, and a change-notification rule for when an item slips or is dropped. Use when preparing a roadmap update, a stakeholder or customer-facing plan, or an internal delivery outlook; trigger on 'roadmap update', 'what are we shipping this quarter', 'share the plan with the customer', 'stakeholders want dates', 'when will X be delivered'. Not for defining what a specific item is (use product-requirements-doc), not for breaking items into stories (use product-user-story-acceptance-criteria), and not for a commercial promise inside a contract or bid (use sales-proposal-assembly with your legal owner).

- Skill: `alihusains/product-roadmap-communication` (Agent Skill)
- Install (CLI): `npx skillmds@latest add alihusains/product-roadmap-communication`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alihusains/product-roadmap-communication/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: alihusains (https://skillmd.com/u/alihusains)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alihusains/product-roadmap-communication

---


# Roadmap Communication

## Purpose

A roadmap presented as a single list of dated items is read by everyone as a set
of promises, including the items that were speculative. When the speculative ones
slip, the credibility of the committed ones goes with them. This skill separates
commitment levels explicitly, matches date precision to real confidence, and fixes
the rule for telling people when something changes.

## Prerequisites

- **Inputs:** the item list with, for each, the current delivery status, the
  evidence behind its date, and whether it is funded and staffed.
- **Required decisions:** who has authority to declare an item committed. If
  nobody does, everything is at most planned.
- **Access:** the audience definition — internal delivery, internal executive,
  customer, or public. The same roadmap is communicated differently to each and
  should never be forwarded between them unchanged.

If an item's commitment level cannot be established with its owner, do not
publish it. An item on a roadmap with no stated level defaults, in the reader's
mind, to committed.

## Data classification

**Internal** for internal audiences; a customer- or public-facing roadmap is
**Public** only after the commitment owner and, where a commercial relationship
depends on it, your legal owner has approved it. Unreleased plans shared with a
customer normally require a confidentiality agreement — check before sending. Do
not include named customer commitments, deal-specific dates, or account
identifiers in a roadmap circulated beyond the deal team.

## Commitment levels

Every item carries exactly one. Publish the definitions alongside the roadmap;
undefined labels get reinterpreted.

| Level | Means | Date precision allowed | What must be true |
| --- | --- | --- | --- |
| Committed | We will deliver this; if it slips you will be told and told why | A specific period, e.g. a named month or quarter | Scope agreed, funded, staffed, dependencies identified, an owner accountable |
| Planned | We intend to do this and have started shaping it | A quarter or half, no specific date | Problem validated, priority agreed, not yet fully scoped or staffed |
| Exploratory | We are investigating whether to do this at all | No date. A horizon at most | Under investigation; may be dropped with no further notice |
| Not planned | Frequently asked for, and not being done now | None | Stated so people stop asking and can plan around it |

The "not planned" row is the one usually omitted, and it is the one that most
reduces repeated stakeholder chasing.

## Procedure

1. **Classify every item** against the table, with its owner. An item that cannot
   meet the committed criteria is planned, regardless of who wants a date.
2. **Strip date precision that confidence does not support.** A specific day for
   work not yet scoped is false precision, and it will be quoted back. Widen the
   date rather than adding a caveat sentence nobody reads.
3. **Write each item in outcome terms.** State what a user or the business will be
   able to do, not the internal component name. Roadmaps written in project
   codenames cannot be evaluated by the audience they are sent to.
4. **Add the dependency and risk note where one exists,** briefly: the external
   dependency, regulatory approval, or vendor deliverable the date rests on.
   Dates that depend on a third party should say so.
5. **Include the "not planned" section** for the most frequently requested items,
   each with a one-line reason. Route the reasoning to the relevant
   `product-requirements-doc` non-goals where one exists.
6. **Tailor to the audience.**

   | Audience | Include | Exclude |
   | --- | --- | --- |
   | Delivery teams | All levels, dependencies, sequencing, capacity assumptions | Nothing; this is the working view |
   | Executives | Committed and planned, with the outcomes and the main risks | Item-level task detail |
   | Customers | Committed and planned only, in outcome language, with the change rule stated | Exploratory items, internal codenames, capacity and staffing detail |
   | Public | Committed only, or themes without dates | Anything you would not want quoted back after a slip |

   Exploratory items shared with a customer are heard as commitments. This is the
   single most common cause of a broken roadmap promise.

7. **State the change rule on the document itself.** For example: committed items
   that slip are notified to this audience within a stated number of working days,
   with the new date and the reason; planned items may move without individual
   notification and are reflected in the next scheduled update; exploratory items
   may be dropped without notice. Publishing the rule converts a surprise into an
   expected process.
8. **Date and version the roadmap,** name its owner, and state when the next
   update is due. An undated roadmap circulates for a year.
9. **Notify changes according to the rule, promptly and specifically.** For a
   slipped committed item: what moved, the new date, why, what is being done, and
   what the recipient should do differently. Do not bundle a slip quietly into the
   next routine update — that is how trust is lost, not by the slip itself.
10. **Verify substantiation for any performance or comparative claim** that
    appears in the narrative around the roadmap. Statements about outcomes the
    delivered work will produce are claims; route them through
    `marketing-claim-substantiation` before an external roadmap is sent.

## Failure modes

- **One list, no levels.** Everything is read as committed.
- **Precision inflation under pressure.** A stakeholder pushes for a date and gets
  one that engineering never gave. Escalate the pressure to the commitment owner
  rather than absorbing it.
- **Committed items with unowned dependencies.** If another team or vendor must
  deliver first and has not agreed, the item is planned, not committed.
- **Internal roadmap forwarded to a customer.** Control this by producing the
  customer view as a separate artefact, not by asking people not to forward.
- **Silent removals.** An item that disappears between versions without comment
  reads as concealment. State removals explicitly.
- **Deal-driven commitments.** A date promised in a sales conversation does not
  make an item committed. It makes it an escalation to the commitment owner.

## Boundaries

- Defining what an item actually is, with goals and non-goals — use
  `product-requirements-doc`.
- Decomposing an item into buildable, testable work — use
  `product-user-story-acceptance-criteria`.
- Committing a delivery date inside a bid, contract, or RFP response — use
  `sales-proposal-assembly` and involve your legal owner; a roadmap is not a
  contractual instrument.
- Communicating an unplanned outage or delivery failure — use
  `engineering-incident-postmortem` and your incident communications owner.

## Hand-offs

- **Receives from:** `product-requirements-doc` (scope, non-goals, and status per
  item), delivery teams (confidence and dependency reality).
- **Routes to:** `marketing-campaign-brief` (only committed items are promotable),
  `sales-proposal-assembly` (what may be represented to a buyer, and at what
  level), and `marketing-claim-substantiation` for outward-facing claims.