A vision that says NO

Description

So far we've treated vision as a compass: something that orients where the company is headed. This lesson adds the half almost always forgotten when writing one: a useful vision doesn't only say where you ARE headed — it also says, with the same clarity, where you are NOT headed. If your vision is so broad that any initiative would "fit" in it, you don't have a vision — you have a wish list disguised as a direction. The acid test of a real vision isn't "does it sound inspiring?" — it's "can I use it, today, to reject an idea I would otherwise have accepted?"

This is uncomfortable on purpose. It's easy to say "yes" to everything that sounds good; saying "no" to an idea that also sounds good, just because it doesn't belong to this direction, is the real work of having a vision. In this lesson we build and run visionFilter, a model that takes Mercado's vision — with what it explicitly includes and excludes — and a list of initiatives, and flags which ones fit and which ones don't. The lesson demonstrates, with code, something that sounds counterintuitive until you see it run: an initiative can be a good idea and still be outside the vision.

Connection to the module. Lessons 2, 3, and 4 gave you the vocabulary to recognize and place a vision. This lesson is where that vocabulary starts to work: not just to describe the future, but to decide, today, what to build and what not to. It's, in miniature, the same principle you'll see at full scale in module 7 (strategy-to-roadmap), where the entire strategy filters the backlog before anyone calculates RICE — here you see it for the first time, at the vision level and with a much simpler model.

An everyday analogy: the GPS that says "go anywhere"

Imagine you ask a GPS for directions and it answers: "any road works, they all lead somewhere." Technically it didn't lie to you — it's true that every road leads somewhere — but the answer is completely useless, because a useful GPS doesn't just recommend a route: by recommending that route, it automatically rules out all the others. If the GPS tells you "turn right at the next street," it's already telling you, with no need to name them one by one, do NOT turn left, do NOT keep going straight, do NOT take the highway. The GPS's usefulness comes, precisely, from ruling out almost every possible option and leaving only one.

A company vision works the same way. "The world where you discover what you didn't know you wanted" isn't just an invitation to build discovery-related things — it's, with the same force, a silent rejection of becoming the fastest search engine for finding exactly the product you already know you want (that's a different GPS, headed to a different destination), or the store with the lowest possible price in every category (yet another destination). Both things — ultra-fast exact search, guaranteed lowest price — are legitimate, profitable businesses. They simply aren't the business this vision describes. Saying "yes" to exploration automatically means saying "no" to aggressively competing on those other two dimensions — not because they're bad ideas, but because a GPS pointing everywhere at once orients no one.

Worked example: what fits Mercado's vision?

Mercado's vision, written precisely, isn't just the inspiring sentence — it explicitly carries what it includes and what it excludes. We build visionFilter, which walks through a list of initiatives and, for each one, first checks whether it clashes with something the vision rules out, and if not, whether it connects with something the vision includes.

// visionFilter flags which initiatives FIT the vision and which are left
// out. A useful vision isn't a wish list -- it also RULES THINGS OUT.
// An initiative can be a good idea and still not belong to this vision.
function visionFilter(vision, initiatives) {
  return initiatives.map((initiative) => {
    const brokenExclude = vision.excludes.find((rule) => initiative.conflictsWith.includes(rule));
    const matchedInclude = vision.includes.find((rule) => initiative.supports.includes(rule));
    let fitsVision;
    let reason;
    if (brokenExclude) {
      fitsVision = false;
      reason = `conflicts with something the vision rules out: "${brokenExclude}"`;
    } else if (matchedInclude) {
      fitsVision = true;
      reason = `serves something the vision includes: "${matchedInclude}"`;
    } else {
      fitsVision = false;
      reason = 'does not connect with any "yes" in the vision';
    }
    return { initiative: initiative.name, fitsVision, reason };
  });
}

const mercadosVision = {
  statement: 'The world where anyone discovers, on Mercado, what they didn\'t know they wanted.',
  includes: ['curatedDiscovery', 'localSellerTrust', 'serendipity'],
  excludes: ['exactSkuSearchEngine', 'lowestPriceRace', 'genericMegastore'],
};

const initiatives = [
  { name: 'recommendationsEngine', supports: ['curatedDiscovery', 'serendipity'], conflictsWith: [] },
  { name: 'sellerTrustBadges', supports: ['localSellerTrust'], conflictsWith: [] },
  { name: 'lowestPriceGuarantee', supports: [], conflictsWith: ['lowestPriceRace'] },
  { name: 'oneClickReorder', supports: [], conflictsWith: [] },
];

console.log('=== What fits Mercado\'s vision? ===\n');
const results = visionFilter(mercadosVision, initiatives);
for (const r of results) {
  console.log(`${r.initiative}: fitsVision=${r.fitsVision} (${r.reason})`);
}

const inCount = results.filter((r) => r.fitsVision).length;
console.log(`\n${inCount}/${initiatives.length} initiatives fit the vision.`);

What to expect. Running the file with Node, the output is exactly this:

=== What fits Mercado's vision? ===

recommendationsEngine: fitsVision=true (serves something the vision includes: "curatedDiscovery")
sellerTrustBadges: fitsVision=true (serves something the vision includes: "localSellerTrust")
lowestPriceGuarantee: fitsVision=false (conflicts with something the vision rules out: "lowestPriceRace")
oneClickReorder: fitsVision=false (does not connect with any "yes" in the vision)

2/4 initiatives fit the vision.

Look closely at the two initiatives left out, because they're two different kinds of "no," and it's easy to mix them up:

• lowestPriceGuarantee is left out because it directly clashes with something the vision rules out. Offering a lowest-price guarantee is a good business idea — plenty of successful marketplaces compete exactly that way — but Mercado, in this vision, explicitly decided not to compete on that dimension. It's not that the idea is bad; it's that it belongs to a different GPS, headed to a different destination.
• oneClickReorder is left out for a different, more subtle reason: it clashes with nothing, but it also serves nothing. One-click reordering is a reasonable convenience improvement, with no direct conflict with "discovery" or "local trust" — it simply has no relation to either one. visionFilter marks it out anyway, because "not being harmful" isn't enough: to fit the vision, an initiative has to actively serve one of its "yeses."

This is the lesson's central point, executed and not just stated: fitsVision: false doesn't mean "bad idea" in either case. It means "this isn't the game this vision chose to play" — and a company that says "yes" to both rejected initiatives would end up, sooner or later, being a little bit of everything and a clear direction of nothing.

Going deeper: include what you also exclude, with the same precision

Writing a vision's includes is usually the easy part — anyone can list three or four nice things they want their company to represent. The excludes are the real work, because they require naming, out loud, legitimate and profitable businesses the company is going to say no to. A useful way to find your excludes: ask yourself "what's the exact opposite business to ours, one that could also succeed in the same market?" For Mercado, that opposite is an ultra-efficient exact-SKU search engine (the buyer already knows what they want, they just need the lowest price and the fastest delivery) — a real, profitable business, deliberately different from the one Mercado chose to build.

Also notice that visionFilter, as written, has no "impact" or "effort" field at all — on purpose. It isn't prioritizing (that's RICE, the topic of product-thinking-for-engineers-guide); it's asking a prior, simpler question: does this belong to this direction or not? An initiative can pass the vision filter and still have a bad RICE score (and not get built yet); and an initiative with an excellent RICE score can fail the vision filter (and never get built, no matter how profitable it looks in the short term). That's exactly the relationship between this lesson and module 7: the vision/strategy filter comes before, not after, calculating impact and effort.

Common mistakes

Writing only the "yeses" and leaving the "noes" implicit. What happens: the vision is written with a list of aspirations ("innovation, closeness, trust") without ever naming what's explicitly excluded. Why it happens: naming a "no" feels like closing doors, and closing doors is uncomfortable in a meeting where everyone wants to sound ambitious. How to spot it: if nobody at your company can name, without hesitating, a profitable business the vision says no to, your vision probably only has implicit "yeses" — and so it orients nothing, like the GPS in the analogy. How to fix it: for each include, find its direct opposite and name it as an exclude, with the same precision — "curated discovery" has "ultra-efficient exact search" as its direct opposite, and naming that out loud is what turns the vision into a real tool.

Confusing "it's a good idea" with "it fits the vision". What happens: an initiative gets defended by saying "but it's an excellent idea, it's going to work" as if that were enough for it to fit the vision. Why it happens: evaluating whether something is a good idea (would it create value? is it feasible?) is a different, easier exercise than evaluating whether it belongs to this specific direction — and the mind tends to collapse the two questions into one. How to spot it: if your argument for an initiative never mentions the vision, only mentions that "it's good," you probably evaluated the wrong question. How to fix it: remember oneClickReorder — a reasonable improvement, nothing wrong with it in itself, that still gets left out because it connects to none of the vision's "yeses." "Good idea" and "belongs to our direction" are independent questions; an initiative needs to pass both, not just one.

Using the vision's "no" as a generic excuse against any uncomfortable idea. What happens: someone rejects a proposal by saying "that's not our vision," without being able to point exactly to which exclude it violates. Why it happens: "that's not our vision" sounds like a solid argument and closes the conversation quickly, even when the real objection is something else (lack of time, lack of budget, simple difference of taste). How to spot it: ask whoever is rejecting the idea to finish visionFilter's sentence: "conflicts with something the vision rules out: _____." If they can't name the specific exclude, the rejection isn't coming from the vision — it's coming from somewhere else, and should be discussed as what it actually is. How to fix it: require every "because of the vision" rejection to cite the exact exclude, just like the model does — that keeps the filter honest and stops it from becoming a catch-all to avoid uncomfortable discussions.

Exercises

Exercise 1 — Predict before running. Without running anything, for this new Mercado initiative, predict what visionFilter would return and why:

const newInitiative = {
  name: 'sameCategoryBundleDiscounts',
  supports: [],
  conflictsWith: ['lowestPriceRace'],
};

Exercise 2 — Add an initiative that DOES belong. Write a fifth initiative for the worked example's initiatives, one visionFilter would mark fitsVision: true, and that's different from recommendationsEngine and sellerTrustBadges (don't repeat the same supports).

{ name: 'exploreByMoodCollections', supports: ['serendipity'], conflictsWith: [] }

Exercise 3 — Defend a "no" to the team. Choose lowestPriceGuarantee or oneClickReorder from the worked example. Write, in 2-3 sentences, how you'd explain to a coworker why that initiative — despite being a reasonable idea — isn't going to get built, using this lesson's exact vocabulary (not a simple "I don't like it").

Summary and next step

A useful vision isn't a list of nice things — it's a two-sided filter: it says where you ARE headed, and with the same force, it says where you are NOT. You saw visionFilter run on four real Mercado initiatives, and you saw, with code and not just theory, that an initiative can be a good idea (oneClickReorder) or even a profitable business in another context (lowestPriceGuarantee) and still be left out — not for being bad, but for not belonging to this direction.

Before moving on you should be able to: write, for any vision, at least one exclude as specific as its includes; and tell apart the two kinds of "no" you saw in the worked example — the one that clashes with an explicit exclude, and the one that simply connects to no include.

Lesson 6 takes this same criterion — does it really rule something out? — and uses it to tell a truly aspirational vision apart from an empty slogan that, however inspiring it sounds, wouldn't pass this lesson's filter even once.

Resources

• Roger Martin, "Decoding the Strategy Choice Cascade" — rogermartin.medium.com/decoding-the-strategy-choice-cascade-475d40555eb1. "Where to play" implies, with the same force, "where not to play" — this lesson's same principle, in Playing to Win's vocabulary. In English.
• Richard Rumelt, Good Strategy Bad Strategy — goodbadstrategy.com. The kernel's guiding policy acts as guardrails that constrain action, not as a wish list — this lesson's same idea, applied one level down (strategy instead of vision). In English.
• Marty Cagan (SVPG), "Product Vision FAQ" — svpg.com/product-vision-faq. Real questions from product teams about how a concrete vision ends up rejecting ideas that, in isolation, sounded reasonable. In English.
• Jim Collins, "BHAG (Big Hairy Audacious Goal)" — jimcollins.com/concepts/bhag.html. A well-built BHAG is, by definition, specific — and being specific automatically excludes everything that isn't that concrete thing. In English.