I once was a witness to a very talented Product Owner being rejected a job because they didn’t know all the names of prioritization frameworks.
What?
Why?!
Who cares.
When they were asked to name some, the job seeker went straight to explaining their prioritization approaches in a logical and deliberate way. They mentioned RICE and MoSCoW, but it was obvious that they were more interested in doing it the right way for the particular company and the particular product in the specific moment of time and market condition rather than remembering the names.
They had the right vision. But they didn’t get the job. It was a big mistake on the hiring manager’s part. Over the course of the next few months, I observed how their preferred hire, who had better memories for names, consistently failed to have the product vision and chose prioritization approaches that cost the company delays and rework.
Because knowing all the names is a memory skill. Knowing the frameworks is a technical skill. Knowing when, why, and how to prioritize is a product management skill.
Anyone can make prioritization mistakes. But is it enough to avoid them?
Mistakes Them Makes
After analyzing a few solid articles about prioritization mistakes, I have selected the top 7 that are mentioned more often and seem to cause the biggest pains:
- Prioritizing Features Instead of Problems
- Chasing Competitors Instead of Following Your Strategy
- Giving in to the Loudest Stakeholders
- Prioritizing Easy Wins Over Important Work
- Trusting Gut Feelings Instead of Evidence
- Treating Prioritization Frameworks as a Substitute for Strategy
- Failing to Revisit Priorities as Conditions Change
All are absolutely real and all can create serious problems. But these are sort of lower-level mistakes that we can mitigate with varying degrees of success (unless your Gut is really, really loud).
There are significantly more impactful strategic mistakes teams consistently make in the area of prioritization that can actually be detrimental to your product viability.
And the very first one is to find answers in the methodology. As if there is a “correct” way for you to prioritize and if you follow it to a tee, you will be OK.
Unfortunately, it doesn’t exactly work this way. None of the existing prioritization methodologies can fix the bigger underlying issue. That’s why I thought it was important to share my thoughts on…
The Biggest Prioritization Mistake You Can Make
That sounds pretty obnoxious. Like I know all the answers.
Meh. I don’t. But I know one trick that works always. All the time. Regardless of what you prioritize.
It’s a Dimensional Strategic Vision.
Prioritization is not an art of creating a queue. It’s an art of Strategy, Architecture and… Collaboration.
Let me explain.
Why Is Prioritization a Strategic Decision?
Here is the problem that teams live like they go to work, without even knowing it. They think that prioritization is just about building a big queue. They apply their selected framework only to find out that they ended up delivering a product that lost relevance before it even reached QA.
Effective prioritization is not about queueing. It’s not even about tiered queuing.
It’s more about dimensional strategic granular queueing.
Here’s how the product is usually constructed (aaah! we are moving to the architectural part)!
Capability (Group of related features)
→ Feature – Group of interconnected functionalities that allow accomplishing a specific group of goals
→ Functionality – A set of processes that support each other where some of the processes could be imperative for the MVP, and some – complementary. Individual functionalities may be related but should be independent enough so turning off one functionality will not break the whole product.
→ Process/Workflow (user process, action/operation) – The lowest level of the product hierarchy, representing the individual flows or actions through which users accomplish a specific task.
I always give Microsoft Office as an example.
Microsoft Office is a Capability Portfolio.
MS Word is a Capability – a document processing tool.
Editing Text is a Feature.
Editing font case is a Functionality.
Changing font case from Title case to sentence case is an action/operation.
Your taxonomy may vary. Your architecture may have more or fewer layers depending on the product, but without understanding this structure and maintaining it in the prioritization approach is an issue. Not only because it’s just much easier to prioritize on each level and then reprioritize on the next, but also each level of prioritization should consider its own strategic data.
OK, let’s assume you are using one of the most progressive SAFe-specific methods, WSJF (tasks with the highest economic value are prioritized first).
I hope you don’t assume that your development team is supposed to know which functionalities bring the highest economic value? And even if they have a Product Manager on the team and they already have the numbers, market needs are usually represented in numbers that are mostly applicable to capabilities and features. How are we even sure we are working with the right feature?
That’s why your Strategic approach to prioritization should start with the Architecture of your product and/or product ecosystem. This architecture will give you a very clear picture of what level to test against the market needs. This way you ensure your roadmaps support your feature like a layered cake. And you test demand of each level individually, starting with the Capability, then following with Features, Functionalities and Processes.
Then you prioritize winners. Then you prioritize winners within winners. First, determine which capabilities deserve investment. Within those, determine which features matter most or should be delivered first. Within those features, determine which functionality creates the necessary value. Only then move to individual processes.
And you do it consistently to ensure relevance. And each level may need a slightly different approach to prioritization. And each queue may change based on your updated findings, and the development backlog may just change completely if you have to push back a feature that is currently in development to honor the one that was lower on the list but is getting super hot by the day.
And here’s another important part: the same people should not necessarily be making prioritization decisions at every level.
SAFe recognizes this through its layered approach to product development. Strategic investment decisions happen at the portfolio level, capabilities are addressed at the solution level where that layer exists, features move closer to Product Management, and detailed delivery decisions move closer to Product Owners and delivery teams.
And that’s why your prioritization is not just about Strategy and Architecture. It’s also about Collaboration. Because all of the levels of influence that operate on specific levels of your product architecture need to stay in tune with your strategy. Because if you – legitimately – stop development of a feature that’s dead in favor of something that is on, the development team will not like it if they don’t understand why.
And if you do this pivoting often, they will become less and less engaged and be less and less of your partner. And that means weaker morale and lower quality of work. In the end, people are your best asset. And you need to make sure they like (if not love) brining your vision to life.
That’s why it’s maybe one of the most important parts of effective prioritization – to be transparent about the strategy with designers, developers, technical writers and testers – people who are actually building your success. Literally.
Granted, pivoting just because you think something will work better is not what I am talking about. I specifically mentioned “testing” above. All prioritization decisions should be grounded in data. You don’t need to do extensive market research all year round.
Here is a simple path to make sure you stay relevant and have enough assurance in taking the best path you can take at any particular moment and still be light enough to keep you from spending tons of time and money on endless studies and never deliver anything.
- Have the layered Capability – Feature – Functional roadmaps.
- Prioritize each level. Reprioritize within each group. Keep it consistent.
- Observe the market and do smaller targeted studies that affect your immediate roadmap. Start with the higher-level Item Group. If changes are observed, rethink strategy.
- Identify the point of no return for in-flight work. For each effort, identify the point in the delivery cycle where the delivered work will still provide value if shipped, outweighing the cost (in time and labor) of it being delayed or dropped.
- Ensure your delivery team knows your strategy exactly and understands where your vision is.
- And then use your prioritization framework of choice when you know exactly what you are prioritizing and why.
I could also add that since you will be so transparent with your developers, it’s a very good practice to periodically ask them about your product and what they think about it and its roadmap. You may be surprised by the gold your team may give you in ideas.
Or, in other words…
Don’t solve an operational problem. See your product as a whole, and your delivery team as your biggest ally. The only way to build a great product is – together.
I wish more leaders remembered that.
