Product Owners


I think the Product Owner is uniquely challenged in Scrum. You are both externally focussed on the market/customers and internally focussed on keeping the team moving in the right direction. As a Product Owner, it was my responsibility to

  • know the market,
  • demo the product to prospective customers,
  • work directly with UI/UX personnel to improve the customer’s possible interactions, and
  • come up with competitive pricing.

I was also responsible to the team for

  • providing a vision
  • managing the backlog and
  • guiding each release of the product.

This Agile Life added an interesting task to the Product Owner’s list of things to do.

  • Work with the team in identifying what will be reviewed with stakeholders at the Sprint Review.

So what is the difference between a Product Owner and a Product Manager?

According to Mike Cohn of Mountain Goat Software

The Scrum product owner is typically a project’s key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.

The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed.  1

According to Roman Pichler, a product owner is more than just a re-branded product manager: Product owners tend to take on a wider range of duties, which makes the role multi-faceted and challenging. 2

In my experience, I have worked with Product Managers who were mostly outwardly focussed. They might provide direction to the team at a high level and usually at the beginning of a project but they were not interacting with the team on anything more than an occasional basis once a release was begun. I have also seen Product Owners who were mostly internally focussed on managing the teams’ backlogs. In fact, on a product that has multiple teams, managing the backlog and handling team questions for 2+ teams can consume in large amount of your day.

So which is it? Outward or Inward?

Is one more important than the other? Well like most of life, it depends. In an organization with a fractured upper management, having an outward focus is huge. The Product Owner must frame the discussion and guide the organization (and its politics) to a successful conclusion. Navigating upper management’s conflicting interests is essential to the success of especially a new product. On the other hand, a novice or weak team will need the focus.


A very common question you get is what do a PMO and Project Managers do in a agile world. The development team is self-managing, the Product Owning owns the backlog and each team should include both dev and QA. So we are done right? Time to update the résumé…

My retort is that there is a lot that a PMO can bring even when Development is humming along in a perfect agile process. Here is a short but high value list to start the conversation:

  • Strategy
  • Reporting
  • Release Manager


One of the primary tenets of Agile is that the team should be working on the highest possible work at the present and the Product Owner should be sorting the backlog accordingly. Even if your product owners/teams are functioning at the highest level, one of the challenges to most companies is that they are still siloed by product. So a team could be working on a medium or low priority set of stories in one product when they could be working on another product with much higher priorities for the company. The idea is that you align at the portfolio level rather than the product level. The PMO’s job is to answer this question

What is the best use of our time to the company?

Once we have that answered and assuming the teams are aligned on sprint length and start/stop dates, Product Owners and teams can attack what brings the most value to the company right now. To the company, this brings additional value in that many developers are no longer being siloed into one product/technology and the company has many people cross-trained in multiple projects.


Another critical tenet of agile processes is the idea of information radiators. These should be essential for distributing information thoughout the stakeholder community and amongst the teams. Information radiators are also essential to the success of any agile implementation. Management is used to seeing metrics for project status and especially during the early stages of agile will be nervous that everything is going to go to hell in a handbasket. Information radiators provide that status comfort but I have yet to meet a scrum master/product owner who was not happy (ok one but see previous blog post) to get help with presenting metrics that were understandable. The PMO lives in the world of gathering, analyzing, and presenting metrics on project status!

The second big reporting area that the PMO can help with is risk. How is it measured, tracked, and reported. There are many different ways to present risk. My favorite is a 5 x 5 scale where 1–5 ranks severity and probability with 5 being high. Multiply the numbers together and anything over a 10 gets tracked and anything over 15 gets reported. I have found that Development can easily provide information on this scale and Management can easily understand the scale.

Release Manager

Great, the software is complete! The team should congratulate itself and probably schedule happy hour to celebrate. However while it is a significant accomplishment that the software is done, is the rest of the company ready to ship? One of the areas where most companies that adopt agile struggle is integrating the fast-paced cycles of agile with a company that has not fully adopted agile across the board. So is everyone else (Marketing, Sales, Documentation, Finance, Legal) ready to ship? Usually, the answer is no…

Here is a task that falls right into the wheelhouse of a PMO, release management. I have successfully used both MS Project and a newer, more agile product called Trello. Trello is very adept at this because unlike building an aircraft carrier, release management is less linear and more an aggregation of disparate single tasks. Trello allows everyone to filter on their tasks and statues and allows everyone constant visibility on the overall process. The PMO is more the shepard who guides the flock in the right direction.

Good references

I have done the reading so you don’t have to read the bad books. I would highly recommend these books on Agile Portfolio Management:

Picking Scrum Masters

What: Dogmatic Scrum Masters may doom your implementation

Symptoms: If you witness any of the following behaviors, you have a DSM

  • Displays limited flexibility. The DSM may be usually enthusiastic believers in scrum but they view the world through a black/white prism. The DSM may tie up scrum of scrums for hours fighting tooth and nail against the team “bastardizing” Scrum.
  • Does not hold their team accountable but fights when others do that they are “bastardizing” the team’s independence. I have witnessed a DSM who championed his team when he should have been trying to figure out why his team was repeatedly not completing stories for multiple sprints. When questioned, the DSM would vociferously defend his team from outside interference rather than try to get to the bottom of the problem.

Results: The DSM causes a triple whammy. One, they may poison their team by not holding them accountable. The team then thinks this is normal and begins to repeatedly miss commitments that they themselves had made. Second, other teams see this and it quickly spreads. Finally, upper management will also notice during sprint reviews that stories taken were not completed repeatedly. This will directly lead to upper management losing confidence in the agile implementation.

Actions: My recommendation would be to try to work with them for a sprint or two (no longer than a month to six weeks) and if you don’t see the changes that are necessary, change scrum masters. I cannot stress how corrosive this is.