30: Reserve time for housekeeping

30: Reserve time for housekeeping

I’m writing about 100 things I’ve learned as a product manager.

Like doing the washing-up, vacuuming under the sofa or cleaning your windows, housekeeping tasks with your product can get neglected because they’re tedious, not as interesting as new features and so on.  However, if you’ve ever found yourself eating breakfast cereal out of an oven tray with a serving spoon because every single item of cutlery and crockery is festering in a pile in your sink, it should be apparent there is inherent value in tackling housekeeping tasks bit by bit over time.

The kind of housekeeping tasks we’re talking about are the less sexy aspects of product delivery, so it could be:

  • Sorting out that manky piece of code that the founder wrote years ago, but is too fundamental to touch
  • Documenting how a particularly black-belt bit of code actually works for non-Jedi masters
  • Putting in place a real content management system (CMS)
  • Automating that annoying manual process that has become so routine, we’ve forgotten how much time we’re wasting on it

It can also be difficult to justify from a business case perspective a housekeeping task over a bugfix or a feature request.  I received a question recently along the following lines (names have been withheld to protect the innocent):


I have a question I was hoping you could help with. I’m a product owner and I’m finding it a real challenge to rank and prioritise software enablers (new CMS etc.) over new product features.  Not only do internal stakeholders clash but there’s a lack of education to shareholders about what the enablers might offer us.  How could I go about quantifying these enablers? And how they could contribute towards growth?


A Product Owner

From companies I’ve worked with in the past (and I’ve not yet come across a company that doesn’t suffer from this problem to some extent), my view is that you need to ringfence a certain amount of time (10-20%) in each development cycle for housekeeping tasks, i.e. anything that isn’t a new feature or a bugfix.  You still need to size, prioritise and decompose (where necessary) tasks within that mini-backlog, but the difference is that bugs and features can’t kick out the housekeeping tasks.

In terms of managing the stakeholders, one approach is simply to allow people to expect that the team can deliver a certain amount of new features and bugfixes in a development cycle using only the available 80-90% of time, i.e. don’t draw attention to the fact that you’re reserving 10-20% for other useful stuff.  It could be argued that this is not very transparent and a little sly, however it is ultimately in the company’s best interests, even if they don’t realise it.

Alternatively, and slightly more ethically, be open that you’re ringfencing time and put the effort into a rough business case for the housekeeping tasks you need to do.  There is, after all, a cost associated with the work you’re doing.  Highlight short-term pain to avoid a much bigger long-term problem, operational cost savings, customer satisfaction improvements etc.  In other words, spell out the benefits of why you need to do it, but bring it back to measures that business stakeholders care about.  The risk here is that you’ll still get steamrollered by the the Highest Paid Person in the room and your housekeeping time becomes un-ringfenced again, regardless of the benefits.

A third option is to piggy-back housekeeping tasks on associated customer work as this will be easier to justify.  Mind you, if your customers are being directly affected by the absence of your housekeeping so far, you’re arguably already in the ‘no cutlery or crockery’ state.

Helpful?  Let me know in the comments.

Have a great Christmas!

Get articles when they’re published

My articles get published irregularly (erratically, some might say). Never miss an article again by getting them delivered direct to your inbox as soon as they go live.  

Read more from Jock

The Practitioner's Guide to Product Management book cover

The Practitioner's Guide To Product Management

by Jock Busuttil

“This is a great book for Product Managers or those considering a career in Product Management.”

— Lyndsay Denton

Jock Busuttil is a product management and leadership coach, product leader and author. He has spent over two decades working with technology companies to improve their product management practices, from startups to multinationals. In 2012 Jock founded Product People Limited, which provides product management consultancy, coaching and training. Its clients include BBC, University of Cambridge, Ometria, Prolific and the UK’s Ministry of Justice and Government Digital Service (GDS). Jock holds a master’s degree in Classics from the University of Cambridge. He is the author of the popular book The Practitioner’s Guide To Product Management, which was published in January 2015 by Grand Central Publishing in the US and Piatkus in the UK. He writes the blog I Manage Products and weekly product management newsletter PRODUCTHEAD. You can find him on Mastodon, X (formerly Twitter) and LinkedIn.

Leave a Reply

Your email address will not be published. Required fields are marked *