From all the major product tasks I’ve been involved with, the quarterly planning was always the most daunting for me. The main reason is that it involves a lot of work and the end result is almost always the same – no one is really happy or satisfied with the resulting plan. The management expected more to be achieved and the R&D feels like the plan is too demanding. You are squashed in between.

What can you do about it?

You can certainly make this process more efficient and painless and even reduce the drama. I’m not sure about your ability to affect the end result though 🙂

But before we delve into all of this – let’s start with what this process is about and why it’s important.

What is a ‘quarterly plan’?

As its name implies in a very straightforward way – the quarterly plan is a plan which encompasses all the features that should be delivered within the upcoming quarter.

Essentially, it’s a list of features which is backed up by a list of commitments from the delivery chain you are responsible for (developers, QA, designers, analysts and of course… product).

Why is it important to have such a plan?

Some could argue that the existence of a product roadmap should be enough and hence there is no need for a quarterly plan. Though I do understand why this argument makes sense on the theoretical level, when it comes to the practical terms – it doesn’t hold much water IMHO. The reason is (and I discussed it briefly when covering the product spheres of responsibilities (here)) that the level of granularity is different on both.

On the product roadmap we will include items (features) which are more ‘high level’ and are well understood by the management. With the product roadmap the goal is to align the expectations across the board as for when each capability will be ready. When reviewing the roadmap – no one cares when we’re going to fix the annoying bug which has been disturbing our users for a few months now. Fixing it doesn’t promote the product strategy in any way – and hence it shouldn’t be on the roadmap.

When it comes to the quarterly plan, however, this bug will become an item of its own (assuming it’s at least a few days of work).

You see – the quarterly plan includes ALL working items that are going to occupy the delivery chain and are known in advance. This is one of the main reasons why it becomes so daunting. But as you would expect – there is one big upside here: it transitions everyone from the dream-land to reality.

The management wants you to progress according to the roadmap. But in the same breath they expect you to deal with many accumulated customer requests, bugs, cost reduction tasks and more.

The quarterly plan forces them to face reality. You can’t have the cake and eat it too. They will need to give up on one or more things as the amount of available working days is constant and can’t change.

If you decide to skip the quarterly plan and simply progress with sprints hoping that you’ll be able to deal with both the roadmap and reality together, then you’ll soon find out that the day-2-day reality usually wins, and you slowly drift away from the roadmap.

And the sad news is that you’ll be held accountable for not meeting the roadmap goals, because you didn’t do the necessary work which was required for setting up proper expectations.

 

Ok, so how do I do it ‘right’?

When approaching the quarterly planning you can take either the bottom-up or the top-down approach.

The bottom-up approach

With this approach you are asking all the internal stakeholders who work with your product group what they would like your group to promote in the upcoming quarter.

You then add all the roadmap items, prioritize the list, get rough estimations from your ‘delivery chain’ (developers, QA, analysts and designers) for each of the features, and now it’s just a matter of where the knife cuts the list based on the available working days in the quarter.

The idea is quite simple, conceptually. Quite challenging to actually perform, though. We’ll touch it in a minute.

The top-down approach

With this approach – you take a look at the roadmap and mark the items that must be done in this quarter, or otherwise the business will not move forward. You add other stuff that has been requested for a while or/and you know it’s important, though not directly derived from the roadmap.

Get effort estimations for these items.

How much capacity is still left? Probably nothing. But if there is some capacity – you can now ask all the internal stakeholders for their top 1-2 items. This will probably fill the gaps.

Which approach to choose?

To cut through the chase I’ll tell you directly that the top-down approach is much more efficient.

The bottom-up approach suffers from few main drawbacks:

1. It takes a lot of time to collect all the requests. Some of the stakeholders won’t be prepared and they will need to find the time and sort it out.
2. The list can become quite long and it will take a huge amount of time just to understand what each of the requests is about
3. Your team members will need to provide effort estimations for many items that are not going to be worked on eventually. Thus, a lot of wasted effort.

 

On the other hand – the top-down approach doesn’t suffer from these drawbacks, but it does put more responsibility on you. You need to do your homework, and you need to do them very well!

Trust me – you are going to be challenged by many internal stakeholders as for why this is the plan, and why those are the priorities. You need to be prepared for that and justify the existence of each item in your plan, and specifically what happens it goes away in terms of the business impact.

Now, politically-wise, I’d advise you to reach out to all of the major internal stakeholders and ask them for their top 1-2 items, regardless of your available capacity. Why?

1. They will feel that they were consulted and considered in this process, and it will avoid the noise of ‘how come there is a plan and I wasn’t involved?!’
2. You will understand what’s important to them, and be more prepared if they decide to challenge your plan. It will allow you to counter questions such as ‘how come the plan doesn’t include X?! The customer has been asking for that for 3 quarters already’.
3. They may actually provide an input that will make you reconsider your plan and you may decide eventually to shuffle some priorities and accommodate some of their requests.

The small details of the process

Whatever approach you choose, I recommend following these guidelines:

1. Everyone who is part of the delivery chain needs to be involved. Prepare them in advance that the quarterly planning is upon us and that they will need to be ready to provide estimations and work with you for understanding each of the items.
2. Start the process a month before the quarter ends. Yes, you will hear a lot of things in the spirit of ‘Eh? But we just completed the previous planning a few weeks ago. Are we starting a new plan already?’ 

They have a point, I must admit. If not done very efficiently – it may feel like the team is just transitioning from one planning to another. I will address this point shortly, but regardless – it doesn’t change my recommendation – start the process a month before the quarter ends as it takes time.

1. Be transparent. I always create and share a ‘planning’ spreadsheet where all the internal stakeholders can input their requests and/or see how the plan is forming up. I usually divide it to ‘raw data’ – where the internal stakeholders simply input their requests in their own words, and then a new sheet called ‘consolidated asks’ which includes all the requests after I unified similar items, modified some of the texts to make it clearer and removed junk. Make sure they can all mark their priorities and who have asked for what.
2. Delegate. The spreadsheet mentioned above also hands over the responsibility to ‘make a request’ to the other stakeholders. Hence, instead of you chasing them – give them a deadline to add their requests to the sheet and only reach out to them if something is not clear. It will save you tons of time.
3. Get clear commitments from your team. When you have the first draft of your plan – get your extended team (the developers and all the rest) to commit to it. Of course you don’t need to talk to each team member individually – just get the commitments from the team or group leaders.
4. Get a clear buy-in. When you are done – present your plan to the management and get their official blessing. Don’t skip this step or they may argue that they didn’t approve it or didn’t know this is happening. Be smart.

 

If you followed my guidelines above you should be able to come with a quarterly plan in an effective manner. Yes, it will probably still be annoying – but I truly believe it’s better than not doing it at all.

One optimization you might consider, and I heard Facebook is applying this practice (just something I’ve heard, but I haven’t verified) – is doing a 6 months plan instead of a quarterly plan. I never tried it myself, but it does make some sense.

The upside is very clear – you and your team won’t feel like you are constantly ‘planning’ and the overhead of the quarterly planning will be significantly reduced.

The downside is that a lot can happen in 6 months. It could be too much to the level where the plan no longer makes sense in the face of reality.

Again, I haven’t tried it – so it’s all theoretical from my perspective. If you have a better perspective on this – I’d be happy to hear!

 

That wraps up the post for today.

If you found this post/series useful – let me know in the comments. If you think others can benefit from it – feel free to share it with them.

 

Thank you, and until next time 🙂