Static vs. Dynamic Optimization

Chapter 4

Fixed objectives versus search, learning, and adaptation

Summary

Treat product development as a dynamic optimization problem, not a static one. The difference is not academic. It changes how you define success, how you make decisions, and how you structure work.

The previous note showed why product systems are harder to model: the relevant things evolve, the processes overlap, and time and state matter more. This note adds a second lens. Once the landscape itself is moving, the problem is not just harder to represent. It is also a different kind of optimization problem.

The Core Distinction

A static optimization problem assumes:

the objective is known
the constraints are fixed
the solution can be computed

A dynamic optimization problem assumes:

the objective evolves
constraints can be introduced, removed, or reshaped
the solution is discovered over time

In product work, you are usually not solving for a fixed answer. You are navigating a moving landscape.

In more practical terms, static framing assumes you can define the goal, lock the constraints, make a plan, and then execute. Dynamic framing assumes you will learn what matters while doing the work, revise constraints to shape the search, and update decisions as new information appears.

Aspect	More static optimization	More dynamic optimization
Definition	The objective and constraints are mostly known up front and stay stable long enough to solve against them.	The objective, constraints, or both may shift as the work unfolds and new information appears.
Objective function	Usually treated as fixed during the work.	Often revised as the team learns what matters or what is feasible.
Constraints	Mostly known in advance and expected to hold.	Can be introduced, relaxed, tightened, or reinterpreted over time.
Solution approach	More planning-heavy, analytic, and compute-oriented.	More adaptive, iterative, and learning-oriented.
Nature of the problem	Clearer boundaries and a more stable landscape.	Higher uncertainty, weaker initial definitions, and a changing landscape.
Decision making	Decisions are more front-loaded.	Decisions are revisited as signals, feedback, and conditions change.
Best fit	Stable environments with relatively dependable inputs.	Evolving environments where search and adjustment are part of the work.
Flexibility	Lower once the problem is framed correctly.	Higher because the framing itself may need to change.
Example	Tune a manufacturing line with known capacity and safety limits.	Explore product strategy or optimize a portfolio as conditions keep changing.

Other Names You May Hear

Different domains describe similar ideas in different ways:

Optimization framing	Roughly similar ideas
Static optimization	planning, prediction, upfront design, deterministic systems
Dynamic optimization	learning, adaptation, exploration, control systems
Objective function	success metric, goal, value function
Constraints	guardrails, policies, enabling constraints
Solution	plan, roadmap, implementation

These are not exact matches, but they help translate between theory and practice.

Operational Difference

Use this test:

If you can define the objective, constraints, and solution before starting, and you have very high confidence they will all hold, you are in a more static problem.
If any of those change meaningfully as you proceed, you are in a more dynamic problem.

Here is a rough gradient:

Case	Objective	Constraints	Solution shape
Very static: manufacturing throughput tuning	Increase throughput by a known amount	Mostly fixed: machine capacity, labor, safety limits	Choose and tune from a fairly well-understood solution space
More mixed: service operations improvement	Improve incident response and reduce customer pain	Some fixed, some redesignable: tooling, handoffs, ownership, alerting	Partly known upfront, partly discovered through investigation
Highly dynamic: new product or strategy work	The goal itself may shift as you learn	Useful constraints may need to be introduced gradually	Emerges through exploration, interpretation, and adjustment

Most consequential product work sits closer to the second and third cases than the first.

Example: Amazon's Weekly Business Review

A good example of dynamic optimization in practice is Amazon's WBR. It is often described as a metrics meeting, but it is more accurate to think of it as a system for continuously updating a model of the business.

leaders review hundreds of metrics weekly

"The metrics in a WBR are not static — you are expected to add or discard controllable input metrics as they stop working ..."

As Cedric Chin argues in his piece on the Amazon WBR, it is best understood as a process control tool: a way to uncover and distribute the causal structure of a business so teams can act with better understanding.

From a modeling perspective:

the business is treated as something unfolding over time
metrics act as signals of that unfolding
weekly review creates a learning loop

This is dynamic optimization in practice.

Where Teams Get Into Trouble

Most issues come from treating dynamic problems like static ones.

Common failure modes:

locking the objective too early -> optimizing for the wrong thing
treating constraints as fixed -> losing the ability to explore
over-indexing on planning -> under-investing in learning
chasing precision over direction -> local optimization, global confusion
expecting one "right" solution -> ignoring viable alternatives

Back to the Framework

This connects directly back to the earlier notes in the series.

In clearer, more stable systems, the relevant endurants are easier to identify, the constraints hold more consistently, and the perdurants are easier to model as bounded flows. Static optimization makes more sense there because the landscape is not moving very much while you work.

In product work, the relevant endurants are often still being clarified, the constraints may be chosen or revised to shape the search, and the perdurant is the unfolding process of learning, deciding, shipping, interpreting signals, and adjusting. That is why the optimization problem is dynamic. The object of optimization is not fully settled when the work begins.

Seen this way:

learning is part of the optimization process
enabling constraints shape the search space
flexible objectives acknowledge that success criteria evolve
long-term thinking means optimizing across time, not just for the next local gain
multiple viable solutions are normal, not a sign that the team has failed to choose the one right answer

This is not just a different set of tactics. It is a different class of problem.

As Things Become More Dynamic

Focus on unfolding perdurants: Model the things that happen over time, not just the things that exist. That usually means execution, discovery, learning cycles, and decision changes. These are not secondary details. They are often the primary mechanism by which the system evolves.
Model enabling constraints explicitly: Constraints are not just static rules. They are introduced, adjusted, and sometimes removed to shape how the system learns. Model when a constraint was introduced, what it was intended to do, how it changed over time, and what effect it had.
Focus less on labels, more on trajectories: Whether something is called an epic, initiative, or project is often less important than how it unfolds. Shift from categorizing work toward understanding how it evolves, how it branches or converges, and how decisions shape its path over time.
Treat objectives as evolving, not fixed: An objective is not always a stable target. Model how the objective was defined, how it changed, and what triggered the change. This preserves the context behind decisions and avoids rewriting history.
Preserve change as first-class: When something changes, do not overwrite the past. Model the transition, the before and after, and the reason for the change. This allows the system to represent learning, not just current state.

Why This Matters

If you model a dynamic problem as static:

your plans become brittle
your metrics become misleading
your teams optimize the wrong things

If you model it more accurately:

you design for learning
you adapt without thrashing
you make better long-term decisions

Try This Now

Write down a current product initiative.
Ask: which parts of this are actually fixed?
Then ask: what are we pretending is fixed that is not?

RAG Status, Endurants, and Perdurants

Getting the Words Right