A colleague, exasperated, once told me: “I just feel like you’re blocking me from getting anything built!”
I stopped myself from replying that I was, in fact, employed to stop people from building things. Well, that wasn’t the job description, but it’s an incredibly important part of product management that is often overlooked.
We talk a lot about prioritisation within product – which feature or project is higher value, which is more effort. We adjust our roadmaps – whether they’re in our heads, digital on a screen or my preferred style of post-its on a wall – and communicate the change as features slip up or down a place in priority order. Priorities for product shift, as we know, in line with those of the business.
However something I don’t see people doing is saying what they’re not going to do. Most companies have a finite limit on their development resource, so there isn’t really a scenario in which they will complete all the projects on the roadmap. It’s almost a given that those below the top five will stay below the top five ‘til kingdom come.
I’ve found that the organisations I’ve worked with each have an ‘attention span’. People can conceptualise and plan for features coming up in, say, the next nine months, but after that point, they take it off their mental list. So I’ve sometimes opted to make that explicit – we’d have a bucket of things we were aiming to complete in the duration of the company’s attention span, subject to change, and – more importantly – a bucket of things we weren’t going to touch during that time.
People get quite nervous when you label a bucket “Not even looking at”. I’ve found it’s only possible in an environment where the team is fully aligned on one or two specific company objectives. A long list of OKRs in an organisation with smallish tech resource only encourages a scattergun approach where small, ineffectual changes are made at half effort to many things. Having a “Not doing” bucket reminds the organisation that, in order to put our welly behind the few important things, we need to say no to the others.
I have a similar approach to lengthy backlogs. Once your list of projects is over five or six, people stop remembering them. Clear and meaningful communications are much easier when the team can keep the projects in their head. Yet some backlogs contain hundreds of projects or features, of which maybe a third to a half will ever be looked at. My approach? Delete the second half. I think it’s entirely valid to prioritise projects simply by waiting and seeing whether they’re raised again. More than a few times this has moved a ‘must-do’ project to a never-heard-of-again one (and saved a whole lot of time and money in the process).
Building new things is, of course, no bad thing. But from our ‘fixing the plumbing’ perspective, it’s also not inherently a good one. New features or products come with bubbling potential and feel cleaner than tweaking existing ones. But each new thing also brings with it years of upkeep, the necessity to wire it into any tracking or reporting, and the overall increased complexity of the systems used by the organisation.
Once the software has reached a certain level of complexity, I prefer a one in, one out approach. For each new thing you want to build, you select another to sunset. This is true for the larger elements – swapping out a CRM, for example – and the smaller ones. Want to add an option to the dropdown? You’ll need to remove another. I’ve seen a lot of features retained “because someone might be using it”. If you’re not sure, remove it on the front end and you’ll soon find out whether it was in use. By cutting out redundant portions of code and unused features, you reduce your tech debt and thereby make room for more productivity. I call it ‘springboard work’.
Of course, when you’re essentially rejecting product ideas, there’s such a thing as a ‘soft no’ – ie we’re not doing this now, here’s why, and you can still feel good about this conversation. And I know I’ve failed in providing this many times. However, I like to think that where I’ve said no, I’ve done so for good reasons, whether that’s because the idea hasn’t been properly thought out or it’s too much work for too little reward. It keeps the bar high for the company and its tech and, most importantly, means you have the capacity to properly and wholeheartedly commit to the few things that will matter.
Impact beyond Alpha
4-8 weeks of a Discovery or Alpha project is a fleeting time for us to accomplish our mission: to help institutions embrace the opportunities of the internet era. What can we try to extend our impact beyond the confines of the project.
Personal principles for product in a crisis
Building at pace for BEIS
Our Notbinary squad has been working with BEIS to build public services to meet the requirements of the Coronavirus (COVID-19) outbreak.