Deciding how much of your product roadmap – if any – to show your customers can be an area of uncertainty. Your product roadmap is your company’s high-level and strategic goals documented, along with an execution strategy that communicates how you plan on getting there. Your product roadmap is relevant for anyone concerned with where your product is headed: the team, the board, and… the customer. Sharing your product roadmap with customers is key, but it can be difficult to do so without conjuring updates and features which will certainly change on the way. If you’re not careful, you might find yourself in dangerous territory, read on to stay away from common pitfalls.
Since your roadmap tells your customers the about your vision for the future, it’s a great conversation starter. The thing is, any Product Manager will tell you that the roadmap is a plan which guides you towards an endgame, but what happens between then and now is subject to change. Make sure to be aligned with your product team to know where your organization is currently at on its way towards the end goal.
Depending on that, be transparent with your customers and understand that no matter what, they will have feedback for you. If you’re sharing a long-term plan which is already far underway, don’t pretend that fundamental feedback will have a direct impact on the development process, but try to involve customers in user-testing and feature feedback sessions. On the other hand, if the product roadmap is still subject to major changes, encourage feedback around the direction your product is headed to solidify it. This approach creates a relationship so strong that it offsets any risk associated with making your product roadmap public.
Don’t Promise What You Can’t Deliver
If you understand why transparency is key, you’ll also understand that you must stay away from unrealizable promises. Your role is to protect the long-term relationship your organization creates with its customers. It feels nice in the short-term to make customers feel like they’re being listened to, but a strong relationship is one where you value honesty above all else. Remember, you’re free to position yourself as their ally because the role of a CSM is to bridge the “us vs. them” gap they might otherwise be perceiving.
Finally, manage expectations. It is your responsibility to make sure that at the end of the day, your customers don’t confuse your roadmap to be set-in-stone. Stakeholders should be comfortable with uncertainty because your roadmap, too, will be adaptable. Be prepared to reallocate resources in order to align your initial vision with new developments, whether they’re coming from the user base of the competitive landscape.
Don’t Put A Timer On It
Sharing a roadmap without dates allows you to change the route you’re taking as you make new moves. Instead of wasting time and energy focusing on the when you’re going to deliver, focus on the what – allowing you to talk about the actual vision and direction you’re taking.
Of course, don’t have your customers lingering on without any solid footing. A 12-months aspirational plan with key actionable items and an approximate timeline is a good way to hold yourself accountable while giving your product team some room to breathe and adapt along the way.
Focus On Semantics
Be aware of the power of your words. As a Customer Success Manager, you are the messenger between your product team and the customer – how you phrase and present a situation deeply affects the customer. Consider the difference between:
“We absolutely will change the UI by the end of the year, every person on the team is on it”
“Great feedback on the UI, we’re currently gathering data from our user base to put together a proposal. Once we have it, we’d love to hear what you think. We’re looking to deliver within 12 months”
The second option does a few things: it manages expectations around what exactly will change and when it will be delivered, it is transparent about the stage where the project is (proposal), and it builds the relationship through further involvement in the project.
Finally, stray away from deadpan deadlines and focus on providing validation through experimentation.