← All guides

From product plans to clear expectations

Show direction. Don’t promise every idea.

A roadmap brief separates available capabilities, conditional plans and exploration, keeping audience limits, dependencies and exclusions visible.

Make this with my agent

Bring your notes. Review a draft before sharing.

Explore the method
  1. 01
    Available to whom?

    CSV export is available only to invited pilot teams—not everyone.

  2. 02
    A target, not a promise

    Saved views target October 2026, dependent on access review.

  3. 03
    Exploration stays undated

    Alerts have no committed scope or date; a mobile app is outside this cycle.

THE REAL HTML · FICTIONAL EXAMPLEView on its own

A worked example, not a customer result. September 2026 dates are sample facts.

Now make it about your work

Your direction. Your agent. Clear expectations.

Help readers distinguish what they can use today from conditional plans and undated exploration.

Start with three things

  1. Approved priorities, audience and snapshot date.
  2. Exact availability limits, target windows and dependencies.
  3. Intended outcomes, exclusions and disclosure boundaries.
Make this with my agent

You review the facts and access. Nothing is published without your approval.

The method behind the roadmap briefAsk your agent to preserve each commitment level, keep conditions beside the affected work and flag wording for product-owner review.

How do I turn a product roadmap into a clear stakeholder brief?

Give your agent the approved priorities and the exact commitment status of each item. Ask it to explain the customer problem and intended outcome, then separate available work, planned work and exploration. Preserve target windows and uncertainty. Review the wording for the specific audience before sharing a dated roadmap snapshot.

What to give your agent

  • Approved roadmap items with current status, scope and decision records.
  • The customer problem and intended outcome behind each priority.
  • Dates labeled as commitments, targets or absent; dependencies and exclusions.
  • The intended audience and approved disclosure boundaries for future work.
  1. Choose the audience before the detail

    A customer wants to know what they can use or plan around. An internal team may need dependencies and unresolved decisions. Use the same underlying facts but include only approved audience-safe detail. Do not convert internal speculation into a public announcement.

  2. Define the status labels in words

    Write what available, planned and exploring mean in this roadmap. Do not let color or placement on a timeline imply a delivery commitment. If sources use inconsistent labels, ask the product owner to reconcile them before the agent writes a confident summary.

  3. Explain why, without reopening prioritization

    Connect each approved item to its stated problem and intended result. A roadmap communication brief explains direction; it does not manufacture a new prioritization score. Link to the decision rationale where appropriate and say what is deliberately outside the current scope.

  4. Make change and uncertainty easy to see

    Show the snapshot date, target-window qualifiers and dependencies next to the item they affect. Have the owner check public-facing promises before sharing. When direction changes, revise the brief and communicate material changes directly instead of relying on readers to notice a refreshed page.

Keep creating and revising in the agent you already use. Start with a saved artifact style and learn how to update HTML without changing its link.

Use the full promptReady for your agent and your notes

Use the conversation where you already did the work. Only attach material you are allowed to share.

Get the ready-to-copy creation request →
Create a stakeholder roadmap brief as static HTML using my approved roadmap and authorized context. State the audience and snapshot date. Explain the supplied customer problems and intended outcomes. Separate available capabilities, planned work, exploration and exclusions with explicit text labels. Preserve pilot limits, dependencies and the difference between target dates and commitments. Do not invent dates, prioritization scores, impact results or product promises. Ask only for missing essentials and flag inconsistent status definitions. Use my saved artifact style if available. No live roadmap, voting, forms, scripts or automatic notifications. Show a draft for product-owner review. Do not publish or change access without separate explicit approval.
Check before you shareAccuracy, clarity, and permission
  • Does available mean available to this exact audience?
  • Are targets, commitments and undated exploration visibly distinct?
  • Are dependencies and exclusions next to the affected item?
  • Has the product owner checked the brief for unintended external promises?

When HTML fits

A dated explanation of approved direction for stakeholders who need context without navigating the planning tool.

When another format fits better

Keep prioritization, live delivery tracking, voting and binding commercial commitments in their established workflows. This page is not a synchronized roadmap.

What we started withThe same facts, as a wiki page

Fictional team wiki

Harbor product direction — September 7, 2026

Objective

Product-owner review draft. The objective is to reduce repeated report setup, not a measured impact, adoption or time-saving result.

Available and planned

R1: CSV export is available to invited pilot teams only. Broad availability and expansion are not promised. R2: saved views are planned for an October 2026 target window, conditional on access review. October is not a release commitment; review outcome, completion date and item owner are unspecified.

Exploration and exclusions

R3: alerts are being explored, with no committed scope or delivery date. X1: a mobile app is outside this cycle; no future date or further reason is supplied.

Status definitions

Available means usable by the stated audience; planned means approved direction subject to conditions; exploring has no committed delivery scope or date. Keep these states separate.

Review and communication

The product owner must approve audience-specific wording before external sharing. Later changes need reviewed revisions and direct communication where expectations change. This static snapshot does not synchronize planning tools, collect votes or notify recipients. The fictional source records D1, R1–R3, X1 and S1 have no supplied public URLs, customer quotes or priority scores.

Inspect the HTMLOne self-contained file

The example is sanitized and isolated from this site. No scripts, forms, or live data.

<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>Harbor direction: available, planned, exploring</title><style>
*{box-sizing:border-box}html{color-scheme:light}body{margin:0;background:#faf6fa;color:#302439;font:17px/1.65 system-ui,sans-serif}main{max-width:1000px;margin:auto;padding:clamp(20px,5vw,64px)}h1,h2,h3,p{margin:0 0 18px}h1{font:500 clamp(32px,5vw,58px)/1.14 Georgia,serif;letter-spacing:-.025em;overflow-wrap:anywhere}h2{font:500 29px/1.3 Georgia,serif;overflow-wrap:anywhere}h3{font-size:19px;line-height:1.4}.label{font:700 12px/1.6 system-ui,sans-serif;letter-spacing:.08em;text-transform:uppercase}.intro{font-size:20px}.lead{background:#53355f;color:white;padding:24px;margin:28px 0}.lead p:last-child{margin:0}.grid{display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,230px),1fr));gap:20px;margin:24px 0}.card{background:white;border:1px solid #bbc5c4;padding:24px}.metric{font:500 38px/1.2 Georgia,serif;display:block;margin-bottom:12px}section{margin:36px 0}ul,ol{padding-left:22px}li{margin-bottom:12px}.note{font-size:14px}.warning{border-left:5px solid #956118;padding-left:20px}a{color:inherit;text-underline-offset:4px}a:focus-visible,summary:focus-visible{outline:3px solid #956118;outline-offset:4px}table{width:100%;border-collapse:collapse;table-layout:fixed;font-size:15px}th,td{text-align:left;vertical-align:top;border-bottom:1px solid #bbc5c4;padding:12px 8px;overflow-wrap:anywhere}caption{text-align:left;font-weight:700;padding:12px 0}pre,code{white-space:pre-wrap;overflow-wrap:anywhere}footer{border-top:1px solid #bbc5c4;padding-top:24px;margin-top:40px;font-size:14px}@media(max-width:480px){th,td{padding:10px 4px;font-size:14px}}@media print{body{background:white}.card,.lead{break-inside:avoid}h2,h3{break-after:avoid}}
</style></head><body><main><header><p class="label">Harbor direction / Fictional snapshot / September 7, 2026</p><h1>Less repeated setup. Different levels of certainty.</h1><p class="intro">Reducing repeated report setup is the objective—not a measured result. This wording needs product-owner approval before external distribution.</p></header><section><h2>What the current direction means</h2><div class="grid"><article class="card"><p class="label">Available · R1</p><h3>CSV export</h3><p>Available to invited pilot teams only. Broad availability and expansion timing are not established.</p></article><article class="card"><p class="label">Planned · R2</p><h3>Saved views</h3><p>Target window: October 2026. This is not a release commitment.</p><p>Depends on access review. Its outcome and completion date are not supplied; no item owner is named.</p></article><article class="card"><p class="label">Exploring · R3</p><h3>Alerts</h3><p>No committed scope or delivery date. Exploration is not scheduled development.</p></article></div></section><section class="warning"><h2>Not in this cycle</h2><p>A mobile app is excluded. The source does not give a later date or a further rationale. Do not infer either.</p><p class="note">Source X1.</p></section><section><h2>Read these labels literally</h2><p><strong>Available</strong> The stated audience can use the capability.</p><p><strong>Planned</strong> Approved direction, subject to stated conditions.</p><p><strong>Exploring</strong> No committed delivery scope or date.</p><p class="note">Source S1. No prioritization score or new recommendation is implied by the layout.</p></section><section><h2>Before this is shared</h2><p>The product owner checks audience-specific wording and disclosure boundaries. No adoption, impact or time-saved result is supplied in D1.</p><p>Material changes need a reviewed revision and direct communication where expectations are affected. This page does not synchronize with a planning tool, collect votes or send notifications.</p><p class="note">Source C1. D1, R1–R3, X1 and S1 are fictional source records; URLs are not supplied.</p></section><footer>Fictional worked example by share/artifacts. Names, dates, figures and records are invented for demonstration. Static snapshot; no live data or automatic updates.</footer></main></body></html>
The original worked scenarioThe source scenario, step by step

One roadmap, three commitment levels

Fictional Harbor product direction, reviewed as a synthetic example only.

The original notes

CSV export is available to invited pilot teams. Saved views planned for October, target only, depends on access review. Alerts exploring, no date. Mobile app excluded this cycle. Goal: reduce repeated report setup; no impact measurement yet.

Available

CSV export for invited pilot teams, not broad availability.

Planned

Saved views target October, dependent on access review. The window is not a promise.

Exploring

Alerts have no committed scope or delivery date.

Outside this cycle

A mobile app is excluded. Reducing repeated setup is the intended outcome, not a measured result.

A reader should not have to guess which parts of the roadmap they can rely on today.

Questions, adaptations & sourcesGo deeper when you need to

Should I show a date for every idea?

No. If scope or timing is not committed, say that. Adding a date to make the layout look complete can create an expectation the team never approved.

How is this different from a prioritization brief?

Prioritization helps choose what to pursue. This brief communicates the chosen direction and its confidence levels. It should not silently rescore or reorder the approved plan.

Can I share the internal version with customers?

Only after reviewing its disclosure boundaries and promises for that audience. Internal dependencies, experiments and customer references may be unsuitable for external sharing.

Further reading