Articles

9 Great Rules for Project Planning

We start examine tools with which Product Managers set their plans for the quarter, the year or even for the upcoming 3 years. This is a navigation map of sorts that shows if and when the team deviates from a given route.
In order to really make this tool effective you need to remember some useful rules.

1. Planning goes top-down

Typically, planning occurs as follows:
Company executives (~ 1 week) => Subcompany (3–4 weeks)=>Teams
At the start, the team plan will not be extremely detailed. In the beginning, the starting-off point will be templates, for example, “make badges so people don’t miss notifications”, and then the plan will be gradually supplemented.

2. Planning needs to happen well in advance

Due to the fact that the process takes a lot of time. With regards to annual planning, this usually takes place in December. The PM consults with the team regarding how realistic it is to complete a particular project on time.

3. Any changes in release dates should be reflected in the document

If there are projects that have been moved up from the previous quarter, they will be counted in the new period, and the document must indicate that the project was not completed in that quarter and therefore transferred to the current one. Although if the release comes out towards the beginning of the quarter, then the project’s recorded closing period should first be discussed with the company’s executives.

4. Everything must be timed appropriately, even corrections

Global plans are fixed for the quarter and their implementation is noted in the document.
It should be a rule of thumb that everything should be timed appropriately. If you understand that something is not working, then it is better to remove it from the plan entirely. A PM can reallocate the budget as he or she sees fit: the PM can close a project, or he or she can start a new one.

5. There is no such thing as an infeasible KPI; but there are incorrect action plans

If the project was evaluated incorrectly from the start or KPIs were chosen incorrectly, then it is better to immediately come to the Product Manager and decide what to do next with the PM’s help — what hypotheses can be used to fulfill the KPI?

6. To evaluate the success of features, the A / B test is everything!

There are A / B tests where one feature is shown to a group of people and another feature is shown to others. In such cases, no layering occurs. For example, you can take 10% of your audience show them the feature. After some time, you might realize that the feature wasn’t a hit. Leave this part of the audience alone and show a different feature to another 10% of the audience.
To avoid the influence of external factors on the success of the feature, there are two options available:
1) Using the A / B test, the feature is launched in such circumstances that nothing affects it. This way external changes do not affect the behavior of the audience, but only the output of the feature does;
2) Do nothing. The only important thing is how much money has come into the company, and how much has gone out.

7. Strategic projects require a different ROI, but still must be included

There are strategic projects that are designed to last several years. For example, when a product needs to be localized in another country. This will not bring in money quickly and the ROI is calculated differently. But these types of projects must be included in the document + be placed at a higher level.

8. Any project must be calculated

Technological change is usually offered by CTO (Chief Technical Officer). He makes his proposals, projects in the same document and then everything is discussed with the team.
Even if we are talking about some new technology, for example, an examination of machine learning or training a team for something that may not be profitable, but it requires serious investments, the Product must be able to evaluate everything. In such cases, he says that you can earn X money, but there are certain risks, and the probability is that we will earn 5%. Here you need to understand whether it is wise to invest in it or not.
Most often, SRT ideas are combined with product objectives, but in fact the product does not conduct technological projects. To do this, there is a separate team that implements such projects.

9. The most important thing in the project is money

The PM is the main person in the project. The PM monitors the team budget and analyzes spending every month. If the PM does not like something, then he or she decides whether to close the project or keep it going. Using Jira, the PM allocates the budget to different teams. The PM can use something other than Jira, at the PM’s own discretion.
The budget for developer tools is allocated to the relevant unit. Developers and the PM jointly evaluate and then track how much the tools cost. If something doesn’t suit the PM, he or she will then analyze why so much money is being spent.
Money is the most important thing in the project. A PM can show all the expenses: how much was spent, how much the company saved. If something didn’t work out, then the PM says that it is better to focus on something else.

Use these rules for effective planning and you will always know what direction you are moving in!

ProductStar team 

with 🖤