Why you should delete requests that are past what you consider “soon & forecastable”.
With 100s of requests for a product, what do you do with the ones that simply are not on your current horizon? Do you put them into the “in two quarters” column? Do you put them on the “idea pile”? Do you keep pushing them back quarter by quarter?
I suggest a different method, which is the honest & transparent one in my opinion, but not the ones people tend to like at first.
Delete them.
More precisely, delete everything that is beyond your product event horizon.
I think:
- Every product manager has a “product event horizon” for his product.
- It’s the point where things are more uncertain than certain.
- Deleting these things past it is more honest than keeping them on and has a lot of benefits for both sides.
I recently thought about a simple request I got. “When team X is done migrating this tool TZ, please also update your tool YZ”. That seemed reasonable.
But when I got to realize that this “migration” isn’t done for another YEAR I decided to delete the request.
My reasoning was simple, if this migration is done in a year, both my and the migrated tool will look way different than they do now. I honestly do not know, whether it will make business sense to update my tool OR whether it is even necessary.
enter my product event horizon.
The Event Horizon
A black hole is a great example of an event horizon.
“Often, this is described as the boundary within which the black hole’s escape velocity is greater than the speed of light.”
The product management event horizon is the boundary within which the uncertainty’s velocity is greater than your planning & forecasting speed. Or simply put, it’s the point in time, at which you have no idea what the product should be like.
Increasing Uncertainty Is The Essence Of Agile Environments
Things are uncertain. The product grows and develops. The team learns. The environment changes. The company changes. All of these are moving parts. And you simply cannot forecast them. Which is the reason we want to stay agile and react to inputs as fast as possible.
Of course, there are other environments where this is not true, those belong to the complicated or the simple domain, but there, we don’t need agile product management.
In SCRUM coaches suggest updating the roadmap depending on how uncertain your environment is.
The increasing uncertainty is usually also reflected in good agile roadmaps & product backlogs which contain:
- Lots of details and lots of small items for “now and soon”.
- Fewer details and fewer items, but larger ones for “next up”.
- No details, only large blocks and only 1–2 of them for “later”.
Benefits Of Deletion
Items beyond your product event horizon are in the space, where this item is just as likely to be implemented as any other item period.
So by deleting:
- You acknowledge, that it will most likely not get done.
- You give whoever asks the chance to find a workaround or find more substance for the problem, add material, add a “larger block”.
- You declutter your roadmap.
- You give insights into your prioritization process.
- You sharpen your products’ focus.
I personally also much rather would like to hear that my requests will not get done, so I can get on and find a workaround.
I hope you enjoyed this short piece.