Getting Agreement on Priorities
The First Law of Priorities: Raising the level of one priority requires lowering the level of one or more other priorities. Otherwise, it requires changing the schedule, adding new resources, or compromising quality.
This law is often very unpopular. Many managers would love to repeal it.
Here's a typical scenario: The Product Manager has identified "installation user experience" as the number one priority for the next sprint. Meanwhile, Sales meets with a top customer who says he "must have" a new printing feature "immediately." Management decides that this should be added to the top priority list for the release.
Obviously, something has to give. Extend the schedule? Add people for design, programming and QA? Or jam it into the existing schedule, using existing resources, and overlook the fact that quality will inevitably suffer?
Unfortunately, the last choice is often the road that's taken. Why? Well, sometimes it's hard to say no. When management says, "just ask people to work a little harder for this one sprint, and spend a little less time on the installation work," they sometimes fail to see that the original schedule was developed carefully. PMs and engineering managers usually want to be "can do" players, and agree to changes even though they know that it places the project at risk.
In this situation, the product manager has a very important responsibility. Setting priorities is all about weighing options, and no one can weigh options effectively without adequate information. The PM is in the best position to gather information from engineering, marketing, sales and management. To this, the PM can add data about customers and the market. It's then up to the PM to clearly explain the benefits and costs of each option, in a way that can be understood by all parties.
This role is crucial because, simply, there is no one else in a position to serve as a "clearinghouse" - someone who is responsible for digesting all the relevant information and making sure that everyone understands it.
For example, the installation feature may have been based on information from Product Support and a user experience designer, and the costs are based on estimates by engineering and QA. Management may only see that it's an item on a product roadmap, and not understand the urgency and opportunity involved. It's up to the PM to explain exactly why the work is important, and the consequences of not doing it. At the same time, the PM needs to understand the customer request that Sales has raised, and explain the costs and benefits of addressing it immediately, later, or not at all.
Decisions often come down to "bang for the buck." Sometimes this is an easy calculation…if the PM has defined what constitutes "bang" and has assembled data about how many "bucks" it's going to take to achieve the bang.
To get it right, each feature must be weighed in terms of:
- Effect on customers: target customers, key accounts, etc.
- Resource requirements (including impact on other features/projects)
- Opportunity cost: what won't be done if this is done?)
- Time to completion
- Quality concerns: will this or other features be compromised?
- Product support impact
- Impact on marketing and sales plans, training, launches, etc.
- Effects on partners, suppliers, and/or manufacturing
- Effect on other products
- Impact on product roadmap and strategy
- Revenue impact
Those are a lot of factors to consider. Yet every decision to add a feature or raise a priority may have an impact in each of these areas. By ignoring them when decisions are made, the likelihood increases that there will be an unforeseen consequence of the decision. A PM has to be emphatic about one fact: Not everything can be the top priority. Sure, a team can do several things at once, but not everything at once.
Prioritization is an art: if you have 20 feature projects under consideration, picking the top five most "urgent" features may not make sense. It may be more valuable to combine a group of related features into a "feature set" that, taken together, provides more of a benefit to a customer. The person best equipped to define useful feature sets is usually the one who knows the customer best - the product manager. To succeed in prioritization by feature aggregation, the PM must articulate yet another set of costs and benefits, explaining the benefits of feature synergy and the costs of not combining features into logical sets.
The First Law of Priorities can be deadly if overlooked, or it can provide the key to building a product roadmap that's based on consensus and actually works. Ignore it at your own risk.
This law is often very unpopular. Many managers would love to repeal it.
Here's a typical scenario: The Product Manager has identified "installation user experience" as the number one priority for the next sprint. Meanwhile, Sales meets with a top customer who says he "must have" a new printing feature "immediately." Management decides that this should be added to the top priority list for the release.
Obviously, something has to give. Extend the schedule? Add people for design, programming and QA? Or jam it into the existing schedule, using existing resources, and overlook the fact that quality will inevitably suffer?
Unfortunately, the last choice is often the road that's taken. Why? Well, sometimes it's hard to say no. When management says, "just ask people to work a little harder for this one sprint, and spend a little less time on the installation work," they sometimes fail to see that the original schedule was developed carefully. PMs and engineering managers usually want to be "can do" players, and agree to changes even though they know that it places the project at risk.
In this situation, the product manager has a very important responsibility. Setting priorities is all about weighing options, and no one can weigh options effectively without adequate information. The PM is in the best position to gather information from engineering, marketing, sales and management. To this, the PM can add data about customers and the market. It's then up to the PM to clearly explain the benefits and costs of each option, in a way that can be understood by all parties.
This role is crucial because, simply, there is no one else in a position to serve as a "clearinghouse" - someone who is responsible for digesting all the relevant information and making sure that everyone understands it.
For example, the installation feature may have been based on information from Product Support and a user experience designer, and the costs are based on estimates by engineering and QA. Management may only see that it's an item on a product roadmap, and not understand the urgency and opportunity involved. It's up to the PM to explain exactly why the work is important, and the consequences of not doing it. At the same time, the PM needs to understand the customer request that Sales has raised, and explain the costs and benefits of addressing it immediately, later, or not at all.
Decisions often come down to "bang for the buck." Sometimes this is an easy calculation…if the PM has defined what constitutes "bang" and has assembled data about how many "bucks" it's going to take to achieve the bang.
To get it right, each feature must be weighed in terms of:
- Effect on customers: target customers, key accounts, etc.
- Resource requirements (including impact on other features/projects)
- Opportunity cost: what won't be done if this is done?)
- Time to completion
- Quality concerns: will this or other features be compromised?
- Product support impact
- Impact on marketing and sales plans, training, launches, etc.
- Effects on partners, suppliers, and/or manufacturing
- Effect on other products
- Impact on product roadmap and strategy
- Revenue impact
Those are a lot of factors to consider. Yet every decision to add a feature or raise a priority may have an impact in each of these areas. By ignoring them when decisions are made, the likelihood increases that there will be an unforeseen consequence of the decision. A PM has to be emphatic about one fact: Not everything can be the top priority. Sure, a team can do several things at once, but not everything at once.
Prioritization is an art: if you have 20 feature projects under consideration, picking the top five most "urgent" features may not make sense. It may be more valuable to combine a group of related features into a "feature set" that, taken together, provides more of a benefit to a customer. The person best equipped to define useful feature sets is usually the one who knows the customer best - the product manager. To succeed in prioritization by feature aggregation, the PM must articulate yet another set of costs and benefits, explaining the benefits of feature synergy and the costs of not combining features into logical sets.
The First Law of Priorities can be deadly if overlooked, or it can provide the key to building a product roadmap that's based on consensus and actually works. Ignore it at your own risk.