To Think Outside the Box, First Squeeze It
To think outside the box, you first need to squeeze it. Most teams treat constraints as obstacles. But some force clarity. Others hide the real problem. The worst ones? Still invisible. A framework for finding what matters when everything feels important.
You're working hard, but you're not making progress. Your team ships, but the metrics don't move. The velocity is high, but the impact is low.
The problem isn't your effort. It's the constraints you can't see. Some constraints should be squeezed. Others should be questioned. And the most dangerous ones? You don't even know they exist.
John was sitting in his cubicle, head down on the table, trying to think outside the box. His last project had failed because he didn't question the scope committed above his paygrade. This time, he wouldn't make that mistake. He had been tasked to increase retention metrics by 5% in the coming quarter, but he wasn't sure where to start.
Let's look at John's problem:
Increase the metrics by 5% in the coming quarter.
Timeline: 3 months
Goal: +5%
The timeline is reasonable. Three months is generally enough time to make a meaningful impact on retention.
The goal, however, seems arbitrary. Why 5%? Why not 3 or 10? What has been the trend until now? Is retention increasing or decreasing?
This is where John finds himself trying to understand the reasoning behind the target and what he can do to achieve it.
John's target was an OKR — Objectives and Key Results, the framework Google popularized for aligning goals. His Key Result: increase retention by 5%. After talking to his skip, he learned these KRs were "aspirational" but important. The problem? John still didn't understand if the 5% improvement would actually improve retention. The reasoning had gotten lost in the layers of translation.
John made a pragmatic choice. He shouldn't wait for perfect clarity on where the 5% came from. Instead, he'd identify what would actually move retention, regardless of whether it hit an arbitrary number.
John had a clear set of next steps:
- Don't be limited by the 5% target until the reasoning is fully clear.
- Identify the maximum impact areas achievable within the target timeline.
He asked Claude to analyze customer calls, support tickets, survey results, and churn patterns from the last 6 months.
Claude came back with a sorted list of 4 impactful areas worth prioritizing. The results weren't surprising, but John made an interesting observation. The 4 areas were in drastically different directions:
- Market Positioning - Customers arrived with mismatched expectations
- User Experience - Complicated workflows drove occasional complaints
- Reliability - Bug reports were a leading indicator of churn
- Missing Features - Customers relied on third-party workarounds
Not satisfied, John decided to reframe the problem. If I could only solve for one and had only one month, what would I focus my efforts on?
He dug into the customers who had churned and found that while the average churn was X%, the Enterprise customers, who represented 70% of the revenue, were churning at 2x the rate of SMB customers. And 80% of them cited the same issue: Reliability.
He discussed this with stakeholders and shared his findings. Leadership agreed. They updated the OKR: +5% retention for Enterprise customers.
Four problems. Four customer segments. But only one combination actually mattered: solve Reliability for enterprise customers.
- Market positioning? Doesn't matter if enterprise customers are leaving.
- UX improvements? Nice to have, but not the core.
- Missing features? Only if enterprise is asking for them.
- Reliability? Non-negotiable.
Three months later, John's dashboard showed 2% retention improvement. He'd missed the KR. But when finance ran the numbers, enterprise churn had dropped by 40%, saving $2.3M in annual recurring revenue. The original 5% target aimed at all customers would have spread his efforts thin, chasing SMB and mid-market customers who represented a fraction of the impact. The constraint he ignored saved the quarter. The constraint he found — enterprise customers, saved the business.
John's story isn't unique. Every team faces constraints. The question isn't whether constraints help or hurt. It's knowing which ones to squeeze, which ones to break, and which ones you haven't discovered yet.
The Power of Constraints
Most teams treat all constraints the same: obstacles to overcome.
But constraints aren't just obstacles. Leveraged correctly, they help focus your efforts into solutions that actually matter by introducing boundaries to your problem set.
These constraints aren't created equal. You have to tighten some, break others, and occasionally find the missing ones.
The difference comes down to two questions:
- Is a constraint REAL or ARTIFICIAL?
- Is a constraint VISIBLE or INVISIBLE?
Real constraints are constraints you cannot change or are beyond your control. Laws, physics, resources. You have to work within them.
Artificial constraints are targets and assumptions someone chose. These can also be inherited rules. Someone at some point made them up. These are decisions that can be questioned.
Visible constraints are the ones you can see and name. Like fences, these can be moved, broken, jumped over, or in some cases even enforced to setup guardrails.
Invisible constraints, the toughest of the lot, are patterns, segments, or assumptions you haven't discovered yet. Why are they the toughest? Because unless you identify these, you won't know what you are working with and these constraints may silently break your solution and only appear retrospectively.
Put them together and you get a simple prioritization framework with four types of constraints:
| VISIBLE | INVISIBLE | |
|---|---|---|
| REAL | Time, budget, physics, legal | Hidden patterns, actual user needs, true dependencies |
| ARTIFICIAL | Arbitrary targets, old policies, inherited rules | Unstated assumptions, "how we've always done it" |
Based on the type of constraint and how you categorize them, you can decide what to do with them.
Let's walk through each and understand what action to take:
1. Real + Visible: Squeeze Them to Find Focus
John had 3 months to make an impact. That's real and visible. He couldn't change it, so instead he squeezed: "If I only had 1 month, what would I focus on?" The tighter constraint forced elimination of less impactful solutions.
When to use: You're drowning in options. Add a tighter constraint to force focus on what's essential.
2. Artificial + Visible: Question Them
The 5% improvement target was arbitrary.
John questioned it: "Why 5%? Where did this come from? Is this even the right metric?" Breaking free from this constraint let him optimize for business impact instead. We often take these constraints at face value, which can lead to a failure at the Bet Layer where the team executes perfectly against the wrong goal. Push back. Question what doesn't make sense.
When to use: A constraint feels wrong or disconnected from the actual goal. Question its origin.
3. Real + Invisible: Reveal These
Enterprise customers bringing 70% of the revenue was real but John didn't see it until he dug into the data.
Once revealed, this invisible constraint reframed everything: solving for "all customers" was the wrong problem.
When to use: The solution feels too broad or unfocused. Identify the variables that affect your problem and search for the hidden pattern that narrows the real problem.
4. Artificial + Invisible: Surface These
John assumed he was solving for all customers but he didn't even realize he'd made that assumption until the data surfaced the truth: enterprise customers represented 70% of revenue. Once surfaced, he replaced the artificial constraint (all customers) with the real one (enterprise customers).
When to use: You keep spinning on the same problem. List every assumption you're making. One of them is likely blocking the solution.
The Framework in Practice
The 2-Second Pit Stop: When Time Is the Only Thing That Matters
In the 1950s, Formula 1 pit stops were chaos.
Four people worked on the car, including the driver, who helped while the crew used mallets to knock wheels off the axle. The whole process took over a minute. Pit stops were something you avoided unless you had no choice.
Today, twenty people change four tires in under two seconds. The current world record is 1.80 seconds.
That's obsession.
The constraint is brutal and immovable: the race is happening, competitors are gaining ground, and every tenth of a second costs track position. You can't negotiate with physics. You can't ask for more time.
So teams squeezed the only thing they could control: Efficiency.
The answer wasn't fewer people. It was more. Where 1950s crews had four generalists doing multiple tasks, modern teams deploy over twenty specialists. The front-right tire changer doesn't touch the rear-left. He removes one wheel, ten thousand times, until his hands move faster than thought. Three people per corner: one removes the old wheel, one mounts the new one, one operates the gun. Parallel execution. No waiting. No wasted motion.
Teams practice pit stops dozens of times every race weekend, starting before sunrise. They use video analysis to study every frame. They employ dedicated pit stop coaches who scrutinize hand positions, foot placement, the angle of the wheel gun. They train crews like Olympic athletes — reaction drills, physical conditioning, muscle memory exercises.
Since 2013, the world record has improved by only 0.12 seconds because they've squeezed the constraint so hard they're hitting the limits of human reaction time.
When the only thing that matters is time, everything else becomes negotiable. More people? Add them. More practice hours? Schedule them. More analysis? Study every frame. The constraint forces clarity: if it doesn't make the stop faster, it doesn't survive.
The Email That Generated 42% More Clicks By Doing Less
Whirlpool's marketing team was about to launch an email campaign with four calls-to-action. Three buttons pointed to different product features. Only one pointed to a rebate page, the actual business goal.
Tom Mender, their Senior Database Marketing Manager, had just learned a principle at a conference: quality of clicks matters more than quantity. Years of A/B testing had proven that emails with a single focused CTA outperformed those with multiple options.
He saw the disconnect immediately. All four links sent consumers in a different direction. Only one of them actually aligned to what the goal of the email was.
The campaign was days from launch. The agency had already designed the email. The assumption — more CTAs equals more clicks — was baked into the creative. But Mender forced his team to test it anyway.
Control: 4 CTAs.
Treatment: 1 CTA. Just the rebate button.
Result: 42% increase in clicks.
But the impact went beyond one campaign. The test sparked what Mender called "a 180-degree turn" in how Whirlpool marketed, creating a test-and-learn culture across the organization.
When you constrain a choice to align with a singular goal, you don't just improve metrics. You clarify what you're actually trying to accomplish.
The Developer-Only Customer: How Stripe Squeezed Its Audience
In 2010, accepting payments online was a nightmare.
Legacy processors demanded merchant account applications, relationship managers, and convoluted APIs designed for enterprise sales. Weeks of integration work. Opaque pricing. The process was built for CFOs negotiating contracts, not developers trying to build products.
Thousands of internet businesses were never built because accepting money was simply too hard.
Stripe made a radical bet: constrain the customer base to one group. Developers.
Not business owners. Not procurement teams. Just developers who wrote code.
The constraint forced every product decision through a single filter: does this make a developer's life easier?
The result was radical simplification. A few lines of code processed payments instantly. No applications. No waiting. Developers could sign up and start testing immediately. Pricing was transparent, no negotiation required.
But constraining to developers meant sacrificing the traditional path. No enterprise sales teams. No targeting executives. No competing for brand recognition.
The tradeoff was deliberate. Developers integrated Stripe before asking permission. By the time executives decided on a payment provider, Stripe was already in production. The switching cost made it irreversible.
Documentation became the sales channel. Self-serve onboarding eliminated support costs. The company invested in developer experience over sales teams.
The constraint worked. Bottom-up adoption created viral growth. Once integrated, customers couldn't leave. From that foundation, Stripe expanded into a $95B platform.
When you squeeze your customer base to a single audience, you can't be everything to everyone. But you can be essential to the people who matter.
Conclusion: Squeeze the Box
John started this story trying to think outside the box. That's what we're told to do when we're stuck, isn't it? Break free from constraints. Dream bigger. Remove the limitations. But that advice sent him in circles, staring at a vague five percent target with no idea where to begin.
The breakthrough didn't come from thinking outside the box. It came from squeezing it until only the essential remained. Three months became one month in his mind. Four problems became one problem. All customers became enterprise customers. Every time he tightened a constraint, the path forward became clearer.
To think outside the box, you first need to know what's actually in it.
You need to understand which walls are real and which ones you built yourself. You need to see the constraints you didn't realize you were carrying. And sometimes, you need to make the box smaller before you can see past it.
The next time you're stuck on a problem that feels too big or too vague, try this:
Squeeze. Ask yourself: if I only had half the time, what would I focus on? If I could only solve this for one customer segment, which one keeps the business alive? If I had to choose one metric that actually matters, what would it be?
Question. Which constraints did someone hand me, and which ones did I assume? The five percent target, the assumption that you're solving for all customers, the belief that you need every feature before launching. These aren't laws of physics. They're choices, and choices can be questioned.
Search. What constraints exist that you haven't seen yet? What patterns are hiding in your data? What segments are you overlooking? The invisible constraints are often the ones that matter most, and you won't find them by thinking harder. You find them by looking at what the system is actually telling you.
John's story isn't unique. Every team faces constraints. The question isn't whether constraints help or hurt. It's knowing which ones to squeeze, which ones to break, and which ones you haven't discovered yet. Start with one. Pick a constraint you've been taking for granted and ask: is this real, or did someone just make it up? That single question might be the squeeze you need.