post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

How to build a companion product and win user trust

mission statement

Deep dive: Crafting your product vision and mission

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

Nigel is currently Head of Product at <a href="https://www.willistowerswatson.com/en-GB" rel="nofollow">Willis Towers Watson</a>. He has held senior product and technology roles at EY's innovation lab, a blockchain startup, Software AG and SunGard among others, but started his career as a developer in true startup style in the back of a garage.

Director, Product Management

Nigel Farmer

<p>Product management is still a young discipline, and the methods that we use are evolving all the time. Currently in the product community, topics such as product discovery, theme-based roadmaps and outcomes vs outputs are all very much in vogue, and rightly so. These are all helping to move our craft forward, and enabling teams to solve the right problems and create successful products.</p>
<p>Recently, there has also been lots of debate on the difference between Product Managers and Product Owners. Some argue that Product Owners are internal facing whilst Product Managers are external facing. Others, such as <span style="text-decoration: underline;"><a href="https://melissaperri.com/blog/2017/06/29/product-manager-vs-product-owner">Melissa Perri</a></span> say that Product Management is the job and Product Owner is the role played in a Scrum team.</p>
<p>A Product Manager should indeed play the role of Product Owner. But whilst going on a two-day course and getting CSPO or PSPO status might prepare you somewhat for the role of Product Owner, there’s a lot it doesn’t teach you. It doesn’t teach you how to define a product strategy, how to create product messaging, how to price, launch or retire a product, and much much more. <span style="text-decoration: underline;"><a href="https://svpg.com/product-manager-vs-product-owner-revisited/">Marty Cagan said much the same thing</a></span> back in 2016.</p>
<p><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2020/07/57a2a354-2077-42e9-b4e9-22d4ec89e078_ferenc-horvath-4gKHjKG7ty4-unsplash.jpg" alt="" /></p>
<p>There is, of course, a big difference between someone with no product experience doing a two-day course and getting certified, compared to someone with several years’ product management experience whose job title happens to be “Product Owner”. A lack of consistent use of product job titles doesn’t help but, as Martin Eriksson states, <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/product-management-job-titles-and-hierarchy/">the experienced Product Owner should really get their job title changed</a></span>.</p>
<p>However, there does seem to be a certain amount of disdain towards the Product Owner role and the certifications, perhaps because they don’t equip you to do all the things I mentioned above. Many see the certification as having no or little value, or only worth having on your CV to ensure you get through the keyword checks of a job application.</p>
<p>One of my most used quotes comes from <span style="text-decoration: underline;"><a href="https://en.wikipedia.org/wiki/Peter_Drucker">Peter Drucker</a></span>:</p>
<blockquote><p>Doing the right thing is more important than doing the thing right</p></blockquote>
<p>However, in the spirit of the agile manifesto, it&#8217;s not that we don’t <span style="font-style: italic;">value </span>doing things right, just that we value “doing the right things” more. But perhaps some teams don’t quite have the balance right, because over the years I have seen many teams that are not implementing agile methods very effectively. This impacts on teams ability to achieve those desired outcomes, and have the impact they’re hoping on KPI’s and OKR’s.</p>
<h2>Backlog Antipatterns</h2>
<p>Specifically, despite often elevating the product manager over the product owner, I see a lot of poor practise around backlog management&#8230; a key responsibility of the product owner role, which many product managers don’t seem to have quite mastered.</p>
<h3>Very Long backlogs</h3>
<p>A backlog that has too many items is difficult to manage, to prioritise, and for others to understand. It’s likely that there are many items that have been on the backlog for a long time. They might have been important once, but possibly not now. Regularly prune your backlog, and delete those long-standing items that never got the team’s attention. If they are truly important, they will come back.</p>
<h3>Adding Every Idea to the Backlog</h3>
<p>The backlog that your team is working from should not contain every idea that anyone ever has. Nor should you add every customer request; your response of “I&#8217;ll add it to the backlog” becomes a hollow promise that, in the long term, will affect your credibility. Your backlog should only contain the things you have a high confidence of addressing in the short-mid term. You need to track those other things, but be sure to separate strategy, ideas and feedback from execution.</p>
<h3>Strategic Alignment</h3>
<p>Regularly review your backlog to see how it aligns with your strategy. Is it delivering what’s on the roadmap? Ask yourself that question when new backlog items are created. Make sure the team understands where you are heading. This will encourage good and relevant ideas, and further encourage them to be proactive. Otherwise, if all their ideas go unimplemented or purged, the team will become demotivated and discouraged from contributing in the future. Discussions around strategy with customers are also a way you can say “No” to their requests with justification, whilst getting input and buy-in on your future direction.</p>
<h3>Teleporting Requirements</h3>
<p>When requirements magically appear at the top of the backlog from nowhere just before a planning session, it means the team is not prepared and you are not setting them up for success. Of course plans and priorities can change, but when every requirement always appears out of nowhere, this implies that there is no plan, no roadmap, no alignment and the team don’t understand the vision of what they are working towards.</p>
<h3>The Team don’t Look at the Backlog</h3>
<p>If the first time your team knows about any requirements is when they are discussed in a refinement or planning session, it’s not a good sign. It might mean that they are not as invested in the product as they should be, or are too busy shipping features to think about what’s next and what goals they are trying to achieve. A clear sign of this is if refinement sessions are being skipped because the team is too busy with the current iteration of work.</p>
<h3>The Product Owner “Owns” the Backlog</h3>
<p>Another sign to watch out for is the product owner (PO) being too protective of the backlog. The PO might own the prioritisation, but it’s the <span style="font-style: italic;">team’s</span> backlog and all should be encouraged to contribute &#8211; adding items, writing acceptance criteria etc. Just to give you an example, one sign of an overprotective PO can be when a team is complaining about a high level of technical debt, but it’s not on the backlog &#8211; they’re effectively not “allowed” to include important details in the backlog.</p>
<p>It’s also really important to involve the team in product discovery sessions, and get direct access to users. They will learn and contribute so much more, but this often doesn’t happen when teams are measured on capacity, velocity and shipping code &#8211; i.e. on output rather than outcomes.</p>
<h3>The Wrong Level of Detail</h3>
<p>If your requirements start as placeholders with no description/story and no acceptance criteria, and somehow make it up the backlog and into development in that state with little-to-no detail, then the team really should be pushing back. But if the team <span style="font-style: italic;">isn’t</span> pushing back, then the chances of success are limited.</p>
<p>Estimates (if you have them) are likely to be unreliable, your planning will be ineffective, and the team is less likely to deliver what is forecast. When this happens repeatedly, it’s demotivating, and is also likely to have a knock-on effect to other teams such as support, sales and marketing.</p>
<p>But you can also go the other extreme, with too much detail, defined too soon, and which becomes so prescriptive that there is little room for course-correction or creativity by the team. It can be good practice to have a  <span style="text-decoration: underline;"><a href="https://www.mountaingoatsoftware.com/blog/make-the-product-backlog-deep">DEEP</a></span> backlog, <span style="text-decoration: underline;"><a href="https://www.agilealliance.org/glossary/invest">INVEST</a></span> in user stories (or other form) and use the <span style="text-decoration: underline;"><a href="https://ronjeffries.com/xprog/articles/expcardconversationconfirmation">3 C’s</a></span> (card, conversation &amp; confirmation) approach.</p>
<h2>Final Thoughts</h2>
<p>Personally I found the CSPO course to be quite valuable when I took it some years ago. I already had a lot of experience, but it taught me about the Product Owner role at a time when my team was new to agile, and thus was extremely worthwhile. And although I had already read a lot of books from the likes of Mike Cohn, Roman Pichler and Kenneth Rubin, I learnt some new things which I was able to immediately apply back in the office &#8211; a true measure of the worth of any training course.</p>
<p>The courses might not benefit everyone, but assess how you are performing the Product Owner role and get some feedback from the team and your peers. If you think you have room for improvement, then give it some consideration, because not only may you benefit from it, but your team, your product and your customers may too.</p>

The Lost art of Backlog Management

Nigel Farmer

Read more

Comments