A star product manager on your team comes to you one day, upset about the lack of coherent strategy. You’re confused: you have goals, a beautiful mission statement, an objective and measurable key results (or KPIs, depending on your parlance). The team has a good roadmap with specific things they are building. What is possibly wrong?
“We’re doing a bunch of tactical stuff but we don’t have a strategy.”
If you hear this, again and again, it is likely because the distinction between strategy and tactics is unclear. Sometimes one legitimately does not have a strategy — you’re in the problem definition phase, or your strategy is to out-execute the competition. More often, you haven’t outlined the strategy or communicated it to your team in a way that feels coherent.
A strong, written exposition of your strategy, including rejected options, accelerates the product development process. Teams that understand the central strategy are empowered to come up with their tactics and execute without centralized decision making. They don’t have to come to you for every last detail. This article captures my take on strategy and tactics as applied to building software products, based on nearly a decade of trial and error during my career at YouTube and Facebook.
What is Strategy?
“Strategy is the creation of a unique and valuable position involving a different set of activities. It requires you to make trade-offs — choosing what not to do. Strategy involves creating a “fit” among the companies activities.”
— Michael Porter, What Is Strategy?, On Strategy
Strategy is easier to understand in the context of military theory or multi-player games, with clear goals and win/loss scenarios. Chess has been played and analyzed for centuries and is an excellent lens through which we can try to understand strategy. A player’s goal in chess is simple: checkmate your opponent. However, when the game starts, the board is wide open.
Here are three (amongst many) different things a white player could choose to do:
Focus on attacking quickly and going for the quick win. White aggressively develops his queen and attacks rapidly. Black must pay attention to traps while focusing on developing their pieces.
Control the center and developing your pieces. White opens into the center and then fights to maintain that control. This is a popular opening for a good reason: it is less risky than extremely rapid development and leaves a lot of options for future attacks.
Defend first, giving up the center. White has castled and has nicely defended the king but, in doing so, has lost control of the center. The result is a more aggressive black game while white plays passively and waits for a black mistake.
No particular strategy leads to an immediate, measurable advantage. Neither player captures or loses pieces immediately by following any of these strategies. However, they lead to wildly different games.
Choosing one strategy means not choosing the rest. One cannot defend the king and simultaneously control the center, using the same set of moves. One cannot be aggressive and attack with the queen while also developing the rest of the pieces. The strategic pick must fit with the player. Aggressive players picking a defensive strategy will result in neither sharp offense nor solid defense. A player must know who they are (or trying to become) and pick a plan that works well with them.
What are Tactics?
Tactics are a set of actions that result in concrete, measurable gain.
Continuing with our chess analogy, let’s look at the following sequence of events:
In two moves (set of actions), by sacrificing the queen, white has checkmated the black king and won the game (concrete, measurable gain).
Tactics can involve any number of moves — but the result should be clear and unambiguous. In the example above, the gain is winning the game — the biggest prize of all. Not all tactical play will result in such a significant benefit; often, the increase is a single piece like a pawn or positional advantage of occupying a square in the center. The critical difference is that a tactical move quickly results in a definite advantage, while a strategic position is an opinionated way of making progress toward the ultimate goal.
From Chess to Products
Chess has fairly clear rules and an unambiguous goal. Rules and goals may be a lot fuzzier when building products, creating ambiguity. How do we apply the learnings above to product development?
Start with a clear goal. Without this, the discussion about strategy and tactics falls apart. Regardless of the phase of product development, the goal should be clear, even though it may not be easily measurable. For example, in the very early stages, the goal is to determine 1) does the customer have the problem we think they have? 2) does our product or feature solve the customer’s need?. Post product/market fit, the goals are often to increase revenue, users or engagement, and thus grow the business.
Develop strategic positions toward the goal. A “strategic position” is a choice to focus on some part of the overall problem. The approach is to segment the problem space and then choose a combination of those segments to over-serve while ignoring or under-serving the rest. Porter lists three approaches to segmentation,
- Segment an industry’s products and focus on building a particular subset.
- Segment based on customers’ needs.
- Segment based on customer access and how products reach them.
It is important to note that these are not MECE (mutually exclusive and completely exhaustive). Combinations of these sources will lead to different strategic positions that one could take.
Smaller, Better, Faster → Tactics. Improving the performance, reliability, and efficiency of software is an excellent thing, but it is not a strategy. These are operational indicators and will generate a definite tactical advantage, but they do not signify a unique position that your product could occupy.
Winning with Strategy and Tactics
Achieving your goals involves excellent strategy and artful execution. One without the other is likely to result in unnecessary friction, if not outright failure. One must have a solid strategy, choose to communicate it often and follow it up with solid execution. Execution includes things like operational effectiveness — building products that are fast, reliable, and efficient. Another critical element of execution is excellent design — the product needs to be coherent and understandable, and communicate its purpose. Details matter and small issues and bugs diminish the impression of a well-built product. However, none of these things — A+ engineering, beautiful design, perfect understanding of data — constitute a strategy. One can win based on tactics alone, through fast, solid execution. But this advantage is not as sustainable as one achieved through a combination of strategy and tactics.
I’m your host, Rushabh Doshi. After spending nearly a decade managing some of the brightest engineering teams at Facebook and YouTube, I’m taking a break and doing some writing, spending time with my family and figuring out my next thing.
If you enjoy these articles and would like them in your mail, please subscribe to my newsletter.