Session note: designing product strategy when requirements keep changing

The Situation

You're trying to design product strategy, but every time you think you have clarity, something changes. Market conditions shift. Customer feedback contradicts what you thought you knew. Technical constraints emerge that you didn't see coming.

The natural response is to lock down requirements and create a plan. But the plan becomes obsolete before you can execute it. So you update the plan. Then it becomes obsolete again. You end up in a cycle of planning and replanning, never actually making progress.

The problem isn't that requirements are changing—that's normal. The problem is that you're designing strategy as if requirements are stable when they're not.

What Most Teams Try (and Why It Doesn't Work)

Most teams try to create stability by locking down requirements earlier. But this creates different problems.

Locking requirements too early

If you lock requirements before you understand the problem, you're optimizing for the wrong thing. You end up building something that solves a problem you don't actually have.

Creating detailed roadmaps

Detailed roadmaps assume you know what you'll need in six months. But if requirements keep changing, you don't. The roadmap becomes a wish list that doesn't guide decisions.

Treating change as a problem to solve

Change isn't the problem—it's the reality. The problem is designing strategy as if change won't happen. You need strategy that works with change, not against it.

How I Approach This in Practice

I design product strategy for uncertainty by focusing on constraints, principles, and decision frameworks—not detailed plans.

Clarify constraints, not requirements

Requirements change, but constraints are more stable. What can't you change? What are you optimizing for? What are the non-negotiables? These constraints guide decisions even when requirements shift.

Create decision frameworks, not roadmaps

Instead of planning what you'll build, create frameworks for deciding what to build. When requirements change, you use the framework to make a new decision, not update an old plan.

Design for learning, not execution

If requirements keep changing, you're still learning what the problem actually is. Design strategy around learning, not executing a plan. The goal is to learn faster, not execute faster.

Lock decisions, not plans

You can't lock a plan when requirements change, but you can lock decisions. Make clear decisions about what you're optimizing for, what you're learning, and what you're betting on. Then adjust tactics as you learn.

A Real Example

A B2B SaaS company trying to design product strategy while their target market kept shifting. Every quarter, they'd create a detailed roadmap, then requirements would change, and they'd replan. They spent more time planning than building.

Instead of a roadmap, we created three things: constraints (what they couldn't change), principles (what they were optimizing for), and a decision framework (how to evaluate new opportunities against existing priorities).

When requirements changed, they didn't need to replan—they used the framework to make a new decision. The constraints and principles stayed stable, but the specific requirements could change without breaking the strategy.

The outcome wasn't a stable plan—it was a stable way of making decisions. Requirements still changed, but decisions got faster because the framework was clear.

When This Matters

This approach works when:

• Requirements are genuinely uncertain. You're in a new market, building something new, or conditions are changing faster than you can plan.
• You're still learning what the problem is. You don't have enough information to lock requirements, but you need to make decisions anyway.
• Change is the reality, not a problem. Requirements will keep changing, and you need strategy that works with that, not against it.

This approach doesn't work when:

• Requirements are actually stable. If you know what you're building and why, detailed planning works fine. Don't overcomplicate stable situations.
• Change is a symptom of unclear leadership. If requirements keep changing because leadership can't decide, that's a different problem. Fix the leadership alignment first.
• You're using uncertainty as an excuse. Some uncertainty is real, but some is just avoiding decisions. Be honest about which is which.