Guest Post by: Eric Wang (Mentee, Session 8, The Product Mentor) [Paired with Mentor, Chris Butler]
Journey Into the World of Strategy
The notion of a strategy in product management seems like something that only high-level stakeholders at the executive level should care about. After all, many product managers tend to treat a strategy as something that’s scared and driven top-down from the executive management level. This believe usually means that the tough decisions have already been made and we just need to execute based on what has been defined, right? Sadly, that’s rarely true, and strategies from the upper management are often multi-year in length with a scope focused on the company profitability without any of the product level details.
In my company, we review a living document with our management chain on a quarterly basis to align business direction for the short-term (immediate one to two quarters) to the long-term (two to five years). The challenge to the product managers is to translate these into a more functional plan for our engineering team.
Simple task, right? Not quite! Some of the challenges from my personal experience has been
- We perceive strategy from the management as the gospel – Usually the opposite, a good leadership team usually expects the individual contributors to provide iterative feedback.
- We perceive strategy from the management as perfectly informed – The reality is that this is a set of decisions based on a snapshot of information at an instant of time!
- We cannot challenge the strategy from the management – Many people with important titles have worked on this, so we must accept it as is…right?
With these three fallacies, Chris introduced me to the concept of “proto-strategy.” In a nutshell, this is a prototype of a strategy, an iterative version of a strategy in an instant of time. The idea is to treat the strategy as a prototype that will undergo many iterations and testing. We will ultimately produce a fluid plan that serves its purpose by being the north star of your product.
Pillars to a Proto-Strategy
For a proto-strategy to be helpful, it needs to be succinct and easily recalled from memory as you will need to draw back to this frequently.
Some fundamental principles I found helpful when starting this exercise,
- Keep it short and sweet so that you can quickly memorize the core message
- Make a list of the scope and the challenges to your product
- No formal stakeholder review as this is meant to be the first version that will undergo many iterations and refinements
- Test your strategy whenever opportunity arise as this is intended to be YOUR source of truth to guide you along
- Most importantly, the proto-strategy is meant to serve when faced with two good options for a decision (two bad choices make a dilemma, and you want to avoid this)
First Attempt
As expected, I ran into a lot of issues at the start of the process. For example, my first iteration focused on the problem statements, targeted customer, technical strategies, pricing strategies, and competitiveness evaluation, which was all excellent content that offered important product context but just not the right place. Instead of focusing on shaping a strategy doc, this first attempt turned into a business proposal. After getting feedback from Chris and along with more coaching, I was directed to focus the effort on my interpretation of the strategy to the specific challenge I am working on, rather than the entire product. With the new guidance, the draft was about a page in length.
Second Attempt
After more reviews, the second draft was focus on two generalized themes
- Define a specific problem space
- Define my interpretation of the solution with its value proposition
A word of caution here on offering a solution to your defined problem. I advise every product managers to focus on the customer outcome rather than the technical implementation. A well-defined problem space with success criteria will be much more beneficial and often more natural to get buy-in from your engineering team. With this refinement, the proto-strategy is now just short of half page in content.
Lessons Learned
Without going into the gory technical details, my proto-strategy revolved around a product focused on digital video delivery platform targeted for broadcasters running an over-the-top (OTT) workflow. The product is essentially a middleware tying together various aspects of a video business from the signal acquisition, video transcoding, subscriber management, payment processing, analytics, and personalization.
Suffice to say, the scope of the product is extensive and our major challenge is to find a balance in make-or-buy decisions. Working under an aggressive deadline with a limited amount of cash, every decision we make can have a significant impact, and this is where a proto-strategy can help.
Before I can use the proto-strategy efficiently in my daily life, I went through another (and final) round of editing with Chris to further trim down the details. Specifically, a lot of “how” has been removed as those were more engineering and solutions focused details. At this point, I have the proto-strategy down to about a quarter page in length and ready to commit this to my memory.
Overall, some valuable lessons captured from this exercise,
“How does this strategy framing help translate into actions?”
This question is meant to force you to bridge the gap between strategy and execution. Specifically, I must think about how our sprint planning and feature prioritization aligns with the strategy. For example, is our engineering sprints solving the problems that align with our Orbis product vision and release goals?
“What is our secret sauce to make the customer more successful?”
This question forces you to think about your value proposition and how you plan to compete in the industry. For the Orbis platform, this means that we formalize our core themes such as video-delivery-as-a-service, reduction of operational expenditures and reductional of capital expenditures since data center and infrastructure build-out is no longer necessary.
“What are we betting on? (and betting against?)
This is meant to help me identify assumptions and the major themes out of the scope of the current timeframe of this strategy. This also implicitly forces me to cross-check the high-level strategy as laid out by the management, where I can ensure alignment in the final deliverable.
The process helped me formulate a strategy from high-level, wide-scope to something that’s more detailed and scoped that’s easily understandable by the engineering team. Anecdotally, I found that having this proto-strategy, I was able to convince and defend a many of my product decisions with the internal stakeholders without much effort. The more I apply the strategy, the louder the message becomes. I am curious to see how this will work out in the longer term, and how to manage the changing strategy when need finally arise.
To summarize the process, I advise you to start the document by focusing on defining the problem. After that, sit on this for a while and come back to this a short time later. When you review the draft, start condensing the problem statements to reduce the page length. As we reach the quarter to half page length, the next exercise is to commit this to the memory and let this be your guiding principle in your daily life. Specifically, activities such as release or sprint planning, feature prioritization, and retrospective.
Testing the Proto-Strategy
Before using this in your daily environment, you should try to apply the following litmus tests,
- Are the statements factual? Stick to accurate numbers and no fluff statements that cannot be measured.
- Is the strategy prescriptive enough without being instructional? Is the strategy formulated in a helpful statement that promotes discussion rather than being a to-do list?
- Can the short form strategy be used as an elevator pitch?
Using the Proto-Strategy
My first real application of the proto-strategy is in our feature planning, where we needed to evaluate a make-or-buy decision to complete the regional blackout scenario that’s core to content distribution in the broadcasting industry. The problem space usually contains custom implementations that do not scale or interoperate with different systems. My proto-strategy indicated a set of criteria on the core bets on our platform being interoperable with third-party technologies.
A proposal from our management suggested that we sign a particular long-term partner in this space and integrate their technology directly into our platform. The proto-strategy helped me formulate a counter-proposal along with financial numbers to provide feedback on the implication of this decision. Ultimately I was able to convince the stakeholders that building this feature ourselves, which will delay our time-to-market, but pay a dividend for us as we can control the implementation to serve multiple customers reaching a broader market.
The second instance where the proto-strategy helped me was during a customer meeting, where the customer’s management team asked me to summarize our Orbis product during an informal coffee. Right off the bat, I went straight to my proto-strategy and discussed their challenges along with the list of value propositions on how we can solve their problems. A few weeks later, I was informed by my GPM that the customer was delighted that we were able to articulate the problem space and wanted to explore additional partnership based on this meeting.
Not Everything is Perfect
As with any tool, there is a downside when misused. For example, the proto-strategy is what “I” believed to be the strategy to a scoped challenge, which of course, should never be treated as THE strategy until multiple rounds of testing. While this was not a problem I faced, I also believe that conflicting proto-strategy may occur on a large product, which can lead to contradictory directions for the engineering team or the customers. As with the original warning, the moment you share a strategy doc, you open the floodgate to a lot of critiques.
To summarize, a proto-strategy is a tool that has many uses cases and serves as a guiding light for me whenever there is not a clear a decision. The proto-strategy is meant to be lightweight and simple to construct, but the process of getting there invokes many tough questions and therefore prepared me upfront.
Lastly, the proto-strategy is meant to serve as a starting point that aligns with high-level strategy and not necessarily intended to be perfect. I believe, every PM needs to allocate time to devote to this exercise as the ROI and the upside can be tremendous. When leveraging this method across a large organization or product line, be sure to discuss the proto-strategies as a group to reduce contradiction that may lead the team astray.
Eric is a seasoned product manager in the Greater Seattle area passionate about technology. His experience includes software development, program management, and product management ranging from enterprise B2B to consumer-facing media software. When Eric is not in front of a computer, he is out enjoying the nature of Seattle (rain or shine).
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Sign up to be a Mentor today & join an elite group of product management leaders!
Check out the Mentors & Enjoy!
Jeremy Horn
The Product Guy
The Product Guy 