The Reverse Test: What a Strategy Doc Must Rule Out

What Actually Changes After You Write “Customer-Centric”?

I remember once writing “we’ll be customer-centric” in a strategy document and feeling rather proud of myself. It felt like I’d set a direction, and my teammates nodded along. But that single sentence gave us no way to decide what to do first when different customers made conflicting requests.

Reading Jason Cohen’s recent piece made me reconsider this. Cohen draws a distinction between phrases that are hard to disagree with—like “customer-centric”—and choices that actually require giving up an alternative. For a strategy document to be useful, he argues, it needs the latter.

Using the Reverse Test to Spot Vague Statements

The “reverse test” Cohen introduces asks whether the opposite of a strategic statement could also be a reasonable alternative. The opposite of “we’ll build good design” is “we’ll build bad design”—not something anyone would seriously choose. But whether to deliver a complete experience within the product itself, or to accommodate a wide range of needs through external extensions, is a real choice with trade-offs on both sides.

Cohen explains that making a choice means accepting its downsides too, and checking whether your various choices reinforce one another. If you can capture both benefits at once, do so—but when they conflict, follow the priority you’ve set. Jason Cohen, “Strategic choices: When both options are good”

Passing this test doesn’t guarantee business success. But it’s useful for catching sentences where it’s hard to tell what was even decided.

Say you’re opening a restaurant. Writing only “we’ll serve delicious food” won’t help you decide on a menu. But if you decide whether you’re mainly serving office workers grabbing a quick lunch, or guests who want a leisurely dinner, you can start discussing the menu, seating, and hours. Neither option is unconditionally better—you just need to prepare according to the customers you’ve chosen.

Write Down What You’ll Have to Deal With After You Choose

Consider a small product team. Promising to build every customer request directly can mean not just more development work but more maintenance and support inquiries. Conversely, narrowly defining your core features means you won’t be able to serve some customers’ needs.

You don’t have to end the conversation with “we’re a small team, so we can’t add more features.” You can split responsibilities—some features you own directly, others you solve by connecting to other tools. But you still need to decide who handles it when an integration breaks or an external tool changes. If you only write down the convenient part, whoever ends up owning that problem later will bear the cost.

The same problem shows up in pricing. If you lead with a low price, offering every customer a lengthy onboarding consultation becomes a burden. If you charge a premium and promise attentive support, you need to secure the staff and time to actually deliver it.

That’s why I think a strategy document should spell out not just the outcomes you’re aiming for, but also what you’re willing to bear. Then, when a teammate proposes a good idea, you can explain concretely why you’re saying “that’s good, but we’re not doing it this time.”

Aligning Customers, Product, and Operations Together

Roger Martin and A.G. Lafley’s Playing to Win treats strategy as a set of interconnected choices. Martin’s five questions are as follows. Roger Martin’s strategy framework

1. What is our winning aspiration?
2. Where will we play?
3. How will we win there?
4. What capabilities must we have?
5. What management systems do we need to sustain them?

Simply handing these questions off to separate departments to fill in isn’t enough. If you’ve decided to target large enterprise customers but aren’t prepared for security reviews or long procurement cycles, your target market and your operating model may not line up. You need to decide together which side to change.

How fast you ship new features also has to be tied back to your customers. Some customers welcome rapid change, while others place more value on the stability of the workflows they already rely on. Which customers you’ve chosen determines what you need to check before launch and how you provide support.

The Agile Manifesto’s preference for working software over comprehensive documentation doesn’t mean documentation is worthless. It acknowledges that both have value while stating a priority. A strategy document should do the same: tell you which standard to use when things conflict. Manifesto for Agile Software Development

Oswarld’s Lens

From my experience building GTM strategies, I get wary whenever the phrase “balanced strategy” comes up. I’ve seen that phrase used countless times to postpone an important decision. The result is that customers no longer have a clear reason to choose the product on either quality or price.

You can certainly improve on price and quality at the same time. What I take issue with isn’t stating two goals at once—it’s failing to set priorities even when people and budget actually run short.

In sales, you have to decide which customer requests you’ll take on. Accepting every request just because there’s a chance of closing the deal can push aside the development that your actual target customers need. That doesn’t mean you should reject every new request either. Review whether it’s an opportunity significant enough to change your existing judgment, and if you decide to change it, update your product and operating plans accordingly.

This applies to individual work too. A channel covering many topics and a channel focused on one field gather material differently. Content that takes a long time to produce and content posted frequently also need different schedules. Rather than one being the right answer, you need to decide what to prioritize given the time and capacity you currently have.

I don’t think strategy has to be fixed forever. When the market changes, you can change your choices too. But if you change direction, you should be able to explain why, and what you’re stopping and starting as a result.

Try picking one important item from your strategy document. Think about a company that makes a different choice, and what that company’s customers like about it. Then write down why you’re choosing your side, and what you’re giving up because of that decision. My standard is whether what’s left is a sentence your teammates can actually use to decide their next task.

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.