Request a briefing

Essay · Strategy Design

Shaping the Future: Product Strategy in the Age of Uncertainty

The constraint in software organizations has moved from engineering to product management, and four practices decide whether strategy reaches the work

The constraint in software moved from engineering to product management

A bottleneck relieved in one place reappears in another. In the 1990s, as companies turned to software to grow revenue and margins, engineering was the constraint. There were never enough developers to build the features customers were waiting for. Better tools, shared code libraries and agile methods relieved that constraint, and it moved downstream to testing, operations and support.

The DevOps movement met that constraint with two kinds of change. The first was a set of practices from lean thinking and the theory of constraints: managing flow, visual boards and value streams. The second was automation: continuous integration and delivery, containers and infrastructure written as code. Together they automated the simple work and freed people for the hard human work of communication, collaboration, experimentation and improvement.

In high-performing software organizations, the constraint has moved again. It now sits in product management. Engineering can build faster than the organization can decide what is worth building. A product leader sits where marketing, strategy, engineering, design, operations, sales and support meet, and has to make sure finite money and people go toward products that meet a real customer need. When that decision is slow or poorly made, every team downstream waits or builds the wrong thing.

The constraint in software moved from engineering to product managementThree stages: engineering in the 1990s, then testing, operations and support, and today product management.1990SEngineeringToo few developers to buildwhat customers wantedNEXTTesting, operationsand supportRelieved by lean practices,DevOps and automationTODAYProduct managementEngineering can build fasterthan the organization candecide what is worth building
A bottleneck relieved in one place reappears in another. In many high-performing software organizations it now sits in product management.

Most organizations are built to exploit the value they already have

The usual definition of strategy is a defensible position in an attractive market. Positions erode. Competition and the spread of every good idea push products from novelty toward commodity, and margins fall as the market fills. A leader's harder challenge is to keep finding new and unexpected ways to create value.

Most organizations are designed, staffed and paid to do something else. They exploit existing value from known customers in known markets. The symptoms are familiar: business units that act like separate companies, constant battles over priorities, a reactive calendar of urgent projects, and technical debt that makes every change expensive. In a Booz & Company study published in the Harvard Business Review in 2008, employees at three out of every five companies rated their organization weak at execution.

Many leaders reach for alignment as the cure. An organization can be perfectly aligned to the wrong thing. It first has to be clear about why it exists and how it creates value, and then it can design its structures, measures and meetings around that answer.

Organizations learn the way flocking birds do

Arie de Geus told a story, drawn from the biologist Allan Wilson, about British garden birds and milk bottles. For decades milkmen left open bottles on doorsteps, and blue tits and robins drank the cream. In the 1930s dairies sealed the bottles with aluminum tops. By the early 1950s, by de Geus's account, the whole population of about a million blue tits had learned to pierce the seals. The robins never did.

The difference lay in how each species lived. Robins are territorial and spend their time keeping other robins out of their gardens. Blue tits move in flocks from garden to garden. Wilson's three conditions for a species to learn were mobility, a few individuals who invent new behavior and a social way to spread it. Organizations work the same way. Every company has a few curious people who find the cream. The organization learns only when those people mix with others and there are regular ways for what they find to spread.

Four practices connect product strategy to the work

The first practice is a roadmap of value hypotheses. Most roadmaps list features to be built by fixed dates. A more honest roadmap is a sequence of bets about which customer needs are worth meeting, each written so the team can test it: we believe that doing this, for these people, will produce this measurable outcome by this date. When a bet fails, the team knows what it will try next. When it succeeds, the team knows how it will scale.

The second is a chain of requirements that ties each piece of work to strategy. A strategic theme runs for several quarters. It breaks into initiatives of one to three months, epics of a few sprints, features of a few weeks and stories of a few days. Scott Sehlhorst calls this a requirements cascade. Each level answers a different question, and anyone in the chain should be able to ask why and get an answer that leads back to strategy. Assumptions travel down the chain, and what the teams learn travels back up.

The third is a system of metrics that changes decisions. Douglas Hubbard argues that a measurement is worth taking only when it can change a decision. What a product needs to measure depends on where it sits on its adoption curve: validated learning first, then traction, then margin. Lagging measures report what happened. Leading measures give a team time to act. A team that understands correlation can forecast next month, and a team that understands cause can change it.

The fourth is a regular cadence of meetings with clear purposes. Teams walk their boards every week or two, product and portfolio leaders review results and replan every month, and the portfolio is reviewed every quarter. Each meeting has a stated purpose, a small set of people and the inputs it needs. This cadence keeps understanding shared across teams and lets the organization replan as information arrives.

Product leaders design the conditions for discovery

Innovation starts when people turn a limitation into a hypothesis about value. It moves faster when teams from different disciplines scan the market together and share what they learn. It slows down under the wrong constraints and speeds up under the right ones. Product leaders now design those conditions. The organizations that keep finding new value treat product management as the place where strategy meets the work, and they design it with the care they once gave engineering.

Watch the talk: “Shaping the Future: Product Strategy in the Age of Uncertainty”, a webinar by William Haas Evans, October 2022, on Vimeo.

William Haas Evans

Founder and chief strategy officer of Fugue Strategy Advisors. He works with leadership teams on strategy design, strategic foresight and organization design. More about William

References (6)
  • Gary L. Neilson, Karla L. Martin and Elizabeth Powers, "The Secrets to Successful Strategy Execution," Harvard Business Review, June 2008.
  • Arie de Geus, "The Living Company," Harvard Business Review, March–April 1997.
  • Everett M. Rogers, Diffusion of Innovations (Free Press, 1962).
  • Scott Sehlhorst, writing on the requirements cascade at Tyner Blain (tynerblain.com).
  • Douglas W. Hubbard, How to Measure Anything (Wiley, 2007).
  • Eliyahu M. Goldratt, The Goal (North River Press, 1984).

Read next

Request a briefing

What is standing between your team and its goals this year?

Tell us in a 30-minute briefing, and we'll help you decide where to start.

Request a briefing