Scoping and Shaping For Success

By John Cutler 2024

https://cutlefish.substack.com/

Want to support my writing? Subscribe to one of my newsletter paid plans.

Unlocking, Unblocking, and Shifting

Drivers, Limiting Constraints, Floats, Enabling Constraints

The Basic Idea—What Do You Do With This?

How to define a driver

Pressure Testing Drivers

Drivers vs. Limiting Constraints

Limiting constraints vs. enabling constraints

Floats vs. Enabling Constraints

Improving the chance of success (through shaping)

The Moves

Warning Signals: Too Many Drivers / Limiting Constraints

What Makes a Good Enabling Constraint?

Examples of Enabling Constraints

Enabling Constraint (Before and After)

Static vs. Dynamic Optimization Problems (and why it Matters)

Experience and Tradeoffs

Good Times, Normal Times, and Hard Times

Making the Case

AI GENERATED INTRODUCTION

I was procrastinating shipping this because I had no introduction. In the interest of getting it out to the world, I have opted to “hire” AI to write a brief introduction.

Teams often find themselves bogged down by competing priorities, excessive constraints, and unclear objectives. “Scoping and Shaping for Success” provides a robust framework designed to help individuals and teams overcome these challenges by unlocking focus, reducing cognitive load, and creating pathways for real progress. Through a mix of enabling constraints, flexible floats, and clearly defined drivers, this guide will show how to shape efforts toward clearer, more actionable goals.

At its core, this framework introduces the importance of balancing drivers (desired impacts), limiting constraints (real obstacles), floats (areas of flexibility), and enabling constraints (temporary limitations that boost creativity). By refining these elements, teams can shift from being stuck in place to moving forward with purpose and clarity.

This piece breaks down critical concepts like the "Basin of Attraction"—a metaphor for being stuck in familiar yet unproductive patterns—and the "Tradeoff Trap," where teams spiral in circles, making ineffective compromises. It also explores the nuances between enabling and limiting constraints, offering practical techniques to structure initiatives in ways that improve their chances of success. From how to define a clear driver to how to test if your constraints are helping or hindering, this guide takes a deep dive into the art of scoping and shaping efforts for optimal outcomes.

Whether you're building product features, navigating organizational hurdles, or leading a team through uncertainty, this framework equips you with the tools to simplify decision-making, focus energy where it counts, and set the conditions for ongoing success.

About the Format

This mini-book is structured as a collection of thought experiments, mental models, reflection questions, and actionable activities. It's designed to be skimmable and flexible—feel free to jump around and explore sections in any order. Throughout, you’ll find specific activities that I recommend trying out in your work or with your teams.

I originally created this as a companion piece for my Scoping and Shaping for Success workshop, which I’ve since discontinued as I explore how to integrate these ideas into other learning experiences. Let me know how you like the format and whether it sparks new insights for you!

Unlocking, Unblocking, and Shifting

What does it feel like for a team to be unblocked?

Thought Exercise (Unblocking):

Think about a time when:

It felt like your:

• Team was spinning in circles. Making progress felt like moving through quicksand, navigating an endless maze.
• It was very hard to stick to decisions or even understand what you decided on in the first place. Alignment was fleeting—you drifted apart faster than made progress together.
• A lot of repetitive conversations—rehashing the same tradeoffs over and over
• You kept needing to “reset” over and over, but ended up trying roughly the same approach to making progress (or at least it seems that way). Everyone had a pet idea of how to fix the problem (“you just need to….”), but none of that panned out
• You might have had a sense that the effort was “destined to fail” but it was hard to elaborate why/when/how. It felt like the cards were stacked against you
• It felt like you were “moving the deckchairs around”, “trying to play tetris”
• It was very hard to get into a state of flow—the “good kind of challenging”

And then something happened that:

• Felt like you had “unlocked a portal” to a path forward
• Suddenly things seemed “simpler” but somehow not oversimplified
• It felt like pulling that one loop out of a knot, and the knot unraveling
• As if the “answer had been there all along”
• An almost instant boost in clarity, alignment
• Instead of tip-toeing around twenty gotchas, you could move ahead with confidence
• Instead of coming to work and spending most of your time feeling stuck, you found yourself having long uninterrupted periods of productive work
• Somehow, with things getting more focused you actually had MORE creative options, but those options didn’t seem as overwhelming

What actually happened? What was the catalyst? If the change involved adding or removing people from the team, what did those people bring to the situation?

Unlocking and Unblocking Examples

Some examples to think about drawn from a LinkedIn thread:

Example 1

It's curious, but I've actually seen top-down, HIPPO-led pivots re-energise teams. I wish it weren't so, and I hate that teams get into this state, but it almost feels like a defibrillation exercise that can give them something to hold on to and rebuild. Hypothesis: Teams feel un-empowered and they have lost the will to fight for their initiatives. They feel unable to make progress because they don't believe they'll be listened to.

Having initiatives top-down mandated takes all of that off of the table because you have automatic buy-in (presuming you don't have a magpie leadership team that chases after every little shiny silver thing that catches their attention). This enables you to get back to the craft rather than trying to fight political battles, or spending all your time trying to bullet-proof a business case.  (source)

Example 2

“We recently had a team do a migration of millions of (large) documents with rather strict timelines for completing the entire migration. When we started we had the applications running but still had to improve throughput performance by some 1000%. With no clear idea on how to approach this.

In the end we managed to pull it off a day or two before the deadline. The catalyst to making this work in our case, was to start with a sprint kickoff with a very clear and ambitious goal and shared sense of urgency. And creating ownership of the issue. Then working through very short cycles of hypothesis testing and loads of observability.

Additionally we came together often to have test runs all together (every time rehashing it being a team effort/problem to solve). During the entire thing we had a dynamic Miro board with all the steps/hypotheses visualized in order and we kept adding to it with every new issue we encountered.

We failed fast and often to learn and adapt and “celebrated” the fails as additional learnings, creating a positive vibe of progress and accomplishment along the way. In my opinion, the game-like challenge/reward approach kept the team engaged and made them exceed their usual performance by a lot.” (source)

Example 3

“We painted a picture of what would happen if we didn't get our shit together. Basically put together a list of potential outcomes and their implications, and it made the choice of optimal/desired outcome pretty stark. Rather than trying to define the one thing, define all the potential paths, and get really effing clear on which one we wanted to take as a group. Zoom zoom. “

Example 4

“A few jobs ago… I presented what I thought were effective presentations, produced well-built prototypes, no movement. Was told that I could do this stuff, but the common engineer would struggle with TDD, CI/CD, keeping up with new tech, relying on open source platforms, and the cloud. Then, I mentored an intern who produced a prototype of CI/CD and containerization.

That broke open the dam. Giving management the understanding that it doesn’t take exceptionalism to succeed in a modern SW org, helped pivot that is still moving to this day.” (source) Jeremy Pulcifer

Example 5

“Naming the problems and working towards a shared goal. So, I’ve had teams that were at loggerheads because the company had given them competing goals e.g decomp a monolith (team Y) and also add new features (team X). By calling this out and making it ‘conscious’, and getting the parties together to discuss how both needs could be met and co-creating a path forwards (collaboration is key) this gave the boost in clarity and alignment you mentioned. It’s that moment where teams remember they are part of a bigger picture.” (source) Valerie Dryden

Example 6

For an AI pivot I led for a B2B start-up, I wrote a series of “fake” press releases that spelled out what would, in theory, be amazing if we were to launch the features and capabilities outlined in each press release. We reprioritized the portfolio based on the press releases, sketched out a new roadmap, and accelerated. The first of the “fake” press releases was rewritten to be a real press release 45 days later. Tada! (source)

Example 7

What helped: segmentation of customers, outlining differences between segments, outlining gabs (roadblocks) per segment, share the learning with the dev team to get feedback & buy-in, then share the learning with Stakeholders (source)

Example 8

COVID. I worked in a domain which could no longer function. Nothing like an external crisis to focus the mind on what really matters and make what needs to be done very simple and very obvious. (source)

Example 9

Gonna sound like a cliché but it was a really simple, Phoenix Project style exercise in focus. I inherited a platform team as acting Product Mgr, the team was essentially acting as a group of individuals all doing different things toward different goals. Got them focused on a single thing by killing or parking the other things and it was like flipping a switch, the team started to flow...

The main thing that made the change awkward was persuading the team members to cross-skill themselves - the reason for the previous separate workstreams was mostly that they picked up the things that suited their individual specialties instead of working out how they could help each other when focusing on a single thing. The key factor was making this inevitable - forcibly holding back the things that were tempting the team to fragment their focus. (source)

Example 10

I had a couple teams that were overburdened and underperforming. Morale low, energy low, productivity low.

One of the product folks shared her team had 12 projects going at the same time from various sources. Classic High WIP issue, but underneath that not enough structure in the product culture / strategy / ways of working.

We killed half of those within a week, put another few in the "later" bucket, had some difficult conversations, slowly dug our way out of 1-2 projects that were BAU / tech issues needing automation, until they ended up with 1 big project and 2-3 smaller ones at any given time.

Then we worked on connecting the teams to the customers and the sales/support/marketing teams in a structured way (not just getting bombed via chat messages and back channels), built dual-track planning and investment processes so discovery was more structured and product lead / designer / lead dev were more empowered, and built product strategy frameworks so they could make better decisions within certain guidelines. (source)

Helpful Frame #1: Basin of Attraction and Phase Shift

Basin of Attraction

Imagine you're walking in a hilly landscape, and you find yourself in a valley or a hollow. No matter where you move within this valley, you're still stuck in the same general area – this is like being "stuck in a rut." In complex systems theory, this valley represents a "basin of attraction." It's a state or set of conditions where the system naturally settles or gets attracted to.

When your team is stuck, you could say it is stuck in a specific "Basin of Attraction”. This basin is defined by certain drivers (forces or motivations pushing the initiative) and constraints (limitations or restrictions). The team is "stuck" because they are not adding new enabling constraints (which are restrictions that actually foster creativity and progress) or areas of flexibility. They're also not refining their list of drivers to better suit their goals. This situation can lead to stagnation, where the team keeps operating within the same limited framework without making significant progress.

Phase Shift

Then, a catalyst occurs — a phase shift. This is a critical moment where someone or something (a catalyst, or introduction of a new attractor) causes a fundamental change in the team's perspective or approach. This catalyst could be a new piece of information, new constraints, areas of freedom, a reevaluation of goals, or an innovative idea from a team member. This phase shift reframes the effort in a way that "cracks it open," breaking the team out of their current basin of attraction.

Helpful Frame #2: The Tradeoff Trap

The Trade-Off Trap

A situation in decision-making, especially in complex projects or product development, where teams get stuck in an endless cycle of making tradeoffs. These tradeoffs, rather than propelling the project forward, often result in a middling, compromised outcome. Each tradeoff tends to add more dependencies and increase cognitive load, complicating the project further. Instead of making strategic, meaningful tradeoffs that could significantly advance the effort, teams find themselves in a loop of decisions that only lead to incremental changes and heightened complexity, often undermining the overall effectiveness and vision of the project.

Trade-off Story #1

A B2B SaaS team is thinking about how to increase its total addressable market. So, it is targeting more and more niche segments. Each of these niche segments has some unique needs (and leverages core features). The company ponders what new features to build. They develop complex spreadsheets that detail exact estimates, team sizes, and try to predict the total revenue available for these niches. When they compare opportunities, they don't find step changes; rather, it is more like very similar long-term forecasts. They descend into constant analysis, trying to consider the ROI of every feature being built, the cost to sell those features, the cost to support those new features, etc.

A new team member joins and starts asking probing questions. "Is any of this micro-optimization actually delivering value? I see that we end up playing Tetris with our teams as we try to peanut butter spread them against opportunities." "What is the real issue here?" A new, more junior team member speaks up boldly. "Are we thinking about the bigger picture? Isn't the problem here that nothing really stands out in terms of value? Are we really at the point as a company where we're trying to eke out the last tiny % of growth? I don't think so." There is silence in the room, as people consider that question.

Someone from the platform team adds their perspective. "Whenever we build these features, we are adding complexity to our product offering, and that complexity costs money and creates drag. I don't see that at all in these spreadsheets. It is like we're missing out on a big part of the puzzle in our effort to be precise. Shouldn't we be considering the platform strategy, and whether it is actually improving the unit economics as we go into these niche markets?"

Someone from support adds their perspective. "I don't think we're really calculating the cognitive load involved in having to support these niche features. It isn't in the spreadsheet. We have some very intricate models, but it is like we're missing out on another big cost and question."

Slowly it starts to dawn on the team that they are stuck in the tradeoff trap. It is easy for someone on the outside to see, but it was hard for the team. From the outside, it was clear the team was struggling with analysis paralysis and chasing very trivial marginal gains. From the inside, this felt like doing a "good and thorough job".

As the team started to discuss these issues more, they started to get clear on a way forward. At the end of the day, the big question was what they needed to do to make the unit economics clearly favorable to enter new niche segments. And thus, a new strategy was born.

Public Reactions:

“In my experience, this isn't something a team slips into, it's baked in from the beginning as part of the corporate culture. When timelines are predetermined to fit quarterly financials and projects are driven by short-term business goals, it limits vision and the ability to examine the problem space. The typical trade-off decisions, in my opinion, are actually just a lack of cohesive product strategy and we've normalized it instead of dealing with the root cause.

The tragedy is that, due to the pressure and making decisions too quickly, I've seen team members develop tunnel vision and become unable to recognize alternatives that are better and actually easier to implement, forcing false trade-offs and dooming themselves to a never-ending cycle of trying to clean up an ever larger mess.” (source)

Trade-off Story #2

Have you ever heard anything remotely approaching this logic?

“If George and Ina each allocate 50% time to Project Thunder, and then Lenny does 10% time combined with moving the two open reqs to Team Apollo and hiring those roles in the next two months, we should—if we sort of combine Project Thunder and Project Inferno—be able to finish Thunder, Inferno, and chip away at Homestead so that when The Hex Pistols are done with the event streaming re-architecture and Project Kafka-esque, assuming Xenia approves the design document, we should be able to hit the deadline for Project Sycamore as promised in the 2023 annual plan."

Caveat

Remember that perceptions of trade-offs change as we gain more experience. We learn that certain things aren't trade-offs that we previously thought were. We discover trade-offs we didn't see before. In some cases, we realize that what appeared as trade-offs are actually polarities, intrinsically intertwined, more like a yin and yang. For more on the impact of experience on our view of tradeoffs, see here.

Drivers, Limiting Constraints, Floats, Enabling Constraints

An overview of the framework we’ll focus on today.

For our conversations and activities today, we will be using a framework that I first discovered in Johanna Rothman's book, "Manage It!: Your Guide to Modern, Pragmatic Project Management." In her book, Rothman makes the point that product work is different from project work, and that the normal project management triangle, which imagines project work as a triangle with scope, quality, and cost at each point, is insufficient for product work. She notes that the project management triangle lacks

1. The concept of value
2. Doesn't capture the learning we do in product work, and therefore doesn't meet our needs
3. Additionally, she points out that the way it represents costs can be misleading in product contexts, where we often have to maintain complexity for long periods of time, yet can realize incredible return on investment from small amounts of work.

Rothman doesn't spend much time on this idea, perhaps only two or three pages, but it left a big impression on me. Since then, I've used these ideas in my work. But perhaps more importantly, I've used this framework as a way to label what I've noticed good product leaders doing in their work. Since then, I've also learned about the concept of enabling constraints (from Liz Keogh and my own framework building) and have incorporated that into my approach.

An overview of the framework:

• Drivers are the positive impact(s) we hope to achieve (to increase, to decrease, to advance our, to maximize, to minimize)

• Example: Increase ease of onboarding for SMB customers (Decrease 90th percentile time from signup to Nth template revision and re-publish)

• Limiting constraints are the things we must navigate on our way to achieving those goals (but we, required to, need to, are constrained by, limited by)

• Example: Required to notify customers ~4 weeks in advance

• Floats are areas of flexibility, they increase range of movement and provide more options (we have flexibility to ____, ___ is optional)

• Example: We have flexibility when it comes to how extensible and integrated this needs to be (w/Admin and Flow Coordinator)

• Enabling constraints temporarily decreases the range of movement/options for the purpose of making progress. (we are choosing to ____, for now we ____, for now let’s ignore _____, later we can revisit ______ )

• Example: For now, let's ignore the downstream reconciliation workflow implications (let's revisit in June)

Together, these elements form a coherent statement for an effort. For example, we are working to increase the ease of onboarding for SMB customers. We are constrained by the need to notify customers four weeks in advance. We have flexibility when it comes to how extensible and integrated this needs to be, and for now, we can ignore the downstream reconciliation workflow implications.

Examples

The Basic Idea—What Do You Do With This?

The basic ideas is as follows:

1. Efforts with more drivers and limiting constraints will fail
2. Efforts with fewer drivers and limiting constraints have a higher likelihood of succeeding
3. Adding floats and enabling constraints improve the chance of success

The framework helps individuals and teams organize their thoughts and “shape” strategies, goals, and initiatives so they’ll be more likely to succeed.

Example

This example involves a product that allows people to maintain collections of movies (some they purchased on blu ray and laser disk). It is a complex product involving agreements with movie studios, multiple players, and different privacy regulations. The team is planning H1 2024. “A” attempts to juggle lots of constraints and drivers. Versions “B” and “C” narrow the focus and add areas of flexibility and enabling constraints.

How to define a driver

A template and prompt for defining drivers

Drivers are the positive impact(s) we hope to achieve (to increase, to decrease, to advance our, to maximize, to minimize). I like to use the following prompt for defining drivers.

Right now we are working to improve the ______A________ ______B________ for ______C_______ which we could potentially measure by tracking _____D_______.

Variable and Direction

A and B describe the variable and the direction we want to move it:

For example:

Right now, we are working to improve the (A) probability that (B) customers will create >=2 functional integrations within 15d of the first product use.

For A, I ask people to pick from a selection of noun/preposition pairs. The pair is connected to a variable (B), and describes disposition of, state of, quality of, etc. The trick here is that I force people to get specific by giving them lots of options (25):

• Speed of
• Quality of
• Ease of
• Efficiency of
• Efficacy of
• Our ability to
• Rate of
• Productivity of
• Growth of
• Probability that
• Extensibility of
• Probability that
• Maintainability of
• Cost structure of
• Unit economics of
• Our confidence that
• Reproducibility of
• Accuracy of
• Precision of
• Resilience of
• Predictability of
• Resolution of
• Consistency of
• Interoperability between
• Reliability of

C—For Who

In an ideal world, we would describe the FOR WHO. This step isn’t required in all situations but is extremely valuable.

For example:

Right now, we are working to improve the (A) probability that (B) customers will create >=2 functional integrations within 15d of the first product use for (C) customers arriving through organic search who view integration content.

D—Measurement

Next, we brainstorm some potential ways to measure our impact on the variable.

For example:

Right now, we are working to improve the (A) probability that (B) customers will create >=2 functional integrations within 15d of the first product use for (C) customers arriving through organic search who view integration content. We could potentially measure this tracking:

% that achieve the milestone

By channel

Look at drop-offs in the journey

Time, distribution of time

Many people combine measurement with the variable. For example, they might say, "We're trying to increase the number of daily active users." However, I prefer to decouple these because, in most cases, metrics alone don't really tell you what is valuable about that thing.

Daily active users is a proxy for something. If you are doing some kind of content play, daily active users might represent the number of eyeballs hitting your advertisements. However, if you're in a B2B SaaS product, you may not even want people to be active in your product every day. That might be a signal that your product isn't doing a good job at what it's trying to do. So, in general, make sure to decouple the variable from how you plan to measure it.

More examples of the prompt in action:

Right now, we are working to optimize the accuracy of personalized content recommendations during onboarding for users with specific industry backgrounds which we could potentially measure by tracking engagement with recommended content and subsequent feature adoption rates.

Right now, we are working to increase the efficiency of the account setup process for enterprise-level users which we could potentially measure by tracking the number of support tickets raised during setup and time to first key action in the platform.

Right now, we are working to enhance the efficiency of the reconciliation process for mid-tier customers using AccountPro which we could potentially measure by tracking the average time taken to reconcile accounts and the frequency of manual interventions required.

Right now, we are working to improve the accuracy of automated reconciliation matches for mid-tier businesses with a high volume of transactions which we could potentially measure by tracking the percentage of automatically reconciled transactions that are confirmed as correct by users and the reduction in manual corrections needed post-reconciliation.

Pressure Testing Drivers

A couple tests to figure out if we have a “good” driver

So, how do we know if we have a “good” driver?

We can apply four tests:

1. The Too Broad / Too Narrow Test: Try brainstorming solutions to see if we brainstorm too many or too few solutions.
2. The 'Oh But...' Test: When brainstorming solutions, do you find yourself saying, 'Oh but that can't work because of X' or 'Oh but that can't work because of Y'? If so, you probably haven't incorporated those constraints or drivers adequately.
3. The 'If I Knew' Test: If we find ourselves asking for more information because knowing something would lead us in a completely different direction, then there's a chance there are many unknowns, which is okay. Alternatively, it could mean that the driver itself is too vague.
4. The 'So What' Test: Is it clear why this matters? If not, we need a better driver. If it is, then we're okay."

The Too Broad / Too Narrow Test

A basic way to figure out if you have a good driver is as follows:

1. If a driver is too broad and open-ended, you'll be able to brainstorm a myriad of different approaches to achieve that goal. In a brainstorming session, the wall—virtual or otherwise—would be covered in sticky notes with all the ways you could have that impact.
2. If the driver is too narrow and there's only one way to achieve it, it's probably too specific and solution-oriented.

Imagine three values here:

1. Way too many brainstormed solutions, we need to narrow.
2. Way too few solutions, we need to broaden.
3. Just right

The “Oh But…” Test

Another way to determine if you have a good driver is to brainstorm potential solutions. If you find yourself discounting some solutions for various reasons, then you should probably have defined a better driver (or added another one). For example:

Say my driver is decreasing the time it takes for people to onboard our product. Maybe it currently takes 7 to 14 days with various activities and requires an administrator. I want to reduce that time.

A developer suggests removing the data import test altogether. If our goal is to decrease onboarding time, then making that optional seems logical. However, if we immediately discard that idea because bad data could set the account off on a bad track, it prompts us to question our goal.

Are we trying to decrease their time to value, the number of perceived steps, or the number of customers stalling onboarding? If removing the data import test accelerates onboarding, maybe we should make the driver about making it easier to test data or minimizing the impact of potentially bad data.

Three options:

1. When we brainstorm solutions, we end up having to discard most of them because the driver didn't really describe our thought process or specific goals.
2. When we brainstorm solutions, we end up discarding some of them, but it still seems like we are dealing with too many.
3. When we brainstorm solutions, we don't need to discard many of them. They're all fairly valid, and although we think some might work better than others, there aren't any that we can immediately discount because of connection to the driver.

The “If I Knew” Test

Less experienced people often don't know the factors that might alter their decision-making. As we gain experience, details start to matter. The "If I Knew" test asks what information would change one's path.

For example, if building a product for youth sports leagues, I might assume coaches are parents of the kids on the teams. But if I knew the league had paid coaches or coaches unrelated to any team members, I might implement different security protocols and design the product differently.

Three options:

1. When I consider the information that I would need to make good decisions, I have an endless list of follow-up questions. I would need a lot more information to make good decisions.
2. I'm not able to immediately rip this apart, at the same time, I'm not establishing a lot of conviction here.
3. I have enough information to guide my important decisions. I can't really identify details at the moment that would drastically shift my approach.

The “So What” Test

Finally, it's helpful to understand how the driver fits into the bigger picture. What will be the impact if we improve this aspect? If you can't answer that, you might need to adapt your driver.

Three options:

1. I have no idea why this matters.
2. I could guess there's some reason why this matters.
3. I know instantly why this matters for the business, and for our customers.

Pressure Testing Drivers Activity

Here are some example drivers. Apply the tests above:

"We are working to increase the happiness of our users."

"Increase usage of feature X by all users."

"Improve the load time of our website by 20%."

“Increase Our confidence that customers will renew their contracts.”

“Decrease the time it takes for SMB customers to accept their first online order without errors or outstanding issues"

“Decrease the friction involved in our SMB customers getting to the point where they can accept online orders, and ultimately the first 'payoff' of our product by taking their first order”

“Increase the probability of successfully answering product questions self-service (without needing to connect with live support) and users immediately using the new information to achieve goals in-product”

Here is one person’s take on our various tests applied to these examples. Of course, your answers (and the context around your answers) may vary.

Drivers vs. Limiting Constraints

The differences between drivers and limiting constraints (with a focus on deadlines, requirements, etc.)

It can sometimes be difficult to distinguish between drivers and limiting constraints.

For example a team might list a deadline as a driver and not as a limiting constraint.

How do you tell the difference?

Drivers:

• Represent value
• Represent the focus of the effort, not the constraint we must navigate around
• Are something we can increase or decrease that is beneficial
• Suggest impact

Limiting constraints:

• Add cognitive load
• Are not inherently valuable
• Make forward progress harder and more complicated
• Feeling like you’re making an unfortunate tradeoff
• Reduce the chance of success, or reduce positive impacts
• Not a flow state. Disruptive. Causes mental strain

How about deadlines?

In the case of a deadline, the big question is whether your company's key value proposition is your ability to hit deadlines. What would being 5 days late actually be worth? How about 30 days? What is your customer attempting to optimize for because of that deadline? Would the customer actually pay you more if you could achieve a better outcome for them? Would they give you more time? What role does the deadline play? If you are a company that charges a fixed cost for a project, it's very likely that a driver of yours could be the profitability of the project. This isn't as applicable for product work, but it could be a factor.

Should you include requirements as drivers?

The concept of requirements can be difficult to navigate here. If a customer says they will not buy your product unless your product does X, then you could argue that having that requirement is a driver. Or, maybe more specifically, closing that deal is a particular driver. However, if the requirement is a guess at what may produce future value, then it's questionable whether that requirement should ever be a driver. Instead, we might want to make the driver the goal the customer is hoping to achieve, for which they believe the requirement is necessary. In fact, we might list a constraint as the fact that the customer is sure that that thing is required.

How about speed?

Teams often list speed as a driver. Again, it's important to ask, speed for what? Is it speed of learning, is it speed to start earning, or is it speed for the sake of speed?

This is all to say that you should use your judgment when it comes to differentiating drivers and constraints. However, you should challenge things like deadlines, requirements, and regulations, and ask what's really driving the effort.

Limiting constraints vs. enabling constraints

How limiting constraints differ from enabling constraints

Scenarios

As an initial activity consider these two scenarios:

Scenario #1

A team has to maintain customizations of their product for their largest enterprise customers. Adding new enterprise customers isn’t getting easier—in fact, it’s becoming increasingly harder—they have yet to treat these customizations as a platform. When they roll out product improvements, they have to conduct regression testing across each of these customized versions; otherwise, they risk breaking things. Additionally, these large enterprise customers require at least 90 days of notice about new changes, and many of them have change approval boards for their vendors. To top it off, the team has developed knowledge silos and specialization. Their sales engineers specialize in particular customer customizations and can’t be moved around to meet emerging capacity needs.

Scenario #2

A team is dealing with a lot of personas for their product. Trying to build for all personas is problematic because these personas have very different adoption habits. Some customers take a while to try anything new, while other personas are early adopters and eagerly embrace every new change. There are differences, and you can’t automatically assume that what you build for the early adopter group will be immediately applicable for the later adopter group. That said, the team has to narrow their focus to make progress. They want to learn quickly and believe they can validate some of the big assumptions quickly, believing that this learning will benefit both groups eventually. So for their next big initiative, they agree to focus on the early adopters first, for at least three to four months. They “put a pin” in the assumptions related to the late adopting persona, acknowledging that risk.

Criteria for distinguishing enabling vs. limiting constraints

Both limiting and enabling constraints limit our options, however:

Limiting constraints (repeated from above):

• Add cognitive load
• Are not inherently valuable
• Make forward progress harder and more complicated
• Feeling like you’re making an unfortunate tradeoff
• Reduce the chance of success, or reduce positive impacts
• Not a flow state. Disruptive. Causes mental strain

Enabling constraints:

• Reduce cognitive load (but we do pay attention)
• Help us focus, help us be more creative, help us move forward
• Feel like a “load off”
• Increase our chance of success and moving forward
• Can be negotiated in the future
• Help teams get into a flow state

Let’s compare our scenarios using these criteria

Floats vs. Enabling Constraints

Comparing floats with enabling constraints

Floats are fairly straightforward to define, as they describe areas of flexibility.

You know you have a good float when it expands your options, frees you to try different approaches, and reduces pressure, among other benefits.

The key difference between floats and enabling constraints is that enabling constraints actually reduce your options, but in ways that benefit you. Floats, on the other hand, expand your options in ways that are also beneficial.

It pays to be explicit about floats. Here are some example floats:

We have flexibility when it comes to

• which customer segments we target.
• how extensible we need to make this.
• incorporating our brand assets.
• how consistent this needs to be across our product suite.
• the timeframe.
• which partners we will support initially.
• who can work on this.
• using vendors to augment the team.

Improving the chance of success (through shaping)

Narrowing drivers and constraints and adding floats/enabling constraints for more clarity

The basic idea with this framework is that if you have too many drivers or too many constraints, and you don't have enough floats, the effort will be more likely to fail. On some level, this is common sense. If you try to achieve too many goals at once, you may risk achieving none of those goals. If you try to navigate too many constraints at once, you may risk never finishing what you started. If you don't have enough areas of flexibility, then you'll have trouble navigating all those constraints.

The role of enabling constraints is a slightly more complex topic, but you likely already intuitively understand the value of enabling constraints. All of us have been in a situation where someone (or something) helped us narrow our focus, and held some variables constant, and this allowed us to make progress.

The basic idea is that by refining and limiting drivers and constraints, and adding floats and enabling constraints, we can increase the chance of success.

Example: Tightening Up an Initiative

Scenario: We're building a feature to help artists connect with their fans. Our product caters to superstar artists with millions of fans, as well as niche and up-and-coming artists, who are attempting to build their initial fan base. Research points to very low adoption rates for the current outreach channels. Fans originally sign up to follow, but don't necessarily keep up with the feeds. Meanwhile, for up-and-coming artists, it's hard to get an organic distribution loop going because they don't have an audience to begin with.

First Version of Initiative

In the first effort, we try to build for all artists. We don't distinguish between the superstar artists and the up-and-coming artists. And we don't distinguish between fans who are opting in to follow their favorite artists, but are overwhelmed by all the content, and fans who are curious about finding new content and breaking artists. Similarly, we load ourselves up with constraints like not changing the interface based on the artist type, not expanding to new channels, and being locked into the current feed data model.

That sounds destined to fail! Let’s revise:

Second Version of Initiative

In the second effort, we fine-tune our driver to increase the probability of connecting new and emerging artists with the types of fans that engage regularly with new and emerging artists, and growing emerging artist fan bases through those avid early adopter fans recommending those artists. We also agree that we can change up the feed interface as an experiment. And we agree to an enabling constraint to get something out to customers within the next 4 weeks, and specifically to artists who are attempting to break out who have a modest number of fans already. In other words, we're not going to target zero to one new artists.

A lot more floats! This is looking much more focused.

The Moves

The various moves available to you when shaping an initiative

Using this framework, we can identify a couple key moves that you can make given an initiative.

You can:

Reduce the number of drivers. Move non-drivers to floats.

Example:

A team was working on revamping the workflow for submitting work orders. One of the drivers was to migrate to a system of parent work orders and child work orders. There was evidence that some (but not all) customers needed this. Most customers just had a single work order associated with a maintenance task. The team also rationalized that since they were in the work order entry interface, and since customers were increasingly using the interface on a mobile browser, that they would optimize for entry on a mobile browser. You can see the problem here. Adopting a data model for parent and child work orders is very different from optimizing work order entry on a mobile browser. In fact, doing the former will make the latter that much more difficult. So the team decided to shift the mobile browser optimization to a float and focus on the parent and child work order problem.

Reduce the number of constraints and shift those constraints to floats (or enabling constraints).

Example:

A team was contemplating making changes to how it collected personal information. Naturally, they had to follow rules and regulations for GDPR and other data privacy guidelines. They currently operate in the United States and in Europe. To make progress, they decided to focus exclusively on the United States. Although this would be a little bit harder in the long run, this allowed them to test some key parts of the data model. In this sense, it was an enabling constraint, not a float.

Refine drivers and narrow them.

Example:

A nonprofit was eager to increase the average donation amount and to encourage people to sign up for regular giving campaigns, where money would be removed from their bank account on a regular basis. They were also at a shortfall for that year, and were falling well behind their goals. They realized that the goal of meeting their short-term target might be at odds with their goal of long-term, sustainable giving. They also didn't want to encourage people to set up recurring campaigns and not actively participate in the charity and its mission. So they divided up their efforts. They set one team about trying to hit that short-term goal, and in that effort, they didn't include incentives to sign up for recurring giving. They just needed to hit the short-term goal. And they signed another team to the target of sustainable, long-term giving with charity involvement. In fact, for that effort, they created a North Star around engaged givers, who not only gave money but who were active in events and the cause.

Be more specific about constraints.

Example:

A team listed a constraint as “resources.” They wanted to point out the fact that they didn't have unlimited resources to do everything they wanted to do, and therefore resources were going to be an issue. But after closer inspection, they realized that that was too vague. There are rarely situations where teams have unlimited resources. Instead, they chose to be specific about certain resources, and in their case, these resources were specialized data science roles that they were having trouble hiring for, and also specialized sales engineering roles that took a long time to train people up on. This helped them be more specific about the resources that were lacking.

Add more floats. Often, floats will emerge from shifted constraints. But it can help to continue to list a bunch of floats to inspire people to different ideas.

Example:

A team was trying to drive up the number of sign-ups for a Playbook by the end of the year. Their thought was that if they could get a lot of sign-ups, they could do a year-end wrap-up and send it to people who subscribed to company communications. The author of The Playbook desperately wanted to include a section on advanced techniques and an extended appendix. Originally, the team had a general float around scope, but as the effort became more clear, they realized that they could be more specific, so they added specific floats around the target persona, whether advanced techniques were necessary, and whether it was necessary to have a really robust appendix. Sure, the team might have been thinking these things, but it was helpful to just list them as floats.

A good technique here is to ask the question, when making decisions what might we know that would provide more optionality?”

Add enabling constraints.

Example:

A team had a good track record of cutting scope, but for a particular effort, they decided to shorten the time box even more, to make sure that things didn't get off track. This extra enabling constraint helped them make progress.

Refine enabling constraints.

Example:

A team had a general enabling constraint around focusing on a certain persona. But realistically, the persona never really narrowed things down as much as they wanted. So they specifically defined a set of criteria that let them identify the exact users who fit in that persona category. These are the customers that they were going to target.

Warning Signals: Too Many Drivers / Limiting Constraints

Warning signals that you may be on a team that is struggling with too many drivers and limiting constraints.

Warning Signals

Here are some warning signals that a team is struggling due to too many constraints and drivers

• Decision Drift: The team invests a lot of time and energy trying to make a decision or a set of decisions, and those decisions quickly drift and fall apart. Then, they're back to square one. You notice a lot of backtracking on decisions.
• Analysis Paralysis: You notice the team spending a lot of time trying to reconcile perceived trade-offs. They need increasingly more data to make increasingly more detailed trade-offs as they move forward.
• High Cognitive Load: You notice that team members don't seem to be completely present. Even making basic decisions is difficult. They might be less reliable than expected. You notice people zoning out in meetings, having lower attention spans, and needing to check out earlier in the day. When Friday rolls around, instead of people feeling energized, it looks like they've been through an incredibly long week.
• Complicated Plans: After a lot of deliberation, the team comes up with an intricate plan, with a lot of dependencies and contingencies. There’s a lot of "if this happens, then that will happen." It feels like a very fragile plan, and not very resilient considering the amount of uncertainty involved. You may see the team making a lot of premature decisions (scope, plans, etc.)
• Many Drivers and Constraints: When you ask the team what is motivating the effort, or driving the effort, they list lots of drivers. When you ask them to list constraints, they list lots of constraints. You observe them trying to check a lot of boxes when it comes to stakeholder needs, or assuming that by having lots of drivers, they are going to make lots of people happy.
• Circular Execution: When it comes to execution, the team appears to go in circles. After successive failures, they keep going back to the drawing board. In this reactive mode, they're driven to even more micro-optimization. You notice the team getting in a loop of not hitting the mark, going back to the drawing board, and instead of massively simplifying what they're doing, or using some enabling constraints, they layer on even more drivers and constraints.
• Unreliability: Because they're having trouble making progress, they may be tempted to take on more work than is reasonable. And because of this, they might be losing the trust of other teams that are working with them.

Caveat

The caveat with all this is that these symptoms are also present when teams lack experience, they lack a supportive environment, they are overloaded with work, there's low psychological safety of some sort, etc. So, you can't immediately assume that they have particular initiatives that are overdriven or over-constrained. However, if you step back, these environmental factors themselves impose limiting constraints on a team. A team that lacks experience has a limiting constraint of a lack of experience, and so you need more floats, more enabling constraints, and fewer drivers for a team in that situation.

What Makes a Good Enabling Constraint?

What makes a good enabling constraint?

A good enabling constraint:

• Lowers cognitive load. Makes decision making easier (quality and velocity)
• It is easy to describe, and know if you are doing it or not
• Is easy to follow. You don’t need to question yourself, analyze.
• Has an expiration date and which point you can reassess
• Is safe-to-fail. If it goes wrong, no one will be harmed, blamed, threatened
• Shapes conversations in positive ways: less time in analysis paralysis, more time talking about progress, what’s happened, what you’re going to do, etc.
• Doesn’t have a lot of caveats and gotchas that need more explanation
• Doesn’t get “adjudicated” every day/week. Not a negotiation each time

Scenario #1:

A team decides on a work in progress (WIP) limit. However, because they handle various types of work, they've decided to segment their WIP limit and classify items based on the outcomes of a meeting held every Monday. The team will assign a complexity score to each item, which they will then use to assign the work to one of four categories. Each category will have its own WIP limit.

The concept of WIP limits has been debated, so they decide not to include blocked items in the WIP limit count. Items can be flagged as blocked, and this does not apply to the general rule. Additionally, since the QA team is short-staffed, they have items that get "pushed back" based on capacity. These items are not counted in the main WIP limit calculation but in a separate calculation.

There is also a parallel roadmap from the engineering team. In the planning for the enabling constraint, there were concerns about how to treat these items. Sometimes, engineers are concerned about surfacing "invisible" work that originates from the engineering roadmap. This issue was left somewhat unresolved when they established the WIP limit. Incentives are a bit out of whack, with people being cautious about surfacing all of their work.

Checklist and assessment:

• Lowers Cognitive Load: The scenario seems to add complexity rather than reduce it. The process of classifying work into different categories based on complexity scores, and having different WIP limits for each category, increases decision-making complexity.
• Easy to Describe and Follow: The process described is quite detailed and involves several exceptions (e.g., blocked items, pushed-back QA items, parallel engineering roadmap). This complexity makes it harder to describe and follow without questioning or analysis.
• Expiration Date for Reassessment: The scenario does not mention an expiration date or a specific timeline for reassessing the effectiveness of the WIP limit.
• Safe-to-Fail: The scenario doesn't clearly indicate whether implementing this WIP limit is safe-to-fail. Given the complexity and the unresolved issues (like the treatment of items from the engineering roadmap), it seems there could be significant risks if the system doesn’t work as intended.
• Shapes Conversations Positively: The scenario suggests potential for confusion and concern (e.g., incentives being out of whack, reluctance to surface all work). This environment might lead to more time spent in confusion and less on discussing progress.
• Lacks Caveats and Gotchas: The scenario has multiple caveats and exceptions, such as the treatment of blocked items and the separate handling of QA capacity issues.
• Doesn’t Require Frequent Adjudication: Given the complexity and the unresolved issues, it seems likely that the WIP limits and their exceptions would require frequent reassessment and negotiation.

Scenario #2

A leader describes four key priorities and force-ranks them; they are ordered. The basic advice to everyone in her group is as follows:

1. Whenever there is an opportunity to work on a higher priority item, that is where you are expected to invest your time.
2. We acknowledge that not everyone can work on all areas of the codebase, so if you can't work on a higher priority, do the following: A) work on smaller batches of work (1-3 weeks) in case opportunities to work on higher priority work open up, and B) don't get in the way of higher priority work by burdening dependencies who might be helping with the higher priority work.
3. We will do this for one quarter and assess progress, at which point we can renegotiate it.

4. "Even if we don't get this perfect, I'm fine taking responsibility for questions and concerns from stakeholders." Anyone working on a higher priority item has the go-ahead to say no to any other work. Overall, we want to keep a batch size of less than one month before getting anything into production.

Checklist and assessment:

• Lowers Cognitive Load: This approach does seem to reduce cognitive load. By force-ranking priorities and providing clear guidelines on where to focus efforts, the team members have a straightforward decision-making process regarding their work priorities.
• Easy to Describe and Follow: The directive is clear and easy to understand. It outlines a simple hierarchy of priorities and gives actionable steps for team members who can't work directly on the highest priority tasks.
• Expiration Date for Reassessment: The leader has set a clear timeline for this approach – one quarter. This provides a definite period after which the team will reassess, adding clarity and a sense of temporariness.
• Safe-to-Fail: The leader's statement, "Even if we don’t get this perfect, I’m fine taking responsibility for questions and concerns from stakeholders", indicates a safe-to-fail environment. It shows that the leader is willing to bear the responsibility for potential shortcomings, which can encourage team members to embrace the new approach without fear.
• Shapes Conversations Positively: This directive focuses the team's conversation on progress and prioritization, likely reducing time spent on deciding what to work on and more on actual progress.
• Lacks Caveats and Gotchas: The directive is straightforward without too many complications or exceptions. It's clear about the expectations and the process.
• Doesn’t Require Frequent Adjudication: The guidance seems designed to stand on its own without the need for constant negotiation or revisiting. The rules are set for a quarter, indicating that it won’t require frequent adjustment.

Examples of Enabling Constraints

Here are some examples of enabling constraints

The enabling constraints mentioned above focus on the “how” aspect of a team’s work. Consider also:

• Focusing on one customer segment at a time.
• Focusing on one form factor at a time (for example, mobile or desktop).
• Constraining yourself to the existing architecture (though this could also be a limiting constraint).
• Constraining yourself to one part of the customer journey.

Enabling Constraint (Before and After)

Comparing how we feel without and with enabling constraints

Before adding the enabling constraint, the team feels:

• Stuck
• Going in circles
• Back where they started
• Their heads hurt
• Every meeting is a chore
• Like they're in quicksand
• This feels like a maze
• Challenged, in a bad way

After adding the enabling constraint, the team feels:

• Motivated
• Clear-headed
• Moving forward
• Liberated
• Challenged, in a good way
• Hopeful
• Inspired
• Able to act
  

Learn to trust what you are seeing and feeling. You’ll know when there’s a breakthrough and the enabling constraint is having an effect.

Static vs. Dynamic Optimization Problems (and why it Matters)

Comparing static and dynamic optimization problems

Framing things as a combination of drivers, constraints, floats, and enabling constraints should remind some of you of optimization problems. In optimization problems, the goal is often to find the best solution within a set of given constraints. The problem becomes more complex and harder to solve effectively as the number of constraints and objectives increases, particularly if these constraints and objectives conflict with one another.

There are several aspects of product development that we need to keep in mind:

1. Learning. We have the opportunity to learn as we go. Our understanding of the problem and the solution space evolves with each iteration. We can use enabling constraints to focus on one potential solution, learn from that solution, and then expand to other parts of the problem. This approach helps to simplify complex problems and make them more manageable.
2. Flexible constraints and objectives. Our constraints are not set in stone; over time, we can refine the objective function as we learn more. This flexibility allows us to adapt to new insights and changing circumstances.
3. Perfection is not the goal. We don't need perfection; there's a lot of benefit in extracting 80% of the value with 20% of the work. So, this is not an all-or-nothing affair where we either solve the problem entirely or don't solve it at all.
4. Long-term. In product work, today’s success is often dictated by making decisions over many years.
5. Different Solutions. Many problems can be solved in completely different ways, and we can achieve the exact same outcome using various tactics. Flexibility and creativity in approach are key in product development.

With product work we are dealing with a dynamic optimization problem, not a static optimization problem.

So why does this matter?

When defining drivers, limiting constraints, floats, and enabling constraints, it is important to remember that you are dealing with a dynamic optimization problem, not a static optimization problem. This is why enabling constraints and floats are so important. Enabling constraints help us focus on an area of the problem and constrain our options temporarily, but we're still dealing with a dynamic optimization problem. Similarly, with drivers, it doesn't pay to work on all of our drivers at once, because we can expand the drivers we are addressing over time as we learn.

Limiting constraints can be problematic because they force us to treat the problem as a static optimization problem, even though ideally it isn't. The beauty of dynamic optimization problems is that we can exploit the uncertainty to our benefit. We don't want to be playing three-dimensional Tetris with a bunch of limiting constraints.

Experience and Tradeoffs

The impact of experience on how we perceive tradeoffs and why it matters

It's very important to realize that our perception of trade-offs changes as we gain more experience.

For example, my perception of the trade-off between quality and speed has evolved over the years.

1. Initially, I believed there was a clear trade-off: slowing down meant higher quality, and to go fast, you had to lower quality.
2. Then, I started to understand it as a trade-off between immediate quality and future quality, believing that a slight slowdown now could yield better quality later
3. I eventually realized that speed and quality were more like polarities than a trade-off. Moving quickly and integrating often could lead to higher quality, which in turn allows for faster progress. This led me to stop viewing speed and quality as opposing forces.

We also notice trade-offs that we didn’t see before.

1. Early in my career, I might have built for a certain persona without worrying much about the details.
2. But as I gained experience, I realized that nuances, such as understanding power dynamics within a B2B customer's organization, could significantly alter my approach. For example, I might develop features specifically for decision-makers who might not be the end users, but who might need to justify the value of the product.

With more experience, I also learned the limits of certain factors.

1. I used to be concerned about whether an engineer spent 25% versus 35% of their time on a task.
2. But I later realized that the real issue was multitasking rather than the specific time allocation.

This understanding relates to the use of enabling constraints. Less experienced individuals might hesitate to use enabling constraints, trying to hyper-optimize capacity allocation. However, with experience and an understanding of the situation's dynamics, decision-making evolves.

Good Times, Normal Times, and Hard Times

How our perception of trade offs differs during good, normal, and hard times

In good times, teams are generally under less pressure to hyper optimize and are more likely to be given flexibility. In normal times, there's always some back and forth. Managers want teams to detail their trade-offs and expect pushback, while teams want to share their thoughts and have leaders prioritize. In harder times, things get tougher. Leaders, experiencing analysis paralysis, are stuck and feel a greater need to understand trade-offs. They face more pressure to hyper optimize and do more with less, while teams desperately want clear decisions and priorities.

This relates to our discussion today. In harder times, there is a tendency to add more limiting constraints and drivers, and be cautious about using enabling constraints. When things hit rock bottom, enabling constraints are often introduced, like focusing solely on survival.

The important point is that these are the exact conditions where enabling constraints are powerful. We need decisive, easy-to-follow constraints. As things get harder and more complex, our ability to make good decisions decreases, but the demand for good decisions increases.

Despite the pressure to add limiting constraints and drivers, remember that during tough times, enabling constraints are crucial to make sense of uncertainty and move forward with focus.

Making the Case

Making the case for reducing drivers and limiting constraints, and adding floats and enabling constraints

We've noted that experience is a factor when it comes to advocating for reducing the number of drivers, reducing the number of constraints, adding floats, and adding enabling constraints.

Being static optimization problems, it makes sense that people would believe that if you just plan hard enough, you can brute-force the optimization problem and end up with a solution. But we know we're dealing with dynamic optimization problems.

Here are some tips for making the case and advocating for fewer drivers, fewer constraints, more floats, and more enabling constraints:

1. Highlight the risks. Adding drivers and constraints increases the chance of failure. You need to make this clear to everyone involved.
2. Give very clear examples of how trying to achieve too many drivers can send the team in too many directions.
3. Advocate for a short-term experiment with an enabling constraint and show the results.
4. Discuss the difference between static and dynamic optimization problems and their implications.
5. Give examples of how, given a certain driver, the team could brainstorm many different solutions, and then discuss whether those solutions would actually fit the bill.
6. Really dig into the effects of high cognitive load. No one wants a team making poor decisions. Create an environment where people can openly discuss the levels of cognitive load they are experiencing.
7. Invite people to offer drivers and constraints. Engage them in the activity. Explain how adding more adds to levels of risk.
8. Focus on the feeling of flow that a team gets when they can be focused and making progress toward a goal. We can all relate to that feeling.
9. Use fun examples like vacations, planning a family meal, or figuring out how to navigate a new city.
10. Stress the power of learning and how drivers can be adapted over time, constraints can be explored, floats can be added, etc. What you're showing is not a static thing; it's something that can emerge.