Asymmetric Strategy: Shogun's 3 Steps to Win Uneven Fights
Shogun's asymmetric strategy: how Toranaga beat a stronger coalition by finding their weak spot. 3 key steps.
TABLE OF CONTENTS
Overengineering: Stop Feeding Wants and Starving Your Needs
Cure overengineering and false constraint paralysis today.
Overengineering: When Wants Win, Needs Lose
The drive for perfection often creates a massive growth ceiling for your daily operations.
When faced with a frustrating daily problem, your instinct might be to design a flawless, fully automated system before taking any action.
If you fail to break this habit of overengineering, you stay trapped in analysis paralysis while the problem remains unsolved. But if you succeed, you learn to use rapid prototyping to shatter false constraints and achieve your dream outcome at a fraction of the cost.
The 3 Core Drivers of Overengineering
Most people use one of two common approaches when faced with a frustrating problem.
The first is premature optimization, where you try to mentally engineer a flawless, fully automated system before taking any action.
The second is solution abandonment, where you simply accept the friction and leave a core need unmet because building the perfect fix feels too exhausting.
These approaches have the following limitations that make it hard to distinguish ‘nice to have’ wants versus ‘must have’ needs:
Rigid Framing
When expensive requirements aren't explicitly ranked and tested, every item on the mental list feels equally critical. There’s no mechanism to discover which requirements are truly load-bearing versus which are simply assumed conveniences.
For instance, a "not bending down" requirement might feel like a need until you later realize it’s a negotiable want — but without a crawl-walk-run test, that distinction never surfaces.
When you refuse to test a messy, incomplete solution, you lack immediate data. Waiting for a fully polished execution phase prevents you from discovering that your ‘perfect’ comprehensive solution might actually be subpar at what matters most to you.
Optimizing for the wrong pain
Product searches and workaround tolerance both focus on the surface symptom (the task itself — scrubbing) rather than the true issue (bare hands, lack of leverage, friction of access that prevent long-term adoption). Existing approaches never force the person to articulate what specifically they hate, so solutions keep targeting the wrong variable.
Designing a complex solution based purely on theory often blinds you to the actual dealbreakers. You might build an intricate tool only to realize you hate the setup process, proving you ignored a true, hidden requirement: the solution needed to be easy to grab and go.
Perfectionism & the joy of building
Standard problem-solving jumps to a "complete" solution: one product, one tool, one fix. This blocks the discovery that a multi-component solution (for instance, a handheld scrubber + spray bottle) can be better than any single perfect product — and far cheaper, more accessible, and easier to grab and go.
There’s also a real joy in building that quietly fuels this instinct: every added feature feels justified because it’s satisfying to create your perfect thing. That momentum turns into an ever-growing task list, where “might as well add this too” leads to something bloated, complex, or expensive to maintain or adopt.
A 3 Step Roadmap to Cure Overengineering
The common approach is to list requirements, wait until a solution meets all of them, and then act. The approach we built is different because it uses a deliberate constraint test that actively fights overengineering.
It intentionally forces you to try a solution that you know violates some of your assumed requirements and prioritizing those that help you get real data quickly.
By taking immediate, imperfect action, it uses feedback to prove which needs were real and which were nice-to-have wants.
Step 1: The Crawl Phase Fights Overengineering
What This Is
This step involves separating the absolute core mechanical need from the delivery mechanism. You isolate the cheapest, fastest, lowest-fidelity way to test the core mechanic of the problem you are trying to solve.
Why It Matters
This addresses the Rigid Problem Framing driver. Instead of planning a complex final execution phase, you define a basic "crawl" phase, bypassing the analysis paralysis that leads to overengineering. I find that calling it a ‘crawl’ does something psychologically, giving you permission to do something imperfect because you know you can always make it better in a future ‘walk’ or ‘run’ phase.
How You Can Use It
You will use the Constraint Stripping Protocol. You list every assumed requirement of your desired solution and cross off everything except the one physical action required to generate a result.
Examples (Toggle for more)
- Less Productive Example
- John needs to clean a stubborn stain on his floor. He spends three weeks sketching designs for a specialized brush that will attach to his expensive shop vacuum because he assumes the tool must be automated and he must not bend over.
- More Productive Example
- John applies the Constraint Stripping Protocol to his floor cleaning problem.
- He reflects on prior experiences and workarounds, and recognizes one major mechanical need is generating enough friction against the floor.
- He decides his "crawl" phase will simply be using a scrubber he jerryrigs in five minutes using existing tools while also using a basic spray bottle of cleaner.
- Decision and Output: John stops prioritizing his preference to not bend over, allowing him to define a testable action that bypasses weeks of overengineering.
Step 2: The Imperfect Prototype Defeats Overengineering
What This Is
This step involves executing the "crawl" phase while intentionally violating your assumed requirements. You use the basic tool, knowing it forces you to experience the friction you were trying to avoid.
Why It Matters
This addresses the Optimizing for the Wrong Pain driver. By generating immediate feedback, you test the actual physics of the problem, discovering that complex solutions may actually deliver a subpar outcome on your most important needs.
How You Can Use It
You will use the Testing Mandate. You set a timer for, say, ten minutes and force yourself to attempt the task using only the basic, stripped-down tools you identified in the previous step.
Examples (Toggle for more)
- Less Productive Example
- John spends hours buying an expensive specialized spinner brush tool to avoid getting his hands dirty and allows him to use it while standing up. But when he tries to use it, the spinning bristles lack the leverage needed to scrape the stain, the most important need, wasting his time and money.
- More Productive Example
- John uses the Testing Mandate and grabs the scrubber he jerryrigged and spray bottle.
- He bends over and physically scrubs the stain, intentionally violating his initial rule against bending down.
- He realizes that the handheld scrubber provides the exact heavy leverage needed to remove the dirt instantly.
- Decision and Output: John experiences immediate physical feedback that proves his overengineering instinct was wrong.
Step 3: Calibration Cures Overengineering
What This Is
This step involves reviewing the physical test to permanently discard false constraints. You acknowledge which preferences were acceptable to break and which requirements were actually non-negotiable.
Why It Matters
This addresses the Misidentified Root Pains driver. You redefine your success criteria based on reality rather than theory, ensuring that any future systems you build are actually easy to adopt and use.
How You Can Use It
You will use the Need Versus Want Filter. You review your physical test and categorize the friction points to determine what actually matters for long-term user adoption.
Examples (Toggle for more)
- Less Productive Example
- John continues to try and force the vacuum attachment to work because he already spent money on it, falling victim to the sunk cost fallacy and leaving the floor partially dirty for another week.
- More Productive Example
- John uses the Need Versus Want Filter to review his experience scrubbing the floor by hand.
- He acknowledges that bending down was not actually that bad, but getting his bare hands dirty was completely unacceptable.
- He realizes that a complex, heavy vacuum attachment violates his newfound need for a solution that is quick and easy to grab and go.
- Decision and Output: John permanently discards the false constraint that the tool must attach to a vacuum, sticking with his jerryrigged solution for now, permanently curing his overengineering paralysis.
Actionable Checklist for Overengineering
Checklist (Toggle for more)
- List all assumed requirements and cross off everything except the core mechanical action using the Constraint Stripping Protocol.
- Set a timer and force a ten-minute physical test of the cheapest solution using the Physical Testing Mandate.
- Discard the illusion that automation is always better than manual leverage.
- Categorize your friction points after testing using the Need Versus Want Filter.
- Prioritize "easy to grab and go" adoption over complex, flawless theoretical systems.
Toolkit for Overengineering
Toolkit (Toggle for more)
- Constraint Stripping Protocol: A mental framework used to separate absolute core mechanical needs from preferential nice-to-haves.
- Physical Testing Mandate: A rule requiring immediate, low-fidelity execution to generate physical feedback and break analysis paralysis.
- Need Versus Want Filter: A review tool to permanently discard false constraints and redefine success criteria based on physical reality.
Overengineering FAQs
How do you know when you are overengineering a solution?
You are likely overengineering when you spend more time designing the perfect automated system than it would take to execute the task manually in a low-fidelity "crawl" phase.
Why is premature optimization a problem?
It is a problem because you risk scaling a process before validating that the core physical mechanism actually works, often leading to wasted money on specialized tools.
How does the crawl walk run method stop overengineering?
It stops it by forcing you to take immediate, imperfect action. This physical feedback proves which constraints are real dealbreakers and which are just illusions.
What is the difference between a want and a need in operations?
A need is an absolute requirement for the task to be completed successfully, while a want is a preference that makes the task more comfortable but is not strictly necessary.
Why do people fall into the trap of overengineering?
People fall into this trap because they use rigid problem framing and suffer from prototyping aversion, preferring to wait for a flawless solution rather than testing a messy one.
This is part of a series about Innovation Strategy
List view
Overengineering: Stop Feeding Wants and Starving Your Needs
Asymmetric Strategy: Shogun's 3 Steps to Win Uneven Fights
Top Reasons for Customer Churn: 3 Overlooked Root Causes
Getting Your First Customers in Five Hours a Week
How to Break Your Growth Ceiling While Bootstrapping a SaaS
Fast Follower Strategy: 4 Startup Idea Shortcuts
What The Lord of the Rings Teaches Us: 3 Powerful Strategy Lessons
Problem Validation: Solve a Real Problem Before It’s Too Late
Feeling Overwhelmed? Here's How to Prioritize Strategic Initiatives
Assumption Testing: A Strategic Framework for Success
What is a Calculated Risk? An Essential Guide
The Regret Minimization Framework: A Practical Checklist
Strategic Prioritization: Why Your First Move Might Be Your Biggest Mistake
Strategic Decision Making Framework: Don’t Miss This Essential Tool
Problem Statement Worksheet: 30 Minute Exercise to Clarity
This Problem Statement Template Delivers Results
How to Write a Problem Statement: Avoid These Common Mistakes
Tech-Enabled Services Versus SaaS Business Model: Key Metrics
Dan Wu, JD/PhD
Lead Innovation Advisor
I build and advise mission-driven ventures to scale like startups.
SVP of Product & Chief Strategy Officer.
- As a go-to-market-focused product leader, I’ve led and launched products and teams at tech startups in highly-regulated domains, ranging from 6 to 8 figures in revenue.
- Led core products and product marketing key to pre-seed to D raises across highly-regulated industries such as data/AI governance, real estate, & fintech; rebuilt buyer journeys to triple conversion rates; Won Toyota’s national startup competition.
Harvard JD/PhD focused on responsible innovation for basic needs.
- Focus on cross-sector social capital formation, with a strong background in mixed-methods research.
- Selected as a National Science Foundation fellow & published on responsible strategy and innovation in outlets like Oxford University Press, Fast Company, and TechCrunch.
First-generation college student prioritizing inclusion and belonging in his practice.
- I was raised by a single mother without a high school degree.
- I’m passionate about mentoring and coaching using methods that “works with” (versus “do to”), sensitive to one’s constraints and experiences.
Made with Bullet