As we head into the end-of-year home stretch and the inevitably slower holiday period, I decided to make some roadmap adjustments to ensure we would finish the year strong.
It is difficult for any team to plan well for last few weeks of the year. Even if your business doesn't align with the traditional calendar year, you are likely to be working with customers, partners, and vendors who do scramble to wrap up their quarters and annual cycles at year's end.
On top of that, many of your employees are requesting time off from work leaving sizable gaps in the schedule. And you can just give up on trying to arrange any real business-related travel plans, e.g. to visit customers or to conduct on-site interviews.
With all the distractions that come with the holiday period, I began to ask myself how I could make the most of these remaining weeks of the year.
What drove this decision
We had been moving at a nice clip for the past few months. I was proud of the work being cranked out by the Product and Tech teams. We had achieved some good momentum and I was eager to preserve as much of that as I could. Many of the current projects would naturally extend into the early part of next year and I was determined to minimize any slow down around these particular initiatives.
We had achieved some good momentum and I was eager to preserve as much of that as I could.
But I also knew that it would be difficult for teams to coordinate larger tasks if their coworkers' schedules were inconsistent. With all that in mind, I took another look at the product roadmap to optimize our efforts for the last few sprints of the year.
The decision: Line up a collection of smaller stories, projects, and research to advance roadmap initiatives and to keep the teams productive.
I don't want to make it sound like the teams would otherwise be idle. We had just deployed our last major release of the year and I knew we would have some post-release work to tackle. For example, it was going to take some team coordination to gradually and prudently roll out some of the latest enhancements to the full customer base. Then there was the need to respond to users who would be wrestling with the most recent product changes. And of course, we are always prepared to deal with any bugs that may have slipped through.
The real challenge for me was to identify new product work that we could take on and to fit it into our irregular schedule.
Plan of attack
My goal was to maximize the collective team utilization and minimize any dead spots in the upcoming calendar. No one would be satisfied with blatant busy work and yet, it would be difficult to make much tangible progress on any new product initiative. I, more than anyone, wanted to feel like we had been productive during this time.
I determined that no one solution was going to work so to increase my chances of success, I ended up using several different approaches simultaneously. In the end, I was able to surface a number of smaller-scale projects to accommodate the various gaps in the teams' schedules.
Lay the remaining groundwork for next year's new product offering
Over the last 8-10 months, we had been working on a number of smaller, separate initiatives that were intended to fit together to create a larger, cohesive feature set. However, unless you had been working closely with the Product team, it would be difficult to see how the individual building blocks we had been delivering over many releases were meant to come together. This was the time to explain the broader vision.
I began by updating the product roadmap to illustrate how we would piece together 4 or 5 of the individual initiatives to create a major new offering to be rolled out in the early part of next year. Then, I scheduled new stories that would ultimately combine the separate components into a new whole. I had already convinced myself that this was going to be a thing of beauty but of course, I have been wrong before!
After we had finished connecting the dots (and bytes) and had painted the whole picture, we would be able to move forward by putting it in front of our users. I would continue to validate the new offering by testing it with our internal stakeholders, with customers in our Labs program and finally with prospects in the Sales funnel.
Tee up a list of discretionary items to fill downtime
Without even looking closely at the calendar, I knew we would have a week or so before the start of January where the Engineering ranks would be somewhat thin. My counterpart overseeing Engineering agreed that we could declare a "free sprint" where the developers would have more latitude in how they spent their time in the office.
I had a decent backlog of research topics that I lined up in case the well of ideas ran dry but I was pretty sure the developers would surface their own pet projects to keep themselves occupied. We continue to see some forward-thinking proposals come up through Engineering and I certainly wanted to encourage more of that activity.
I was pretty sure the developers would surface their own pet projects to keep themselves occupied.
There were, in fact, a few out-of-band product initiatives that were already in motion, and all in different stages of completeness. Those Tech Team members that had expressed an interest in exploring extracurricular material had been encouraged to do so with the intention of tying the work back to short- and/or long-term customer value. Based on the success of those efforts, I could easily extend the initiatives and even stage a few more to follow.
Swap in some overdue projects to tackle technical debt
The company has had a banner year in terms of acquiring new customers. But the reality of growing your customer base and increasing the number of users/transactions on your platform is that scale-related challenges bubble to the top. Inevitably, I would need to schedule some cycles for the less glamorous housekeeping activities.
Every software company has technical debt and it requires discipline to stay on top of that debt. I am always grateful to find those few Engineers that appreciate the value of cleaning up and are quick to roll up their sleeves (can you roll up t-shirts sleeves?) and pitch in to help. We would use this end of the year time to tackle a few of these efforts as well.
The impact
It can be tricky for a Product Manager to figure out how to best utilize the weeks at the end of the calendar year. I looked for some small, but important projects that would move us forward but that had few, if any dependencies to avoid schedule impediments.
In using these three approaches: the free sprint, more "groundwork" stories needed to assemble the next product offering, and addressing technical debt, I was able to stock the upcoming sprints with productive work and reduce everyone's concerns about holiday dead time.
Look for more reports from theProductPath around capacity planning, roadmap planning, and managing product teams here on PM Decisions.
In a dauntless attempt to answer the near ubiquitous question, "What does a Product Manager do?", I decided to dedicate an entire year to recording and sharing my own journey down the product path.
The Product Decision: Contribute to the growing body of knowledge by sharing weekly accounts of my on-the-job product experiences as the Head of Product for a late stage startup.