Product Model Concepts (LEGO dub)

Product Strategy

last modified: April 26, 2024

Strategy is the decision-making framework that guides the teams' development of the value proposition from its current state to the future state described by the product vision.

To work efficiently, teams need guidance in the form of strategy to focus and align their efforts, and to help them make tradeoff decisions. It is the degree of prescriptiveness of this guidance that separates empowered product teams from feature teams stuck in the build trap.

Strategy is a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the current context.

--Stephen Bungay, The Art of Action

Good strategy is simple and obvious. Good strategy helps teams decide what’s important, what they should build next, and what they should say “no” (or at least “not yet”) to.

Good strategy answers two questions clearly:

  1. What are we trying to achieve (mission, vision, objectives, and goals)?
    1. in the long-term (mission, vision)
    2. next (objectives and goals)
  2. How do we intend to achieve it (strategy)? Or, how do we intend to get there from here (strategy)?

In other words:

  1. Our vision is what we intend to create in the future; the value proposition we hope to offer, along with the implicit PMF we believe awaits that product.
  2. Our current PMF is how well our value proposition (design + opportunity solutions) meets the opportunities of the markets we serve.
  3. Our strategy guides us from our current value proposition to our desired future value proposition. It helps teams make day-to-day decisions that will move us closer to our vision.
  4. Strategy deployment breaks strategy down into pieces for different time horizons (EtBT talks about teams needing framing to make good decisions).
  5. Outcomes and output seesaw (PMiP, p. 154) talk about something similar, where teams need to be guided by either specifics around desired outcomes or around desired outputs.

Strategy informs the work of the product teams (and others) and the feedback from the product teams’ work (user research and metrics on released features) impacts company strategy (reflective equilibrium). EtBT, p. 73

When teams are not sufficiently constrained, they become stuck. As Bloom explains:

The unconstrained team is the most frightened and scared to act in the organization. They feel like they cannot make a decision because there are too many options. Appropriately constrained teams, ones who have a direction set to the right level for them, feel safe to make decisions because they can see how their stories align to the goals and structure of the organization.

Not having the right level of direction lands us in the build trap. Teams are given instructions that are either too prescriptive or too broad. Executives will get too far into the weeds, managing by authority and not allowing autonomy. Or teams could, as Bloom mentioned, be given so much freedom they are unable to act. That is why strategy deployment is key, from a product development perspective.

Perri, Melissa. Escaping the Build Trap: How Effective Product Management Creates Real Value (pp. 74-75). O'Reilly Media. Kindle Edition.

Strategy deployment: think of different levels of strategy as stories at different time scales. EtBT p. 74 “… bounding the teams in a direction that allows them to make decisions on a monthly or weekly basis.”

What Are the 3 Types of Decision Making?

  1. Strategic: Long-term, high-level decisions determine the direction of an organization and require a lot of forethought.
  2. Tactical: These decisions translate strategic direction into action, focusing on how and why work gets done.
  3. Operational: Daily, routine decisions put strategic and tactical goals into practice.

A Decision-making Framework vs. a Plan

Product teams need some guidance from the top to ensure that all teams are working efficiently toward the same goal. It is the degree of prescriptiveness of this guidance that separates empowered product teams from feature teams stuck in the build trap.

This is not a binary classification but is measured on a spectrum. Without enough direction, teams will work at odds or flounder from a lack of guidance or simply because they have too many options. If, however, the guidance is so prescriptive that it doesn’t give teams the responsibility for discovering opportunities and experimenting towards ideal solutions, those teams are simply feature teams lacking the power and tools needed to make decisions about the product’s development, focused on execution.

A framework “is a … conceptual structure intended to serve as a … guide for the building of something that expands the structure into something useful”. A framework gives teams the guidance they need to make decisions that will advance the product in a specific direction while giving them the freedom to determine the best path forward within the limits of the framework.

A decision-making framework can guide the work of your product teams, enabling them to act in furtherance of the company’s objectives by designing solutions that are both viable for the company and coherently aligned with the needs, pain points, and desires of the product’s customers.

By contrast, a plan is “a detailed proposal for doing something.” A plan tells teams what to build, when, and how. If, instead, that guidance is too prescriptive and the features built are not supported by a solid understanding of the needs, pain points, and desires of the market, teams waste time and effort building features that don’t fit the opportunities of the market, don’t get used, and don’t add value for their customers.