Product Strategy: what if we stopped hiding behind frameworks?
What is product strategy really about? Mostly about choices.
But how to make choices? Gut Feeling? Are you serious? Wouldn’t they favor biases, politics, HIPPO effect (Highest Paid Person Opinion) and other irrational decision making processes?
So what about data (eg. RICE framework)? Shouldn’t they avoid all of these pitfalls by bringing in clarity, objectivity and finally trust? It would finally turn Product Strategy into a simple and straightforward analytical process!
But if that was really the case, why are our companies still ruled by managers, leaders or CEOs ? If decision making could rely on data, couldn’t robots do the job, probably way better than humans?
So maybe it’s time to acknowledge that gut feeling, among other non quantitative pieces of information, might finally be an effective way to do a proper prioritization? And what is “gut feeling” in the Product Management field ? You said it: Product Discovery. To echo Peter Drucker’s famous quote, maybe that “Product Discovery eats Product Strategy at breakfast”.
The fallacy of prioritization frameworks
Here is how Product Strategy usually happens in many companies. The Product Team comes with a list of features to be prioritized for the next quarter. Indeed, tech resources will always be way more limited than product ideas! Thus the need for prioritization.
Since no one agrees on the priorities between the stakeholders (Product, Business Owners, Marketing, Executives), the company tries to bring in more quantitative insights to make the discussion more objective.
Let’s start with ROI
It usually begins with the ROI (Return On Investment). Since the company wants to create impacts, this metric definitely makes sense. Each Business Owner comes with the expected impact of the feature they want on their perimeter.
Let’s add size
But the ROI is not enough. Some features are definitely hard to develop, the tech team argues! Perhaps we should also ask the developers to size the features (hoping it won’t take more time to size all of them than to develop one of them).
We also need reach…
Hold on. The marketing team now makes the case about the reach. And they are right! Some highly impacting, easy to develop features will only reach a few thousand users…
And what about Strategy?
It’s now time for the Executive Comitee (E-team) to enter the game. Even if the reach is important, none of the previous metrics take into account the long-term vision the E-team is in charge of. Some features will prove their impact on the very long term. Besides, if we don’t ship them now, we will miss the next big thing. This is the E-team duty to define the strategic weight metric.
We need a score!
But wait… The prioritization framework is becoming too complex : we now have too many columns, we need to calculate a score to aggregate all these metrics into one single and easy to read one. Let’s ask the data science team !
Then comes the CEO
Even with a score, debates are endless, the data science team keeps changing the weight of each criteria to take into account new concerns from the stakeholders. Someone must make the call! It will be the CEO.
This process has one positive outcome: at the end of this process, everyone in the company is equally… unhappy!
Is there another way to prioritize ?
If you really want to prioritize a list of features (it can sometimes make sense), why not using techniques like 2-by-2 prioritization? You first prioritize feature A against B, then C, then D, then E. Every time a feature wins, just add one point.
Do the same with feature B against, C, then D, then E. You get the point : do it again with feature C against D, then E. End up with D against E. By adding all the points, you finally have a score for each feature that might be helpful for decision making.
Prioritizing in a relative way is always more efficient and easier than prioritizing absolutely. Besides, following the debates on each feature, it should be way easier for stakeholders to align.
Another technique may consist in asking “helpful” questions like “What if we could do only one feature ?”, “What if we did not develop Feature X ? What could we do instead?”, “Within one year, which of these features could really change the game ?”…
Instead of prioritizing features, what if stakeholders prioritized outcomes ? It would lead to passionate discussions about the kind of outcomes the company needs. And it is way easier to align on expected outcomes than solutions (features). And because everyone has their own bad taste when it comes to a solution, why not let the (extended product) team decide about what are the best solutions to impact the outcome you all agreed on?
What is a product strategy really about ?
Product Strategy is glorified as the purest part of Product Management, as Strategy is glorified in business (see the prestige around Strategy Consulting firms like McKinsey, BCG and Bain). But “Culture eats strategy at breakfast” said Peter Drucker once, meaning that no matter how detailed and sharp your strategy is, if you don’t have a great culture it will never work.
In the Product Management field, we could say “Discovery eats Strategy at breakfast”. Because once Discovery is properly made, Strategy becomes very easy ! Of course you will still have trade offs to make about resource allocation, about managing the debt against developing new areas, about organizing your teams… But these ones are (more) easy to solve.
If you really want to work on Product Strategy as a Product Leader, here are some areas you should put your energy on.
Define clear Principles
At some point, no matter how great the Discovery was, some decisions can only be made at the level of the company’s principles or mission (see the article about the Product Pyramid). For instance, Amazon has always been clear about the predominance given to Users over Sellers. This is a company principle. At a lower level, you can also have Product Principles allowing your teams to make decisions by themselves : should they favor simplicity over functionalities? Speed over Beauty of interfaces? Velocity over Reliability? If you are not clear with such big criteria, your teams will not be able to navigate by themselves.
Allocate resources clearly
This is definitely part of the Product Strategy. How much resources are you ready to allocate to a strategic objective? Teams will adapt to the resources they are given by reducing the perimeter of some features or finding less costly solutions to reach the outcome (think of No-Code for instance).
Organize your teams efficiently
As a product leader, the way you organize your teams will have consequences mainly about the way teams collaborate. No team topologies are perfect, they maximize at a given moment the organization efficiency to reach specific strategic objectives. They will favor collaboration between some teams and make it more difficult for some others.
Bring clarity
As a product leader, it is your role to give clarity so that the team can make good decisions. Clarity requires focus on a very limited set of goals. Clarity requires a deep work to define together with the teams the outcomes to be reached. Clarity finally requires a long enough timeframe to iterate and dive deep on the problem and thus produce impact (3 months is really the minimum on new products requiring fast iterations, 6 months for more mature products).
Conclusion
Product strategy should not be seen as such a big deal. If Product Discovery is correctly made, it can even be… easy, at least at the product team level.
At the company level, prioritization frameworks might not be the solution people think they are. Without a clear focus at the company level, Product Strategy will never be possible.
Prioritization should rely on constructive discussions based on clear insights coming from the Discovery rather than endless frameworks.
Because at the end, Strategy is just about courage to make choices and convergence to agree on them. Data will never be the solution for that, at best another piece of information.
