Delivering “the right” 80/20

What goes into shipping more value and less fluff

If you’re a product manager, you’re probably grooming the backlog and prioritizing ruthlessly in order to deliver the best possible results. But chances are, with each passing release, you may not feel like you’re delivering as much value as you and your stakeholders would like. You’re not alone.

Your success as a software product manager has a lot to do with your ability to maximize the value delivered over time. Ultimately that means limiting the scope. More importantly, it means choosing the right scope. This is where we aim to apply the 80/20 rule.

The 80/20 rule, also known as the Pareto Principle, is a management principle that states 80% of the value of your output, results and achievements come from 20% of your combined efforts (time, resources, money). Within product management, the 80/20 rule means that you’re delivering 80% of the value of a feature to the customer with 20% of the effort, or in 20% of the time.

In reality, delivering 80/20 is easier said than done. The success of the delivery depends on a sustained and deliberate focus on defining the right problems, shifting team culture and managing stakeholder expectations.

Let’s start by getting into the weeds of defining the right user problems using this 80/20 approach.

80/20 Problem Definition

In my experience, one of the biggest differences between the average and top tier product managers is their ability to define and break down problems, not solutions. There are two main pitfalls that plague product managers:

• They don’t spend enough time defining the problem
• They break down the solution instead of the problem without realizing it

Avoiding these two pitfalls allows product managers to focus on what’s really important.

Let’s say we were to add a new commenting function to Roadmunk at the roadmap level. I should mention that Roadmunk has a commenting feature on roadmap items, but let’s say we didn’t have one already and we were approaching the problem from scratch.

When asked to define the epic for this commenting feature, some PMs might write: “users want to comment on the roadmap.” That would be restating the solution as a lazy problem statement. Saying “the user wants to have a discussion about the roadmap” is better but it’s not granular enough to effectively inform trade-off decisions.

These definitions don’t actually help us break down and prioritize the work. If we stop there, we end up scoping out “commenting” and then breaking down the work into stories and sprints that don’t address the real problem.

We can take that better (but still lazy) problem statement (“the user wants to have a discussion about the roadmap”) and break down the user stories like this:

• Leave a comment on a roadmap item
• Respond to a comment on a roadmap item
• Leave a comment on a roadmap
• Respond to a comment on a roadmap
• Surface comments in notifications
• @ mention users in a comment
• E-mail users about unseen comments

You might say: “It’ll be most efficient dev-wise to sequence them in this order and once I get through the first four I’d consider that potentially shippable. Great, we’ll stop there because that fulfills the 80/20 rule.”

Right?

Wrong! (possibly)

Why? Because it might not fully solve the problem. Customers don’t care about development efficiency or that they got half of a feature early. They’ll never use the feature if they can only complete half of their workflow.

The key lies in breaking down the problem, not the solution. Here are a couple of problem statements that come to mind instead. I should mention that these are just two out of many other possibilities:

• Stakeholders need to ask questions about the roadmap
• Multiple owners/collaborators need to negotiate priorities & resourcing

Now let’s say we determine that the first one, “stakeholders need to ask questions about the roadmap”, is the most impactful priority for our customers. The right 80/20 decision here would be to focus only on solving that specific problem (while giving the engineering team the vision for the end solution so they can make good architectural decisions).

An example of an 80/20 solution to address that priority could be:

• Leave a comment at the roadmap level
• Notify all roadmap owners and collaborators of any new roadmap comments
• @ mention other users

This breakdown allows stakeholders to ask questions about the roadmap and allows roadmap owners to respond to those questions. We’ve only chosen to implement a fraction of the scope but we’ve solved a whole problem end-to-end. Could the solution be more feature-rich? Yes, but now there’s an opportunity to iterate on this solution with customers in the loop or to stop here and move on.

Arriving at this 80/20 problem definition requires a lot of effort and thoughtfulness from everyone in the product team. But at the very core, it’s about maintaining a deep sense of empathy for what users are actually trying to achieve with any given feature.

By always breaking down problems and not the solutions, product teams can feel confident in knowing that their user base will always be happy with what they deliver.

Main takeaways

• Always break down problems, not solutions. Doing this eliminates the chance of writing lazy problem definitions that don’t actually break down and prioritize the right solutions
• Shift away from breaking down the work into stories and sprints that are missing the mark in terms of addressing the real problem faced by users
• Limit the team’s scope to include only user stories that address the core problem. Customers would rather have a complete 80/20 solution to their problem, which they can use, rather than half of a feature delivered early

Getting your team to speak in “problems” is easy on paper, but implementing this — and making sure everyone understands it — may require a new level of commitment from the whole team, especially within your development team. I get into the concept of an 80/20 team culture in the second part to this post which you can read here.