Three ways to tell if your strategy is load-bearing

The weight test nobody runs

Most strategic plans collapse under scrutiny not because the logic is wrong, but because the assumptions underneath can't carry the load. A three-year roadmap rests on a forecast. A pricing model rests on customer segmentation. A partnership rests on aligned incentives. The plan looks fine until you ask: what happens when we actually put weight on this?

I run a simple diagnostic with clients before they commit resources. Three questions, twenty minutes, and we usually find at least one assumption that won't hold.

1. Can you state the inverse?

If your strategy depends on "customers want convenience," write down the opposite: "customers will tolerate friction for X." If you can't fill in X with something specific and testable, the original claim isn't load-bearing—it's decorative.

A regional logistics company told me their expansion plan assumed "demand for same-day delivery is growing." The inverse: "customers will wait 48 hours if..." They couldn't finish the sentence. Turned out they'd never measured willingness-to-wait, never tested pricing tiers by speed, never mapped which customer segments actually valued immediacy. The plan was resting on a surface that didn't exist.

We spent two weeks running small experiments—offering next-day at a discount, same-day at a premium, letting customers choose. The assumption reformed under measurement. Some customers would wait a week for a 15% discount. Others paid double for four-hour windows. The strategy that emerged wasn't "expand same-day coverage"; it was "segment by time-sensitivity and price accordingly." Load-bearing.

2. What happens at 3×?

Double your key variable and watch what breaks. If you're planning to hire 50 people, model 150. If you're launching in two cities, sketch five. If you're processing 10,000 transactions a month, pretend it's 30,000.

This isn't about realistic growth—it's about finding which parts of your plan are structural and which are scaffolding. Structural elements scale cleanly or fail in predictable ways. Scaffolding just falls over.

A software team came to us with a plan to reduce support tickets by improving documentation. At current volume—maybe 200 tickets a week—better docs would help. At 3× volume, even perfect documentation wouldn't matter because the problem wasn't information access, it was product complexity. The plan was resting on a local minimum. We tripled the assumed load, the assumption cracked, and the real strategy surfaced: simplify three core workflows before writing a single help article.

3. Can you find the equation?

Every strategy implies a relationship between inputs and outputs. Revenue grows when we reduce friction. Retention improves when we add features. Efficiency increases when we centralize operations. Write it down as an equation, even a rough one, and see if the math is possible.

A library system wanted to expand programming—more author talks, more workshops, more community events—to increase membership. The implicit equation: more events → more members. But when we mapped it, the numbers didn't close. Each event reached maybe 30 people. Conversion from attendee to member ran about 10%. To hit their membership target, they'd need to run 90 events a year with their current staffing, which was two full-time coordinators. The surface couldn't support that load.

The equation revealed the real constraint: staffing, not programming. The strategy shifted to fewer, larger events and a volunteer training program. Load redistributed, plan held.

When the surface is curved

Sometimes you'll test an assumption and find it holds locally but not globally—it's true in your current context, at your current scale, with your current constraints, but the surface curves away from you as conditions change. A pricing strategy that works at 5,000 users and fails at 50,000. A management structure that scales to four teams and collapses at seven.

These aren't bad strategies. They're strategies with a load limit, and knowing the limit is half the work. The other half is deciding whether to reinforce the surface or accept the boundary.

I worked with a consultancy whose referral model was load-bearing up to about 40 clients. Past that, the math required more referrals than their clients could plausibly generate. The surface was curved—exponential demand against linear supply. They had two options: accept the boundary and stay small, or find a second surface to rest on (outbound sales, partnerships, content). They chose the boundary. The strategy held because they knew exactly how much weight it could carry.

Run the test

Pick your current plan. State the inverse of your key assumption. Model it at 3×. Write the equation. If any of those exercises feels impossible, you've found the spot where the surface is thinnest.

Most teams skip this step because the plan already feels finished. But a finished plan that can't carry weight is just expensive documentation. Better to find the weak point now, while you can still redistribute the load.

For the full assumption-mapping process, see surface analysis. For what to do when an assumption fails under test, start with projection—sometimes the strategy works fine in a different dimension.