The Product Roadmap shows the direction of the product and how the product is intended to grow. It demonstrates alignment to needs and a plan to deliver over time. The Product Roadmap is built around the vision for a solution, it outlines how the vision will be achieved and is defines how to measure progress.
Elements of the Product Roadmap include:
The Defined Vision and Strategy – as an input
Another input are the Desired Outcomes
Maintenance of the roadmap is performed by the Product Management Team, which ensures it is current and remains aligned properly
The roadmap will focus on a collection of requirements or themes, or features.
And it deals on a high level of things expected to be valuable to the solution.
Above is a simplified example of a Product Roadmap. It shows parallel development of some capabilities, some that are spread across multiple quarters, and some that may be delayed due to a dependency. This example shows that all capabilities are projected to be completed by Q4.
Dealing so closely with vision, it’s no surprise Product Roadmap is used for the Strategy Horizon. It identifies each feature and positions them in columns related to projected timeframes. This makes it a good tool for projecting resource requirements. The context is Product Management or Refinement and the Audience is the internal Team.
Product Roadmaps provide a shared focus on what is needed and overall direction, including MVP discussions. It can be utilized for discussions on priorities or other options. Variations can be provided for a target audience.
However, if the vision is chaotic, this tool loses effectiveness. Also, there is a potential to view this as milestones instead of overall directional goals.
And if it’s too detailed, it can be hard to maintain, so keep things at a high level.
Portfolio Kanban identifies the status of each initiative, this can be a simple communication tool to give visibility across all initiatives, as well as to monitor and adjust resource allocations. It is used to give visibility to the Process, Work In Progress, which helps in decision making and feedback on the strategy level.
The Portfolio Kanban will have columns for each step in the organization’s process from idea to completion. Each column has defined criteria for when the item can progress and has limits for entering the column or the work in progress.
The important thing is that each initiative is represented.
Additionally, there are regular meetings to discuss the Portfolio Kanban board and affected prioritization. Metrics are updated to help with prioritization. It is displayed in a place where everyone can see it.
This is a vital tool for the strategy level because it allows decision-makers to have a visual understanding of all initiatives in the organization. The information displayed can illuminate any bottlenecks and allow for decisions to re-allocate resources. Also, utilizing Kanban principles, the organization may determine it is beneficial to place constraints or limits in certain cases, which actually increases speed.
The context is Communication and the audience is the Internal Team.
Some of the strengths of Portfolio Kanban are that you can set up varieties of this at the Initiative and Delivery horizons., and it allows Portfolio Management to be optimized. It increases feedback and visibility into what is in progress and where the bottlenecks are.
Some limitations are that it is a bit one size fits all at the strategy level – so if there are different paths for some initiatives, this would not work well for them.
And it doesn’t explain why an initiative is in one place or phase for an extended period, just shows that it is.
Because of the title, many people are confused about Minimal Viable Product.
This isn’t the same as just getting by. For example, if a new internal project is underway, the organization was already “getting by” previously. But the new MVP project provides essential coverage to meet a need without expensive “gold plating.” If funding ran out and MVP was achieved, you would have a working product in the market or for your internal client and would be doing much better than before. Additional features may be developed beyond MVP, but those are done after the product is viable. So, just because MVP is achieved does not mean the project will stop, just that it could and still be usable.
That is an important threshold to cross in product development.
MVP is an important technique for Avoiding Waste. When a potential capability or feature is added to the solution, one of the first things we should ask is whether this is necessary for a product to be viable.
And by viable, that means that it meets the minimum requirements for the early adopters of the solution.
Again, it isn’t that non MVP features will never get done. Just that the MVP features will come first. In other words, it avoids waste by giving priority to what is necessary.
In defining the MVP, it is important to address the following.
First, identify who needs or wants this solution. Then from that group, identify the early adopters.
Next, identify what needs to happen for the goal to be met and how you can verify that has been met.
Thirdly, as the solution goes along, actually measure the results to verify the intended need is being met by the minimum solution.
Finally, Define the requirements for each feature of the MVP solution.
One interesting thing about MVP is how this focuses on early adopters. If you do not satisfy them, you do not have a product.
Another aspect is this is not a static state – MVP can change over time. As new features are identified, it becomes important to understand whether these are to become part of the MVP or whether they should be delayed for later – risking their exclusion from the product if there is not enough value.
That determination is how waste is avoided with this technique.
The context is Product Management or Refinement and the Audience is both Internal Teams and External Stakeholders.
Strengths and Limitations
Some of the things to be aware of for MVP Using are how it can be used to avoid unneeded or unwanted robust features.
Also, it’s important to realize the amount of research required to identify what is important for early adopters, and that sometimes features may be a best guess. And if the solution is simple, going through all this might be overkill.
If you’ve not seen my announcement on LinkedIn, I have been very busy developing a course called Preparing for the Agile Analysis Certification Exam. It has been published on the Udemy platform, so it is available to everyone. This is a self-paced version of the course I have taught to Business Analysts across the US in association with the Bluegrass chapter of IIBA.
This covers the entirety of the Agile Extension to the BABOK Guide with over 3-1/2 hours of videos and several quizzes. The quizzes are intended to help foster the “Agile Mindset” and help you grow in understanding of the concepts presented in the Agile Extension.
If you are interested in learning more about Agile, becoming certified as an Agile Analyst, are curious about whether there is a career path for Agile Analysts, or just need some ideas on how to improve your projects – this is a great course to cover everything.
Visioning is used to determine the desired outcome for an initiative worded in a concise and approachable manner.
Agile Extension to the BABOK® Guide – section 7.24
When Patriots coach Bill Belichek meets with his team to begin practices, I would imagine that the first thing he says is something like “Our goal for this season is to win the Super Bowl.”
Everything else the team does is derived from that goal. The team may not fully know how they are going to do that. And certainly the other teams want to prevent them. But everyone on the team knows that when Coach says “We’re going to win the Super Bowl” he knows they can succeed. And they understand what winning means.
Elements of Visioning
But there’s more to Visioning than simple inspiration. Yes, it is a set of beliefs. But it also is a SHARED set of beliefs. Everyone gets there or no one does. That is called a Vision Statement
This shared set of beliefs comes out of facilitated vision exercises – or Vision Exercises. Finally it is expressed in detailed objectives to measure the goals – known as Impact Metrics. These metrics show that the plan is working, but are not necessarily cause and effect related.
Back to Football, Coach may set goals for player’s strength, speed and skill. Will those cause them to win? No. Will they help? Yes. That’s the difference between correlation and causation.
Visioning begins in the Strategy Horizon, where the organization determines which initiatives align to organizational goals. The vision for an initiative is set just before the beginning of the project and lasts through it’s duration.
The Vision Statement helps orient all those involved in the project toward the overall goal both of the initiative and the organization. It identifies how the resulting product will leave an identifiable mark on the products or services provided or on the organization as a whole.
One additional consideration is that Visioning may be associated with multiple related initiatives.
Finally the context is communication, and the audience is internal teams and external stakeholders.
In Agile, many techniques can be used to improve different aspects of the processes. Many of them may on the surface appear to be similar in purpose. But when you look closer, there may be a distinction that favors one over another for specific situations.
So, how do we determine which technique is appropriate to address the specific issues we are seeing?
When deciding which technique to use, the three factors I look at are the Horizon, the Audience, and the Context.
In other articles, I’ve talked about the Three Horizons – Strategy, Initiative, and Delivery. Understanding which Horizon we are dealing with impacts which set of techniques is available.
Some of the usefulness of some techniques spans across all Horizons. Others may be in two or only one. Appropriate understanding requires understanding the purpose of each Horizon, remembering that a Horizon is not so much a time frame as it is a level of decision making. Decisions can impact an initiative from any of the Horizons.
For example, if a project is actively being developed, the Strategy Horizon can realize there needs to be a change in direction. Just because we are actively delivering the product does not mean Strategy has ended. In Agile, all three Horizons can be active simultaneously.
And that feedback can go both up and down through the Horizons. So understanding which techniques are appropriate to each decision-making level – to each Horizon – is essential.
Below are 4 charts which identify the various techniques as well as which source they are discussed – the Agile Extension or the BABOK Guide
Next is the Audience. Answering the question of “Who,” the Audience can be condensed into two broad groups:
Part of the team
External to the team
So, Who is the Team?
In Agile, the team is considered to be those involved in identifying and delivering a solution to a problem. The team may be further broken down to those working at a specific Horizon – for example, those working with organizational strategy are part of the team, but they are not delivering the product. One would be the Strategy Team, the other the Delivery Team. But for our purposes, that distinction is covered when you consider the Horizon in choosing a technique.
Those that are external to the team is everyone else. External to the team can include individuals such as Customers, Subject Matter Experts, Vendors, Regulators. These would be anyone who is both interested in the success of an initiative, but not involved in bringing the project to life. And they may or may not be part of the organization.
Now we are getting to the heart of the matter – why do we need this technique. Context is another way of asking, “What is the purpose?” or “What do I hope to achieve?” It is the “Why” of the decision process.
There are five categories of Context.
Product Management or Refinement
Understanding Your Customer
So let’s look at each of these.
Techniques that fall into the Communication context when, not surprisingly, the point is to communicate information. The receiver of the communication is determined by the Audience, which I mentioned above.
Some examples of Communication techniques would be things like Planning Workshops, Portfolio Kanban, Visioning, Retrospectives, Backlog Refinement, and Reviews.
Process Analysis involves looking for ways to improve processes. This may be processes involving the team, or in the solution itself.
For example, a Process Analysis may find gaps in the solution.
Another example, Process Analysis may reveal that the team is getting bogged down at a certain point in delivery. Perhaps the team needs to adjust to prevent that from continuing.
Some examples of techniques useful for Process Analysis include Value Stream Mapping and Impact Mapping.
Product Management or Refinement
Here we are concerned with delivery schedules or other items associated with defining the product. These answer questions like:
What is necessary?
When do we make a decision?
How does this align with our objectives?
When will features be delivered?
Examples include Minimal Viable Product, Product Roadmap, Purpose Alignment Model, Real Options, and Kano Analysis.
For Requirements Management, the concern isn’t the requirements themselves so much as how they are collected, sequenced, reviewed, prioritized, or refined. For analysts involved in Agile, this can be a large portion of the work.
Several examples of this context include Relative Estimation, User Stories, Job Stories, Spikes, Story Elaboration, Story Decomposition, Story Mapping, and Behavior Driven Development.
Understanding Your Customer
The context of Understanding Your Customer involves techniques in which details about the usage or motivations can be conveyed to the team. Many times, understanding the motivations can have an impact on the final design.
Some examples include Personas, Storyboarding and Value Modelling.