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

Leading B2B product management in high-resistance environments

10 tips for writing good product handover documentation

Poll results: What tools are product managers using the most?

Leadership coaching: 5 reasons why you should do it

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Ideating in the problem-solving stage of the Product Operating Model

Artificial intelligence (AI)

How to build an AI product that doesn’t suck

<a href="https://plus.google.com/+SergeDoubinski/">Serge Doubinski</a> is a product manager who focuses on growth of consumer web and mobile applications. Previously at StubHub, Formspring and Tagged he blogs at <a href="http://iheartpm.com">I♥Product Management</a> and advises companies on all things product management - tactical as well as organizational.

Serge Doubinski

<img loading="lazy" decoding="async" class="alignright size-medium wp-image-4789" src="https://www.mindtheproduct.com/wp-content/uploads/2014/03/5570724322_8872a99cb8_o1-225x300.jpg" alt="Empty Product Backlog" width="225" height="300" srcset="https://www.mindtheproduct.com/wp-content/uploads/2014/03/5570724322_8872a99cb8_o1-225x300.jpg 225w, https://www.mindtheproduct.com/wp-content/uploads/2014/03/5570724322_8872a99cb8_o1-768x1024.jpg 768w" sizes="(max-width: 225px) 100vw, 225px" />You&#8217;ve got sprint planning coming up and, looking at your backlog, you see that there is nothing ready for the team to work on.
I have talked to quite a few product people about this and no matter how experienced they were, all of them told me that this is a situation they&#8217;ve encountered at one point or another. I remember the first time this happened to me I kind of freaked out, blamed myself, and scrambled to put some specs together so we could go back to smooth sailing.
Until the same thing happened a few months later.
Crap. Now what?
As with everything else that goes wrong, a postmortem is a good idea so that you can pause and explore the possible causes of this situation. Luckily in this case there aren&#8217;t that many:
<ul>
<li>Your backlog is actually too light</li>
<li>Too many blockers</li>
<li>Changes in company priorities</li>
</ul>
So let&#8217;s look at them in more detail so that you can better identify next steps.
<h3>Your backlog is too light</h3>
It&#8217;s always good to check right away if the problem is you. There&#8217;s nothing wrong with being honest with yourself about getting caught off guard and simply not creating enough user stories for the team to work on. Sick time, vacations, busy work, procrastination &#8211; the reasons for this could be many, but I would argue that, while unpleasant to admit to, this is by far the easiest cause to deal with.
What can you do about this?
<ol>
<li>Remind yourself that just like gas in the car, your ideas are what keeps the product going forward. Make sure you have enough in the tank. It&#8217;s always good to have a list of a bunch of small projects that you can quickly flesh out. Improvements on existing functionality are great for these, but make sure you&#8217;re not creating busy work for the team.</li>
<li>Empower other product people or your tech leads to assist with user story creation and have them jump in when needed. Think of it as a backup generator. It will require you to still admit to yourself that you need some assistance, but it could also be an opportunity to showcase your trust and collaborative attitude by positioning it something along the lines of &#8220;I think in this sprint it would be great for you to drive some of the projects while I solidify a few of mine.&#8221; Now that&#8217;s teamwork!</li>
</ol>
&nbsp;
<h3>Too many blockers</h3>
This can be a tough one. You thought another engineering team was going to take care of a project and eliminate a dependency but they hit on some tech debt and scope doubled. Or maybe the design team was going to deliver final mocks but they&#8217;re running a few days behind. The partnership that was already signed still got stuck in legal and you didn&#8217;t get that API access you needed.
You know how in the examples above it&#8217;s all due to delays from other folks? Well, I hate to say it, but this is still on you. Sure, they didn&#8217;t finish their work or make things available for you to pick up and run with, but why are you finding out about this just now? Were potential delays accounted for? Let&#8217;s make sure we do everything to prevent this from happening.
What can you do about this?
<ol>
<li>Communicate with other teams more if your progress depends on theirs. If you have a project which is directly tied to the work the other team is doing, you have to become the honorary member of that team. Attend their standups, check their board and movement of stickies, talk to leads and constantly monitor progress.</li>
<li>Pad their estimates. You have planned a bunch of sprints with your team and you really trust their estimates. Can you say the same about another team? You are getting this information second-hand likely from their lead or your product counterpart. Has that person been delivering 100% of their sprints? They can be awesome at what they do, but remember that they will be overly optimistic about delivery timelines if they know you&#8217;re waiting for them. 
Think about this &#8211; when you&#8217;re running late to a meeting will you say that you&#8217;ll be there in under the estimated time or over? &#8220;I&#8217;ll be there in 5!&#8221; Yea, right.</li>
<li>Repeating blockers are likely bottlenecks. If you keep running into the same issues that delay you, there is probably a need to pay down some tech debt or grow the team if they can&#8217;t handle the volume of work you&#8217;re requesting. This is another tough call, but you&#8217;ve gotta rip that band-aid off ASAP.</li>
</ol>
<h3>Change in company priorities</h3>
This one can be a sledge hammer. You had your nice and pretty backlog all groomed with prepared specs, and then you get a note from up above that says &#8220;Next quarter we&#8217;re doing this other thing.&#8221; Ouch. I guess they really took that <a title="Beware The Dogma Of Agile And Lean" href="https://www.mindtheproduct.com/beware-the-dogma-of-agile-and-lean/">agile thing</a> to heart.
There could be a few things going on here, one of which is really, really good and the other really, really bad: 
A) You company leaders understand that every business is constantly evolving and has to stay ahead of the curve by adjusting strategy. 
B) The people making decisions are being too reactionary and are not focused enough on the long term company goals.
The scary part about this is that the solution to these is the same:
What can you do about this? 
Talk to your leaders. You need to understand why things are being switched up and what&#8217;s driving the decisions of people who are setting the course for the product. Best case, there is a well thought-out decision about where the company should be moving, and there needs to be some work done on better communicating that to the product team, giving them time to prepare in advance.
If the worse scenario is in play, the conversation has to be about ensuring that the right calls are being made, and that the product team has enough influence on the decision making process so that it aligns with the product vision. How to deal with this can be a post of its own.
<h3>One more thing you can do</h3>
Work with your technical lead to create a robust engineering backlog. It will usually consist of bugs and projects around paying down tech debt. What you should do is make sure that your upcoming projects are well understood by your technical counterpart and that this engineering backlog is optimized in a way that will support what&#8217;s up ahead.
If these are bugs that are getting fixed, make sure they&#8217;re closely tied to pages/features you&#8217;re about to update and improve. Don&#8217;t work on fixing things you might be drastically changing depending on the outcome of a planned A/B test.
Paying down debt? Make sure these are areas that you&#8217;re planning on building on top of and you can really use code getting cleaned up for faster development or better performance. Don&#8217;t spend time refactoring portions of your product you&#8217;re not planning on touching for more than a couple quarters. Unless it&#8217;s a part of your long term vision, it&#8217;s usually a sunk cost rarely recovered as product continues evolving.
&#8230;
As you can see, the availability of things for the team to work on is very much in your hands. Always remember that it&#8217;s perfectly fine to find yourself in this situation, but also make sure that you understand the cause, which in turn will allow you to learn more about yourself, your company, or your process.
It&#8217;s almost certain that quite often you will hear your team say that they don&#8217;t know what to work on next, so make sure to always have something in your back pocket, ready to go at a moment&#8217;s notice. This shouldn&#8217;t be too hard given that as product managers we always want to build more than the resources allow for, and if you follow some of the suggestions provided here, your backlog should become a full and healthy reflection of your preparedness and vision for the team to execute on.
Have you ever found yourself with an empty backlog? What caused it?

When the Product Backlog Runs Out

Serge Doubinski

Read more

Comments