Product strategy
A product strategy is not a list of initiatives with dates, nor is it a document written once a year. It is the foundational decision that gives meaning to everything else: assigning problems rather than features to teams only makes sense if someone has first determined which problems actually matter—and that decision is the strategy.
Cagan’s Four Parts
Marty Cagan describes product strategy in four parts:
- Focus. Deciding on the few problems that truly matter—and, consequently, everything that will *not* be done.
- Insights. Knowledge gained from analyzing data and learning from customers; these may relate to business dynamics, internal capabilities, new technologies, or the competition.
- Action. Translating those insights into work for product teams.
- Management. Actively supporting that work, without falling into micromanagement.
Focus is the hardest part. Cagan recounts seeing companies with a list of fifty major goals or initiatives posted on a wall, and teams complaining that they have no time for their own work because those obligations take up everything. Strategy begins with accepting that not everything is equally important.
From strategy to team objectives
The action component is where OKRs come in. Cagan explains that findings point to problems worth solving, and that the most common way to assign these to teams is through the OKR system: the objective represents the customer or business problem that needs to be solved, while the key results measure progress. Each product team is assigned its own objectives.
OKRs are the operational translation of strategy. A team objective is a problem that the strategy has deemed worth solving, and its key result measures whether that bet is making progress.
The strategy stack
Roman Pichler organizes strategic decisions into a "Strategy Stack," where each level guides the next:
| Level | What it determines |
|---|---|
| Business strategy | Where the organization is headed and how it succeeds. |
| Product portfolio strategy | Which products to invest in and how resources are allocated among them. |
| Product strategy | What problems a product solves, for whom, and why. |
| Roadmap | How that strategy unfolds over time. |
| Product backlog | The specific work to be carried out. |
Technology strategy sits at the same level as portfolio and product strategy: it influences them and is, in turn, influenced by them.
The implication for OKRs is straightforward. A well-chosen objective derives its purpose from higher levels; an OKR that cannot be traced back to a product strategy decision is disconnected—it may be well-phrased, yet still fail to serve anything the organization has decided to pursue.
The place of strategy in the operating model
In a product-based operating model, strategy also serves a governance function: empowered teams need direction, not instructions. This direction is provided in the form of strategic context—a vision, a focus, key insights, and transparency—which enables each team to make sound decisions without having a solution dictated to them.
Implementing strategy is not about distributing tasks, but about sharing understanding: when a team grasps the "why," they can adapt the "how" based on what they discover—which is precisely the behavior the model aims to foster. Transparency—ensuring teams see the logic behind decisions, rather than just the decisions themselves—is what allows context to replace control.
Without a strategy, it’s just a wish list
When a prior strategy is lacking, OKRs end up being filled with whatever each area wants to achieve, or with the usual requests simply rephrased as objectives. The result is easy to spot:
- Too many objectives. Without focus, everything seems like a priority, and teams are given more than they can actually handle.
- Objectives that mirror the organizational chart. Each department has its own, even though none of them address a customer problem.
- Objectives that no one can justify. When asked why a particular objective was chosen over another, the only answer is that someone requested it.
Common errors and anti-patterns
- Starting with OKRs. Drafting objectives without a strategy to determine which problems matter results in nothing more than wish lists formatted as OKRs.
- Confusing strategy with a roadmap. A list of initiatives with dates does not explain which problems have been chosen or why.
- Trying to cover everything. A strategy that lacks focus prevents teams from prioritizing or saying "no."
- Distributing OKRs by department. If objectives mirror the organizational chart rather than customer problems, the strategy is left out of the picture.
- Assigning tasks instead of providing context. Delegating work rather than sharing the understanding that enables the team to decide the "how."
- Communicating decisions without the "why" behind them. This forces teams to execute without the ability to adapt.
References
- Cagan, M. Product Strategy: Overview, SVPG.
- Cagan, M. Product Strategy: Actions, SVPG.
- Pichler, R. The Strategy Stack: Connecting Business, Product, and Technology Strategy.
- Cagan, M. y Jones, C. (2024). Transformed: Moving to the Product Operating Model. Wiley.
Resources
🏦 OKRs and Product StrategySkill Arena · Scrum Manager
🏦 Agile Product Operating ModelSkill Arena · Scrum Manager
See also
Do you want to move forward in agility? You can look for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.