Left and Right


Product Roadmap:  A Roadmap for Every Answer

Product roadmaps are a tool used to visually present a business strategy. Roadmaps serve multiple goals. The goals of roadmap development generally are varied, including not only the ultimate roadmap itself but also the journey to develop the roadmap.  Typical goals include:

  • Describing the vision and strategy visually.  According to Pearson Prentice Hall, 65% of people are visual learners.  A roadmap provides a powerful tool to connect with an audience.
  • Provide a guiding document for executing the strategy. A strategy is often visionary, the roadmap provides a path for action that moves past motivating words into tangible actions.
  • Get internal stakeholders in alignment. My four-year-old grandson’s favorite word is why.  Frankly, it is contagious.  A roadmap allows members of an organization to determine whether what they are working on fits into the big picture.  The roadmap helps to answer “why.”
  • Facilitating the discussion of options and scenario planning.  The journey to an initial roadmap and the process for maintaining the roadmap (a roadmap is not a destination) provides a process and an environment to discuss and evaluate how an organization is going to pursue its strategies to reach its goals.
  • Communication vehicle to external stakeholders, including customers. This is a classic use of roadmaps. Tuned for marketing, roadmaps are often invaluable for generating feedback as well locking in customers.

The myriad of goals that roadmaps can address implies that there are a number of different types of roadmaps.  Three different types of roadmaps are typical.

  1. Product/Business roadmaps are the classic version that provides the visualization of features and services required to deliver on a set of goal(s) and strategy.  The primary audiences for a product/business roadmap include executives (at a high level) and middle management (at a more granular level).
  2. Marketing roadmaps are typically an external communication vehicle predominately used for firms to communicate with customers outside the firm.  Note: I have seen teams serving internal customer bases develop marketing roadmaps.  The primary audiences for a marketing roadmap include sales, marketing, and customers.      
  3. IT roadmaps generally represent the planned evolution of one or more of the architectures stewarded by IT.  Architectures exist (whether documented or not) for information, systems, technology to name a few.  All of the IT architectures function within the business architecture and should enable the business’s strategy and goal.  IT roadmaps tend to follow the same audience pattern as product/business roadmaps with the exception that the level of detail sometimes is driven down to the sprint level (bad choice).  Remember that roadmaps are not plans!

The granularity of any roadmap is driven by what the tool is being used to communicate and, to some extent, hubris.  High-level product/business roadmaps tend to include high-level strategic initiatives the specifics of which fade the farther in the future the roadmap peers into the future.  Specificity in the future is a form of hubris.  Granularity can spin down into releases by period, specific features and in some cases maintenance and bug fixes (enter hubris again).

Roadmaps can serve many masters and answer many questions however there is not a one size fits all solution.

We will next tackle a suggested hierarchy of roadmaps in a typical corporate setting


A Roadmap Provides Direction

Product roadmaps are a tool used to visually present an approach to translating a business strategy into the real world. The visualization of the impact of a strategy on a product allows all relevant constituencies to grasp how a product and its enablers are intended to evolve.  

In order to create and use product roadmaps, there are several key concepts and components that need to be agreed upon.   (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music


SPaMCAST 447 features our interview with Angela Wick on the role of the Product Owner and Business Analyst in Agile efforts. These two roles are critically important for delivering value in an Agile environment. Angela provides a fresh take on the Product Owner role and the Product Owner’s relationship to other roles Agile teams.

Angela is the founder of BA-Squared, LLC, a training and consulting practice.  She is passionate about modernizing requirements practices and helping organizations collaborate on a Product Vision aligned to strategy and guiding them to a meaningful backlog and iterations that keep the customer and organizational value top of mind.

She trains, coaches and teaches organizations on Product Ownership and Agile BA!

Email: Angela@BA-Squared.Com

Web: http://www.ba-squared.com

LinkedIn: https://www.linkedin.com/in/angelawickcbap

Twitter: https://twitter.com/WickAng

This is not first time the SPaMCAST has featured essays and conversations on the role of product owners ( for example
SPaMCAST 430 and SPaMCAST 325).


Re-Read Saturday News

Chapter 9 continues the third section of Holacracy, Evolution Installed: Living Holacracy.   Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson was published by Henry Holt and Company in 2015.  This week’s chapter is titled If You’re Not Ready To Adopt: Moving Toward Holacracy.  In this chapter Robertson softens his if-you-can’t-do-it-all-don’t-do-anything approach.   (more…)

Book Cover



In approximately three weeks we will begin the next book is The Science of Successful Organizational Change. Remember to use the link to buy a copy in order to support the podcast and blog. The reread will be led by Steven Adams.   I am looking forward to sitting on the other side of the table during the next re-read!

Chapter 9 continues the third section of Holacracy, Evolution Installed: Living Holacracy.  This week’s chapter is titled If You’re Not Ready To Adopt: Moving Toward Holacracy.  In this chapter Robertson softens his if-you-can’t-do-it-all,-don’t-do-anything approach.   (more…)

Making decisions is exhausting. It involves perception and analysis, and most of all: taking responsibility.
Mental load and the worry cache, Seth Godin, June 15, 2017

In most organizations, software development and maintenance is not a solitary activity.  Even a relatively simple enhancement require the involvement of multiple roles to identify, translate and implement an idea.  Teams are the tool used to effectively gather and coordinate all the needed roles in one place. While it is easy to perceive the team as a monolithic unit, every individual on a team is a decision-making machine.  Each person will have a different tolerance for uncertainty and ambiguity which will affect how they make decisions. (more…)

Sign for Sheltering In Place

Sheltering Reduces Uncertainty

“Uncertainty and complexity produce anxiety we wish to escape”. – Al Pittampalli from How to Hold Meetings That Actually End With Decisions (Webinar June 8, 2017)

Much of the process of translating a user story or requirement into something that can be used is as much about managing and removing uncertainty as it is about technical transformation. Agile and legacy development (used in the broadest sense) are littered with techniques to help the team learn and to gather feedback. The techniques can be sorted into three categories: (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 446 will feature our essay on questions.  Questions are a coach and facilitator’s secret power! But, with great power comes great responsibility.  

Our second column is from Gene Hughson.  Gene and I discussed his essay Go-to People Considered Harmful originally published on his blog Form Follows Function (www.genehughson.wordpress.com).  The concept may sound counterintuitive, but it is not.

The third column is from Kim Pries, the Software Sensei.  In this installment, Kim dives into the topic of servant leadership.

Re-Read Saturday News (more…)