A well-made product roadmap is one of the most valuable resources for a SaaS company.
It informs and sets expectations for everyone in and around an organization. However, communicating product roadmaps and the information in them can be tricky.
Every company has many groups of “stakeholders”. These are people or organizations that care about how you’re doing. Stakeholders can be both internal and external.
Different stakeholders have different interests, values, and concerns—depending on their commitment to your business.
Presenting the same information to these different groups generalizes it to the point where it’s not useful. That’s why you should pick and choose the main points based on the stakeholder group.
You don’t necessarily need several physical versions of your roadmap. However, there are times when you have the power to choose which information to highlight—such as meetings, presentations, Q and A rounds, etc.
In these situations, you should focus on different aspects depending on who you’re talking to. This way, every group gets the most valuable information for them.
Personalizing roadmap presentation to different groups avoids a lot of miscommunication, confusion, unnecessary back and forth, and communication gaps.
Today, we’re going to talk about the most common things different stakeholders care (and don’t care) about.
PS: the following points are generalizations to guide you in your presentations. There will always be exceptions when it comes to what someone cares about. Make sure to leave room for discussion and questions for these cases.
Their main objective: to see whether the company is moving in the right direction in general, whether the company is focused on the right things.
What they care about: high level goals, plans and progress, validation of plans.
What they don’t care about: technical details, complicated data, detailed timelines.
How to present:
- Start with high level goals and when they are expected to be met
- Use simple data that validates why these goals exist (customer requests, etc)
- Explain the expected outcome of these goals (in simple words and numbers)
- Briefly describe the progress towards these goals
Investors and executives aren’t intensely involved in your company’s everyday operations. They probably have tons of other ventures on the side. This means that they can’t spend time on details that don’t matter to them.
Focus on the general direction and high-level goals—and keep it short and sweet.
Their main objective: making sure their business can operate or keep operating using the software, and seeking added value for their use case.
What they care about: when things will be done, exactly what will be done, and how it changes things for their business.
What they don’t care about: who’s responsible, technical details, detailed timelines.
How to present:
- Customers don’t care about details of a roadmap item, they want to know when they can start using it
- Speak about planned deadlines for product roadmap items, but remember to “under promise and over deliver”
- They also want to know what an item actually entails, so they know whether it’s valuable for them or not
- If you collect feedback in a public board and have requests or items you’re NOT going to put in your roadmap, make that very clear, too
Remember—customers are using your software to improve their own business. They care about the functionality of your product. Focus on changes in that functionality. If you’re adding features, explain how it can add value to their use case.
If you’re removing or not building certain features, be transparent about it.
Technical team members
Their main objective: getting their tasks done in a timely and efficient manner.
What they care about: technical details, detailed timeline, who’s responsible for what.
What they don’t care about: high-level information, excessive details about the reasoning behind a task (such as in-depth customer research).
How to present:
- Focus on timelines first—product and development teams need to be able to coordinate well to meet deadlines
- Then, go into the technical requirements of everything on the roadmap
- Ownership is also crucial—make sure everyone is crystal clear about which items on the product roadmap they are directly responsible for
Technical team members want to be efficient with making functionality happen. They need to know when, where, what, and who with they have to do in order to build something great. Coordination is key.
Non-technical team members
Their main objective: efficiently organizing their work, communication, and tasks around the product roadmap.
What they care about: general timelines, who’s responsible for what (for questions and information), details about big changes so they can prepare, benefits of items to communicate to third parties.
What they don’t care about: technical details.
How to present:
- Focus on the timeline and what will be happening when—especially when it comes to big changes
- This gives marketing plenty of time to organize their work around external communication
- Big changes and deadlines should also be communicated to support so they can let (potential) customers know about what’s coming up
- Letting non-technical team members know who’s in the implementation team will also create a sense of security around needing extra information
Non-technical team members want to make sure their job (whether it’s sales, support, marketing, or something else) aligns with what’s changing with the product.
These people are often left out of the loop when it comes to roadmaps and other “technical” discussions. Don’t make that mistake.
Focus on the right product roadmap items for the right people
Having a roadmap is great. However, discussing it is only valuable if you talk to the right people the right way.
There is no universal way of presenting a roadmap. Generalizing and assuming everyone is fine with the same information will cause confusion, unnecessary questions, and coordination issues.
Choosing what to focus on when communicating a roadmap to different stakeholders will ensure everyone will get optimal information for what they need.
Need an option for a good-looking, functional product roadmap to go with your feedback?