You need to evaluate an effective roadmapping tool to help you stay on track. But how do you know which one will support your specific More →…
The Pareto Principle, commonly referred to as the 80/20 rule, states that 80% of the effect comes from 20% of causes. Or, in terms of work and time management, 20% of your efforts will account for 80% of your results. In this article, we will discuss how agile product managers can use and benefit from the 80/20 rule.
First, let’s review the origin of this principle and how it plays out in many areas of life.
Examples of the 80/20 Rule for Agile Product Managers
Engineer and management consultant Joseph Juran coined the term “Pareto Principle” in the early 1940s after discovering the work of economist Vilfredo Pareto. Pareto pointed out decades earlier that 80% of the land in Italy was owned by 20% of the population.
Juran developed the Pareto Principle as a mathematical tool to identify solutions to quality-control issues. He noted, for example, that 80% of quality failures result from just 20% of the tasks. Juran later described this principle as “the vital few and the useful many.” He suggested that managers look for the vital 20% of activities, personnel, opportunities, and problems—and focus an outsize amount of effort on them.
Consultants, economists, business leaders, and time-management experts continue to find more examples of the 80/20 rule in many areas of life. For example:
- 80% of sales come from 20% of customers
- 20% of your product experience will lead to 80% of all support cases
- 80% of all crimes are committed by just 20% of criminals
- 20% of the tasks on your to-do list will generate 80% of the benefit from the entire list
- 80% of all stress comes from only 20% of all types of stressors
Applying the 80/20 Rule to Agile Product Management
As any experienced product manager will tell you, not all tasks and projects generate the same degree of benefits. Some projects can consume a lot of your cross-functional team’s time, and yet barely make any difference in your product’s conversion rates, revenue, or net promoter score. Other initiatives can take less time and effort and still add significant numbers to your bottom line.
Product teams must regularly choose how to spend their organization’s time and resources. This decision process is why agile product managers have adopted so many prioritization frameworks. They need proven systems to help them determine the most strategically useful ways to spend their team’s limited time.
1. Breaking out your long-term vs. short-term focus
As Matt Smith of Shutterstock explains, agile product managers should focus on long-term product strategy.
It focuses your development team on the short-term sprints. But you should spend the majority of your time and attention thinking about and planning for the long term. That breakout should be roughly: 80% of your time on long-term strategic preparation and 20% on the tactical and logistical details.
2. Prioritizing the most strategically valuable projects
Another way agile product managers can apply the 80/20 rule is by following the advice from the rule’s founder, Joseph Juran. Find those “vital” 20% of projects on your to-do list and give them 80% of your team’s time.
As you evaluate your backlog, look for those initiatives that promise the most significant strategic advantage. These could be new features, new products altogether, or projects that will help you bring your product’s code up to date and help your team settle some technical debt. The most strategically important project could even be fixing an area of the product that is causing an outsize number of customer questions or complaints. This problem area could, after all, be hurting your reputation in the market and lowering your net promoter score.
Now take those projects you’ve identified as having the highest strategic importance. Then, assign them estimated timeframes for your cross-functional team. Make these estimates both in terms of overall time to complete (two months, three sprints, etc.), and in terms of total person-hours.
Finally, estimate your team’s total available time during this period. You can now determine how many of these strategically important projects your organization can take on in 80% of its time. You’ll be left with 20% of uncommitted capacity to set aside for more tactical tasks. These tasks can include attending meetings or being available to take on an urgent project that pops up without warning.
3. Zeroing in on your most valuable customers
One interesting aspect of the 80/20 rule is that it tends to keep following the same pattern as you drill down into the details. For example, let’s say you review your books and discover that 20% of your customers account for 80% of your company’s profit. You can perform the same exercise again. You’ll often find that 20% of the remaining high-profit customers still account for 80% of your profit from that subset of your customers.
With this in mind, agile product managers can also use the 80/20 rule to zero in on their most important customers. How you determine what “important” is will depend on your goals.
If your product is new, these might be the users doing the most social-media posting or otherwise sharing their experiences with your product. Whereas if your product is more well-established, the most important customers might be those who buy your product in the greatest numbers.
You can use this principle to identify this all-important 20% of your customer base. Then, spend a more considerable amount of time (say, 80%) cultivating those relationships. Make exclusive offers available just to them. You can invite them to your customer advisory board. Maybe prioritize their requests for features or customization. Show them some love.
Use the 80/20 Rule to Your Advantage
As scientists and business leaders continue to learn, the 80/20 rule shows up everywhere. It can be an extremely valuable tool in all aspects of our lives. For instance, it saves time while helping us guide our efforts to the most productive or useful tasks. If you’re an agile product manager, this principle is particularly useful. It can serve as a regular check against getting lost in a time-consuming but low-value project.