Hard Prioritization
Setting priorities means completing the tasks that are most important in the first place. If you produce products, this means that first of all, what is most valuable to the customer should be done.
In my experience, the art of making decisions related to priorities is one of the skills that teams are given with particular difficulty. The reason is that these solutions are sometimes very complex. Although this is usually included in the basic responsibilities of a product manager, I found that in the best teams, each member sets priorities in a manic way, focusing on the same goals as his colleagues, and working with them in conjunction.
This article focuses on the basics of prioritization.
')
Prioritization in product management can be divided into two areas:
As we shall see, the ways in which we must solve each of these problems are very different. This is explained by the fact that they involve different solutions.
When you prioritize projects, you have to make one important decision: what will be the first part of my team to invest in ? To find the right approach to this issue, imagine that you are assembling a puzzle. Strictly follow the pattern to find all the pieces, and when they are folded in the right order, you will have the answer.
When you set priorities in a project, you will have to make the same decision hundreds of times: is it really necessary ? The correct approach is as follows: you need to realize that the process of producing a product is always spontaneous and to develop a hard way of thinking that will allow you to quickly make decisions, separating the necessary from the optional.
Strictly follow the scheme to make a puzzle: what will my team invest in first?
The answer to this question may require rigor from you, but the process itself is not particularly difficult:
I assume that most of these ideas are not new to readers, so we will go over them in passing.
The basis for the prioritization of projects is the return on investment (ROI); it is measured as the value of customer value that your team creates per unit of time. Your goal in terms of prioritization is to always do the work that gives you maximum consumer value.
To highlight priority projects, you need to evaluate two points:
As soon as you have all these data for each project, you can simply compare them, and then - voila - the priorities are in full view.
Of course, it is difficult to assess the impact and efforts, but if you consider that the probability of making a mistake in you is the same every time, then, as a comparative exercise, calculating the payback is a completely legitimate method for prioritizing projects.
Tip : made an assessment of effort and impact? Double the first value, and the second divide by two - and you will be much closer to reality.
Since life is not as smooth as a spreadsheet, there are also limitations that need to be considered when setting priorities. The main constraints with which you will have to deal are dependencies, the time frame and composition of the team.
Dependencies
Dependency arises when it is necessary to complete one stage of work in order to advance with another stage.
Suppose your team is developing mobile applications and you want to make it so that on smartphones customers can pay with one click of a button. You figured out that this project will pay off better than all the others, and therefore you want to implement this feature as soon as possible.
However, for this, your company should first of all be able to accept payments at all, on which the other team is working. Dependence on other departments means that you can’t do anything yet, so the right decision in terms of prioritization will be to postpone the payment function in one click and take on the next payback project.
In the process of producing products, dependencies are inevitable, and the more successful a product becomes, the more numerous they are, because a larger scale implies more complex systems. In large companies, understanding dependencies and working with them are often the most important components of prioritization.
I will note in parentheses: many people think that startups have such high rates, because people work harder and more ambitious there. In fact, the difference in speed of work is due to the fact that startups have far fewer dependencies (and customers who will be dissatisfied if something goes wrong), so it’s easier for them to bring tasks to mind.
Inverse dependencies
There are times when you have a project that will be very useful for other teams in achieving their goals. In such cases, the addiction is you.
If you are calculating the project's profitability for the company as a whole, and not just for your product — and you need to do just that — then you should calculate the total return on investment not only of your project, but of all those dependent on it, which you will “unfreeze” to correctly prioritize your team.
Whenever I see how a team works to “defrost” others, I penetrate to these people with respect - this speaks of maturity in grocery thinking. Such teams can be called unsung heroes, those who bring the food company the most benefit.
Time frame
The time frame is the standard constraint that we all experienced. The case takes a particularly serious turn, when there is a risk that you will spend money without having to implement the most payback function, and everything will be over.
In such a situation, the right decision, of course, will be to choose the most profitable of the projects that are really to be completed within these terms.
Line-up
Not all teams are equal, and sometimes the team will influence your decisions about which project you need to take to work.
Take, for example, a team that almost entirely consists of new people in a company - for example, a flock of interns (I don’t want to say anything bad about trainees, they make 50% of all software).
In such situations, you should be careful not to prioritize the project, which contains many risks for customers, even if it has the maximum return on investment. Instead, it will be more profitable for you to prioritize a project that does not affect any critical code fragments or user experience, because then the probability of a bad outcome is reduced several times.
Help the novice teams to get started a bit first of all by successfully rolling out a few small projects. As soon as they have any successfully implemented functions in history, they will be able to proceed to more complex projects.
I downplay the amount of work needed to collect all the information listed above, but as soon as all this is in your hands, all that remains is to lay down the pieces.
When work on a project has already begun, the prioritization is different at a fundamental level. It becomes more spontaneous. Decisions need to be made every day, and there is not enough time to in-depth analysis of each problem that we carried out at the project selection stage. In addition, during this period, the team is on the nerves - after all, all these decisions will somehow affect real customers, and at times it may seem that the reputation of each of those involved in the startup is at stake.
The only way to cope with the speed and chaos of the product creation process is to work out a hard approach, within which all the work the team does is monitored and every action will be called into question: is this really necessary?
To take a hard approach means to recognize the real state of things, to realize that you have to make difficult choices every day, on which to concentrate your strengths. To realize that the intention to launch an ideal product is an illusion that launching always requires compromises.
The hard approach is caused by the desire to bring the product to launch. The expectations of investors and clients put pressure on the team so much that in the end many people simply become frightened to bring the product to the market. They start to bother with trifles to such an extent that the work practically does not move. They lose sight of what really matters — customer value per unit of time — and begin to pursue perfection.
In fact, the very spontaneity of prioritization within the project makes any attempt to determine a fixed sequence of actions meaningless. A more productive strategy is to help the team learn the concepts of product development that will be useful to them in order to firmly answer the question: “Is this really necessary?”. Here are the ones that we look at in this article:
Any default software is still a headache. There are still bugs in it, and over time they will only become more. If a team, faced with a new bug, cannot quickly determine whether to correct it, its ability to focus on the most important tasks will be undermined.
You cannot afford to gather a meeting and discuss priorities each time another bug is detected, so the best way out is to implement a system by which you can determine which bugs to work on right away, and which ones to give up.
As an example, here is a system that has proven useful to my team.
The x-axis represents the percentage of users affected by the bug, the y-axis — how serious this effect will be. The red dot indicates the bug itself.
To use this system, together with the team, determine which level of severity and percentage of users will be considered as maximum permissible (in our case, this is “users cannot make a payment” and 5%, respectively). Next, divide the field into zones and agree on what actions will be taken for each. A set of actions must include "send backlog and do not touch."
If you do not regret this time and effort, your team will become a real machine for eliminating bugs, and the likelihood that someone is working on a minor bug will be eliminated at the system level.
You often hear stories about how terrible the startup founders wrote in the early stages. Then, when the company achieved success, this code was a new programmers team in nightmares.
What, the founders could not write code? It is not excluded. But most likely at that time they simply did not care about the quality of the code, since the probability that the product would be successful was extremely small. Therefore, they focused on speed and validation of the idea.
Each team inevitably sacrifices quality in some way to launch a product. She has to decide where to draw the line, and for the most part this is determined by how priorities are set - what is considered key to product quality.
Here is a good way to find an acceptable point on the speed-quality spectrum: base yourself on your assumptions about the product. Product assumptions are those fundamental opinions about the problem of users or the planned solution that you adhere to.
A simple example is Facebook at the dawn of its business. The alleged problem was formulated as “people want to communicate with each other online.” Having received confirmation that this problem is relevant, they began to come up with ideas for the product, for example, the ability to add other users as friends - in other words, to make assumptions about how to solve the problem posed.
If you analyze your product, you will see that the situation with the assumptions may be as follows:
If you are on the left side of the spectrum, then you have the assumption that users are faced with some problem, but you do not know how true it is. In this case, you'd better cut corners to the maximum and roll out the product as quickly as possible to minimize the risk that you are solving a non-existent problem.
On the contrary, if you are at the right end of the spectrum, that is, you are sure that the problem is topical, and how to create the right solution, then you should ensure the highest possible quality - because you know that the product will be successful, which means you need a good reserve for the future.
Often, companies create separate teams for experiments and for work on the "core". It seems to me that such an organization structure indicates that most teams do not have an understanding of the range of assumptions about the product and, accordingly, they are not able to make an unambiguous choice in favor of speed or quality.
Software has value for users only after launch.
So, we should be able to determine the value of early product launch for users. I have already spoken about this concept in one of my previous articles .
For example: teams often face a difficult choice - is it worth it to implement a function for 80% of clients, while delaying it for the remaining 20%. Usually such a situation arises when its implementation for these 20% will require a niche functionality, the creation of which will take twice as long (compared to what was implemented for 80%).
Let's decompose both options on the shelves.
Looking at the diagram, we see that in the first case 80% of users benefit - they get access to the functionality earlier and have the opportunity to extract more value. Otherwise they would have to wait. Then, it turns out, and there is nothing to guess - should I choose the first option? Not really. The choice remains difficult because:
Paradoxically, in sum, these two effects give the following result: when making the decision to provide users with more value for a certain period of time, we will make people angry more than if we had not done anything. Survived.
However, in such cases, I usually advise teams to be tough and launch the product. And that's why:
Choosing an early launch is one of those ideas that is easy to comprehend, but difficult to bring to life because of the discomfort they cause. Those who are able to rigidly set priorities will understand what is what and will be able to act in the interests of users.
The concepts considered are something that I had the opportunity to see for myself from my own experience. , .
, , , , .
, ; , . , , , ? Hardly. , , .
, , , . : , . , , , .
— .
— , . , . , .
: , .
Is always. . : « ?» — - .
, , . , , — .
, , — , , .
— .
In my experience, the art of making decisions related to priorities is one of the skills that teams are given with particular difficulty. The reason is that these solutions are sometimes very complex. Although this is usually included in the basic responsibilities of a product manager, I found that in the best teams, each member sets priorities in a manic way, focusing on the same goals as his colleagues, and working with them in conjunction.
This article focuses on the basics of prioritization.
')
Basics of prioritization
Prioritization in product management can be divided into two areas:
- Inter-project prioritization is the definition of which project your team should take as follows.
- Prioritization of work within one project - here the goal is to complete one project as efficiently as possible.
As we shall see, the ways in which we must solve each of these problems are very different. This is explained by the fact that they involve different solutions.
When you prioritize projects, you have to make one important decision: what will be the first part of my team to invest in ? To find the right approach to this issue, imagine that you are assembling a puzzle. Strictly follow the pattern to find all the pieces, and when they are folded in the right order, you will have the answer.
When you set priorities in a project, you will have to make the same decision hundreds of times: is it really necessary ? The correct approach is as follows: you need to realize that the process of producing a product is always spontaneous and to develop a hard way of thinking that will allow you to quickly make decisions, separating the necessary from the optional.
Prioritization between projects
Strictly follow the scheme to make a puzzle: what will my team invest in first?
The answer to this question may require rigor from you, but the process itself is not particularly difficult:
- Assess the return on investment for each project.
- Apply three constraints: dependencies, timeframe, and team composition.
- Build a puzzle - build a sequence of projects based on the return on investment and limitations
I assume that most of these ideas are not new to readers, so we will go over them in passing.
1. Evaluate the return on investment
The basis for the prioritization of projects is the return on investment (ROI); it is measured as the value of customer value that your team creates per unit of time. Your goal in terms of prioritization is to always do the work that gives you maximum consumer value.
To highlight priority projects, you need to evaluate two points:
- The amount of customer value to be received;
- The amount of time it takes to complete a project.
As soon as you have all these data for each project, you can simply compare them, and then - voila - the priorities are in full view.
Of course, it is difficult to assess the impact and efforts, but if you consider that the probability of making a mistake in you is the same every time, then, as a comparative exercise, calculating the payback is a completely legitimate method for prioritizing projects.
Tip : made an assessment of effort and impact? Double the first value, and the second divide by two - and you will be much closer to reality.
2. Apply restrictions
Since life is not as smooth as a spreadsheet, there are also limitations that need to be considered when setting priorities. The main constraints with which you will have to deal are dependencies, the time frame and composition of the team.
Dependencies
Dependency arises when it is necessary to complete one stage of work in order to advance with another stage.
Suppose your team is developing mobile applications and you want to make it so that on smartphones customers can pay with one click of a button. You figured out that this project will pay off better than all the others, and therefore you want to implement this feature as soon as possible.
However, for this, your company should first of all be able to accept payments at all, on which the other team is working. Dependence on other departments means that you can’t do anything yet, so the right decision in terms of prioritization will be to postpone the payment function in one click and take on the next payback project.
In the process of producing products, dependencies are inevitable, and the more successful a product becomes, the more numerous they are, because a larger scale implies more complex systems. In large companies, understanding dependencies and working with them are often the most important components of prioritization.
I will note in parentheses: many people think that startups have such high rates, because people work harder and more ambitious there. In fact, the difference in speed of work is due to the fact that startups have far fewer dependencies (and customers who will be dissatisfied if something goes wrong), so it’s easier for them to bring tasks to mind.
Inverse dependencies
There are times when you have a project that will be very useful for other teams in achieving their goals. In such cases, the addiction is you.
If you are calculating the project's profitability for the company as a whole, and not just for your product — and you need to do just that — then you should calculate the total return on investment not only of your project, but of all those dependent on it, which you will “unfreeze” to correctly prioritize your team.
Whenever I see how a team works to “defrost” others, I penetrate to these people with respect - this speaks of maturity in grocery thinking. Such teams can be called unsung heroes, those who bring the food company the most benefit.
Time frame
The time frame is the standard constraint that we all experienced. The case takes a particularly serious turn, when there is a risk that you will spend money without having to implement the most payback function, and everything will be over.
In such a situation, the right decision, of course, will be to choose the most profitable of the projects that are really to be completed within these terms.
Line-up
Not all teams are equal, and sometimes the team will influence your decisions about which project you need to take to work.
Take, for example, a team that almost entirely consists of new people in a company - for example, a flock of interns (I don’t want to say anything bad about trainees, they make 50% of all software).
In such situations, you should be careful not to prioritize the project, which contains many risks for customers, even if it has the maximum return on investment. Instead, it will be more profitable for you to prioritize a project that does not affect any critical code fragments or user experience, because then the probability of a bad outcome is reduced several times.
Help the novice teams to get started a bit first of all by successfully rolling out a few small projects. As soon as they have any successfully implemented functions in history, they will be able to proceed to more complex projects.
Prioritization between projects: put the whole puzzle together and get to work
I downplay the amount of work needed to collect all the information listed above, but as soon as all this is in your hands, all that remains is to lay down the pieces.
We set priorities within the project
When work on a project has already begun, the prioritization is different at a fundamental level. It becomes more spontaneous. Decisions need to be made every day, and there is not enough time to in-depth analysis of each problem that we carried out at the project selection stage. In addition, during this period, the team is on the nerves - after all, all these decisions will somehow affect real customers, and at times it may seem that the reputation of each of those involved in the startup is at stake.
The only way to cope with the speed and chaos of the product creation process is to work out a hard approach, within which all the work the team does is monitored and every action will be called into question: is this really necessary?
To take a hard approach means to recognize the real state of things, to realize that you have to make difficult choices every day, on which to concentrate your strengths. To realize that the intention to launch an ideal product is an illusion that launching always requires compromises.
The hard approach is caused by the desire to bring the product to launch. The expectations of investors and clients put pressure on the team so much that in the end many people simply become frightened to bring the product to the market. They start to bother with trifles to such an extent that the work practically does not move. They lose sight of what really matters — customer value per unit of time — and begin to pursue perfection.
Show me a team that has no bugs at the launch stage, and I’ll say: they should have rolled out the product a long time ago.
In fact, the very spontaneity of prioritization within the project makes any attempt to determine a fixed sequence of actions meaningless. A more productive strategy is to help the team learn the concepts of product development that will be useful to them in order to firmly answer the question: “Is this really necessary?”. Here are the ones that we look at in this article:
- Create a prioritization system
- Use product assumptions to strike a balance between quality and speed.
- Start time
1. Create a prioritization system
Any default software is still a headache. There are still bugs in it, and over time they will only become more. If a team, faced with a new bug, cannot quickly determine whether to correct it, its ability to focus on the most important tasks will be undermined.
You cannot afford to gather a meeting and discuss priorities each time another bug is detected, so the best way out is to implement a system by which you can determine which bugs to work on right away, and which ones to give up.
As an example, here is a system that has proven useful to my team.
The x-axis represents the percentage of users affected by the bug, the y-axis — how serious this effect will be. The red dot indicates the bug itself.
To use this system, together with the team, determine which level of severity and percentage of users will be considered as maximum permissible (in our case, this is “users cannot make a payment” and 5%, respectively). Next, divide the field into zones and agree on what actions will be taken for each. A set of actions must include "send backlog and do not touch."
If you do not regret this time and effort, your team will become a real machine for eliminating bugs, and the likelihood that someone is working on a minor bug will be eliminated at the system level.
2. Use product assumptions to strike a balance between quality and speed.
You often hear stories about how terrible the startup founders wrote in the early stages. Then, when the company achieved success, this code was a new programmers team in nightmares.
What, the founders could not write code? It is not excluded. But most likely at that time they simply did not care about the quality of the code, since the probability that the product would be successful was extremely small. Therefore, they focused on speed and validation of the idea.
Each team inevitably sacrifices quality in some way to launch a product. She has to decide where to draw the line, and for the most part this is determined by how priorities are set - what is considered key to product quality.
Here is a good way to find an acceptable point on the speed-quality spectrum: base yourself on your assumptions about the product. Product assumptions are those fundamental opinions about the problem of users or the planned solution that you adhere to.
A simple example is Facebook at the dawn of its business. The alleged problem was formulated as “people want to communicate with each other online.” Having received confirmation that this problem is relevant, they began to come up with ideas for the product, for example, the ability to add other users as friends - in other words, to make assumptions about how to solve the problem posed.
If you analyze your product, you will see that the situation with the assumptions may be as follows:
- The very problem you want to solve is an assumption
- The solution you propose for a known problem is an assumption.
- Neither the problem nor the solution is an assumption (you know exactly what needs to be done and why)
If you are on the left side of the spectrum, then you have the assumption that users are faced with some problem, but you do not know how true it is. In this case, you'd better cut corners to the maximum and roll out the product as quickly as possible to minimize the risk that you are solving a non-existent problem.
On the contrary, if you are at the right end of the spectrum, that is, you are sure that the problem is topical, and how to create the right solution, then you should ensure the highest possible quality - because you know that the product will be successful, which means you need a good reserve for the future.
Often, companies create separate teams for experiments and for work on the "core". It seems to me that such an organization structure indicates that most teams do not have an understanding of the range of assumptions about the product and, accordingly, they are not able to make an unambiguous choice in favor of speed or quality.
3. Time cost of launch
Software has value for users only after launch.
So, we should be able to determine the value of early product launch for users. I have already spoken about this concept in one of my previous articles .
For example: teams often face a difficult choice - is it worth it to implement a function for 80% of clients, while delaying it for the remaining 20%. Usually such a situation arises when its implementation for these 20% will require a niche functionality, the creation of which will take twice as long (compared to what was implemented for 80%).
Let's decompose both options on the shelves.
Looking at the diagram, we see that in the first case 80% of users benefit - they get access to the functionality earlier and have the opportunity to extract more value. Otherwise they would have to wait. Then, it turns out, and there is nothing to guess - should I choose the first option? Not really. The choice remains difficult because:
- 20% of users who remain unreached will definitely understand that you have decided not to support them, and will become enraged. From their point of view, you'd better not do anything at all.
- 80% of users for whom the function will be connected, in fact, will not feel that they have benefited from having accessed it before.
Paradoxically, in sum, these two effects give the following result: when making the decision to provide users with more value for a certain period of time, we will make people angry more than if we had not done anything. Survived.
However, in such cases, I usually advise teams to be tough and launch the product. And that's why:
- If users knew the context and could decide for us, the overwhelming majority would vote for the launch.
- In the long term, if the team consistently adheres to this strategy, then gradually the ratio of cases when a particular user turns out to be in the number of 80% and 20%, respectively, will level off. As a result, the effect accumulates, and users get more value exponentially over a given period than they would get from a company that prefers to always wait until it can cover 100% of the customer base.
Choosing an early launch is one of those ideas that is easy to comprehend, but difficult to bring to life because of the discomfort they cause. Those who are able to rigidly set priorities will understand what is what and will be able to act in the interests of users.
Prioritization within the project: a hard approach is unnatural
The concepts considered are something that I had the opportunity to see for myself from my own experience. , .
, , , , .
, ; , . , , , ? Hardly. , , .
, , , . : , . , , , .
— .
—
— , . , . , .
: , .
Is always. . : « ?» — - .
, , . , , — .
, , — , , .
— .
Source: https://habr.com/ru/post/324380/
All Articles