Strategic choices: When both options are good

by Jason Cohen on February 22, 2026

Real strategy means choosing between two good options and accepting all the consequences—even the painful ones you don’t like.

I put them all in one basket on purpose. I like to live dangerously.

Everyone in the company makes decisions, all day:

How to respond to this customer. How much effort to put into this feature. What we build next. How we position a weakness on the website. Where next month’s budget goes. Which marketing channel we double down on. What ideas we even bother to consider.

Everyone had better be making decisions. That’s how you scale⁠—whether that’s three people or three hundred, and even if it’s just you. It’s how you manage autonomous teams.

The problem is inconsistency. Decisions can be locally rational but also contradict decisions made elsewhere. If everyone moves in a different direction, the company goes nowhere, even if everyone is productive and efficient.

So you need alignment. Not alignment on tactics (those change weekly), nor on platitudes (those change nothing), but alignment on a small set of macro-level decisions that every other decision must follow. These are called strategic choices.¹

¹ A term popularized by Roger L. Martin, who has much more to say in his 2013 book Playing to Win: How Strategy Really Works and in articles like this. Indeed, he defines “strategy” as a set of choices: “Strategy is an integrated set of choices that uniquely positions the firm in its industry so as to create sustainable advantage and superior value relative to the competition.”

When the daily decisions conform to the strategic ones, “more people” becomes “more results.” Customers stop getting mixed signals. Decisions made independently across the company reinforce each other, so the whole becomes stronger than the sum of the parts.

Most “strategy” documents fail because they avoid sacrifice. They read like moral aspirations: “Customer-first.” “Move fast over bureaucracy.” “Quality over shortcuts.” “Great design over mediocrity.”

Those aren’t wrong-headed ideas, they’re just non-decisions. No one says, “Our strategy is to have low quality and ugly design,” yet mediocre products exist because companies chose other priorities⁠—price, speed, extensibility, power, complexity⁠—and the trade-offs showed up as downsides.

That’s what makes a strategic choice real: accepting consequences you don’t like, because it enables the consequences that make you special. Your unique set of choices make you “the best” according to your target market. A strategy that never says “no” is not a strategy. A strategy should say “no” most of the time; that’s a signal that you actually have focus.

Part of a great strategy is writing down strategic choices with these properties:

Real decisions: Chooses A over B even though B is also desirable.
Accepts consequences: Chooses A and all of A’s consequences, including the unfortunate ones.
Reinforces each other: A set of choices that make the whole stronger than the parts, rather than choices which are smart in isolation but conflict together.

Next I’ll explain each property, share a few facilitation tips, and end with a table of examples to jump-start your discussions.

1. Both sides of the choice are smart

“Good design” isn’t a real choice because “bad design” was never a smart alternative.

“All-in-one” is a real choice, relative to “small core, extremely extensible,” because both are smart. You know this because many successful companies, with great products, have made each choice, which proves both can work.

And notice what that also proves: “both” isn’t a sensible choice. Either the product is self-contained or it isn’t. Either you design the UX as a complete experience, or you design it to accept third-party UX in ways the original designers can’t predict. Either you sell “the one thing you need to buy,” or you sell “the platform with an ecosystem for everything.” Either it “does a few things very well, integrated,” or it “does everything if you piece it together.” Even support follows: support can answer questions about the whole product, or it has to route you to whichever plugin vendor owns the piece you’re asking about.

That long list of second-order effects, affecting the entire company, is how you know it’s a real choice: it permeates everyone’s decisions.

This is also called The Opposite Test. See that article for more tips and examples.

2. Choices come with consequences, both desirable and unfortunate

A platitude feels good because it has no downside. How could “great design” be bad? Customers like it, it reduces support, and developers feel proud.

If it’s all good news, it isn’t a real choice⁠—or you aren’t grappling with the real consequences.

“Great design” comes with costs. You need talented designers, which often implies a larger team. You need engineers who can implement craft, chase down the last 5% of bugs, and still ship. You invest in design systems. Features and changes take longer because they carry an extra requirement beyond “works”: they must be well-designed. You say “no” to features customers want, if it means the design would become worse. Even then, not all customers agree on what “great design” means, so you thrill some people and irritate others.

A strategic choice is a package deal: you don’t get the advantages without the weaknesses.

When you list the consequences⁠—good and bad⁠—you make the decision usable. You reduce individual interpretation, you help everyone align their daily decisions, and it helps you ensure the entire strategy is internally consistent. And, better than just “consistent,” you give yourself a chance to make the choices reinforce each other, one making the other stronger, or at least easier.

3. Not just consistent: mutually reinforcing

Use the choice-consequences to check for contradictions. Conflicts often[[ hide in the second-order effects.

For example, “small team” and “feature-rich” can look unrelated until you follow the implications. Keeping a team small usually means keeping the product small and simple, because the team has to build it, maintain it, support it, and evolve it without growing. That’s in conflict with “feature-rich.” But then you might think of a way you could have both: a small team can maintain a small core that is built for third-party extensions. Then an ecosystem of plugins and APIs makes the entire product feature-rich after all! Now the choices interlock: “small team,” “small core,” and “extensible ecosystem.” Each brings more implications, which surface more choices, and so on. That exploration is how you arrive at a coherent set of decisions instead of a pile of slogans.

Even better than “not conflicting” is “reinforcing.” “Extensible” actively helps the product be “feature-rich.” A small team actively forces the core to stay small, maintaining space for the ecosystem to thrive. Each decision makes the next easier and stronger.

When the choices reinforce each other, the whole company starts to feel like it has a personality⁠—an opinion about How The World Should Be. Some customers won’t share that opinion, but the ones who do will love you all the more. Love is how you win.

And everyone speeds up. You stop re-litigating trade-offs. Marketing and sales stay aligned with the product because everyone follows the same opinions. People even have more fun, because coherence feels like competence⁠—and competence feels good.

Converting weak choices into strong choices

When you’re facilitating the creation of strategic choices, you will find that people constantly write weak pseudo-choices that fail the Opposite Test. They already know which side they prefer, so they’d rather make the other side obviously bad⁠—so their choice “wins”⁠—instead of struggling with a truly difficult choice.

Man at desk has 'In' and 'Out' baskets, and another overflowing basket labeled 'Dither.'

They have a point, though, so your job is to extract the underlying choice that would capture their feeling. Use this question:

What are some successful and beloved companies that chose the “bad” side? Now: What is the underlying reason why people love them despite that flaw? That is, what is the thing they love so much, that even though it has this bad consequence, they still love that product?

That “thing they love” is actually the other side of the strategic choice.

For example, “well-designed UX, not bad UX” is a fake choice. So ask: what are good reasons some products have a poor UX? One common reason is the example given above: the product is a small core with an ecosystem of plugins and extensions. That flexibility lets third-party software “do anything,” which lets customers “do anything,” and that’s genuinely wonderful… but at the cost of UX coherence.

An example of this in the real world is note-taking apps. All-in-one note tools like Apple Notes and Bear are beautifully cohesive partly because they control the entire experience⁠—no plugins, not even an API. Meanwhile, competitors like Obsidian offer an incredible array of downloadable functionality; a common complaint is that the UX becomes a hodgepodge. By asking “why is Obsidian’s UX so messy, and yet the product is so popular and beloved,” you arrive at the real strategic choice, which is “all-in-one vs infinitely extensible.”

Why not both? Sometimes both? This time both?

Everyone will want to “cheat” eventually.

Since both sides are desirable, you’ll start pulling in pieces of the other side. You’ll build an all-in-one product, but customers love that a competitor has plugins, so you’ll start exploring what it would mean for you to add plugins. Or: “We should raise the price; we’re leaving money on the table.” Or: “We should slow down and polish this; it’s embarrassing.” Those temptations feel compelling precisely because the other side is still smart. Strategy exists so that anyone in the company can say, without embarrassment: Yes, that’s a good idea in general, and no, it doesn’t fit the bundle we chose.

Still, sometimes it’s reasonable to do both. Suppose you’ve chosen “lowest price,” which often implies lower quality, because cost is the constraint. Sometimes you can improve quality without increasing cost⁠—better design choices, better suppliers, advantages of scale, great employees. Shouldn’t you take those wins?

Yes. Take them.

The rule is simple: when in conflict, adhere to the strategic choice. When not in conflict, do whatever you think is best. If quality and cost don’t conflict, take both. But reality shows up⁠—as it always does⁠—and eventually they do conflict: a nicer material that blows your margins, an architecture that enables plugins but wrecks coherence, an enterprise permission model that makes every screen more complicated, an extra month of QA versus shipping and learning. In those moments, you can’t mollify everyone. Some customers want one side of the trade-off; others want the other. If you don’t decide consistently, you land in the only truly losing position: not enough quality and design to earn delight and loyalty, and not enough power and breadth to win on checklists and complex use cases. You lose both ways, because you tried to “blend” and instead achieved “bland.”

Another way to look at it: strategic choices are inviolable, but this only matters when they collide with other priorities. You’re right that the “cheat” is good; it’s just in conflict with something else that is also good, and you already decided which one wins. The whole point of writing strategy down is to make that prioritization choice consistently across the company⁠—yearly roadmap decisions and tiny daily ones⁠—otherwise you’re not executing a strategy at all.

The Agile Manifesto is a great example of this in action. “Working software over comprehensive documentation” doesn’t claim documentation is bad; it says that when time is limited (and it always is), you invest more in one than the other. That’s not dogma; it’s a mechanism for consistency under pressure. They even underline the intent: “While there is value in the items on the right, we value the items on the left more.”

You can use the same pattern for strategy, and you’ll usually be stricter about it. If your strategy is low price, you almost never introduce a one-off high-price offering “just this once.” But if your low-price strategy implies lower quality, you happily take higher quality whenever it doesn’t threaten the low price decision.

It’s a choice, not a balance.

Strategic choice examples

You could incorporate a few of these into your strategy, and use them to kick off even better ideas:

Choice	Advantages	Weaknesses
Lowest price over premium price	• Largest possible market, positioned around access and affordability • Many competitors can never win, just because of price	• Can’t afford advertising and sales; word-of-mouth must carry you • Cost caps materials, performance, and “nice-to-haves,” so quality and features hit a ceiling
Premium price over lowest price	• High margins let you outspend competitors on brand, polish, and distribution • Status signaling becomes a feature: “no one ever got fired for buying this”	• Smaller market where the company has no power⁠—customers can buy any competitor • You must continuously fund the brand (marketing, prestige, pay celebs to carry the handbag), or the premium collapses
Cohesive all-in-one UX over extensibility	• “Designed” experience earns delight, trust, and habit⁠—customers feel calm using it • Support, docs, and onboarding stay simple because there’s one blessed path	• You personally own feature breadth; every “just add” request becomes your problem • Power users leave when they need plugins, scripting, or weird workflows you won’t build
Extensible ecosystem over cohesive UX	• Ecosystem creates long-tail capability you’d never staff, and customers love “it does anything” • Partners build your distribution: integrations and plugins become marketing channels	• UX coherence degrades because standards vary; the product feels like a quilt • Security, compatibility, and support are a supply-chain problem you don’t control
Simple UX over powerful capability	• Short time-to-value drives activation and self-serve growth; users feel smart immediately • Lower cognitive load reduces churn and support because fewer people get stuck	• You lose complex workflows, governance, and customization deals by design • You get outgunned on checklists and RFPs where buyers equate “more” with “better”
Powerful capability over simple UX	• You win deep, high-stakes workflows where capability beats elegance, so ACV climbs • High retention because configuration, training, and process integration create switching costs	• Onboarding requires training, setup, and specialists, slowing adoption and expansion • Support/services become mandatory, and the product becomes something customers “operate”
Minimal support over high-touch support	• Fewer support reps keeps margins high and lets the team focus on product instead of tickets • Forces ruthless usability and docs, so the product scales without human glue	• You can’t sell into buyers who require phone numbers, SLAs, and hand-holding • When users get stuck, they churn silently; you lose the feedback loop that would fix it
High-touch support over minimal support	• Humans bridge gaps competitors can’t, creating loyalty and differentiation • High-touch support becomes a product discovery engine: you learn faster because you hear the truth daily	• Expensive and hard to scale; load rises with customers unless you redesign the model • Creates 24/7 expectations and a dependency you can’t remove without breaking retention
Small-team simplicity over enterprise complexity	• Shorter sales cycles: fewer committees, pilots, and procurement rituals • Low implementation burden means customers succeed without consultants and long projects	• You lose enterprise deals that require governance, audits, and corporate integrations • Constant pressure for “just one more thing” slowly rots the simplicity you sell
Enterprise complexity over small-team simplicity	• You pass procurement gates and unlock big budgets once embedded into org processes • Integrations, permissions, and governance create real lock-in and retention	• Long sales cycles require cash, patience, and a sales machine • Product and UX bloat spreads everywhere because every screen must honor roles and policies
Cutting-edge speed over rock-solid stability	• Novelty differentiates; you ship what competitors can’t (yet) and earn attention • Attracts builders and early adopters who want the frontier	• Bugs, breakage, and confusion become part of the brand • Customers pay change-management tax, so conservative use cases churn and avoid you
Rock-solid stability over cutting-edge speed	• Trust becomes the moat for critical workflows; customers fear switching away • Lower support load and lower churn because “it never breaks” beats “it’s new”	• You are slow; visible novelty wins attention and budget • You miss frontier opportunities, and might even become obsolete
Open source over closed source	• Lower trust barrier: prospects can try, inspect, and adopt without begging permission • Community accelerates features and integrations you wouldn’t fund internally	• Monetization is hard because the core feels “free” and competitors have the same product • Governance and maintenance become political and exhausting, and expectations rise because flaws stay visible
Closed source over open source	• Full control of roadmap, UX coherence, licensing, packaging, and pricing power • Simpler governance: no community factions, forks, or public roadmap brawls	• Adoption slows in segments that demand transparency or fear lock-in • You fund velocity yourself; you lose community leverage and must manufacture trust signals
Fewer, better features over more features	• Polish and coherence create delight, retention, and word-of-mouth • Lower complexity means fewer bugs, fewer docs, fewer tickets, and faster iteration	• You lose on checklists and RFPs where feature count masquerades as value • You under-serve edge cases that matter deeply to certain segments, and they churn loudly
More features over fewer, better features	• You win procurement comparisons by checking more boxes out of the gate • Broader coverage expands market and creates more upsell paths	• Quality becomes uneven because breadth steals time from polish and reliability • UX coherence collapses as features accrete, and support/docs explode with new failure modes