In recognizing that the Product team would not have the capacity to launch any new projects in the weeks ahead, I reassessed all the in-flight work to identify lower priority items that could be put on the back burner.
I believe that inside most successful Product Managers there is a solid Project Manager. After all, what's the point of being able to identify the right features to build if you can't then decompose and schedule the work in a realistic way?
I was certainly drawing from that particular skill set as I reviewed the list of projects that we currently had in motion. But instead of slotting in new tasks, I was focused on capacity planning and looking for ways to reduce the overall workload.
What drove this decision
There are any number of reasons why a team might take on more work than they should. Many of us will simply raise our hand to help when we hear about something that interests us. For example, an Engineer is easily tempted to spend time poking around with a cool, new technology. It is not uncommon for small research stories to grow as you uncover more details. Sometimes small projects get early traction and begin to snowball quickly. Then there are those urgent fires need that to be put out but which ultimately take you in unexpected directions.
I will take the lion's share of the blame for letting our teams get a little carried away over the past few months. Like the Engineer who latched on to it, I was also intrigued about one of the tech-related research projects. And like the Product Manager who had been working on an important feature, I was also curious about we could extend it beyond the original scope. I could argue that these, along with all the rest, were good-sounding and well-intentioned projects.
But, in thinking about the future, I knew I had to revisit the current project mix and better position us to take on the next round of work.
The decision: Find good stopping points for some of the projects in motion to clear the path for new initiatives.
The teams only have so much capacity and the calendar is still a fixed constraint so the next best option is to revisit scope. In some ways, though, this was an easy exercise.
Some of the projects had gotten long in the tooth and I could tell the enthusiasm had started to wane. Always conscious of team morale, I knew I could reassign those folks to different projects. In other cases, I needed to get straying efforts back on track or to achieve some closure, so I created some break points.
Plan of attack
I was looking for simple criteria that helped me pick new projects over existing projects. In most cases, that came down to determining when each initiative would like return value to the business. With each project I wrapped up, I was able to increase our capacity to tackle new stuff.
Complete a year-long drive to finally get over the goal line
I started by addressing a particularly problematic project that had stretched out for far too long. In fact, this particular enhancement had been stuck at 95% complete for almost an entire year and everyone was eager to see this finished.
Product and Engineering had completed their pieces many months ago but were now paused indefinitely as an absurd number of weeks had passed without any forward progress. The effort was blocked, waiting on our Operations team who had been struggling to prioritize the work. Unfortunately, I had no more control over the Operations department than any other and would need to be creative in how to apply pressure.
I tried using guilt mixed with a bit of positive motivation and even some old-fashioned horse-trading.
So I tried using guilt ("c'mon guys, this has been overdue for far too long") mixed with a bit of positive motivation ("our customers are really looking forward to this enhancement!") and even some old-fashioned horse-trading ("how's about I offer up some time in the schedule to tackle this other project you care about in exchange for knocking this out?"). In the end, I exhausted some personal capital to get this done but was happy to finally see it on a path to completion.
Scope back a feature enhancement that had expanded over time
In another scenario, I zeroed in on another feature enhancement that had experienced some scope creep. The PM had started out with good intentions but had augmented the work over time as he found more and more technical debt to tackle.
Now as we realized that the latest round of proposed changes would push us well into the new year, we culled the core improvements from the larger set of stories and chose to deliver a smaller, but still substantial upgrade to our customers. This decision contributed some breathing room to the roadmap, freeing up some Engineering resources to work on new work in the weeks ahead.
Conclude a key product prototyping effort
Several months earlier, I had recruited a talented, external resource to build a data analytics prototype that would enable us to conduct some product discovery work with our customer base. In doing so, we secured a trial license to a third-party business intelligence tool which would expire in the next week. That provided a natural stopping point and a good motivation for wrapping up that initiative.
I worked with the contractor to put some final polish around the prototype and together, we delivered a final presentation to my CEO and to an influential external party. After those successful demonstrations, we put the prototype on the shelf with the expectation that we would be able to bring it back at any time, as our needs (and budgets) changed.
Pause the team on new research proposals
I am a big fan of continuous research and development and we are not short on new areas to explore. It is entirely possible, though, that I let us get ahead of ourselves by encouraging folks to come up with new product and technology ideas to research, with the thought of being productive during those holiday weeks at the end of the year.
Now, I had to reset expectations a bit. As gently as I could, I conveyed my appreciation for everyone's enthusiasm and commitment while at the same time explaining that we would have to table some of the research proposals for the time being.
There is nothing particularly special about cleaning up projects at the end of the year, but the cumulative slow down in many areas of the business provided me with a great excuse to pare down our workload. I made sure we did not simply abandon projects mid-stream. I also did not want to give anyone the impression that we had simply become distracted by something more exciting. I tried to help the teams recognize that priorities were always changing while at the same time, emphasized the value of achieving closure.
The net effect of these decisions is that I had fewer projects in motion and more Product and Engineering capacity to head into the new year.