How to best create and manage product roadmaps
•Télécharger en tant que PPTX, PDF•
6 j'aime•1,523 vues
Slides Marc Abraham recently used in his discussion w/ mentees of The Product Mentor. The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…Better Decisions. Better Products. Better Product People. Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community. http://TheProductMentor.com
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à How to best create and manage product roadmaps
Similaire à How to best create and manage product roadmaps (20)
Plus de Jeremy Horn
Plus de Jeremy Horn (20)
Dernier
Dernier (20)
How to best create and manage product roadmaps
- 1. Product Roadmap How to best create and manage roadmaps?
- 3. Not just features & dates
- 4. Take a step back! http://www.romanpichler.com/blog/agile-product-planning-vision-strategy-tactics/
- 5. Outline 3pm 3.10pm 3.20pm 3.30pm 3.45pm Start Intro Examples Middle Vision & Strategy Creating & Managing End Q&A
- 7. Outline Date Jan 10 Jan 10 Jan 10 Jan 10 Name Why roadmaps? Take a step back Create Manage Goal Understand roadmap benefits & pitfalls Focus first on product vision & strategy Discuss roadmap creation Discuss roadmap management Results Shared understanding of roadmap role & value Learned what product vision & strategy entail Clear on goals Remove features Understand pitfalls Happy to be flexible Learned how to monitor & update Metrics No. of participants still on hangout No. of participants realising need for vision & goals prior to creating a roadmap No. of times participants will apply a goal or theme oriented roadmap No. of participants who will rethink stakeholder comms and roadmap monitoring
- 8. Why roadmaps - Benefits & pitfalls
- 10. Pair objectives & strategy
- 13. Help prioritise
- 14. Aid communication By Martin Eriksson: http://www.mindtheproduct.com/2011/10/what-exactly-is-a-product-manager/
- 16. Beware! Roadmap comms “The challenge for me with roadmaps is always the communication and buy in part from all parts of the business. I'm in a 23,000 people company, and is a challenge to have everyone agree or be informed properly.” Christian Miccio, VP of Product
- 17. Beware! Hard to predict
- 18. Beware! Hard to predict “If at all possible remove dates that are too far in the future. Try instead for a Q1, Q2, MVP3, MVP4, Set up. This means you can go for themes rather than actual features once dates become too grey to predict with accuracy. This helps mitigate changes you don't yet know are going to happen.” Gary Finnigan, Product Owner
- 20. Beware! Be flexible “Balancing the sales/marketing teams' needs for planned deliverables to talk about with our need for flexibility to adapt to market changes.” Emily Tate, Product Manager
- 21. Why roadmaps? Provide strategic and product direction Offers rationale for decisions, resource allocation and prioritisation Effective communication tool Facilitate stakeholder collaboration Create continuity of purpose
- 22. Take a step back http://www.romanpichler.com/blog/agile-product-planning-vision-strategy-tactics/
- 23. Vision
- 24. Vision “Based on my experience the biggest challenge is to validate the 'vision' behind the whole roadmap” Antti Suvanto, Product Management Consultant
- 25. Start with a vision - business
- 26. Start with a vision - business
- 27. Start with a vision - product https://wiki.mozilla.org/Firefox/VisionStatement
- 28. Start with a vision - business
- 29. Start with a vision - business
- 30. Start with a vision - product Short: “Create a scalable set of tools and services which help our partners to sell as many products as efficiently as possible.” Long: “To provide an end-to-end partner experience around those tools required by partners to solve their critical business needs or workflow issues, irrespective of the number and types of platforms they sell on.”
- 31. Start with a vision Think big – A good vision is lofty and aspirational A shared vision – Create a common sense of purpose which is shared widely across the company Motivating – Outlines product benefits for others Use for decision-making – Use your vision as guide when making business or product decisions Distinguish between vision and strategy – A vision should not be a plan that outlines how to reach a goal
- 32. Take a step back “Making the complex easy and simple” “Biggest challenge is getting budget approval without committing to delivering features by dates” Stephen Sherwin, Product Manager “Getting stakeholders to accept that referencing themes and user problems or even KPIs you want to improve is a better way to construct a roadmap than listing features” James Henson, Head of Product Ryan Frederick, Product Consultant
- 33. Goals / OKRs
- 34. Goals / OKRs “Make sure the problem is identified and understood across the teams before the roadmap is drawn up” Simon Cohen, Product Manager
- 35. Goals / OKRs
- 36. Goals / OKRs Objective: Enable Not On The High Street (‘NOTHS’) sellers to make product and business decisions based on their NOTHS performance data Results: NOTHS partners make data informed decisions before and throughout Christmas ’15 NOTHS partners benchmark their gross turnover stats as we believe this will help them make product decisions
- 37. But … Don’t forget about strategy, ‘the bit in the middle’ What problem are we trying to solve and for whom? We believe our partners have a need to understand how their products are performing on our platform. We believe they currently suffer from a lack of transparency, making it hard to make decisions. What is the outcome we are trying to achieve and why? We believe that having real time access to performance data will enable partners to make quick decisions about e.g. their stock levels, products to remove or extra staff to hire. We also believe it will remove some of the strain on our account managers who currently spend a lot of time generating reports for partners.
- 38. Strategy – ‘Bit in the middle’ https://blog.intercom.io/talk-product-strategy-saying/
- 39. But … Don’t forget about strategy, ‘the bit in the middle’ (cntd) What are the competition doing? Our competitors are providing sellers access to sales stats, reason why partners expect more transparency from the platforms they sell on. We therefore believe that providing data is therefore a basic hygiene factor. What does success look like and why? Our competitors are providing sellers access to sales stats, reason why partners expect more transparency from the platforms they sell on. We therefore believe that providing data is therefore a basic hygiene factor.
- 40. So what … We believe our partners have a need to have access to their real time sales data, so that they can make critical business and product decisions on an ongoing basis We believe our partners need to benchmark their real time sales data, so that they have more context before making decisions
- 41. Assumptions We believe these needs can be solved through a real time data dashboard which makes it easy for partners to view and extract all the data they need for their day-to-day operations We believe the no. 1 value our partners will get out of this dashboard is the ability to see at a glance how their business and products are performing
- 42. Hypotheses We believe that providing our partners with a real time data dashboard will help them make critical business and critical decisions We know this is true when we see an average of 5 visits of the data dashboard per partner, within 1 month following the first dashboard release We know this is true when we get qualitative feedback from 100 partners within 1 month following the first data dashboard indicating that they have used the data to make stock level decisions
- 44. Strategy - ‘Bit in the middle’ Business goals Revenue & profit User Experience Business model Value chain Customer segmentation Design principles Competitors User needs Technology Compliance Domain Geography Strategy Constraints
- 45. Take a step back Identify business vision-> create product vision Ensure product goals are SMART or OKRs Think about business and user goals to achieve Focus on problems first Don’t forget about strategy, the bit in the middle!
- 46. Create a roadmap
- 47. Create a roadmap “Navigating that ‘if I asked them what they wanted they would have said faster horses’ space in a way that you keep users, bring innovation and strengthen your own identity” Sherwyn Singh, Talent & Leadership Coach
- 50. Problems not features "If I had one hour to save the world I would spend 45 minutes defining the problem and only 5 minutes finding the solution” Albert Einstein
- 51. Unknown unknowns
- 53. What’s wrong? What is the context? Why are we doing certain things? Why not? What value are we looking to deliver and why? What business or user problems are we looking to solve, for whom and why? Don’t forget that your roadmap is a communication and collaboration tool!
- 54. Pitfalls when creating Common pitfalls when creating a roadmap: Why? - Just a collection of features and timings Dependencies - Not thinking about cross-product or team dependencies “Solution sickness” - Fixating on a feature or solution upfront
- 55. Facilitate learning “Working towards goals without getting fixated on specific features leaves room for learning as well. Over time one may learn more about the problems to be solved, and also possible solutions to problems. Going further one may even learn that the problem to be solved is somewhere else than originally thought, i.e. there is an even more important problem that needs to be solved, but the customer (or the solution provider) was not able to identify that in the beginning.” Stefan Baggström, Solution Architect
- 57. Create a roadmap
- 58. Roadmap themes
- 59. Owning the roadmap Who typically creates and owns a product roadmap? Product Manager
- 60. Roadmap stakeholders Who typically influences a product roadmap? Stakeholders
- 61. Roadmap stakeholders By Janna Bastow: http://www.mindtheproduct.com/2014/07/product-roadmapping-prioritisation-portfolio/
- 62. Create a roadmap Don’t fixate on features; focus on problems, goals, assumptions or themes instead Important to not lose sight of measurable results Consider adding extra layers to allow for risks, dependencies and product discovery (‘unknowns’)
- 63. Manage a roadmap
- 64. Manage a roadmap “One of the challenges is around stakeholder management in the agile world. If it goes in a roadmap (and in some ways you have to question the term 'roadmap') with a month/quarter against it then that is often taken as gospel by stakeholder and reported on from them accordingly :-) At best the roadmap is really only accurate the day you drew it!” Alistair Harvey, Head of Product
- 65. Roadmap a one off
- 66. Roadmap Set in stone
- 68. Manage a roadmap
- 69. Roadmap updates
- 70. Manage a roadmap
- 71. Manage a roadmap
- 72. Product Roadmap - 3 things 3 things to take away: Take a step back before creating a roadmap A roadmap needs strategic context Stakeholder communication is critical
Notes de l'éditeur
- As part of the introduction, ask the participants about the biggest challenge they face when it comes to creating and managing roadmaps
- I have seen product roadmaps used in lots of different organisations for lots of different purposes. Whilst there is a lot of value to come out of product roadmaps, there a lot of common pitfalls that I see roadmaps and product managers suffer from. Today, I would like to talk about both the value and the pitfalls of roadmaps - and provide you with some concrete suggestions on how to create and manage product roadmaps effectively.
- There are two core areas I would like to focus on today: Roadmaps are not a loose collection of timings and features - I will talk about the value and the common pitfalls related to creating & managing a product roadmap, and will provide you with some concrete learnings and suggestions that will help you to achieve this value and avoid the pitfalls. In case this example looks similar to something that you or your business are using at the moment, my hope is that after this session you will have a different outlook on how to best create and manage a product roadmap, moving away from templates like this one!
- Take a step back before creating a product roadmap - Having a product vision and strategy in place is a must before you start creating and managing product roadmap, a roadmap only comes in as part of the ‘product strategy’ layer of this onion created by Roman Pichler. I will argue that a roadmap needs to be much more about goals and user problems in order to be effective, rather than features and timings.
- So I want to cover all these different elements and this is my brief outline for today’s session. At 3pm my time I’ll start with an intro about the product roadmap and at 10 past 3 I’ll cover some relevant examples. At 3.20pm I’ll then move on to vision & strategy, after which I’ll talk about creating and managing roadmaps. I’d then love to answer any questions you might have.
- With the best will in the world, I can’t and wouldn’t want to predict exact timings for the different components of my talk. Some items might take a bit longer or shorter to discuss and I won’t know until I start talking. My previous outline presumes a very linear process: “First this, then that” … But I am sure that certain topics in my talk will overlap and I will come back to them. Also, you might have questions throughout the presentation rather than right at the end. Finally, the timings won’t mean anything to you as we’re all in different timezones. But, for me the big problem with this outline [go back to previous slide] is that it lacks total context. For example, where it says “example”, I can imagine you might be thinking “examples of what!?” or where it says “creating & managing” … creating and managing what!?
- Instead, this is probably a more representative outline of the things I would like to cover today. At some point in my talk today we will talk about the value of roadmaps, I will cover taking a step back before putting a roadmap together. I will also give you some real life examples and tips with respect to creating and managing product roadmaps. If you have any questions throughout the talk or you are unclear about things I am talking about, please don’t hesitate to let Jeremy know who will be moderating.
- Let’s start at the beginning: I want to make sure we all have a shared understanding of what the benefits and pitfalls of a roadmap are, in other words the “why roadmaps”.
- We need direction! The first benefit of having a product roadmap is that it helps to provide direction for the business as a whole, us as product managers and the teams we work with, as well as our customers, suppliers and any other external stakeholders. Product roadmaps are a great way to visualise and communicate the strategic and product direction we are taking, and explain the underlying rationale for that direction.
- The second benefit of a roadmap is that it is a great way to link specific business objectives and product strategy.
- A third benefit of a roadmap is that it is a great tool for creating and maintaining a continuity of purpose. Often the ‘how’ (tactics) behind achieving a purpose is likely to change or evolve, but the overarching purpose is likely to remain more stable. The user or business problems that you will be addressing are likely to change, but having a roadmap helps in bringing it all together, visualising this evolution whilst providing a rationale for this change.
- The fourth benefit of a product roadmap is that it provides opportunities for getting a wide range of stakeholders on the same page and getting their input on e.g. product or tradeoff decisions. We all know that having others involved in a roadmap comes with its own challenges, but the roadmap is a good tool to collaborate around.
- The fifth and penultimate benefit is that the roadmap provides a reference point to make prioritisation decisions against. Even if you end up de-prioritising things on the roadmap, you will have something to deviate from rather than just making these decisions willy nilly.
- The sixth and final benefit is that the roadmap can be a very useful communication tool, helping us product managers explaining prioritisation and product decisions, as well as the underlying ‘why’, to a wide range of stakeholders. This diagram was created by a friend of mine called Martin Eriksson and it shows you the ‘intermediary role’ that we often have to play as product managers. A roadmap can be a very helpful communication tool when we liaise with the different stakeholders.
- Now that we have looked at the benefits of product roadmaps, I want to briefly go into the pitfalls related to roadmaps. First, breakdowns in communication is one of the reasons product roadmaps often lose their benefit to the organisation, for example when product managers stop referring to their roadmaps when explaining priorities or the ‘why’ behind certain decisions. A product roadmap can be a great communication tool when engaging with stakeholders about product direction and priorities, but you will have to use it as such!
- A quote from one of our fellow product people [followed by silence]
- The second issue with roadmaps is the common perception is that once a roadmap has got timings against it, things will automatically happen as planned. Not true, as product people we have lots of skills, but predicting the future is not one of them! With the product roadmap, you can come up with a plan for the next 3 or 6 months, but you will have to accept that things change or will not happen as planned.
- The third roadmap related issue to beware of that since we are not clairvoyants we need to accept that things are likely to change. Think business changes, market environments, technology, etc. Our product roadmaps are likely to evolve as a result and we need to treat them as living, breathing documents rather than one off exercises.
- [silence]
- So … to summarise these are the key things I hope you will be able to take away from the part about ‘why roadmaps’ [point for questions]
- So we have talked about why it is important to have a roadmap, I’d now like to take step back and talk about creating product vision and strategy first, before creating the product roadmap. What I want to make clear here is the necessity to come up with a product vision and valid(ated) product strategy before you create a product roadmap. Not only is this critical for when you create the product roadmap - as it provides valuable context - it is just as important for managing the roadmap on an ongoing basis, when you want to communicate how product progress fits in with the wider product vision and strategy.
- If you don’t create a vision first or linking your roadmap back to a vision, you typically end up with a list of features without people in the organisation understanding why we are doing certain things or not doing them. Same applies to having a product strategy.
- The answer to these challenges is to take a step back before you start creating a roadmap: What is the vision for our business? What are we looking to achieve as a business and why? How does this vision translate into a product vision, strategy and Objectives-Key-Results (OKRs) or Key Performance Indicators (KPIs) Does anyone know which company has the vision on this slide?
- The answer is furniture maker and seller IKEA: their overarching vision is “to create a better everyday life for the many people.” The subsequent product strategy should align with this vision and its underlying values: well-designed, functional and affordable.
- Another good example is Mozilla Firefox’ product vision statement.
- Let’s look at an example that I am close to: I work at a UK marketplace called “Not On The High Street” which small enables arts & craft businesses through an online platform.
- The key part of our business & product vision is to create “the place where everything ‘less ordinary’ is found.” Even though this might sound quite generic or lofty for your liking, as a product manager, this statement provides me with a useful starting point for thinking about what this means for my product and my plan to improve or create a roadmap.
- The way you draft these statements is not set in stone, but let’s have a look at some common characteristics of what makes a good product vision [next slide]
- These are the characteristics that make for a good product vision [point for questions].
- Apart from creating a vision, I believe it is important to consider goals before you create a strategy to get there and a roadmap to plan it. In other words, taking a step back to look at what you are trying to achieve and why, well before you start thinking about possible solutions or features: what are our strategic goals and KPIs that our products or services need to impact? what user problems or market needs are we looking to solve and why? how do we achieve these goals? what is our business and product strategy? what is the (most pressing) customer and / or business problem that we are looking to solve and why? How do we know if we have solved this problem? who are the relevant stakeholders and why? what is their vision? what are their objectives?
- Think: Top level - business or product vision - big, aspirational goal Next level down - specific goals or ‘OKRs’ (from Google / John Doerr: Objectives Key Results) related to specific user or business problems that you are looking to solve The key point that I want to make clear here is that I typically work out the specific goals or OKRs first before creating a product roadmap
- We could easily spend a whole separate session on goal setting, but I just wanted to share a simple but good example for now: A clear objective, with well defined results -> SMART (specific, measurable, realistic, achievable and time bound) -> which I can then feed into the roadmap. The one thing I would challenge on this example is that I am not the biggest fan of just asking customers what they want, but we’ll come back to that.
- Real life example
- Once you have established your key product goals or OKRs, I suggest not going straight into roadmap mode, as I believe it is important to think about your product strategy first. Purely as a way to figure out how to achieve your goals, considering and TESTING a number of possible product directions as part of the process and taking into a range of a factors, constraints and stakeholders that influence your product strategy. As product managers, I feel there is often a risk of diving straight into product ideas or features, which can be a risky approach if you have not thought through and validated your wider product strategy, constraints and success factors first.
- So we have looked at taking a step before putting together a roadmap, but now it is time to look at actually creating a roadmap. I will focus more specifically on what a roadmap is and isn’t, looking at things that are important to take into account when creating a roadmap.
- As part of thinking through and validating your wider product strategy, it is important to look at the competitive and understand customer expectations. As part of doing opportunity assessments I always ask myself the question “what alternatives are out there?” and “why now?”. Also, it’s worth using the KANO template to distinguish between “delighters” and “hygiene factors” and validate this distinction with your (target) customers.
- Hence I am always looking to learn about the “so what” for the customer and/or the business - some simple examples
- I will then translate these learnings into testable assumptions, which can be split into business and customer assumptions. The key point I want to stress here is that it isn’t about the solution but the problem and what solving that problem looks like for the users [focus on the user outcome], irrespective of the solution
- Simple example - How do we know that we have met an assumption? How do we measure success?
- My example of validating the product strategy and the underlying problem statements, assumptions and hypotheses quickly and cheaply before going into roadmap and make a firmer commitment (e.g. in terms of time, money, people, etc.). This was part of a DISCOVERY iteration.
- This is by no means an exhaustive list of factors that feed into a business and therefore a product strategy; some areas are more critical from a product perspective than others Too often I see product people jump straight into a roadmap without thinking about things like the key business goals, customer problems or competitive landscape. For example, I find much easier to have a conversation with my CEO about our revenue target for the year, the customer lifetime value or about scaling the business operations instead if whether to go for feature A or B.
- Summary page [point for questions]
- So we have looked at taking a step before putting together a roadmap, but now it is time to look at actually creating a roadmap. I will focus more specifically on what a roadmap is and isn’t, looking at things that are important to take into account when creating a roadmap.
- This quote is a nice way to tie in with the first pitfall I’d like to talk about
- One of the reasons I strongly believe in thinking about vision, strategy and goals - like we just discussed - is that if you don’t, there is a risk of ending with a product roadmap which is effectively a wish list of features (often dictated by customers or internal stakeholders), without much of context or underlying rationale.
- This is a real life example that I came across recently. At a customer event this company gave people 1st, 2nd and 3rd priority stickers and asked them to put these stickers against certain product ideas. As you can see, lots of people voted for the API as the most important idea for the company to implement. One could argue that there is not much wrong with this idea since you are generating direct customer input. However: there is a risk of customers speculating about what it is that they want (or what they think you want to hear) without thinking about whether they really want and how it solves their actual problems it is hard to figure out why people voted 1st, 2nd or 3rd for this idea. Why do they think this idea will have value for them why not? What is the expected impact and why? For example, when company staff asked some customers afterwards why they had given their top vote to the API, some people thought the API would manage their stock levels for them or actually were not quite sure what an API actually was (-> group think) To avoid these pitfalls, I typically work with assumptions and hypothesis which I validate as part of a product strategy, which I find a more reliable and accurate way of learning about customer needs.
- However, one of the other problems with the approach we saw in the previous slide is that you are unlikely to capture the “unknown unknowns, the things we don’t we don’t know” as Donald Rumsfeld would say. There is a risk of customers speculating about the things you want to hear or not thinking through how they would actually benefit from a product or service, which of their problem(s) it would actually solve. Also, going back to the API example on the previous slide [go back to slide], when people who had voted for the API were asked about the API, some did not even seem sure about what an API was, they thought it might be a stock management system!
- This is a good example of some the common pitfalls I summarised on the previous slide: a list of features commitment to specific solutions upfront no sign of cross team or product dependencies no evidence of strategic user or business context, no sign of ‘why’
- What is the context? Why are we (not) doing certain things? - Link with strategic goals and measurable OKRs Focus on problems first, not on features! Going back to the example on the previous slide [go to previous slide] - not particularly effective from a comms perspective or inviting collaboration: yes, it tells you features and timings, but it does not tell you about underlying rationale or priority (e.g. what happens if timings are not met).
- So, to summarise, these are the key pitfalls to be mindful of when creating a roadmap [point for questions].
- This “goal oriented roadmap” was created by Roman Pichler in order to avoid a roadmap just becoming a collection of features and focus much more on PROBLEMS instead. The great thing about Roman’s approach is that it includes goals and metrics, which helps product managers and stakeholders to understand what we problems we are looking to resolve and how we are going to measure success. The other benefit is that you can easily add extra layers to this roadmap. For example, you can add an extra layer for ‘dependencies’, ‘risks’ or ‘product discovery.’
- When creating a goal-oriented roadmap I typically don’t include features as I want to leave some flexibility about possible solutions for when we actually get to work on specific customer theme or problem. This focus on problems follows the product strategy which includes assumptions & hypotheses to validate, before and as part of the ongoing roadmap.
- Creating a theme based roadmap, as invented by Bruce McCarthy, is a similar approach to the goal oriented roadmap. Instead of focusing on features, the emphasis is much more on business or customer themes that you are looking to address.
- I know it varies per organisation, but the Product Manager typically creates and manages the roadmap and is accountable for its delivery.
- Creating a roadmap is one thing, but collaborating with stakeholders around the roadmap is just as critical. The range of stakeholders that can influence a roadmap and that you need typically engage with as a product manager is likely to vary. Typically, stakeholders are to be found in one of the following camps: sales, marketing, tech, suppliers, shareholders, board and customers. One thing that I have learnt over the years is to make sure to involve DEVELOPERS early on when creating a roadmap. Most of the developers I have come across do like to know the ‘why’ behind some of the things they get to work on, so the sooner you can give them more context, the better. We’ll talk more about how to best communicate and manage stakeholders when we talk about managing the roadmap in the last part of my talk.
- This is a good overview from my friend Janna Bastow, who is co-founder of ProdPad which provides business with a tool to create ‘theme’s based roadmaps. Creating a roadmap is one thing, but liaising with stakeholders around the roadmap is just as critical. The range of stakeholders that can influence a roadmap and that you need typically engage with as a product manager is likely to vary. Typically stakeholders are to be found in one of the following camps: sales, marketing, tech, suppliers, shareholders, board and customers.
- So we have talked about creating a roadmap and things to look out for, the question now arises how to best manage a product roadmap and make sure it becomes a living, evolving tool for collaboration and communication [take questions]
- Silence, give the audience a few moments to read
- A product roadmap is not something you do as a one off exercise and then goes onto a shelf to gather dust …
- Especially when working with stakeholders it is important to stress that a roadmap is never set in stone, its main function is to provide a strategic product direction. It enables you to deviate from a roadmap and change priorities in a well informed way.
- This is a good example of where I recently my roadmap to highlight issues around certain product milestones (with the word “RED” and “AMBER” next to them), new things to consider (in orange under 31 Dec) and to bring up risks & dependencies that we are mitigating for. Weekly standups senior manageent.
- Creating a roadmap isn’t a one off exercise, after which everything goes to plan. Ultimately it’s a tool to use as a basis for communication and collaboration. As product manager we constantly have to make tradeoff decisions and the roadmap gives us a tool to take into account when making these tough decisions.
- A crucial part of managing your roadmaps is providing regular updates to your stakeholders. The goal of these updates is to discuss progress against the product strategy and roadmap, priority changes, tradeoff decisions and performance of previous product releases.
- Regular roadmap reviews, updates and ‘product retrospectives’
- Example from a webinar I joined a few years, facilitated by the CTO of GetSatisfaction, a tool for consumers to log product questions or issues -> he didn’t go through each individual feature nor committed to specific roadmap timings, but he gave a good overview of roadmap themes and underlying drivers
- Take a step before creating a roadmap -> it’s important to have product vision, goals and a valid(ated) strategy A roadmap needs context -> Don’t just create an overview of features but focus on times, problems or value instead Stakeholder communication is critical -> A roadmap is a living document which required constant updates, progress measurement, etc.