Main idea

An internal roadmap can carry hypotheses, trade-offs, limits, reasons for non-priority, sensitive topics and open debates. A customer roadmap cannot. Deriving one from the other by automatic extraction or by filtering — hiding internal fields, publishing only certain columns — produces a document that is accurate and unusable.

What you can say about a topic depends on things no filter knows: the real level of commitment, the risk that mentioning it becomes a promise, the sales context of the moment, the segment you are speaking to, the topic's maturity, the company's ability to hold the message six months from now. A committed topic can often be communicated, with its limits. A candidate can sometimes be raised as a direction of thinking, never as a commitment. A topic kept in reserve has to be handled with care.

The customer roadmap is therefore a translation: product and sales work, done by hand, topic by topic.

Why it matters

It closes off an automation that keeps coming back — publishing the roadmap from the internal tool, with visibility rules. The cost of the automation is not in the mechanism, it is in the promise you will not be able to take back.

It also gives a reason to own two objects rather than one half-made public: two documents maintained separately cost less than a single document you no longer dare write honestly because a customer might read it.

Nuances and limits

Manual translation has a recurring cost and drifts out of sync: the customer version ages as soon as the internal one moves, and nobody notices until a customer cites an abandoned topic.

And not every company needs the same caution: on a product with no contractual commitment and no competition over announcements, the gap between the two documents can be thin.

Open questions

• How often should you retranslate, so that a customer roadmap does not become a source of expired expectations?