Marvin Green

Great question! This is something most product teams wrestle with when only looking at the roadmap from a features perspective to balance what to build for existing vs prospective customers. What I’ve found very useful to address this is to revisit the product strategy and business drivers for the product and align the roadmap accordingly. For example, if you assess your product strategy and look at the data for your business drivers, you may see a trend that customers really start adopting your product in years 2-3 with 10x revenue from their initial purchase, what decisions would you make? One decision could be to build more features to get more prospects because you know it will pay off in years 2-3. OR, you could decide to focus on existing customers but learn from your customers why adoption is lagging and then focus on solving your customers needs to speed up adoption so they get value earlier from onboarding or within the first year and shift that 10x revenue earlier in the cycle for your business. In short, I found it best to revisit the product strategy, and leverage data from customers and business drivers to make an informed decision on how to position the roadmap for existing vs prospective customers. Once you identify the customer or business outcome you want to drive, use the roadmap to deliver that outcome.

Thanks for the question! You, my friend, are in a coveted position. I would encourage you to shift your mindset and look at it as an opportunity to influence and educate your leadership team on what you know about your customers and create a vision and strategy for your product to share with them. Since the leadership team is new, you have the opportunity to show them that you are proactively thinking about the product direction and execution versus waiting for direction. So take a shot and give it your best.

I appreciate this question! Generally speaking, we get inputs mostly from sales, customers and product/engineering. I’ve used the approach of building partnerships with stakeholders and that takes care of the influence vs control dilemma. When you have a strong partnership with your stakeholders, they trust you that you’ll make the right product decisions and in turn, you show that you value their inputs. So I would encourage you to think more about building stronger partnerships so you don’t have to struggle with influence and control.

I like this question because it is such a classic situation. I’ve seen this played out at companies and it’s likely a culture issue that it’s very hard to change unless the Product and Sales leadership teams get together and have a heart to heart about it and come to an agreement on the best path forward. Getting the autonomy you are looking for starts at the top and it has to be a coordinated effort to address the culture and behavior. On the other hand, it’s great to get sales input into your roadmap because they are out there daily with customers. If you are looking for a grassroots approach to autonomy, one suggestion would be to ask sales for a prioritized list of their requests (with a business case) and agree on a number of requests you’ll directly add to your roadmap each quarter. This provides sales a window to your roadmap while providing a balance for you.

Thanks for the question! Earlier in my PM career, I used to keep my roadmap a “secret”. As I gain more experience, I realized that it’s valuable to share the roadmap openly with sales, marketing and key stakeholders to build a solid partnership. How I communicate the roadmap and the level of detail I share is based on what each team needs. For example, the sales leadership team may want to know about the big rocks and themes. Your sales engineers will need to go into the weeds of the roadmap and even how you are thinking about building out the features. The best thing to do is to ask the teams/stakeholders what level of info they need and then provide that detail.

I’m wishing you a successful product pivot! You got this! In this situation, you have your internal stakeholders (sales, marketing, GTM, etc) and you have your customers you need to reset expectations with (mostly for B2B products, less so for B2C) For your internal stakeholders, the best thing you can do is be transparent and bring them as close as possible to what’s happening. For example, share the challenges, the tough trade off considerations, data you are using to drive your decisions, etc. This builds trust and partnership. Once you do that, sharing a short term roadmap will be more understandable and you can always provide a DFAD (date for a date) on when you expect to know more or have more things planned (milestones). For your customers, also be transparent about the pivot and why you are making this change. Hopefully this pivot is ultimately for the best interest of your customers. Also, what works really well is if you take the opportunity to solicit feedback from your customers about the pivot and get some insights from them. This builds trust and a stronger partnership with your customers. And since you can’t share plans too far out, a DFAD is also good to manage expectations with your customers.

Interesting question! From my experience, there are two key questions to answer when thinking about going public with your roadmap. 1) Do we have a predictable sprint velocity? 2) Do we have a predicate delivery rate? Once you have a predictable sprint velocity and predictable feature delivery, you have a high certainty that when you plan features, they will be delivered on time or close to when you expect. There is some degree of change and reprioritization that happens naturally with a roadmap so I’m not saying dates won’t ever change. If you go public with your roadmap and keep changing your delivery targets, you will damage customer trust and then have to work hard to rebuild their trust in your execution and roadmap. In terms of what to include in your public vs internal roadmap, it depends. Here are some ideas. 1) You can put your higher priority items on the public version so you negotiate less with those and reserve the lower priority items for your internal roadmap. 2) You can showcase more of the features that customers have requested on your public version. 3) Add items that are closer to delivery (12-18 months) on your public roadmap and keep the items that are further out on your internal roadmap.

At Splunk, we’ve built a tightly executed roadmap update process where we spend about 2 weeks each quarter to refresh our roadmap so our customers, sales and GTM teams have the latest and greatest roadmap info. In that 2-week process, our product managers and product marketing folks actively collaborate on the roadmap updates. What does that collaboration look like? It’s product managers sharing the features and refining the messaging, customer outcomes and use cases with product marketing so we can have a solid roadmap and tell a compelling story to our customers. The marketing team also provides feedback and insights to the product team based on what they are seeing in the market and hearing from customers.