Four scenarios across different domains, demonstrating the cognitive protocol in action.
User: "How do we make this system reliable?"
To make the system reliable, I recommend:
- Add redundancy — run multiple instances behind a load balancer
- Implement health checks and automatic restarts
- Set up monitoring and alerting with PagerDuty
- Write comprehensive tests (unit, integration, e2e)
- Use a CI/CD pipeline with automated rollbacks
- Document runbooks for common failure scenarios
- Schedule regular game days and chaos engineering exercises
These are industry best practices used by companies like Netflix and Google.
Problems: Forward-only planning — lists good practices without analyzing what specifically causes unreliability in THIS system. Generic advice that could apply to any system. No failure mode analysis. The list sounds comprehensive but doesn't prioritize: which of these matters most for the actual failure modes this system faces?
Let me invert: what would make this system UNRELIABLE? What guarantees downtime?
Failure mode mapping:
- Single point of failure in the data path — one database, one cache, one queue. Any one dies, everything dies. This is the most common cause of prolonged outages.
- Cascading failure under load — service A calls service B with no timeout or circuit breaker. B slows down, A's thread pool fills up, A dies, everything upstream dies. One slow dependency kills the system.
- Deployment is a cliff — shipping 100% of traffic to new code instantly. A bug in the new version takes down all users simultaneously with no escape valve.
- Silent data corruption — the system stays "up" but produces wrong results. No one notices until a customer reports it days later. Harder to fix than downtime.
Elimination plan: The reliability strategy must address each failure mode:
- SPOFs → map every component in the critical path. For each: can it fail without taking down the system? If not, add a fallback or redundancy FOR THAT SPECIFIC COMPONENT. Don't add redundancy everywhere — add it where the failure mode is fatal.
- Cascading failure → timeouts, circuit breakers, bulkheads on every inter-service call. The question isn't "do we have health checks" but "can any single dependency kill the system?"
- Deployment cliff → canary deploys or blue-green with automatic rollback on error rate spike. The question isn't "do we have CI/CD" but "can a bad deploy only affect 1% of traffic?"
- Silent corruption → invariant checks on critical data paths. The system should crash loudly rather than corrupt silently.
Which of these four failure modes is your system currently most exposed to?
Active shifts: Inversion (Shift 1) — asked "what guarantees unreliability?" instead of "how to be reliable." Pre-mortem (Shift 2) — concrete failure narratives, not abstract risk labels. Subtraction (Shift 5) — eliminating specific failure modes rather than adding generic best practices.
User: "How do we grow market share from 5% to 15%?"
Growing from 5% to 15% market share requires a multi-pronged strategy:
- Product differentiation: Identify your unique value proposition and double down
- Pricing strategy: Consider aggressive pricing to win customers from competitors
- Distribution expansion: Enter new channels (partnerships, marketplaces, direct sales)
- Marketing investment: Increase brand awareness through content, ads, and events
- Customer success: Reduce churn so growth compounds instead of leaking
- M&A: Acquire smaller competitors to consolidate share
I'd recommend prioritizing based on your current strengths and market dynamics.
Problems: Forward-optimization playbook — lists growth levers without examining what prevents growth. No analysis of why share is currently 5% and stuck. "Prioritize based on strengths" defers the actual judgment.
Before planning growth, let me invert: what keeps you stuck at 5%? What guarantees you NEVER reach 15%?
Guaranteed ways to stay at 5% forever:
- Win deals but lose customers — if annual churn is >20%, you're filling a leaking bucket. Even doubling new sales doesn't move share if half leave each year. The math: at 20% churn, you need to acquire 3x your current customer base to net 15% share. At 5% churn, you need 1.3x. Churn is the silent killer of share growth.
- Compete where the leader is strongest — attacking the incumbent on their best feature guarantees a resource war you lose. They have 3x your budget on their core. You win by making their strength irrelevant, not by matching it.
- Grow without a wedge — trying to be a little better at everything means no compelling reason to switch. Customers need a 10x reason on ONE dimension to overcome switching costs.
- Ignore the non-consumer — the 80% of the market that uses no solution or a makeshift one. They're easier to convert than stealing from a competitor, and the competitor can't retaliate.
Red team — as the incumbent, how would I keep you at 5%? I'd match your pricing on any deal you bid on (I have the margin to absorb it), I'd lock in my top accounts with multi-year contracts, and I'd copy your best feature 6 months after you ship it. You can't win a feature war or a price war.
Surviving growth path: You grow to 15% by (a) fixing the bucket first — get churn below 8%, (b) finding a wedge the incumbent structurally can't copy (their architecture, their business model, or their incentives prevent it), and (c) targeting non-consumers or underserved segments the incumbent ignores because they're too small for their cost structure.
What's your current annual churn rate? That determines whether the growth problem is an acquisition problem or a retention problem.
Active shifts: Inversion (Shift 1) — "what guarantees staying at 5%?" before "how to reach 15%." Adversarial (Shift 3) — played the incumbent to find their retaliation playbook. Subtraction (Shift 5) — fix churn before adding growth tactics.
User: "How do I build a successful career?"
Building a successful career involves several key strategies:
- Develop expertise: Pick a field and go deep — become the go-to person
- Build your network: Relationships compound over time
- Take calculated risks: Join high-growth companies, take stretch assignments
- Invest in learning: Read widely, take courses, find mentors
- Build a personal brand: Write, speak, be visible in your field
- Stay adaptable: The market changes — pivot when needed
Focus on creating value and the career will follow.
Problems: Generic success advice that could be in any career book. No analysis of what actually derails careers. "Focus on creating value" is unfalsifiable. Everything on this list sounds right and adds up to nothing actionable.
Let me invert: how do you guarantee a failed career? What are the reliable paths to career stagnation?
Guaranteed career destroyers:
- Optimize for the current role, not the next one — Become so good at your current job that you're too valuable to promote and too specialized to move. You're "essential" — and trapped. The person who gets promoted is the one already doing the next job's work, not the one excelling at the current one.
- Avoid decisions that could be wrong — Build a reputation for safe, consensus choices. Never take a position that could fail publicly. In 10 years, you'll have a clean record and zero signal. No one will know what you're capable of because you never showed them.
- Build skills without leverage — Accumulate skills that are common and substitutable. Being "good at" many things and distinctively great at nothing. The market pays a premium for scarce combinations, not for average competence across a checklist.
- Ignore the human layer — Focus only on technical output. Don't build relationships, don't learn to communicate upward, don't understand what your organization actually rewards. Be the person who does great work that nobody knows about.
- Never retreat from a bad position — Stay too long in a declining company, a toxic team, or a dead-end specialization because leaving "looks bad" or "wastes" the years invested. The sunk cost trap is the single most common career mistake.
Via negativa career strategy: Avoid all five, and the career almost takes care of itself:
- Do the next role's work before you have the title (avoid #1)
- Take at least one visible, falsifiable bet per year (avoid #2)
- Build a rare skill combination, not a long skill list (avoid #3)
- Invest 20% of effort in making your work visible and building key relationships (avoid #4)
- Pre-define your exit criteria for your current role: what evidence would tell you it's time to move? (avoid #5)
Which of these five traps is closest to your current situation?
Active shifts: Inversion (Shift 1) — "how to guarantee career failure" before "how to succeed." Pre-mortem (Shift 2) — specific failure narratives, not generic risks. Retreat (Shift 4) — explicitly addressed the sunk-cost trap of staying too long. Subtraction (Shift 5) — the strategy is defined by what to avoid, not what to chase.
User: "We have 20 feature requests. How do we decide what to build next?"
I recommend using a prioritization framework. Here are the most popular ones:
- RICE: Score each feature by Reach x Impact x Confidence / Effort
- MoSCoW: Categorize into Must-have, Should-have, Could-have, Won't-have
- Kano model: Map features to basic, performance, and delight categories
- Value vs. Effort matrix: Plot features on a 2x2 grid
Pick the framework that fits your team's style, score all 20 features, and build the highest-scoring ones first. Review quarterly.
Problems: Offers frameworks without judgment about which one applies. Treats prioritization as a scoring exercise rather than a strategic decision. Doesn't examine what makes prioritization go WRONG.
Before scoring features, let me invert: what guarantees bad prioritization? How do teams consistently build the wrong things?
Reliable ways to waste engineering time:
- Build what the loudest customer asks for — Vocal customers have specific, idiosyncratic needs. Building for them creates a product that serves 5 customers perfectly and the market poorly. The features that matter most are often unasked-for because users can't articulate what they don't have.
- Optimize the onboarding without fixing the core loop — Polishing the entry experience while the core value proposition doesn't work. Users arrive smoothly and leave quickly. Acquisition theater.
- Add features instead of deepening existing ones — Feature count goes up, quality of each goes down. Users get "good enough" at everything and "great" at nothing. No feature becomes the reason they stay.
- Prioritize by effort (easy things first) — The value vs. effort matrix is seductive because easy wins feel productive. But the hard features are often the ones that create defensibility and retention. A roadmap of easy wins is a roadmap of commoditizable features.
Red team your list: Take your 20 features. For each, ask: "If we DON'T build this, what happens?" If the answer is "nothing much," it shouldn't be near the top regardless of how easy it is. The features that matter are the ones where NOT building them has consequences — churn, lost deals, competitive vulnerability.
Elimination-first prioritization:
- First pass: remove everything where "don't build it" has no consequences. This usually kills 10-12 of 20.
- Second pass: of the survivors, which ones address a failure mode (users leaving, deals lost, system breaking) vs. an aspiration (might grow faster, could open a new segment)?
- Failure-mode features first. Aspirational features second. Plug the holes before you build the tower.
How many of your 20 features address a known reason users are leaving or deals are failing?
Active shifts: Inversion (Shift 1) — "what guarantees bad prioritization?" before framework selection. Pre-mortem (Shift 2) — four specific ways teams build the wrong things. Adversarial (Shift 3) — "if we DON'T build this, what happens?" as the filtering question. Subtraction (Shift 5) — eliminate before prioritizing, plug holes before building towers.