Long Backlogs and Unmeasurable Work
Hey I’m Ant and welcome to my newsletter! I write actionable posts on product, business and leadership to help you grow your product and craft.
You might have missed these recent posts::
- Building Greater Role Clarity
- The Adjacent Growth Strategy
- Asking Better User Interview QuestionsMy day job is advising companies on how to install a product-centric operating system. My evening job is helping product mangers master their craft through Product Pathways.
I was asked a while back on an interview for Whiteboards.io for my advice on keeping your backlog short.
And my answer was simple but not easy:
"Break the outcome down first, not the solution."
In case you missed it, this was the topic of my last post. But I wanted to continue on this thread and write a (kind of) 'part 2'.
From my experience, there are two common reasons why I see product backlogs become long and unmanageable:
A lack of strategy and, therefore, backlogs become a dumping ground for any and every idea.
Working big, breaking down big solutions, rather than breaking down the outcome (refer to my last post)
A Lack of Strategy
Since becoming a Product Coach, I seem to have unintentionally ended up on a crusade to demystify product strategy (it's no coincidence that I titled the Product Strategy course on Product Pathways 'Product Strategy Demystified')
To steal a quote from Richard Rumelt, author of the book Good Strategy Bad Strategy;
"Executives who complain about "execution" problems have usually confused strategy with goal setting."
I found that many of the companies, leaders, and product teams I worked with either have no strategy or confuse strategy with goal setting, and tools like OKRs.
The end result is that the poor product teams and product managers are caught in this empty space, where basically any half-decent idea is fair game and ends up on the backlog.
I've talked a lot about this topic several times in the past and how to overcome it.
But a lack of strategy makes prioritization near impossible.
To steal a quote from John Cutler because I think he said it better than I ever could;
"without a strategy, all you are left with is a ton of good ideas and no way to prioritize them."
The end result is really long backlogs and either prioritization via spreadsheets with complex formulas like WSJF, or via HiPPOs (Highest Paid Person's Opinion) and committees.
Strategy is important as it's one of the many filters you apply to either say yes or no to work.
I really like this visualization from Martin Eriksson.
Credit: Martin Eriksson, The Decision StackWhen you start to work down what Martin Eriksson calls 'The Decision Stack' you start to say no to more things.
Therefore, prioritization becomes easier because rather than trying to prioritize 100 ideas, I'm trying to prioritize a handful of objectives that align with my strategy—this is much more manageable.
The same principle is applied when you break down outcomes before solutions (as I explored in my last post).
Breaking down the outcome is a form of working down the decision stack.
The best part of working this way is that your backlog immediately becomes much smaller.
Rather than having a backlog of 100s of ideas, we have a strategy and several objectives that we believe to be the first steps to achieving our strategy, and then our backlog only contains the opportunities that align with that objective, not everything and anything we can dream up.
Measurable Work
A second magical thing starts to happen when we work this way. The work becomes immediately measurable.
By defining a strategy and objectives, we're working back from the desired outcome.
However, as mentioned in my previous post, I do often see teams being given outcomes or problem spaces that are too large and therefore, often lagging metrics.
For example, I commonly see companies give teams business goals like “generate $x Monthly Recurring Revenue (MRR).” However, depending on the team, that might not be something that they can directly affect.
This is another reason why we should be breaking down outcomes first.
Rather than trying to dream up all the 'big ideas' that you might do to increase MRR, we contextualize that business goal as a product goal - what product outcome might contribute to an increase in revenue?
For example, you may not directly influence MRR, but you can increase 'conversion' or 'retention.'
The hypothesis being, that if you increased the conversion rate we would have more successful signups = more $$. Or alternatively, increasing retention would lead to less churn and therefore increasing MRR too.
Some might call these opportunities, but I still see them as the outcome (and to be honest, the semantics of terminology don't matter as much as applying the principle to how we work).
Another way to frame this would be that they have the same objective but are broken down.
If you're a fan of the North Star framework or are familiar with the notion of 'Input and Output Metrics,' you would call 'increase MRR' an output metric and the rest inputs.
Regardless of what you call it, the idea is to break it down and make it meaningful to you.
Here's another mental model that I use to explain this to my clients:
You can think about these as 3 'buckets' of outcomes:
Business,
Product,
and, User
Business <- Product <- User OutcomesThe business outcome is to generate more revenue (not a great one, but keeping it simple for illustrative purposes)
The product outcome might be to increase retention.
The user outcome might be to "improve the experience of X."
There is then a hypothesis that binds them all together.
We then believe that if we can "make the experience of X better" (user outcome), it will reduce churn (product outcome), which will eventually translate into more revenue (business outcome).
Now, if you are doing a good job at breaking down outcomes, it's not as clean as 3 layers.
Within each bucket, there might be multiple layers.
For example, a product outcome like 'adoption' might break down to improving 'click-through rate' (CTR), etc. Then, underneath that, your user outcome might be to 'improve the experience of X,' which should help with CTR.
Your problem might then be that the page is confusing, leading to a poor experience and drop-off. We can then frame the problem as an opportunity, which might be something like "Make the value proposition on page Y clearer..."
Breaking down the outcome means that our work is immediately measurable.
Those who don't do this are stuck in a void of minimal feedback. Waiting for that lagging metric to shift - which can take some time!
You know you're in this trap when you always seem to be “just one more feature” away from a tidal wave of customers and revenue… if that's you, time to break down the outcome, find a leading indicator and get some feedback!
This is why I'm a strong advocate for building out KPI trees like this (or frameworks like the North Star Framework, where we map out input and output metrics).
By breaking things down, we end up working much smaller and faster feedback cycles - win-win!
Breaking down outcomes can also help you identify and focus on improving leading metrics, giving you early feedback.Conclusion
Ok, two posts to labor the point.
But I felt it necessary to add a bit more narrative around my last post.
I know I'm biased because of the types of organizations I spend the majority of my time with, but I see too many product teams jump straight into solutions and forget to break the problem or outcome down first—I don't want any of you to make the same mistake!
You can think about what we're trying to do as:
define a small problem (within a larger problem/goal/outcome)
try something
measure the impact of that something - did it solve that smaller problem or not?
If it did, did it also influence the bigger outcome that we’re chasing?
If yes, by how much? (If you get lucky and achieve your bigger goal too, then happy days! Move on to the next big thing.)
If not, let’s move on to the next smaller problem/opportunity - and repeat until we've achieved out larger goal.
Of course, this is basically the whole notion of Build-Measure-Learn cycles, but as you hopefully can see, it's more nuanced once we start to get into it.
Need help with scaling your product or business? I can help in 4 ways::
Level up your craft with self-paced deep dive courses, FREE events and videos on YouTube, templates, and guides on Product Pathways.
1:1 Coaching/Mentoring: I help product people and founders overcome challenges through 1-hour virtual sessions.
Consulting and Advisory: I help companies drive better results by building effective product practices.
Private Workshops and Training: I run practical workshops and training courses for product teams globally.
Top Posts
A common pattern I see in many of the product teams and companies I coach is that they’re doing a lot of incremental work but little-to-no iterations.
They have this big idea (often framed as an initiative) and become solely focused on breaking it down. The initiative becomes a series of epics, and that epic becomes a series of user stories, and so forth.