Product roadmaps come in many sizes and flavors and depending on size and flavor answer a myriad of questions.  There are several common threads through all product roadmaps.  The common threads are:

  1.      Roadmaps are tied to the business strategy.
  2.      Roadmaps answer where are we going.
  3.      Roadmaps answer why we are making the choices we are making.
  4.      Roadmaps are tied to objectives and key results (business outcomes).


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




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…)

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

This week’s Software Process and Measurement Cast features our essay revisiting the product owner role. The product owner role is hard, often messed up and a great opportunity for improvement.

The second column features the return of Steve Tendon talking about Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 17 which is titled Challenges of Work-State Work in Process Limits. WIP limits have their plusses and minuses when discussing hyper-productivity.  

Our third column this week is from Jeremy Berriault. Jeremy discusses how to show the value of QA and why knowing and showing value is important!   Jeremy  blogs at  


Re-Read Saturday News

This week we tackle Chapter 6 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.   Chapter 6, Facilitating Governance, puts the ideas and processes defined in governance to work. (more…)


The product owner (PO) role is incredibly important in any Agile effort. The product owner leads, manages and prioritizes the backlog and networks with stakeholders, customers, and developers of all stripes.  All sorts of problems can beset the role. However, most of those problems are either self-inflicted or a result of poor organizational design.  A laundry list of problems based on observation and responses from other product owners include:

  1. Product Owners Are From IT
  2. Product Owners Are Not Part of The Team
  3. Having a Project versus Product Orientation
  4. Overly Broad and/or Ill-Defined Product Owner Role
  5. Using Proxy Product Owners
  6. Adopting Technical and Business Product Owners
  7. Allowing Part-time Product Owners
  8. Failure of Product Owner to Lead
  9. Product Owner with Controlling Personality

The next set of difficulties are: (more…)

Accept no substitute.

The product owner (PO) role even when performed as described straight out of the book is difficult.  The role is often even more difficult than it needs to be, with information asymmetries between the PO, the team and stakeholders ranging to ill-defined roles. I asked over fifty product owners about why they thought the role was hard to augment my perception. I have scattered excerpts from their responses throughout the essay.  Based on observation and responses the most common reasons the role is difficult are: (more…)

Doing the Product Owner Role Poorly is Like Drowning!

The product owner role is evolving in most organizations. The role has its roots in the roles of product managers, project managers, business subject matter experts (SME) and project sponsors from other methods.  The roles and the responsibilities of the role are critical in any Agile approach to delivering value. The product owner role is difficult, and perhaps consistently more difficult than any other role in software delivery.  The reasons the role is difficult can be traced to several solvable scenarios. The most common reasons are: (more…)

Super Sponsor

Super Sponsor

The product owner is the voice of the customer and performs a significant of a number of activities, including acting as a conduit/facilitator for communication between the team and the outside world.  Other activities include: defining and elaborating stories, prioritizing the backlog and accepting work when the team completes a story.  The product owner’s role is related or influenced by the sponsor’s roles (sometimes known as executive or project sponsor).  The sponsor is the person that has overall responsibility and accountability for a piece of work.  The sponsor champions the project based on whether the work fits the business’s needs and overall strategy, finds and secures the budget and has the overall responsibility for the work to deliver the promised value. This is true even though he or she will probably never write a line of code or test.  Sponsors empower the product owner to act for them on a more tactical basis.  A comparison of how the sponsor’s typical roles translate to the product owner is shown below: (more…)


As we have seen, product owners act as a conduit between the business and/or customers and the team. The product owner’s role encompasses not only the definition of what gets done and when, but also the level of quality of what gets delivered.  One of the facets of the role affecting quality comes when the product owner participates in writing the acceptance criteria for user stories.  Acceptance criteria are part of well-formed user stories and are crafted early in the life cycle when stories are generated and refined as they are groomed.  The product owner role provides another check on quality and occurs when the product owner uses his or her authority to accept completed stories.  I don’t want to suggest that the product owner is only active at the start and end of a sprint or iteration. The product owner interacts with the team on a continuous basis in order to guide the work and the culture. Adoption of acceptance test-driven development (ATDD) is an excellent method of instantiating the product owner’s role in both shaping the vision for the team and influencing the quality of the work a team delivers. (more…)


Product owners play a pivotal role in all Agile projects. This is true whether a product owner exists or not. Since the role is so critical it should be easy to define the role of product owner. However, most definitions tend to quickly devolve into a list of responsibilities that depend on implementation and scale.  One of the most critical and often most variable roles of the product owner is that of the interface between the team and the outside world.  The outside world includes users, customers, stakeholders, sponsors, and sometimes other product owners and teams. We can visualize the interface role on a continuum that on one end includes the product owner acting as a highly structured conduit for information from outside the team to a facilitator of conversations on the other end of the continuum.   (more…)