It’s the nature of Product Dev to be weighed down with urgent requests, nice-to-haves, absurd asks, and bugs to fix – in addition to their regular workload. So, in many ways, the ability to prioritize correctly is the engine that runs a functional department. That’s where Bea comes in.
“Prioritization is the art of saying no. Essentially, it’s the execution of the strategy,” says Beata Kovacs (Bea for short), a London-based trainer who works with product managers and their teams to make better decisions for faster work, higher efficiency, and maximum value to customers.
In other words, she teaches them how and when to say “no.”
That’s not all she does – she’s also a deft guide through decision-making, confusing dev situations, efficiency traps, and finding the process that will get you to the right answer.
First step to effective prioritization: Build a shared understanding
She begins by establishing this foundation.
“Many product teams struggle when it comes to prioritization. This simple-sounding activity is often turned into a battlefield, where stakeholders and product teams fight over decisions, authority and countless strategic questions. There are assumptions, HIPPOs and strong emotions in the room and it takes one hell of an effort to stay constructive and move things forward. The key is to create the most important artefacts that will enable constructive discussions instead of heated arguments.
These artefacts are: a shared understanding of how a product team (and business) differentiates between assumptions and facts, and a shared understanding of how validation will work and what confidence level we need to get in order to move a step forward. The aim is to enable everyone in the room to make good decisions. Decisions that are informed, validated and (as much as possible) bias-free. And the only way to make them is to make sure that everyone understands the reasons behind the ‘why, what, how, when’.
The main goal should be to extend these questions beyond the roadmap and feature ideas. If done correctly, it enables a holistic view where commercial, technical and user values are highlighted. In addition, prioritization should also focus on highlighting risks, as any potential risk should have a huge impact on the final decisions made.
There’s no silver bullet that fits every company in every situation. Creating a list of things to do is easy. Understanding if they are the right things do is complex, and starts with proper product discovery.”
Bea establishes a shared mindset and a process from the very beginning, during Product Discovery. This first phase refers to the activities required to determine if and why a product should be developed. She says the big question to ask is: Are you asking the right question?
“Our way of thinking breaks down product discovery into different stages, starting with problem discovery: ‘Is this a real problem or a symptom of an underlying (systematic / deeper) problem?’
Customer and prospect interviews are a great way to understand problems in the users’ context: current behavior, user expectations and their goals by using our product.
Get the ebook, CX FOR EVERY STAGE: How to scale your Voice of Customer program from startup to enterprise. Learn how to obtain the right feedback and understand customer desires and expectations.
Once a pattern emerges, we move on to solution discovery, where the same process could be used to test solution proposals.
No matter what type of research data you have, you can always find ways to use it to generate more assumptions and validate them; the key is to make sure that the right questions are asked based on the stage where we are.
With this approach, differentiating between symptoms and real problems, new ideas can come from engineering, the business, customers or even from marketing, and by using various tools that are relevant for this type of discovery and prioritization, teams will be able to maximise impact, rather than focusing on improving standalone metrics, such as ticket resolution or NPS scores.
There are three methods I’ve found highly useful for these problems:
1. The value proposition canvas to identify the underlying customer and user problems.
2. The strategy canvas to identify strategic values and directions in a bigger context.
3. The Kano model to prioritise standalone features or ideas based on their perceived value and impact.”
Decision-making when it’s not clear cut
Prioritization is the million-dollar question: How do you decide which task yields more value, both to the customer and for the company?
“The best way to address these type of questions is to engage stakeholders and first try to understand the business strategy. A product strategy without the alignment with the business strategy can deliver value, but the impact will get hurt whenever there’s a misalignment between these two high level directions.
Once that foundation is in place, a good way of thinking about the problem is to use the mentioned tools (value proposition canvas, strategy canvas, Kano model) to understand the bigger context, and make informed decisions based on all aspects that are important to the company.
Every decision that is made in a contextual vacuum will only drive partial value.
The first step is to look on the 3 main areas that are the foundations of product management: UX, tech and business. Then identify the values that can potentially be created for these areas.
Additionally, you also need to understand how important they are in light of the current goals and stage of the company. As an example, if you are in the growth phase, increasing your TAM (total addressable market) with appealing new features might be more important than to replace legacy technology (if it doesn’t cause immediate churn).
By collecting this information and finding a way to create a framework where you are able to compare these values will make these decisions a lot easier and potentially less risky.”
Dev efficiency traps
When the data conflicts
“Don’t be afraid of repeating steps in the process if new data and patterns seem to conflict with earlier findings. The key is not to overdo, but to find the sweet spot, where data is enough to move forward, but does not block the process with too much time spent on each step. The ‘Ship fast – learn fast’ methodology is an amazing approach, where shipping can also refer to ‘ship and validate assumptions,’ not only a MVP of the solution.”
When you can’t see the forest for the tickets
“Many times I’ve seen product teams working on established products struggling to work through their ‘bugs’ and various other tickets generated by customers and internal stakeholders; and the only metric they’re paying attention to was the number of resolved tickets.
However, every time I’ve asked these teams to take a step back, and try to think about these issues in a different way, we were able to come up with new – sometimes highly innovative – solutions that would solve pain points, but also add a tremendous amount of additional value simply by trying to address not only the obvious, but other aspects as well.
Rather than thinking about a resolution ‘inside the box,’ by taking a step backwards, trying to see the underlying problem and identify the goals and jobs-to-be-done in a bigger context, we change the thought process to suggest other solutions that might live outside the box, solve the same pain, but also address other problems.”
On prioritizing requests
“I have two favorite questions to ask myself when I’m building any priority: ‘Why now?’ and ‘Why not now?’ The second one is more important than the first one. It’s easy to find reasons to jump on an idea immediately, but when a team can come up with the ‘not’ reasons, a completely different universe opens up and the quality of decisions immediately starts to rise.”
On handling requests from the higher-ups
“Treat these decisions as any other product decisions: take them as assumptions and figure out a way to easily validate with stakeholders.
There are two main benefits of this approach:
1. It will push the team to be able to articulate these values in a contextual way, that will strengthen the shared understanding and help identify additional risks
2. It can be used to identify key stakeholders and by engaging them early in the process the chance of getting their buy-in increases dramatically”
On the main reason for half-baked features, zombie products, and disengaged teams
“A lot of companies and product teams fall into this trap, thinking that if there’s an established process for prioritization most of the job is done. What they don’t see is that if prioritization only happens every 3 months, 1 month, there’s a huge chance they’re actually following a waterfall process rather than agile.
They are making decisions on a regular cadence that won’t be challenged until the next time they meet. What this effectively means is that they are working towards a perceived value, and until the next prioritization meeting they won’t be able to change the course, even if they find information that changes the context of the original decisions that were made.
This approach is the main reason for half-baked features, never released zombie products, and disengaged product teams. “
Prioritization happens on many levels, multiple times a day.
“The key to escape this trap is to change how we think about prioritization and instead of struggling to get decisions and answers, we create a framework that can be applied on all levels, to any priority-related question. This framework – if executed properly – will help not only the product team, but the wider organization as well.
A great starting point is to start working with OKRs, to establish the wide understanding of the shared goals. As a flexible system, OKRs can be used and aligned on many levels, such as cadence of releases or to fit a complex organisational structure. The trick is to get them right – which is a more difficult task that some would think (here’s a really insightful review of a recent OKR-book: Measure What Matters by John Doerr).
The reason why creating the framework is more important than actual decisions made by anyone is that prioritization actually happens every day, on different levels, done by different people. It is in the DNA of software development – especially agile practices – and the foundation of value creation.”
From Bea Kovacs’s insights, prioritization seems to morph from the ‘art of saying no’ into the science of alignment. Aligning teams and entire companies behind common goals, using common metrics and a shared understanding of what’s important, and why it’s most important now. Because priorities change, as businesses change. What you need is a system to navigate through those shifting waters.
Connect with Bea on Twitter.