Four documents, four different jobs

People use "vision", "strategy", "goals" and "roadmap" as if they meant the same thing. They answer different questions, on different time scales, and you need all four.

• Vision: where we are going, in three to five years. It should be easy to picture. "Every Mangrove store is also a reliable 30-minute fulfilment point for its neighbourhood." It rarely changes.
• Strategy: how we will get there, given what is in the way. It covers one or two years and names the obstacle and the approach. It changes when the diagnosis changes.
• Goals, usually written as OKRs: how we will know the strategy is working, this quarter. You will write these in the next lesson.
• Roadmap: which problems we will work on, in what order. You will build one in Outcome roadmaps.

Each layer narrows the one below it. The strategy decides which goals matter, the goals decide which roadmap items earn a place, and the roadmap decides what engineers build this sprint. Learning flows back up: if a quarter of results shows the diagnosis was wrong, you change the strategy, not only the roadmap.

The most common failure is skipping the strategy layer. A team goes straight from a vision ("be the best grocery app") to a list of features. With no stated obstacle and no rule for choosing, every request looks equally good, and the loudest department wins. That is the problem the rest of this lesson solves.

The kernel: diagnosis, guiding policy, coherent actions

Richard Rumelt's book Good Strategy/Bad Strategy (2011) describes the core of any good strategy as a kernel with three parts. It is the most useful single tool a PM can learn for strategy, because each part has a test you can apply.

1. Diagnosis: what is really going on? Start with symptoms you can measure, then ask why until they share a cause. You are looking for the crux: the one or two obstacles that, once handled, unlock most of the rest. A diagnosis has numbers and evidence in it. It also leaves things out. If your diagnosis lists eight problems, you have not diagnosed yet. The five whys from Problems before solutions work here too, applied to a business problem instead of a single feature request.

2. Guiding policy: our overall approach. A guiding policy is a rule for choosing. Rumelt compares it to the guardrails on a road: it does not say where to put each wheel, but it keeps you from driving off the edge. The test is simple to state. A real guiding policy tells a team what not to do. If you cannot name three requests it rules out, it is too vague.

3. Coherent actions: what we will actually do. A small set of actions, with people and money committed, that support each other. Coherence is the important word. Draw arrows between the actions. If offline receiving makes the cycle counts more accurate, and accurate counts make the store manager's dashboard worth opening, the actions reinforce each other. An action with no arrows to any other is probably someone's pet project riding along.

Four signs of bad strategy

Rumelt names four hallmarks of bad strategy. You will see all four in planning decks, so learn to spot them fast.

• Fluff. Big words that hide the lack of a choice. "Leverage omnichannel synergies to deliver a world-class store experience."
• Failure to face the challenge. The document never says what the problem is, so nobody can judge whether the plan addresses it.
• Mistaking goals for strategy. "Grow partner orders 30%" is a wish with a number. It says nothing about what is stopping growth or how you will get past it.
• Bad strategic objectives. A long list of objectives that don't connect, or objectives as hard as the original problem. "Fix stock accuracy" restates the challenge. "Every delivery received in the app at the dock, even when Wi-Fi is down" is a step a team can actually take.

Two quick tests catch most bad drafts. The opposite test: write the opposite of each sentence. If the opposite is absurd ("we will annoy our users"), your sentence is not a choice. The request test: take five real requests from your backlog and ask whether the strategy decides each one. If it decides none, it is fluff.

Who else does the job, and your right to win

A competitive landscape starts from the job the user is trying to get done (the jobs-to-be-done idea from Problems before solutions), not from a list of companies in your industry. For the job "get tonight's groceries without going out", Mangrove's app competes with:

• Direct rivals: quick-commerce apps that run their own small warehouses and promise delivery in 10 to 15 minutes.
• Indirect rivals: food-delivery apps that added groceries, and ride-hailing apps such as Grab or Pathao that deliver parcels.
• Substitutes: the corner shop down the road (often one of Mangrove's own partner shops), or the weekly supermarket trip.
• Doing nothing: cooking what is already in the fridge.

For internal tools the list looks different, and PMs forget it more often. The Store app's real competitors are the paper receiving sheet, the shared spreadsheet a store manager keeps for expiry dates, the phone call to the DC, the chat group where staff post photos of damaged stock, and the off-the-shelf tool a department head could buy with a company card. Staff cannot leave an internal tool, but they can ignore it and keep using the spreadsheet. If the spreadsheet does the job well enough, it wins.

Your right to win is what you have that rivals cannot easily copy. Hamilton Helmer's 7 Powers (2016) lists seven lasting sources of advantage: scale economies, network economies, counter-positioning, switching costs, branding, a cornered resource, and process power. Each needs two things: a benefit (it lowers your costs or raises what people will pay) and a barrier (rivals can't easily get the same benefit). You don't need the whole framework to use the question. Write down what you have, then ask "could a well-funded rival get this within two years?"

For Mangrove, the honest answer is mixed. It has 320 stores already near its customers, 4 DCs and 1,800 partner shops that order from it every week. A quick-commerce rival would need years and a lot of money to build that footprint. But the footprint only wins if each store's stock record is right. A rival's warehouse is built for picking, so its records are accurate from day one. Mangrove's advantage exists on paper and leaks away at the shelf. That gap is the diagnosis.

Why now?

Every strategy and every big bet should answer "why now?". A good answer points to something that changed and that you can show someone. The usual kinds of change are:

• Technology or cost: something became cheap enough or possible, such as a phone camera that reads barcodes well, or a cloud service you rent by the month instead of a server you buy.
• Behaviour: customers now expect delivery within the hour, because other apps trained them to.
• Competition: a rival entered your city, or a partner started competing with you.
• Rules: a new tax, food-safety or data-protection rule makes the old way illegal or expensive.
• Inside the company: a vendor contract ends, a legacy system is being replaced, or every store finished getting scanners last quarter.

Then ask the reverse question: what happens if we wait a year? If the honest answer is "nothing much", the idea may be good but it is not urgent, and a strategy is about what comes first.