March 20, 2017 at 16:12Tough prioritization
- Transfer
Prioritization means completing the tasks that are most important in the first place. If you produce products, this means that what is most valuable to the customer should be done first.
In my experience, the art of making decisions related to priorities is one of the skills given to teams with special difficulty. The reason is that these decisions are sometimes very complex. Although this is usually part of the basic responsibilities of the product manager, I found that in the best teams, each member manically sets priorities, 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 will see, the ways in which we must solve each of these problems are very different. This is explained by the fact that they involve various solutions.
When determining the priority of projects, you must make one important decision: what will my team invest in in the first place ? To find the right approach to this issue, imagine assembling a puzzle. Strictly follow the pattern to find all the pieces, and when they add up in the right sequence, you will have the answer.
When you prioritize the project, you 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 product production is always spontaneous and develop a rigid way of thinking that will allow you to quickly make decisions, separating the necessary from the optional.
Strictly follow the pattern to complete the 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 complicated:
I assume that most of these ideas are not new to readers, so we will go through 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 with regard to prioritization is to always do the work that will give 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 - your priorities.
Of course, it is difficult to assess the impact and efforts, but if you consider that you have the same chance of making mistakes each time, then, as a comparative exercise, calculating the payback is a completely legitimate method of prioritizing projects.
Tip : did you evaluate the effort and impact? Double the first value, and divide the second into two - and you will find yourself much closer to reality.
Since life is not as smooth as in a spreadsheet, there are also limitations that need to be considered when prioritizing. The main limitations that you will have to deal with are dependencies, time frames and team composition.
Dependencies
Dependence 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 the click of a button. You have calculated that this project will pay off better than all others, and therefore you want to implement this function as soon as possible.
However, for this, your company must first of all be able to accept payments altogether, which another team is working on now. Dependence on other departments means that you can’t do anything yet, therefore, from the point of view of prioritization, the right decision would be to postpone the payment function in one click and take on the next payback project.
In the process of production of 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 and working with dependencies is often the most important component of prioritization.
I will notice in parentheses: many people think that startups have such a high pace because people work harder and more ambitious there. In fact, the difference in speed is due to the fact that startups have much fewer dependencies (and clients who will be unhappy 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, you are addicted.
If you are calculating the profitability of the project for the company as a whole, and not just your product - and you need to do just that - then you should calculate the total return on investment not only of your project, but also of all those dependent on it that you “unfreeze” to correctly prioritize your team.
Whenever I see how a team works to “unfreeze” others, I get respect for these people - this indicates maturity in product thinking. Such teams can be called unsung heroes, those who bring the product company the most benefit.
Time frame
Timing is a standard constraint that we all experienced on ourselves. The case takes a particularly serious turn when there is a risk that you will spend the money without having time to implement the most recouped function, and it will all be over.
In such a situation, the right decision, of course, would be to choose the most cost-effective of the projects that can actually be completed within these terms.
The composition of the team
Not all teams are equal, and sometimes the composition of the team will influence your decisions regarding which project you need to take into work.
Take for example a team that almost entirely consists of people new to the company - for example, a flock of interns (I don’t want to say anything bad about interns, they are the ones who make 50% of the software).
In such situations, you should be careful not to prioritize a project that contains many risks for clients, even if it has a maximum return on investment. Instead, it will be more profitable for you to prioritize a project that does not affect any critical pieces of code or user experience, because then the likelihood of a bad outcome is reduced significantly.
First of all, help the teams of newcomers to get used to it a bit by successfully rolling out several small projects. As soon as they have some well-established features in their history, they will be able to move on to more complex projects.
I downplay the amount of work needed to collect all the information mentioned above, but as soon as all this is in your hands, you just have to put the pieces together.
When work on a project has already begun, prioritization differs at a fundamental level. She becomes more spontaneous. Decisions must be taken every day, and there is already not enough time for a deep analysis of each problem that we carried out at the stage of project selection. Moreover, during this period, the team was on the nerves - after all, all these decisions will somehow affect real clients, 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 randomness of the product creation process is to develop a tough approach, in which all the work that the team is doing will be monitored and every action will be called into question: is it really necessary?
To take a tough approach means to recognize the real state of things, to realize that you have to make difficult choices daily, on which to concentrate your forces. Realizing that the intention to release the perfect product is an illusion that launching always requires compromises.
A tough approach is caused by the desire to bring the product to launch. The expectations of investors and customers put such pressure on the team that as a result, it simply becomes scary for many to bring the product to the market. They begin to bother with trifles to such an extent that the work practically does not move. They lose sight of what really matters - consumer value per unit of time - and begin to pursue perfection.
In fact, the spontaneity of prioritization within a project makes any attempt to define a fixed sequence of actions pointless. 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 we will look at in this article:
Any software by default is still a headache. There are bugs in it now, and over time there will only be more of them. If a team, faced with a new bug, cannot quickly determine whether it is worth fixing, then its ability to focus on the most important tasks will be undermined.
You cannot afford to convene a meeting and discuss priorities every time a new bug is discovered, so it’s best to implement a system by which you can determine which bugs to work out immediately 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 represents how serious this impact will be. The red dot indicates the bug itself.
To apply this system, together with the team, determine what severity level and percentage of users will be considered the maximum permissible (in our case, these are “users cannot make a payment” and 5%, respectively). Next, divide the field into zones and agree on what actions will be taken for each. The set of actions must include “send to backlog and do not touch”.
If you do not regret this time and effort, your team will become a real machine for fixing bugs, and the likelihood that someone is working on a minor bug will be eliminated at the system level.
Often you hear stories about how awful the startup founders wrote in the early stages. Then, when the company was successful, this code was the new nightmare team programmers.
What, the founders did not know how to write code? Not excluded. But most likely at that moment they simply did not care about the quality of the code, since the likelihood that the product would be successful was extremely small. Therefore, they emphasized speed and testing ideas.
Each team will inevitably sacrifice quality 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 - which is considered key to the quality of the product.
Here is a good way to find an acceptable point on the “speed-quality” spectrum: rely on your assumptions about the product. Product assumptions are those fundamental opinions about the user problem or the proposed 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, make assumptions on how to solve the problem.
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 an assumption that users are faced with some problem, but you do not know how it corresponds to reality. In this case, you should cut corners to the maximum and roll out the product as quickly as possible to minimize the risk that you are solving a problem that does not exist.
On the contrary, if you are at the right end of the spectrum, that is, you are confident in the urgency of the problem and how to create the right solution, then it is worthwhile to ensure the highest possible quality - because you know that the product will be successful, which means you need a good foundation for the future.
Often companies create separate teams for experiments and for working on the “core”. It seems to me that such a structure of the organization indicates that most teams do not understand the spectrum of assumptions about the product and, accordingly, they are not able to make an unambiguous choice in favor of speed or quality.
Software is valuable to users only after launch.
So, we must be able to determine the value of the early launch of the product for users. I have already talked about this concept in one of my previous articles .
For example: teams often face a difficult choice - is it worth it to implement the function for 80% of customers, while delaying it for the remaining 20%. Typically, this situation develops when its implementation for these 20% will require a niche functionality, the creation of which will take twice as much time (compared to what was implemented for 80%).
Let's put both options on the shelves.
Looking at the diagram, we see that in the first case, 80% of users win - 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 - do you have to choose the first option? Not really. The choice remains difficult, as:
Paradoxically, in total, these two effects give the following result: making the decision to provide users with more value over a certain period of time, we will anger more people than if we did nothing. 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 are easy to comprehend but hard to put into practice because of the discomfort they cause. Those who know how to set priorities firmly will understand what's what and will be able to act in the interests of users.
The concepts considered are something that I have had the opportunity to verify from my own experience. There are others, and everything I have proposed can be adjusted in the process of application.
Unfortunately, most companies are reluctant to take a tough approach to prioritization, despite the fact that this is a key principle for those who create products.
For example, in large organizations, new functions are constantly rolling out; most employees will not know about this earlier than the users themselves. Do you think they will see under such conditions that their colleagues managed to spend three times less time on launch than others would have spent in their place? Unlikely. But they will notice what is missing in the final product, even if all these shortcomings were missed by the team intentionally.
Conversely, a product licked to shine inside a company is generally praised. One thing is bad: it took two years to bring it to launch. It is a pity that we do not think about how many users have turned away from us because we are desperate to wait for it.
Motivate your team is getting better - that is, tougher.
Time is the most valuable resource that your company has at its disposal. If it is your responsibility to allocate this time, you need to develop this skill to the maximum. This is an art that can be purposefully comprehended in practice.
In conclusion, I offer you one more thesis on the topic of priorities: there is always a way to achieve your goals faster than you planned.
Is always. You just need to find it. You just need to ask the question: "How do we do this twice as fast?" at the end of the meeting - and in some miraculous way, the team will come up with a way out.
I’ve been launching products for two years and have never once encountered such a situation so that the team couldn’t figure out how to provide the user with the same value with less time. I did not come across any cases for the team to prioritize perfectly, which once again confirms the above.
If we accept that there is always a way out, then the most reasonable thing is to actively and firmly prioritize, whether the project is already working or whether you are still choosing which startup to do.
Even if your project is an entire state.
In my experience, the art of making decisions related to priorities is one of the skills given to teams with special difficulty. The reason is that these decisions are sometimes very complex. Although this is usually part of the basic responsibilities of the product manager, I found that in the best teams, each member manically sets priorities, focusing on the same goals as his colleagues, and working with them in conjunction.
This article focuses on the basics of prioritization.
Priority Setting Basics
Prioritization in product management can be divided into two areas:
- Prioritization between projects is the definition of which project your team should take next.
- Prioritization of work within the framework of one project - here the goal is to carry out one project as efficiently as possible.
As we will see, the ways in which we must solve each of these problems are very different. This is explained by the fact that they involve various solutions.
When determining the priority of projects, you must make one important decision: what will my team invest in in the first place ? To find the right approach to this issue, imagine assembling a puzzle. Strictly follow the pattern to find all the pieces, and when they add up in the right sequence, you will have the answer.
When you prioritize the project, you 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 product production is always spontaneous and develop a rigid way of thinking that will allow you to quickly make decisions, separating the necessary from the optional.
Prioritization between projects
Strictly follow the pattern to complete the 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 complicated:
- Estimate ROI for each project
- Apply three constraints: dependencies, timelines, and team composition.
- Build a puzzle - build a sequence of projects based on return on investment and constraints
I assume that most of these ideas are not new to readers, so we will go through them in passing.
1. Measure your 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 with regard to prioritization is to always do the work that will give maximum consumer value.
To highlight priority projects, you need to evaluate two points:
- The amount of consumer value to be obtained;
- The amount of time it will take to complete the project.
As soon as you have all these data for each project, you can simply compare them, and then - voila - your priorities.
Of course, it is difficult to assess the impact and efforts, but if you consider that you have the same chance of making mistakes each time, then, as a comparative exercise, calculating the payback is a completely legitimate method of prioritizing projects.
Tip : did you evaluate the effort and impact? Double the first value, and divide the second into two - and you will find yourself much closer to reality.
2. Apply restrictions
Since life is not as smooth as in a spreadsheet, there are also limitations that need to be considered when prioritizing. The main limitations that you will have to deal with are dependencies, time frames and team composition.
Dependencies
Dependence 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 the click of a button. You have calculated that this project will pay off better than all others, and therefore you want to implement this function as soon as possible.
However, for this, your company must first of all be able to accept payments altogether, which another team is working on now. Dependence on other departments means that you can’t do anything yet, therefore, from the point of view of prioritization, the right decision would be to postpone the payment function in one click and take on the next payback project.
In the process of production of 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 and working with dependencies is often the most important component of prioritization.
I will notice in parentheses: many people think that startups have such a high pace because people work harder and more ambitious there. In fact, the difference in speed is due to the fact that startups have much fewer dependencies (and clients who will be unhappy 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, you are addicted.
If you are calculating the profitability of the project for the company as a whole, and not just your product - and you need to do just that - then you should calculate the total return on investment not only of your project, but also of all those dependent on it that you “unfreeze” to correctly prioritize your team.
Whenever I see how a team works to “unfreeze” others, I get respect for these people - this indicates maturity in product thinking. Such teams can be called unsung heroes, those who bring the product company the most benefit.
Time frame
Timing is a standard constraint that we all experienced on ourselves. The case takes a particularly serious turn when there is a risk that you will spend the money without having time to implement the most recouped function, and it will all be over.
In such a situation, the right decision, of course, would be to choose the most cost-effective of the projects that can actually be completed within these terms.
The composition of the team
Not all teams are equal, and sometimes the composition of the team will influence your decisions regarding which project you need to take into work.
Take for example a team that almost entirely consists of people new to the company - for example, a flock of interns (I don’t want to say anything bad about interns, they are the ones who make 50% of the software).
In such situations, you should be careful not to prioritize a project that contains many risks for clients, even if it has a maximum return on investment. Instead, it will be more profitable for you to prioritize a project that does not affect any critical pieces of code or user experience, because then the likelihood of a bad outcome is reduced significantly.
First of all, help the teams of newcomers to get used to it a bit by successfully rolling out several small projects. As soon as they have some well-established features in their history, they will be able to move on to more complex projects.
Prioritization between projects: complete the puzzle and get started
I downplay the amount of work needed to collect all the information mentioned above, but as soon as all this is in your hands, you just have to put the pieces together.
Set priorities within the project
When work on a project has already begun, prioritization differs at a fundamental level. She becomes more spontaneous. Decisions must be taken every day, and there is already not enough time for a deep analysis of each problem that we carried out at the stage of project selection. Moreover, during this period, the team was on the nerves - after all, all these decisions will somehow affect real clients, 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 randomness of the product creation process is to develop a tough approach, in which all the work that the team is doing will be monitored and every action will be called into question: is it really necessary?
To take a tough approach means to recognize the real state of things, to realize that you have to make difficult choices daily, on which to concentrate your forces. Realizing that the intention to release the perfect product is an illusion that launching always requires compromises.
A tough approach is caused by the desire to bring the product to launch. The expectations of investors and customers put such pressure on the team that as a result, it simply becomes scary for many to bring the product to the market. They begin to bother with trifles to such an extent that the work practically does not move. They lose sight of what really matters - consumer value per unit of time - and begin to pursue perfection.
Show me a team that has no bugs at the launch stage, and I will say: they should have rolled out the product a long time ago.
In fact, the spontaneity of prioritization within a project makes any attempt to define a fixed sequence of actions pointless. 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 we will look at in this article:
- Create a prioritization system
- Using product assumptions to strike a balance between quality and speed
- Time cost of launch
1. Create a prioritization system
Any software by default is still a headache. There are bugs in it now, and over time there will only be more of them. If a team, faced with a new bug, cannot quickly determine whether it is worth fixing, then its ability to focus on the most important tasks will be undermined.
You cannot afford to convene a meeting and discuss priorities every time a new bug is discovered, so it’s best to implement a system by which you can determine which bugs to work out immediately 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 represents how serious this impact will be. The red dot indicates the bug itself.
To apply this system, together with the team, determine what severity level and percentage of users will be considered the maximum permissible (in our case, these are “users cannot make a payment” and 5%, respectively). Next, divide the field into zones and agree on what actions will be taken for each. The set of actions must include “send to backlog and do not touch”.
If you do not regret this time and effort, your team will become a real machine for fixing 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.
Often you hear stories about how awful the startup founders wrote in the early stages. Then, when the company was successful, this code was the new nightmare team programmers.
What, the founders did not know how to write code? Not excluded. But most likely at that moment they simply did not care about the quality of the code, since the likelihood that the product would be successful was extremely small. Therefore, they emphasized speed and testing ideas.
Each team will inevitably sacrifice quality 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 - which is considered key to the quality of the product.
Here is a good way to find an acceptable point on the “speed-quality” spectrum: rely on your assumptions about the product. Product assumptions are those fundamental opinions about the user problem or the proposed 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, make assumptions on how to solve the problem.
If you analyze your product, you will see that the situation with the assumptions may be as follows:
- The 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 to do and why)
If you are on the left side of the spectrum, then you have an assumption that users are faced with some problem, but you do not know how it corresponds to reality. In this case, you should cut corners to the maximum and roll out the product as quickly as possible to minimize the risk that you are solving a problem that does not exist.
On the contrary, if you are at the right end of the spectrum, that is, you are confident in the urgency of the problem and how to create the right solution, then it is worthwhile to ensure the highest possible quality - because you know that the product will be successful, which means you need a good foundation for the future.
Often companies create separate teams for experiments and for working on the “core”. It seems to me that such a structure of the organization indicates that most teams do not understand the spectrum 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 is valuable to users only after launch.
So, we must be able to determine the value of the early launch of the product for users. I have already talked about this concept in one of my previous articles .
For example: teams often face a difficult choice - is it worth it to implement the function for 80% of customers, while delaying it for the remaining 20%. Typically, this situation develops when its implementation for these 20% will require a niche functionality, the creation of which will take twice as much time (compared to what was implemented for 80%).
Let's put both options on the shelves.
Looking at the diagram, we see that in the first case, 80% of users win - 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 - do you have to choose the first option? Not really. The choice remains difficult, as:
- 20% of users who remain unreached will definitely understand that you have decided not to support them and will be furious. From their point of view, you'd better not do anything at all.
- 80% of users for whom the feature will be connected, in fact, do not feel that they have benefited from having access to it earlier.
Paradoxically, in total, these two effects give the following result: making the decision to provide users with more value over a certain period of time, we will anger more people than if we did nothing. 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 make a decision for us, the vast majority would vote for the launch.
- In the long run, if the team will consistently adhere to such a strategy, then gradually the ratio of cases when a particular user is among 80% and 20%, respectively, will equalize. As a result, the effect accumulates, and users get more value exponentially for a given period than they would get from a company that prefers to always wait until it can reach 100% of its client base.
Choosing an early launch is one of those ideas that are easy to comprehend but hard to put into practice because of the discomfort they cause. Those who know how to set priorities firmly will understand what's what and will be able to act in the interests of users.
Prioritization within the project: a tough approach is unnatural
The concepts considered are something that I have had the opportunity to verify from my own experience. There are others, and everything I have proposed can be adjusted in the process of application.
Unfortunately, most companies are reluctant to take a tough approach to prioritization, despite the fact that this is a key principle for those who create products.
For example, in large organizations, new functions are constantly rolling out; most employees will not know about this earlier than the users themselves. Do you think they will see under such conditions that their colleagues managed to spend three times less time on launch than others would have spent in their place? Unlikely. But they will notice what is missing in the final product, even if all these shortcomings were missed by the team intentionally.
Conversely, a product licked to shine inside a company is generally praised. One thing is bad: it took two years to bring it to launch. It is a pity that we do not think about how many users have turned away from us because we are desperate to wait for it.
Motivate your team is getting better - that is, tougher.
Prioritization is an art
Time is the most valuable resource that your company has at its disposal. If it is your responsibility to allocate this time, you need to develop this skill to the maximum. This is an art that can be purposefully comprehended in practice.
In conclusion, I offer you one more thesis on the topic of priorities: there is always a way to achieve your goals faster than you planned.
Is always. You just need to find it. You just need to ask the question: "How do we do this twice as fast?" at the end of the meeting - and in some miraculous way, the team will come up with a way out.
I’ve been launching products for two years and have never once encountered such a situation so that the team couldn’t figure out how to provide the user with the same value with less time. I did not come across any cases for the team to prioritize perfectly, which once again confirms the above.
If we accept that there is always a way out, then the most reasonable thing is to actively and firmly prioritize, whether the project is already working or whether you are still choosing which startup to do.
Even if your project is an entire state.