Get Started for FREE
Sign up with Facebook Sign up with X
I don't have a Facebook or a X account
 Your new post is loading...
Your new post is loading...
Scoop.it!
Lisez aussi : 
No comment yet.
Sign up to comment
Scoop.it!
Your roadmap should be much more than a list of features. Simply listing your features could be easier or even what is expected of you, but doing so will miss the whole point of why you are creating a roadmap at all. Here’s how you should be thinking about it.
Mickael Ruau's insight:
Prioritizing Without Features
This abstract MECE, outcome-based work can be applied in multiple ways, depending on the company stage and its specific challenges. However, one thing should always be there: an end goal. You should start your roadmap efforts by defining and refining its goal. Say a roadmap is for 12 or 18 months — where do you want to be by the end of it? What would be considered a success? It’s only once you have full alignment on that that you can start planning towards it. Now, remember that we left features out of the discussion, so what should you plan exactly? Since your end goal is not to deliver a feature but rather to deliver value or reach certain business results, your path to this goal should be expressed in the same way. To reach certain business results, say an ARR target, you need to reach interim goals along the way. It could be smaller ARR numbers that are in the path to the larger one, but it also could be softer or related goals like demonstrating viability in a new market segment, providing additional value (for example to additional personas or by supporting additional use cases), faster onboarding, reducing churn rates and so on. It could be that to meet your goals, you will need to breakthrough something that is stopping you from getting there, like brand perception, selling to smaller or larger organizations (which often has an impact on how marketing and sales work and not just on product features), or even the efficiency of how you work internally in order to keep your competitive advantage. What about timelines? Notice that I didn’t discuss timelines at all in this article. They are left for later stages of the roadmap creation, just like features. While timeline considerations can definitely impact the final roadmap (since sometimes if something can’t happen soon enough it’s best to not do it at all), you need to initially figure out the order in which things should proceed, regardless of how long each step takes along the way. It is at these levels that you want to find a path that makes sense. By not allowing yourself to discuss features, you are forcing yourself to find a roadmap that will help the entire organization meet the goals together because everyone will go on the same route, not just in the same general direction.
Scoop.it!
Strategy, visualized. Crafted by design, engineered to keep customers close.
Scoop.it!
How can we be agile, experiment, and be outcome-oriented while keeping a detailed plan of all the output that will happen in the next quarters? Promising a product plan that’s filled with certainty…
Mickael Ruau's insight:
The foundation of this roadmap aligns everyone around a common cause:
Secondarily, we can add sub-items to the Product Initiatives:
Finally, we can tag the items (particularly Product Initiatives and Options) with additional information such as:
That’s it, we’ve got our roadmap, with an all-modern look. Can we now frame it and hang it on an office wall? You guessed it — it’s not that easy. Modern or not, roadmaps shouldn’t be set in stone. They need to be updated.
Scoop.it!
From
canny
Successful remote product management can be a challenge. So, having a solid roadmap is essential for product managers. Here's why, and how to approach it.
Scoop.it!
Key Takeaways
Scoop.it!
Stories about how we used Real Options, Set-Based Design, the Creative Process to make surprisingly good decisions in bad circumstances
Scoop.it!
Ce second article est une traduction d’un article original de Robbin Schuurman: Tips for Agile product roadmaps & product roadmap examples. Robbin est à la fois Professional Scrum Trainer chez Scrum.org, steward du programme PSPO-A et auteur de l’ouvrage : 50 nuances de non: Gestion efficace des parties prenantes à destination des Product Owners. Vous retrouverez une interview de Robbin Schuurman en fin d’article. Bonne lecture :)
Scoop.it!
The presentataion that Yves & Geike (11y) Hanoulle delivered at the business day in agile India 2019
Scoop.it!
Use this fast-paced collaborative technique to agree on what to prioritize, what can drop off, and which tasks are inter-dependent.
Scoop.it!
Read Article at https://www.linkedin.com/pulse/ltp4scrum-goal-tree-based-scrum-planning-moving-release-max-börebäck/ Are you an Agile Product Owner, or a scrum…
Scoop.it!
Scoop.it!
In this tutorial we'll show you how to dominate the road mapping process by using Confluence's roadmap planner macro. You won't want to miss this one!
|
Scoop.it!
When creating your roadmap, you need to consider what's important to the company (not just to the product) and what is the best way to make progress across these multiple needs. Navigating all of it could be challenging, so here is a simple tool that will help you find your way.
Scoop.it!
Last year I saw the term ‘Kanban roadmap’ emerge subtly in some product circles. At first I thought it was a bit of a faux pas, perhaps something that would die off naturally as some things do.
Scoop.it!
Roadmap is a pretty controversial word in tech jargon. Basically everyone agrees that we should have one — but no one agrees on what it actually is. Executives usually want the roadmap to predict the…
Mickael Ruau's insight:
Roadmaps vs OKRsTraditionally, the roadmap was a prioritized list of features with due dates and deadlines that were to be built by the technical team. It was a solution-based approach to define the tasks needed to be done. Now while the concept of a roadmap has changed a lot by the lean movement, it is still solution-based: any document labeled “roadmap” is one filled with solutions and maybe some fuzzy deadlines. OKRs on the other hand, are a problem-based approach to define the tasks that should be done. When we talk about Objectives and Key Results, we want to define which problems are best to work on, somewhat independent of what the best solution is. One can easily see that the best way to reconcile the two is to put OKRs first, dig up solutions that address both customer needs and business requirements and then put them in a document labeled the roadmap. There are quite a few models around that aspire to do just that. One of the best I’ve tried is the Opportunity Solution Tree (OST). Teresa Torres’s Opportunity Solution TreeDescribed in the fantastic read Continuous Discovery Habits, the Opportunity Solution Tree is a structured approach to build the right thing in a right way
Scoop.it!
Une tentative de réponse à ce casse-tête de product manager ! Construire une roadmap, bien prioriser les projets et bien la communiquer.
Scoop.it!
Product roadmaps provide a way to understand where a product is headed, but the information provided on most of them doesn’t help to clear the clouds of confusion about whether the product is heading in the right direction
Scoop.it!
TechAway n°9 - 31/03/2020
Scoop.it!
Mickael Ruau's insight:
Throughput and Monte Carlo – The forecast at the Release and Product levelAs we go higher in the layers of the onion, we move the conversation from one PBI to multiple PBIs. At the Release and Product layers of the onion, the Product Owner is now talking in terms of multiple PBIs. For example, a Product Owner might have 54 PBIs left to launch a release. Or she might have a deadline to reach and wonders how many PBIs can be completed on that date. In both situations, forecasting the future can help her narrow her decsion-making process. And as we’ve seen above, forecasting the future requires a calculated value with a probability. My experience has been that Monte Carlo simulations, using throughput as its input, can generate a forecast for those layers of the onion. Basically, the Monte Carlo simulations will use your historical throughput and simulate the future a large number of times (i.e. 10,000 times). Let’s take the example above and see how the results of the Monte Carlo simulations can help the Product Owner. I had previously mentioned above the Product Owner has 54 remaining PBIs to complete her release. Running the Monte Carlo simulations with her historical throughput, she gets the following results: Her first forecast, 25 days with 90% confidence, says there’s a 90% chance her team can deliver the remaining 54 PBIs of the release in the next 25 days. At the far right, there’s a 30 % chance they will deliver them in 16 days. She can now turn back to the business to discuss if 25 days is an acceptable number. If they prefer to have it in 14 days, she can reply the outlook for this scenario has less than 30 % of happening. For a more detailed read on Monte Carlo simulations and a tool to help you do them quickly, I recommend the post Create Faster and More Accurate Forecasts using Probabilities from my fellow PST Julia Webster.
Scoop.it!
From
medium
The customer is central to the agile team and celebrated in the Agile Manifesto. But how present and leading is the customer in agile day-to-day work? Agile Customer Thinking wants to help agile…
Scoop.it!
A Goal Tree, sometimes still referred to as Intermediate Objective Map or IO Map, is primarily a tool for rational analysis of all prerequisites i.e. Necessary Conditions to achieve a Goal, and their dependencies. The Goal Tree is a central tool of the Logical Thinking Process, and an addition to the original logic tools called…
Mickael Ruau's insight:
Further explanations about building a Goal Tree can be found in William Dettmer’s publications. Once built, the Goal Tree has a triple function:
Let’s explore the above points 2 and 3 somewhat more in detail.
Scoop.it!
As more organizations have started moving from project-based to product-based delivery, an understanding about product roadmap as an approach to manage the strategic direction is evoving.
Scoop.it!
From
getnave
Project managers are constantly balancing short-term responsiveness and long-term strategic planning. Too much and too little planning can cause problems. To give your workflows direction, you have to build a flexible Kanban roadmap!
|
