post

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! 🎉

How internal product teams drive growth at Wise

Everything wrong with the product management job market. And how to fix it

Diversity in tech, Imposter Syndrome, and Leadership: Meri Williams (CTO, Pleo)

What good product design looks like – Miguel Fernandez (VP of Product Design, Slack)

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Product Management

Sunday Rewind: Scaling from 60 to 1,000 people

Community

Highlights from September’s ProductTank meetups

Co-founder of <a href="http://www.prodpad.com">ProdPad</a> and Mind the Product who run ProductTank, ProductCamp London and Mind the Product conferences in London and San Francisco. Blogs about Product Management at MindTheProduct.com &amp; ProdPad.com. Simon began his career in Space Engineering, where he developed a Fortran realtime program to automate satellite operations. He then traveled around the world before a stint in the Australian Army.

Simon Cast

<a title="Manuscript Backlog 2010 by Minnesota Historical Society, on Flickr" href="http://www.flickr.com/photos/minnesotahistoricalsociety/5009173503/"><img loading="lazy" decoding="async" alt="Manuscript Backlog 2010" src="http://farm5.staticflickr.com/4148/5009173503_c1eca90604_n.jpg" width="320" height="241" align="right" /></a> An interesting philosophical discussion was triggered on <a title="A Skype Group Chat for Product Managers" href="http://mindtheproduct.com/a-skype-group-chat-for-product-managers/">MindTheProduct&#8217;s Product Managers Skype chat</a> when I questioned why someone had incomplete user stories in their development backlog. The majority of the answers can be boiled down to &#8220;because that is how it is done&#8221;.
However, I feel there is another way, which offers several advantages over doing the grooming in the development backlog.
Grooming and fleshing out feature requests should be done in their own &#8216;queue&#8217; &#8211; call it a backlog or my preferred term, &#8216;product pipeline&#8217;. Once the user stories are ready, they can then be transferred from the pipeline to the development backlog for prioritisation and management into the development cycle. <a title="Video: Marty Cagan on How to make products that people love" href="http://mindtheproduct.com/?p=2523">Marty Cagan</a> referrers to something similar as an <a title="opportunity backlog" href="http://www.svpg.com/the-opportunity-backlog/" target="_blank">opportunity backlog</a>.
<h1>Why move grooming out of the backlog process?</h1>
The product-management process is one of collaboration, not only between the product manager and the development team, but across the company and with the end users. It is important to incorporate these insights from various stakeholders when doing the grooming.
As development backlogs are controlled with a limited number of people having collaborative access, a majority of stakeholders are excluded from the process of grooming, only being shepherded in to &#8216;contribute&#8217; through meetings. As we&#8217;ve all surely learned, meetings are rarely great ways of getting input and feedback in an effective manner, leaving a lot of value from stakeholder collaboration unrealised. It&#8217;s better to change the process than bandage it with meetings.
While the development backlog could be opened up to the broader company, this will see it become full of feature requests and bug reports making it unwieldy, thereby losing its effectiveness as a prioritisation and development management tool.
By moving grooming out of the development backlog, you can open up the grooming process, gaining the advantage of the stakeholders&#8217; insights and discussion around the user stories without impacting the management and prioritisation for development cycles. All the feature requests and bugs added to the product pipeline (as will undoubtedly happen) are simply treated as very basic user stories that can be groomed over time.
One argument used to support grooming within the development backlog is the idea of technical efficiency or building related user stories together. Nice sounding logic, yes, but I question whether there is much gained from this approach. By following this logic what you are saying is user story y is related to user story x and, as we are definitely going to build x, let&#8217;s go ahead and flesh out y and build them together to save effort. There is no consideration of whether y is really needed, but it is getting built because it&#8217;s related to x and it may (or may not) be needed in the future.
By the time you come to use y it could easily be unfit for the purpose, given the learning and changes since it was originally built. That efficiency gain is lost as y needs to be rebuilt anyway to be effective.
It&#8217;s better to focus on building what you need right now and making sure you are building the right things and not whether they are technically related when grooming.
Grooming user stories outside of the development backlog and moving them across only at the point you are almost 100% sure you are going to build them helps focus everyone on working out what should and needs to be built. You avoid the temptation to fill out a development cycle simply to &#8216;fill it out&#8217;, freeing up precious development time for other tasks.
How many product owners have added stories to a development cycle because there was spare time? Probably all of us at one point or another. We&#8217;ve got to be seen to be busy, after all.
Grooming should be an ongoing task and not one that is boxed into a meeting. By making it ongoing, there is the luxury of time to drill down into what&#8217;s really needed or wanted, making the user stories laser focused. In effect it helps ensure you are only building what is needed.
Ongoing grooming helps to incorporate learning while it&#8217;s fresh in everyone&#8217;s minds. What you learn from releases, usability testing, experimentation, etc. will often affect more than one user story. If you only groom the stories in a meeting, as time goes by, what you learned is forgotten and starts to lose its potency.  In restricting grooming to meetings you aren&#8217;t taking advantage of the power of the learning. By doing ongoing grooming, anyone involved in the learning can update all the affected user stories while the learning is still strong in everyone&#8217;s minds. With ongoing grooming, the power of learning can be more fully realised.
<h1>Summary</h1>
Using a product pipeline doesn&#8217;t exclude the development team from the process of grooming but expands it to more effectively utilise the rest of the company, end users and learning. The development backlog then becomes more focused on delivery, raising the productivity of both the development team and the product managers.
By promoting effective collaboration during grooming, product pipeline helps reach the point where that big feature request from sales is whittled down to a focused user story that delivers everything it needs and is straightforward to deliver.
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

Moving the product pipeline out of the development backlog

Simon Cast

Read more

Comments