by Business Analysis (BAPL)

It was close to 4pm and George was staring at his third PowerPoint slide for more than an hour, adding and deleting content several times. He felt as if he had no more power left to make a point. George had been leading a lean product team working on a contract management system implementation in an Agile environment.

Jane, an experienced business analyst noticed a worried George and stopped by for a chat.

Jane: George, you look worked up, something the matter?

George: My stakeholders just don’t seem to get it. I’ve had several sessions with the leadership team and with the ground staff too, however, they never seem to align with the work we have done and the work we have in our pipeline. Despite several presentations, they seem unsure of our product’s vision.

Jane: Aah, a much familiar ground, it’s always a daunting task to bring stakeholders on the same page. Have you tried building a Product Roadmap?

George: Product roadmap! What is that, another management gimmick?

Jane: I understand your frustration George, but this thing works.

George: Well what is it? Can you enlighten me?

Jane: A product roadmap is a summary that plots the vision and direction of your product offering…umm contract management stuff in your context, over the implementation period. It can be a visual summary, a strategic document or a plan and can be tailored to your audience.

George: Tailored to my audience, what do you mean?

Jane: I mean, for the leadership team, your product roadmap can talk about the product’s vision and how it aligns with the organization’s strategic goals. However, for the ground staff, you can dive into details by focusing on specific product features and add further details. You work in an Agile project management environment, don’t you? So, you can consider including themes, epics, stories and features into your product roadmap.

George: So, the product roadmap will cover features, requirements or initiatives and will outline a path to deliver them over a period thereby describing the anticipated product growth?

Jane: That’s correct! Let me show you how it will look at a very high-level so that you get the gist of what I’m talking about.

Jane quickly scribbled a rudimentary sketch of the product roadmap on her tablet.

Jane: Look at this picture. You can spread the planned development of your product across the timeline. This way, your stakeholders will have a single view of what is being delivered when.

George:…and I will be able to communicate the direction and progress towards the vision for my product, both to the leadership and to the ground staff and thereby establish a shared view and understanding?

Jane: Correct again, you are a fast learner!

George: That sounds interesting, but tell me, how does it fit into an Agile working environment where we have continuous moving pieces

Jane: Good question. Its common knowledge that Agile environment values working solutions. A product roadmap focuses on product/feature/value delivered as against focusing on a milestone or checkpoint. Product roadmap enables iterative delivery by showcasing features that are being delivered currently and those that will be delivered next and at later period.

George appeared a bit confused.

George: Hang-on, this sounds like a product backlog, are we confusing the two?

Jane: An Agile expert you are, but there are key differences between a product backlog and a product roadmap. Typically, a product backlog is a translation of how your team will deliver the vision outlined on an Agile product roadmap. The backlog defines product features for near term, but a product roadmap provides a strategic view of where the product is headed over the mid to long term period. It is tied to the organization’s vision and strategic goals often for the next 12 or more months.

George: I am itching to get started! Any input on how should I structure the product roadmap?

Jane paused a while to think:

Jane: A funnel approach is what comes to my mind.

George: A funnel approach? Boy you’ve got some cool analogies but help me understand more.

Jane: The product roadmap should first tell your product’s story at the highest possible level, consider starting with themes and epics and then work its way down into the smaller, more detailed aspects of that story such as requirements, features or user stories.

Jane quickly scribbled the hierarchy on her tablet.        

George: Themes, Epics, that’s right down my alley, but before I get started, are there any limitations to this that I should be aware of?

Jane: Unfortunately, yes. A product roadmap can prove ineffective if the organizational environment is such that it leads to frequently changing vision and desired outcomes. I have seen a few product owners misusing the roadmap as a milestone or a date-driven plan. You will need to be cautious on the level of detail you put into it as it can get very time-consuming to maintain if it is overly detailed or too many variations are made in an attempt to satisfy all stakeholder groups. The trick here would be to find the right balance of details that the stakeholder groups can relate to.

George: I will be mindful of these aspects Jane. I know it’s getting late, but are there any final inputs?

Jane: Well there are a few more things you should consider.

George: Always hungry for more, you have both of my ears Jane.

Jane: Ensure that you as a product owner take ownership of the product roadmap and have your team focusing on maintaining it. Make it a living document rather than a plan set in stone. Regularly discuss, prioritize, estimate, update and share the product roadmap. Ensure that the roadmap reflects the most current priorities and goals, is easily accessible to those who need it. Set expectations with your stakeholders that the roadmap is not a promise. And lastly, keep it simple.

George: You are a star Jane, thank you so very much.

Jane: You are most welcome George; a Business Analyst never shies away from helping where they can. I wish you all the very best!