Can and should I work on more than one thing at a time as a Product Manager?

The great debate on whether we should just focus on only delivering one feature at a time, or whether we should work on multiple streams and changes at once.

Just what is the right thing to do as a Product Manager? Having to manage a work steam and deliver maximum benefit can oft be a stressful position to be in. You want the product to do its very best and its team to be able to deliver as much value as possible, but you want to do this without causing burnout, unhappiness in the team or delivering late and/or poor quality features. Yet when you are faced with stakeholders, sponsors and often leadership teams on a daily basis it can get far too tempting to just try to do too much and it can all come crumbing down around you.

This is often a problem faced by Product Managers, BA’s and Project Managers and its something I’ve discussed many times with my colleagues and peers at meetups and events. When I have been trying to do too much I’ve had discussions with seasoned Software Developers and veteran Product Managers who question why we have different things in progress at the same time— “Aren’t you trying to do too much and it’ll mean you are not going to be able to deliver these or risk delivering them with no value”. The answer has in the past been yes because I've not been thinking smartly about it.

I think almost everyone has attempted to run too many work streams at once and then under delivering on each of the things that was worked on. We were either too optimistic about how long things would take, misunderstood their complexity or ended up having a cross dependency that took much longer to resolve than initially considered. Sometimes that has meant that we’ve over-promised and then under delivered — a really bad place to be in as a Product Manager.

But should we really only be working on one thing at once and is it possible to work on a few different things but still deliver good, valuable features?

I think it is, but you have to be smart about it.

If we break product development down to its basics, you end up with 3 stages regardless of your approach or methodology:

Build, Measure, Learn

These stages are cyclical too because they always feed into each other. By creating something you have to build it. Once its built you will (hopefully) then want to understand how it performed by using some form of measurement to decide on success or failure. Once you have done that you learn from it (including if it fails). The cycle then starts again and allows you to build other things and so on...

So if we focus ourselves to work in one of these 3 areas, are we not potentially losing time by allowing other features to be in those stages?

My suggestion is to do the following with the features in your roadmap:

Multi- Build Measure Learn

Have the product team sat in the middle and working on multiple features but without the team doing the same step of the life cycle of those features at the same time.

I’ve used 3 as an example above, but it doesn’t have to be 3, it could be just 2. Depending on how much capacity you and the team have you could attempt to do a bit more — but don’t over do it, try it, measure it and learn from it.

In the past I have worked on features where it would have actually caused more issues having multiple developers working in the same area of the codebase as it would have caused conflicts later. If that is the case, then potentially another developer could be working somewhere else that won’t cause these conflicts, or doing the setup/investigation tasks for the next item in the roadmap or backlog. This is hopefully something your lead developer should be figuring out for the team anyway!

The value in working this was is that as a Product Manager, if you are currently measuring a shiny new feature that has gone live, the product team could simultaneously be in the build stage of another. This means that after you’ve spent time making best friends with your resident analyst to gather data or with your nose down in spreadsheets and SQL databases your next feature is already being progressed. Once you’ve collated the data you will then be able to spend time learning from it which you can then feed back into your backlog and roadmap.

Now I don’t think what I've stated here is exactly revolutionary and I think many of us are already doing it, however its more about being smart in how you do it. Don’t attempt to be in the build stage of multiple features at once as you’ll only cause yourself problems.

The same goes for delivering multiple features at the same time too. If you have multiple pieces going live at the same time, you won’t be able to spend enough time measuring and understanding exactly what happened with that feature to properly learn from it either. You could end up making poor decisions about the future of the product.

Most importantly though if you attempt to shift to this way or working: Try it, see if you can measure it (in story points/cycle time etc) and then learn from it.