Roadmap · Stakeholders · Communication · Adaptation · PTOS

A Roadmap for Every 'Tribe': How One Artifact Can Speak Different Languages

How to create a single Roadmap but present it in different 'views' for each key stakeholder group (Engineers, Designers, Sales, CS, Execs), focusing on their unique needs and language.

A Roadmap for Every 'Tribe': One Truth, Different Packaging

A product manager working with stakeholders is like a translator between different 'tribes': engineers, designers, sales, support, and leadership. Each 'tribe' has its own language, its own goals, and its own fears. Showing everyone the same roadmap means speaking to no one.

The power of a product manager lies in their ability to influence without formal authority. And the roadmap is their main tool. But for it to work, it must be a boundary object—a single object that different groups read differently but which maintains a common identity for the solution.

The principle is simple: one roadmap as a single source of truth, but different 'views' for each tribe.

1. The View for Leadership (Execs)

• Language: Outcomes, risks, trade-offs, predictability.
• What matters to them:
  • How do our bets move key business metrics?
  • What risks are we taking on?
  • What are we giving up by making this choice (trade-off)?
  • How predictable are our results?
• What the roadmap should look like: A portfolio of bets in the format 'Problem → Target outcome → Confidence/Risks.' No technical details, only strategic brushstrokes.

2. The View for Engineers (Engineering)

• Language: Dependencies, scope, implementation risks, scope in/out.
• What matters to them:
  • What technical dependencies exist between initiatives?
  • What is the approximate scope of work so we can plan the architecture?
  • What are the implementation risks?
  • What exactly is in scope, and what are we deliberately not doing?
• What the roadmap should look like: A map of dependencies and risks. Dates only if it's a hard contractual obligation, otherwise they turn into a debt note that engineers pay for with overtime.

3. The View for Designers (Design)

• Language: Scenarios, user flows, pain points, user journey.
• What matters to them:
  • What user scenarios are we trying to improve?
  • Where is the main pain in the current user journey?
  • Which part of the interface or experience should become simpler, clearer, faster?
• What the roadmap should look like: A sequence of user stories or JTBD, focused on improving the user experience.

4. The View for Sales and Support (Support/CS)

• Language: Cases we are solving; problems we are addressing; what can be promised.
• What matters to them:
  • What pains of current and potential clients are we addressing in the near future?
  • What can be confidently promised to clients, and what is still just in the plans?
  • When will the solution to the most complained-about problem be available?
• What the roadmap should look like: A problem-solving calendar. Not 'feature X,' but 'solution to problem Y for segment Z.' Use Now/Next/Later horizons to manage expectations.

Why Does This Work?

When you adapt the roadmap for each 'tribe,' you do several important things:

1. Show respect: You speak their language and acknowledge the importance of their goals.
2. Increase relevance: You give them the information they need for their work, not just noise.
3. Reduce resistance: When people understand, why something is being done and how it relates to their world, they are more likely to support it.

A product manager doesn't manage people. They manage meaning. And an adapted roadmap is the most effective way to convey that meaning to everyone involved in creating the product.