Product Management means being guided by strategy, not prioritization algorithms
Reclaiming the essence of Product vs. Project Management
I was coaching a new Product Manager with deep domain experience, and our backs were up against the wall.
We hadn’t shipped code for months. Many of us were stuck in so many status meetings about why we weren’t delivering, that we had no time to do the work of discovery and delivery. Finally, I facilitated a session on collaboratively stepping through the key moments in the user journey, a process called “User Story Mapping.”
This allowed us to strip our product down to a focused set of clear choices. In 60 days, we were able to go from a set of Post-Its in a conference room to working software in a retail location, something the organization has never accomplished before or since.
This was followed by successive waves of product releases, culminating in a full national rollout across our entire retail footprint.
Throughout, we iterated based on user feedback.
Client-centric + Simple = Success
We definitely didn’t start with the best product, but by staying close to our user’s needs and making continuous small improvements, we rapidly vaulted from second-tier status in the portfolio to becoming the “hot” product other leaders across the organization wanted to use to promote their products.
We soon became overwhelmed with countless requests, even many that seemed contradictory to our strategy.
With limited engineering capacity and time, and a complicated political landscape to navigate, how would we pick the right feature to add next?
From quarterly problem-solving…
From our first release, our decision-making was straightforward.
I coached the team to run dual-track Continuous Discovery and Delivery, iterating over a problem-based roadmap focusing each quarter’s work on overcoming a specific problem. We also laid out areas of tech debt, UX debt, and technical architecture we needed to get ahead of for the following quarter’s problem.
But as soon as rank came into play, decision-making became increasingly harder.
To playing prioritization “roulette”
Stakeholders across the organization now had a newfound interest in our product.
They descended on the team from all sides, each with their own feature request they wanted to shoehorn into our product. In order to establish some form of objective ranking we turned to the RICE prioritization framework.
We hoped this would show our stakeholders how we prioritized different feature requests, giving objective clarity and fairness to the thought process behind which we picked to deliver first.
The only thing that gets prioritized is feature bloat
But while we were busy prioritizing the full range of feature requests, we didn’t realize until it was too late that our product had started changing in ways we never intended.
Over-engineered, highly-touted features our users had to be trained in never got used. Worse, much-needed features addressing real customer pain points were never addressed.
And still, we continued stuffing more and more features into our product in an attempt to satisfy every stakeholder’s insatiable demand. Over time, with increasing technical and UX debt, the product collapsed under the sheer weight of features.
Leadership eventually pulled the plug on our product, opting to replace it with a stripped-down version rebuilt from scratch.
What really happened?
We had started strong by stripping down to a clear set of user-focused strategic choices.
Early on, we were fortunate to be both autonomous, and empowered given that we owned our own tech stack, and had been largely dismissed by the rest of the organization.
We simply weren’t prepared to manage the sheer flood of feature requests. This forced us to say “yes” to everyone, and try to use prioritization to pick what to build first.
In retrospect, it was clear that as soon as we started playing the losing game of prioritizing feature requests, we were asking the wrong question.
How should Prioritization Frameworks work?
Ideally, they would help lay out the different merits of different solutions, ranking them across different parameters.
Intercom’s RICE framework, for example, proposes Product Managers evaluate new requests across the four dimensions of:
- Reach — How many people will be affected?
- Impact — How much of an impact will this have towards the goal?
- Confidence — How confident are we in our overall estimate, supported by data?
- Effort — How much time and effort will it take to get this feature out the door?
These numbers are input into the following formula to get the “one” number:
The logic behind this formula is that Product Managers armed with the result would have a foundation for richer backlog ranking conversations with stakeholders.
Weaponizing priority
But I’ve found the evidence generated is more often used to shut down conversations.
From the Product Manager’s side, they can hold up the number spit out by the prioritization framework’s algorithm as “proof” they’ve done their “due diligence” and made the right choice.
In certain environments, any data the PM shows up with gets countered by a “HiPPO” (“Highest-Paid Person’s Opinion”), the stakeholder who dismisses their fancy score and insists the PM build what they’re told.
The one reason why prioritization frameworks will never work
The fact remains that prioritization frameworks are a daily reality for many Product Managers.
Some popular product thought leaders celebrate this by publishing articles promising the “largest roundup of popular prioritization frameworks.” It’s telling these posts tend to go viral, speaking to the widespread need for the certainty these frameworks promise.
My contrarian take is I feel they’re all fundamentally flawed, because Product Managers using spreadsheet-based prioritization frameworks to figure out which feature to build are solving the wrong problem.
Worse, they’ll never address what needs to be handled, resulting in bad product management, bad products, and poor client experiences.
Why?
It’s time to accept all prioritization frameworks are just band-aids covering up a deeper problem of a lack of strategic clarity.
Because whenever product managers are reduced to prioritizing features using prioritization frameworks, it’s a clear sign there’s a strategy gap at the top.
What’s the Product Manager’s role?
This is doubly hard when the Product Manager has all the accountability for the success of their product, but no autonomy to choose the features that make up that product.
They’re frequently given predetermined laundry lists of features by senior leadership and sales, and blamed when the product fails to produce the intended results — sales not made, clients who leave. In these environments where Product Managers are only responsible for managing feature delivery, their job is reduced to project management.
They’re literally only responsible for figuring out which of the avalanche of requested stakeholder features in their team’s backlog they should build next, and making sure it gets delivered as soon as possible.
Product Management is a strategic role
While Product Managers have countless responsibilities, ultimately, they’re really only there for one reason:
To bring higher-level organizational strategy to life through their product in ways that delight customers.
That’s it. They’re the ultimate interpreter and designer of nesting their product-level strategy under overarching organizational strategy.
Everything else is some form of Project, Team, or Delivery Management.
The rarity of strategy clarity
In environments where strategy is poorly articulated or even disputed at higher levels, this lack of clarity ends up getting pushed down, putting Product Managers and their teams under constant pressure from multiple sides.
And so they resort to “prioritization theater.”
But it’s already too late, because we’re prioritizing in entirely the wrong space:
The Solution space, instead of the Problem space.
And Rich Mironov writes:
“…we can’t generically prioritize work, validate potential improvements with all audiences, or assume that every customer segment will value benefits similarly. IMHO, sorting backlogs and setting roadmaps based only on multi-column spreadsheets or cost of delay or WSJF is fundamentally flawed. Product management malpractice.”
And Product Management thought leader Saeed Khan writes:
“You shouldn’t be prioritizing “features”. Yes, I said that. Features are implementations that are linked to problems or opportunities. You should be focused on prioritizing problems and opportunities that are tied to higher level goals and strategies. You should not prioritize features.”
As Andrea Saez points out, prioritization fails us at the most basic level:
“Above all, frameworks lack one key aspect of product management: empathy.”
Are we stuck in Analysis Paralysis?
So when we’re ranking in the solution (or “Output”) space by prioritizing features, we’ve abandoned our primary role as Product Manager.
We’re focused inwardly and analytically on planning, rather than bringing your strategy to life through our product for your end-users.
Because what separates strategy from planning is the realization we’re working to drive something inherently out of our control:
Outcomes
An Outcome, or a change in human behavior that sets clients up for success in ways that work for them, as well as for our business.
If we’re trying to focus on driving specific client behavior change Outcomes, we need to work backwards from something else:
Opportunities
Opportunities are client unmet needs, expressed in their own words.
They help us answer the following questions:
- For whom are we building this feature, so they can finally do what?
- Which of their unmet needs does this help them accomplish?
- How does this connect to higher-level company strategic choices?
So we instead choose to prioritize our target customers’ needs across the right channels and geographies (Our “Where to Play” choices). To deliver against them, we’ve identified differentiated ways to help them succeed. (Our “How to Win” choices).
Working backwards from the right client problem with the right “Where to Play” and “How to Win” choices help us easily understand what needs to be built next — no prioritization framework necessary.
How strategy answers the questions of prioritization
In environments where strategy is a core competency across the organization, Product Managers lead their teams and stakeholders to collaboratively design product-level strategic choices that effectively “nest” under and deliver against higher-level strategy.
Unfortunately, strategy is more often isolated in pockets, or rarely gets communicated down with any clarity by senior leadership.
We always already have a strategy
But there is a way out, and that’s recognizing that strategy is what we’re already doing, not what we pretend or claim to do.
Is it well understood and clearly stated? Because strategy has become something of a lost art, both in design, as well as in effective communication, rarely. But there’s a way to not only understand the strategy underlying our current choices, but to stress-test its underlying logic, allowing us to make better product-level strategic choices.
The five boxes of the Strategy Choice Cascade represent a proven, solid framework that helps teams identify, test, and design sets of strategic choices encompassing everything necessary across both “strategy” and “execution.”
The Strategy Choice Cascade can help in three different ways:
1) Reverse-Engineer your current strategy
Working with our Product Trio and key stakeholders by rapidly reverse-engineering our current strategy across the five boxes.
The key here is to not overthink the process, and approach it in a rapid, lightweight manner. You want to start getting your implicit strategy into a space where you can see it.
From this clear strategic foundation, it’s usually always obvious what to build next.
2) Ask “What Would Have To Be True?”
Now that we can see our strategic choices, we’ll want to ask the most important question in strategy: “What Would Have To Be True?”
It might seem subtle, but this question represents a major shift. Usually, it’s one person’s opinion against another of what they believe is true. By shifting the question from “What is True?,” to “What Would Have To Be True?,” we’re able to test the logic underlying three key forces: Customers, Company, and Competition.
As a group, we ask “What Would Have To Be True?” about:
- Our Customers — What would have to be true about our Customers for them to embrace these choices?
- Our Company — What would have to be true about our Company to deliver effectively against these choices?
- Our Competition — What would have to be true about how our Competitors will react to our choices?
3) Ask what would be the biggest barrier to our success?
Based on the answers to our “What Would Have To Be True?” questions, we can now take advantage of the expertise across the team reverse-engineering the strategy.
Someone might point out that customers, in fact, are not using the solution we’ve provided, despite the flood of marketing materials and training efforts insisting they do so. There might even be some data to back this up, comparing expected usage vs. actual.
Just as powerfully, through conversations with customers, we can find out why they haven’t been embracing our product. So this “What Would Have To Be True?” condition won’t hold, and efforts to test and address this major barrier will guide the roadmap.
Identifying and addressing these barriers across the Opportunity and Outcome spaces will provide the guiding frame of reference to adjust our choices, providing newfound clarity into approaching our product’s roadmap.
Takeaways & TL;dr:
Product Managers don’t have to be reduced to Project Managers prioritizing lists of requested features.
This approach will work even if we’re stuck in a “feature factory,” even if no one can or will clearly articulate our strategy. By taking a step back and mapping our current strategy with our core team and stakeholders, we’ll finally have the ability to make choices that align well with the strategic choices being made at higher levels.
The Strategy Choice Cascade offers a proven framework that lays out and tests the logic underlying our product strategy, helping it nest under and effectively deliver against higher-level company strategy.
Don’t know what to build next?
- Collaboratively reverse-engineer your current strategy so you can align with your team and your stakeholders.
- Ask What Would Have to Be True? About Customers, Company, and Competitors for these choices to hold true.
- Identify the biggest barriers. Instead of focusing in the “Output” Solution space, focus instead on the greatest barriers in the client Opportunity and behavior-change Outcome spaces. Prioritize what goes into Continuous Discovery on overcoming those barriers.
From this clear strategic foundation, it’s always obvious what to build next.
References
Rich Mironov — Product Strategy Depends on Company Strategy
https://www.mironov.com/strat-layers/
Roger L. Martin — Strategy is what you DO, not what you SAY
https://rogermartin.medium.com/strategy-is-what-you-do-not-what-you-say-a6e483840557
Roger L. Martin — What Would Have to be True?
https://rogermartin.medium.com/what-would-have-to-be-true-83dac5bd2189
Saeed Khan — Why You Should Avoid Prioritization Frameworks
https://swkhan.medium.com/why-you-should-avoid-prioritization-frameworks-779a61c0087
You must be logged in to post a comment.