Planning features

The problem:

I will discuss in this post about the planning process of complex features that span over multiple teams and multiple planning intervals. I want to make this assumption clear right from the start because i will discuss several variables that affect planning and i want to set from the start what is constant. Talking about features lists for starting with a new product from scratch require different approach.

Now, the issue at hand is related to planning. So you find yourself in the shoes of a product manager that needs needs to plan the implementation, integration and release of a new set of future. We have already emitted an assumption about a client need, we have validated our assumption, and now we are discussing solutions, estimations and planning. You gather in the same room the technical people from all teams that will work on your features and all the business people that will use your features. You take the first feature and present it. Afterwards you reply to all the questions related to the feature and also clarify the details with the business folks present in the meeting. Now it's time to ask for estimations in terms of value and effort and you get responses from both the technical teams as well as the business teams. Next you find yourself in a sea of variables:

• you have multiple possible technical solutions that all have ups and downs
• you have variability depending on the teams that will implement the feature as they have different experience
• you have external dependencies that are unclear when will be available
• you have different business value depending on the moment of release because some event where you could launch the feature
• you have different market conditions over time because you heard that your competitor is also working on a similar feature
• you have technical debt that needs to be addressed in order to use some library needed for your feature
• you have key people that are a "flight risk" in your company
• you have budget constraints for this fiscal year as this feature was not fully budgeted at the beginning of the year
• you have competing development centers from different R&D facilities around the globe
• you have knowledge needs that are not covered within the current teams and you need to hire, externalize or train.
• you have customers that push deadlines based on changes in their planning

And all these variables just examples of what could impact your planning for the first feature. Once you clear all of them out and take into account all variables you then move to the next feature and start it all over again. And after you finish clearing all of this mess for all the features, you find that you need to apply some prioritization method. Once you finish prioritization and publish your backlog you will find stakeholders unhappy with the planning and you need to start everything all over again until you find the optimal usage of the available capacity and you find the right compromise between all stakeholders. For many projects this state where you make everyone happy is a nirvana that is never achieved.

The "bullshit" solution:

Overwhelmed by the number of variable that influence the planning, most product managers will fall back to one of the following methods for feature prioritization:

• Who yells the loudest. The most vocal stakeholder gets it's feature first.
• The player with the most mana. The highest ranking person in the organization decides what features go first based on purely subjective criteria.
• Everything, everywhere all at once. Start all the features in all the teams and pray there are at least small increments to show to the stakeholders at the end of every iteration/reporting period.

The "no bullshit" solution:

This one requires that you actually do some work. First you need to identify all the variables at play for every feature. Then divide them in internal versus external. All external influences or variables are topics outside of your control and get translated into risks and process them for the rest of your development cycle as risks. This would be a topic for another discussion.

The internal variables are those within your control and can be quantified in either business value or effort. Effort is coming from the development teams. Based on my experience this is the easy one to get. Even after all the technical discussion and analysis of what you gain vs. loose for any of the proposed technical solutions it is still easier to quantify effort than business value. Especially if you are working with mature teams that understand relative estimations and estimate accordingly in story points, again, this would be a great subject for a future post. Let me just make a note...

Ok. Now to the heavy lifting of the product management role. Establishing the business value for your features and getting agreement from all stakeholders on the backlog. I'll try to structure the process as an algorithm. The input for your algorithm is a list of features with their respective effort estimations and for each feature a impacted stakeholders list. Then you apply the algorithm:

1. make a list with all stakeholders
2. set meeting with all stakeholders. In the meeting details put also the list of features that will be discussed and make clear the expectations of this meeting: to achieve an ordered list of features, aka backlog.
3. (optional) in the meeting invite you can also make clear the prioritization method you will use. Wether it is Kano, RICE, MoSCoW, WSFJ or any other technique, specify and shortly describe the method and include links to resources that better describe the prioritization process. This will discourage right from the start the challenge over the method applied.
4. if you historically found it is hard to get all stakeholders in the same room make sure you let the ones that decline your meeting that their feature might get a lower priority due to the fact that the rest of the stakeholder do not fully understand the business value provided by this feature. This will reduce the chance of people skipping your meeting.
5. if you know for sure that some stakeholders are needed and have declined your meeting you might need to reschedule in order to make sure that your mandatory stakeholders are present. You might need to do some lobbying with those stakeholders or even escalate to higher-ups, but you need to make sure you have attending your meeting all parties that need to agree with your prioritized list of features in order to avoid lengthy discussions and challenges of the priority down the road.
6. be prepared for the meeting. do not forget it's your show. Be ready to get challenged. Be ready for push backs from your stakeholders and be ready to push back on your own. Remember that any prioritization method you might pick, most of the business values estimated are still subjective views from your stakeholders. Be ready for negotiations and for mediation between your stakeholders. They might start arguing with each other and with you. Bring your best active listening game and fell the pain points of your stakeholders.
7. Hold the meeting, apply your method of choice, get the list.
8. Put on the table all the variables identified before the meeting as all of them impact the business value.
9. More often than not, stakeholders tend to go too deep into details and, if you found that the discussions were valuable, you most probably let them run their course. The time allocated for the meeting will be insufficient in this case and you will need to schedule a follow-up. Make sure you get the commitment from all in the meeting on the follow-up. If your stakeholders list changes, you feature priority will also change.
10. If during the previous meeting you found that some stakeholders were very adamant on some criteria and they are unwilling to negotiate, you might have to do some lobbying until the follow-up meeting. Try to find that are the points where they are willing to negotiate and the points that are non-negotiable. During the next meeting focus on what can be negotiated in order to find the common ground towards agreement.
11. Hold follow-up, go to step 7.
12. If you managed to get agreement from all your stakeholders upon the prioritized list of features then put it somewhere publish so that everyone has access to it. Preferably in the "single source of truth" repository for your project. Refer to it with any occasion, use it in your reporting of the project status, and pick items from it's top at every iteration planning.

Ain't easy... right? The good news is that with experience, it becomes easier. At some point it will become your second nature. Every chat with your stakeholders will turn into a lobbying activity for the feature backlog, Every feedback you receive from them will turn into an adjustment of the plan.

The bad news is that, if at any point in time you feel that the variables have changed substantially enough that they impact your current planning, you need to gather again the data for your current feature list and start the above process all over again.