AMA: Doppler Principal Product Manager, James Heimbuck on Product Roadmap & Prioritization

I am a BIG proponent of having a version of the roadmap that can be shared externally! There are some tactical things you may need to do to ensure you can share and to make sure it is effective. These are my experience and yours will depend on your specific scenario including company size and industry, product, customer type, geography, etc. 1. Confirm with internal stakeholders like legal and your product leadership that you can share a roadmap externally and if it is only for customers or for prospects and if they need to have an NDA or some other agreement in place. 2. Prepare sales enablement training. One of the main benefits of having a roadmap artifact that can be shared is that it means product managers do not have to share the roadmap in person with every external party that wants to get the information. This only works if you prepare your field team on how to talk about the contents and keep them up to date when it changes. In the beginning it will often feel like more work than presenting it yourself but it will pay off. 3. Make the roadmap! My preferred format is a "Now, Next, Later" in which "Now" are big rock projects that we can share some early designs and the specific use cases being built for the first version from. Next contains the solutions we are validating, talking about the use cases we are validating or have validated in research. Later would be the high level strategic areas we want to explore. Each of these may represent a month, a quarter or a year, that timescale depends on your product and org. For a SaaS B2B company I like to keep it at Quarters for Now and Next and a year for the "Later". This goes back to the earlier question about different formats for different stakeholders. With the use case of a public road map you have to remember not only the audience but who is presenting it, or not, so the right context is shared in the content. Good luck!

What is shared on the roadmap is all about who the audience is you are talking or preparing it for review and what incentives they have. Some things I have found success with are: * For the executive team the focus should be on a few large items or themes that have clear ties to business outcomes. If the business focus is on new revenue focusing on the high level items that are intended to drive new sales with high level explanation of how (It serves a new buyer persona, it is a new usage based add on, etc. * For a delivery team the roadmap might need a lot more granularity and may need to be a lot shorter in time horizon. The team cares about what they are working on right now with a glimpse of the future. I find it is really important to remind the team of an overall vision, why it is important we are going there and how the most recent work keeps us moving in that direction to keep them motivated and focused on what we are doing. * For fellow product managers you might focus on how your upcoming deliverables are impacting the larger KPIs or how you are building features they might leverage to improve their own KPIs. There are many other stakeholders you could be building a view for at any time. Unfortunately there is not a one size fits all roadmap format for them because their incentives are different and you want to show them what you are working on as it contributes to those incentives.

Great question! It's easy to fall into "i'm sure a user would want to ABC and then they would XYZ . . " and expand the scope of your first iteration. The process I have found that has the most success is a couple of steps that focus the use cases being delivered to those that move the business goals forward. 1. Match a product outcome to a business outcome * If you have a business goal of increasing revenue product goals should ladder up to that. So new product line, driving user growth by X% or increasing upgrades by X% might be the product goals. 2. Pick a use case that delivers the product outcome. * Going from that product goal, what is a problem to solve or use case to deliver for customers that moves you towards the goal? If you are trying to drive more Daily Active users and find that a specific action is being taken by your power users driving a higher percentage of users to take that action could be a use case to explore. 3. User story map the use case and cut cut cut * Now that you have the use case you can map the customer journey through it asking questions like "what are the ways a customer would get to this step? What do they have to do before this step to get here? What will they need to complete this step?" and and then cutting until there is a minimal path through. There are excellent resources on the web about User Story Mapping that can guide you throughthisprocess. Going through these steps may seem like a lot of work but if you are in the business of building an MVP it is important to be talking about the "why" as often if not more than the "what" and shipping the minimal "what" to get the maximum "why".

Wow that is a great question and a tough spot to be in for sure! I would approach this by starting with the value prop of your product and asking yourself some questions. * How are customers getting value from the product? * Take Uber for example, their value to customers is a fast, reliable way to get transportation. * What actions and behaviors do they need to take to get that value? * Building on the Uber example users get that value when they search, book and complete a ride. * What is preventing users from getting that value? * This is where we start to get to specific problems to go solve that land on the roadmap. Going further with the Uber Example an early problem they may have faced was not very many users were searching because they did not know the exact address of their location for pickup or it was too many steps to get to it. A product outcome for the roadmap may be "Get x% of users to turn enable location services when using the app" Now you can draw the line from an item on the roadmap to a value customers get from your product and why it is important to work on those items and solve those problems. Using this narrative also shares with that team why those things are important to customers so they can fill in their own knowledge gaps about the business, product and customer it serves.

It sounds like the question may be more about how do we empower our teams to work on outcomes than product roadmaps, a spicy one for sure! I would not worry about each team using a specific template for how to present a roadmap expect when you need to present it to internal stakeholders and then would focus on a few high level things. * What problem do you want to solve and what business goal does it impact? * Who is the customer this is for? * What is the expected impact and timeframe it will be achieved in? The assumption here is that your product teams are empowered to work on what they think will deliver that biggest impact customers. There may be a lot of work needing to be done with the teams and internal stakeholders to get to this place before you can shift from presenting about projects to presenting about outcomes.

Talk to customers, talk to customers and talk to customers!! Any time you have a chance to talk to a customer or a potential customer take it! I find that mixing qualitative discussion and validating with quantitative research that we are not solving a problem for a loud customer or the most recent account review helps ensure you are working on a problem with real reach and that solving it will have real impact for customers. For me the best signal of a customer with a real problem is one who is already trying to solve a problem with a workaround. A common example of this I have run into during my career is in building simple user dashboards for customers in a product. This shows up in many ways during customer conversations. You may get questions about an API to pull data, rate limits on an API, specific questions about how to get usage data, etc. Those are good hints that customers are trying to get data for themselves to present or analyze so there is an opportunity to provide it for them in a dashboard OR if a data interface is not your core competency provide them a richer data feed so they can get at the data they need. When it comes to measuring reach and impact of a problem I like to mix a quantitative and qualitative approach. For reach once I have validated there is a problem I'll try to extrapolate how many other customers might have this issue. Using the dashboard example above we might look at how many users are also hitting those specific endpoints a customer asking about the APIs for. If there is not enough attempted usage here (or enough conversations) then it may not be the most important problem to solve right now. For impact I like to work with customers to answer this by comparing and contrasting problems to understand the urgency of the problem. This might work by asking them to stack rank against other requests they have made or as simple as "are you trying to solve this now and if not what are you trying to solve?" Using these approaches helps me keep the recency of the most recent conversation from influencing what I prioritize next.