How to align coroprate and product strategy
How to align corporate and product strategy was one of the questions I never asked during my time at Amazon. It just worked and when something works you take it for granted. In retrospect, it didn't always work. The productboard blog uses Fire Phone as a prime example of misalignment between corporate and product strategy.
“The Amazon Fire Phone was released to much hype, yet 14 months later the company stopped production and discontinued sales shortly thereafter. While there are many missteps that might explain this product failure, I am sure the team behind the Fire Phone had a fantastic product roadmap. The problem is the Fire Phone’s product roadmap didn’t line up with Amazon’s company strategy.
Amazon had success with the Kindle tablet where the product strategy was to profit through sales of digital content, rather than make money on the device. Amazon’s business strategy is that of lower prices and winning through operational efficiency. The Fire Phone launched with a retail price tag of $199 on a two-year contract. This was the same price as the iPhone and Samsung Galaxy phones at the time. Where was the lower price strategy? The product strategy appeared to be selling a premium product at a premium price, just like Apple. Product strategy and thus the product roadmap didn’t align with company strategy, and the Fire Phone died a fiery death (pun intended).”
However dramatic the example, this misalignment was a rare exception. But why was that and how do companies solve this problem at scale while much smaller (and in theory easier to align) companies suffer?
1. Have a clear and commonly understood strategy
When a company’s strategy is not clear and understood by all teams, then by definition it is impossible to align on it. To even have a shot, you have to start by defining your corporate strategy. But what is strategy? How about “an action that managers take to attain one or more of the organization’s goals”? While accurate, this definition is generic. In this post I will use two other definitions that better reflect the kind of actions required to accomplish a strategy and what this means in practice. One of them is Gib Biddle’s: Product strategy answers the question, “How will your product delight customers, in hard to copy, margin-enhancing ways?” because it gives you the ingredients of a good strategy. The other one is Roger Martin’s “Strategy isn’t what you say, it’s what you do”, which gives an obvious but important dimension to how good strategy should impact actions.
Now that we got definitions out of the way let’s get into describing how this alignment works. Great companies have inspiring vision statements to set a big goal for their future. Jeff Bezos says it best: “Be stubborn on vision but flexible on details”. For example, Amazon’s vision is “To be earth's most customer-centric company; to build a place where people can come to find and discover anything they might want to buy online”.
Starting from this vision, leadership teams need to define their corporate strategy, i.e. the ways to attain this vision. How can Amazon be earth’s most customer centric company? What does that even mean? After a lot of deliberation within the Amazon leadership team, customer experience boils down to three key areas: selection, convenience, and price. Here is Jeff again:
“I very frequently get the question: "What's going to change in the next 10 years?" And that is a very interesting question; it's a very common one. I almost never get the question: "What's not going to change in the next 10 years?" And I submit to you that that second question is actually the more important of the two - because you can build a business strategy around the things that are stable in time. ... [I]n our retail business, we know that customers want low prices, and I know that's going to be true 10 years from now. They want fast delivery; they want vast selection. It's impossible to imagine a future 10 years from now where a customer comes up and says, "Jeff, I love Amazon; I just wish the prices were a little higher." "I love Amazon; I just wish you'd deliver a little more slowly." Impossible. And so the effort we put into those things, spinning those things up, we know the energy we put into it today will still be paying off dividends for our customers 10 years from now. When you have something that you know is true, even over the long term, you can afford to put a lot of energy into it.”
Identifying these truths is the essence of strategy.
2. Fall in love with the problem, not the solution
The next step is to cross the bridge between strategy and execution. Companies get structured in organizations with a mission to tackle one or more of these pillars. Continuing with the Amazon example, each org owns subsets of the customer experience: the fulfillment org owns part of the convenience goal (speed up delivery times) while the marketplace org owns part of all three goals (improve selection, convenience, and prices through third party products). These organizations consist of teams that specialize even more. A team within the fulfillment org can own an initiative to increase items eligible for two day delivery for a specific category. To accomplish this, the team creates their roadmap by breaking down this initiative to specific items like enhancing inventory placement models so that products are closer to customers.
The flow from corporate to product strategy is a two way road: corporate strategy defines the main pillars and cascades these down to orgs and teams (top down), while each team defines their strategy (and eventually roadmap) based on these high level guidelines (bottom up). If all steps in this process work well, then corporate strategy actually aligns with product strategy. In a startup environment the layers are fewer so in theory this seems even more straightforward. However, startups suffer from the risk of bridging the gap from strategy to roadmap items too soon.
A source of misalignment is the perception that product teams are there to implement ideas conceived by “the business”. This is a very old-school way of viewing the contribution of product teams and won’t get you far in today’s tech environment. Avoid project or feature teams at all costs.
Your goal should be to build a great product culture. A great product culture is connected to a large extent to what Marty Cagan and Chris Jones call empowered product teams. Such teams are positioned to drive change and ship great products that customers love. They own product strategy, which is a major part of the company’s strategy. They own their domain and are held accountable for their performance and results. They directly talk to customers and try to identify and serve their needs. They are trying to solve a problem rather than implement a solution or a feature assigned by the “business”.
A common pitfall is to rush to a solution (e.g. let’s remove a few customer onboarding steps) but this is counterproductive. The ideal interaction with a product team is to help define the business problem (e.g. “reduce time for onboarding”) and let them propose specific initiatives to accomplish this. It is ok to have opinions on what to do. Actually it is more than ok; it is required. The team needs your feedback and guidance. However save this for a product strategy or roadmap review; don’t create the roadmap for them.
There are many reasons why that is a best practice. Empowered teams feel more in control and as result they are more engaged. This results in a higher level of ownership and accountability on results. In addition, as companies scale, details matter and executives or stakeholders are not as close to a domain as a product manager that spends significantly more time thinking about this specific problem. Not only do they have better access to insights from customers, but they also better understand implementation details and tech limitations so they can propose the best possible solution. There are countless times where an executive proposed a solution and when the team dove deeper on what they actually wanted to accomplish they found a better and cheaper solution for the problem1.
Of course, just adopting these principles will not lead to the desired effect all at once. This is a yearlong journey that affects the whole company. The leadership team has to trust the product organization and give them the space and resources they need to deliver, stakeholders must be educated on how to work with the product team so that they can maximize the company’s total output, while the company’s hiring strategy should screen for key skills needed by PMs to successfully meet these expectations. While some aspects become more complicated as the team scales, the main principles and elements don’t change much. Hire skilled product managers, assign them challenging problems to solve, keep them accountable for the outcome, and everything else will follow.
3. Monitor progress and fine tune until you get there
Starting from a point of alignment does not mean that this will always be the case. There is a risk that you either lose focus or that the strategy and priorities change. Companies need to have regular check in mechanisms to track progress and maintain this alignment.
A word of caution: This is by no means the only or the best framework. This is one framework that has worked for me combining elements from the OKRs, some Amazon techniques, and other practices I found to work well. Feel free to fine tune and customize as needed based on your company’s needs.
Set objectives at the leadership level and cascade to teams to fill in their key results. For example, an objective could be “Improve fulfillment customer experience” with a key result to “reduce delivery times for US apparel selection from x to y”. This key result can then become an objective for the fulfillment PM with a respective key result to “improve inventory placement model in US fulfillment centers to ensure placement within 100 miles for at least 50% of customers”.
Goals (key results) should follow the SMART format. Also consider setting shared goals for initiatives that cut across teams and require a higher level of coordination.
Planning has a fixed cost for each iteration as teams need to set priorities, scope projects, identify dependencies, commit to timelines, etc. To optimize for this, we should plan as rarely as possible. However, we need to trade this with the flexibility benefit of reassessing priorities based on new information. To optimize for flexibility we should plan as frequently as possible. The optimal planning frequency depends on the maturity of the organization and the type of the product. As a default, three month iterations seem to be working well in most cases but assess if that fits your teams and adjust as needed.
Teams should have reviews at different frequencies:
Metrics: You should review metrics (at least) weekly. Most things don’t change much week over week so the focus should be to explain abnormal variations and not the expected noise on each metric. Set up your metrics dashboard to easily spot any deltas to last week, same week last year, or your plan.
Goals: You should review goals (at least) monthly. This is a review where you go through your OKRs and call goals as green if on track, yellow if at risk to be delayed, and red if you aren’t able to complete on time. For any yellow or red goal, teams should have a path to green (e.g. new launch date, additional resources, etc.)
Strategy: You should review strategy (at least) quarterly. This is a review of a strategy doc (not ppt) where the team includes their progress (successes, misses), learnings, goals and metrics updates, the proposed future direction, and any areas they need feedback from leadership.
Remember, these changes take time so don’t expect to reach the desired state immediately (but you should see good progress soon enough). If you apply these changes you are setting the foundations for a great product org and a great company in the long term.
The product version of a Pareto improvement