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):
Hi,
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?
Yours,
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!