product-strategy: choose the team’s focus and what to drop

---
name: product-strategy
description: Writes, reviews and applies a product strategy, meaning the diagnosis of the challenge, the guiding policy, coherent actions and what the team will not do, then 1 to 3 measured outcomes, a roadmap in three columns (now, next, later) and a check of new work against it. Use at planning time, or when someone asks "write our strategy", "review this strategy", "what should we focus on", "set our OKRs", "build the roadmap", "we have too many priorities", "prioritise the backlog" or "does this project fit our strategy". Grounds every claim in evidence, flags goals and feature lists posing as strategy, and gets the team to agree to one version they can repeat.
license: MIT
metadata:
  source: https://alcoven.co/skills/product-strategy
  version: "2"
---

Product strategy: name the challenge, choose, and say no

A strategy is a short argument: what is really going on (the diagnosis), the approach the team will take to it (the guiding policy), and a few actions that carry it out together (Richard Rumelt's kernel, 2011). You can tell it is a strategy by what it rules out. Most documents called a strategy are a goal ("triple revenue"), a list of features, or both. The person asking is usually at planning time, or has a team stretched over too many things. They fear committing everyone to the wrong bet in public, and a document nobody reads after the offsite. Keep it to a page or two, ground each claim in evidence, and make it short enough that anyone on the team can say it back.

Strategy chooses the few problems worth solving and the outcomes that show progress. Deciding what to build for each problem is discovery's job (the product-discovery skill).

What you need

• The vision: the future the product is working toward, for its customers, in a sentence or a paragraph. If there is none, draft one sentence from the brief for the person to confirm.
• The numbers today, each with its date. For choosing the measures themselves, use the metrics skill if the project has it.
• The insights: what customers do and say (discovery notes, interviews), the market and competitors (the market-watch skill's briefs), what technology now makes possible, and the business's limits (cash, people, time).
• What exists: the current strategy, roadmap, OKRs, backlog, promises made to customers, decisions on record and anything people agreed to. Look in strategy/, roadmap/, planning/, okrs/ and the brief.

Pick the part

To write a strategy, do every step. To review one, use the review below. Outcomes or OKRs are step 6 (with no strategy, write a short diagnosis first), the roadmap is step 7, and "does this fit" or "prioritise this list" is step 8. A whole company's strategy gets the full method; one team's cycle inside an agreed strategy gets steps 6 to 8.

The method

1. Read the record and list the insights (one of Cagan's four parts of product strategy): about customers, data, technology, the industry. Read before asking anything. Give each its source and date, and mark which are evidence and which are beliefs. Output: the insight list.
2. Write the diagnosis. One paragraph: what is going on, what makes it hard, and the crux, the part of the challenge that matters most and that the team can actually do something about (Rumelt, The Crux, 2022). Name the obstacle; a target says where you want to be and nothing about what stands in the way. Output: the diagnosis, with its evidence cited.
3. Choose the guiding policy. One or two sentences: the approach to the crux. It must rule out things someone on the team wants, and it should rest on an advantage (an insight others lack, a strength, focus). Write the two or three approaches you considered and why they lost. Output: the policy and the alternatives.
4. Name the coherent actions. Three to five actions that reinforce each other, each with an owner and the people or money it needs. Make the first ones close enough to reach with what the team has (Rumelt's proximate objectives). Actions that pull in different directions are a to-do list. Output: the actions.
5. Write what you will not do. Specific things people want or have asked for: customer segments, markets, features, projects to stop. Each with one line of why and when to look again. Output: the not-do list.
6. Set 1 to 3 outcomes. For each: the change in what customers or the business do, the measure, today's reading with its date, the target with its date, and a guardrail that must not get worse. Prefer what the team can move in weeks (what customers do in the product) to results it can only hope for. With OKRs: one objective per outcome, two to four key results that are measures (never tasks), each marked commitment or stretch, checked every week or two. Teams propose key results; leaders agree them. Output: the outcomes table.
7. Lay out the roadmap: now, next, later. Each item is a problem to solve, tied to an outcome. Now: what teams work on this cycle. Next: what is being shaped and tested. Later: directions, deliberately loose. Give dates only for real commitments (a contract, a regulation, an event), kept in their own short list and made after discovery has reduced the risk (Cagan's "high-integrity commitments"). Output: the roadmap.
8. Check proposed work against it. Which outcome does it serve? Does it fit the policy? Is it on the not-do list? What would it push out, what does waiting a month cost, how much time is it worth, what evidence is behind it? Answer: fits (to discovery, or into Now), doesn't fit (cite the line), or challenges the strategy (propose an edit). A score such as RICE can sort a long list and start the conversation. Methods and limits: references/prioritising.md. Output: a cited verdict per proposal.
9. Get agreement, then keep it current. Ask the team to agree to one version. Then test it: can two people each say the strategy in two sentences? If not, shorten it. Read the outcomes at a fixed rhythm; revisit the strategy each quarter, or sooner when the diagnosis changes (a failed bet, new evidence, a market move). Record each change and why.

The kernel, the review checks, outcomes, OKRs and roadmaps in detail: references/method.md. The document's template and a worked example: references/template-and-example.md.

Reviewing a strategy

Start with what is strong. Then check it against Rumelt's four hallmarks of bad strategy and the kernel: fluff (grand words that commit to nothing), failure to face the challenge (no obstacle named), goals mistaken for strategy (targets with no approach), and bad strategic objectives (too many, or out of reach). Add: no not-do list, a roadmap of features with dates, outcomes with no baseline or date, and a strategy nobody can repeat. Give the two to four gaps that matter most, each with its fix, as suggestions.

Common mistakes

Since AI made building cheaper (2023 to 2026), output is plentiful and proves little: teams that use AI to speed up a feature roadmap ship more without better results (Cagan, 2026). The not-do list and the outcomes matter more now.

Speaking up

• Once, with evidence and the cheapest fix. "This draft reads as three goals. One paragraph on what stands in the way (churn after month two, numbers/retention, 20 Oct) would make it a strategy before the board sees it. Shall I draft it?"
• Credit what is strong first. If they go ahead, do the work, and note the open risk once in the document.
• Match their pace, and never repeat a concern they have decided on.

What you never do

• Refuse or water down work because a step was skipped.
• Invent market data, benchmarks, customer evidence or targets. Targets come from the person; missing evidence is said to be missing.
• Change the strategy, a target or the roadmap on your own. Propose the edit.
• Promise dates to customers for the team.
• Treat a score as the decision, or rank people.

In Alcoven

Pass the project's slug and cite by § address.

1. open_project: the brief, the home widgets with their readings, what is agreed and open. agreed with about: the strategy or the subject; numbers for each baseline and its date.
2. related with the draft diagnosis or the proposed work: what the project already holds on it, and anything that conflicts.
3. add_document for the strategy (for example strategy/2026-q4.md), after showing the person the text; changes later go through edit_document, which the person confirms.
4. hand_out with ask: agree and the person's own line on top: each member gets up to three passages that concern them (the not-do list to sales, an outcome to the team that leads it) and is asked to agree to this version.
5. One widget per outcome, from the source that holds its measure, with - Compare: target 45 by 2026-12-31 and - On home: yes (four at most on the home).

To check new work, run agreed and related on the proposal and answer with § addresses; put the verdict on the proposal with add_note. Add a task for each check-in on the outcomes.

Elsewhere

Keep the strategy as one file in strategy/, outcomes and roadmap inside it. Read the project's files first, use git log for what changed since the last version, and cite file paths. Record in the file who agreed, and when. With only the conversation, ask for the brief, the numbers and the current plan, and say what you could not see.

Files

• references/method.md: the kernel, the review checks, vision and strategy, outcomes and OKRs, roadmaps, what changed since 2023, sources.
• references/prioritising.md: prioritising methods and their limits, appetite and the betting table, saying no, checking work against the strategy.
• references/template-and-example.md: the strategy document's template and a worked example.

Product strategy: the method in detail

The ideas behind each step, with where they come from. Sources at the end, each read on 2026-10-22.

The kernel

Richard Rumelt (Good Strategy Bad Strategy, 2011) defines good strategy as coherent action backed by an argument, and gives it three parts:

The crux. In The Crux (2022), Rumelt sharpens the diagnosis: of all the challenges, find the one that is both important and addressable, where action promises the most progress. He borrows the word from climbing, where it means the hardest move on a route. A team that names the crux spends its effort there.

Proximate objectives. The first actions should be close enough that the team can reach them with what it has, given the diagnosis. A far goal with no near step leaves people unsure what to do on Monday.

The four hallmarks of bad strategy

Rumelt's list, with the question to ask of a draft:

1. Fluff. Grand, abstract words that sound like thinking ("customer-centric excellence through innovation"). Ask: what does this sentence commit us to? If nothing, cut it.
2. Failure to face the challenge. The document never says what is hard. Ask: what is the obstacle, in one sentence? If nobody can say, there is nothing to judge the plan against.
3. Mistaking goals for strategy. Targets and wishes ("grow 3x", "be the leader in...") presented as the plan. Ask: how will we get past what stands in the way?
4. Bad strategic objectives. Too many, unrelated, or out of reach; a long list of things to do, labelled strategic. Ask: if we did only three of these, which, and why those?

Add the checks this skill uses: no not-do list; a roadmap of features with dates; outcomes without a baseline or a date; and a strategy nobody on the team can repeat.

Vision and product strategy

Marty Cagan separates the two (SVPG, 2020 and 2023; Cagan and Jones, 2020):

• Product vision: the future the company is trying to create for its customers, usually several years out, meant to inspire and to guide choices. It changes rarely.
• Product strategy: how the team will move toward the vision while meeting the business's needs. Cagan names four parts: focus (choose the few objectives that matter most, which means deciding what not to pursue), insights (from customers, data, technology, the industry, the business), action (turn the insights into problems for specific teams to solve), and management (leaders stay involved, help teams with obstacles and adjust as they learn, without dictating how).

In Cagan's product model, deciding which problems to solve is a leadership job guided by the vision and strategy; deciding how to solve them is the team's job (the product-discovery skill). Rumelt's kernel and Cagan's strategy fit together: the diagnosis comes from the insights, the guiding policy is the focus, and the coherent actions are the problems handed to teams.

Outcomes, and OKRs done well

An outcome is a change in what customers or the business do, with a measure, a baseline and a dated target. Output is what the team ships. Cagan's 2026 framing is that every company trades outcomes against predictability: a culture that ranks "delivered what we promised" first gets output, whatever its slides say.

Choose one to three. More spreads the team thin. For each, add a guardrail: a health measure that must not get worse while you push (support load, refunds, reliability).

OKRs are one way to write outcomes. Andy Grove used them at Intel; John Doerr brought them to Google and wrote them up in Measure What Matters (2018):

• The objective says what you want to achieve, in plain words.
• The key results say how you will know: specific, time-bound and measurable, so each is clearly met or not. Doerr's site suggests three to five per objective; Christina Wodtke (Radical Focus, 2016, 2nd edition 2021) suggests one objective per team and three key results.
• Mark each as committed (expected to be met in full) or aspirational (a stretch). Google's guide grades key results from 0.0 to 1.0 and calls 60 to 70% the sweet spot; always scoring 1.0 means the goals were too easy.
• Key results measure outcomes. Words like "launch", "build", "consult" or "analyse" signal a task. Google's guide says the same.
• Check in weekly. Wodtke's Monday check-in covers this week's three or four priorities, confidence in each key result out of ten, the next month's work, and two health measures to protect. She suggests setting a stretch at about 5 out of 10 confidence. A Friday session shows what was finished.
• OKRs and KPIs differ. A KPI tracks the health of something already running; an OKR aims at a change. Keep health measures as guardrails.

Common OKR failures (Doerr's site, Google's guide, Wodtke, Cagan): too many objectives; key results that are tasks or features; sandbagging (targets set low to be safe); no check-ins until the quarter ends; objectives cascaded down each function, so the engineer, designer and product manager on one team chase different goals (Cagan's central complaint, "Team Objectives", 2020); individual OKRs tied to performance reviews; and OKRs used in a company that still hands teams a feature roadmap, so the objective is decoration. Cagan's conclusion in 2020 was that OKRs rarely help until teams are given problems to solve.

Roadmaps

Why feature roadmaps fail. Cagan (2015) gives roadmaps two real purposes: making sure teams work on what matters most, and letting the business plan around dates it truly needs. A list of features with dates serves neither well: the problem behind each feature is often unstated, at least half the ideas will not work as hoped, and the ones that work need several rounds. Teams ship on time and miss the result.

The alternative. Give each team its problems and outcomes, from the strategy, and let it discover what to build. For the few cases that need a date, make a high-integrity commitment: a date given only after enough discovery to know the work is valuable and feasible, used sparingly (Cagan; Jones and Cagan, 2025).

Now, next, later. Janna Bastow and Simon Cast at ProdPad drew the roadmap as three columns with no dates: what the team is working on now, what comes next, and what is further out. Bastow describes a roadmap as a strategic communication document: if an item is not part of the strategy, it is not on the roadmap. Detail falls as the horizon grows: Now items are specific problems with owners; Next items are problems being shaped and tested; Later items are directions. Write each as a problem tied to an outcome, with no date.

What changed, 2023 to 2026

• Building got cheap. Andrew Ng argued in January 2025 that as AI makes writing software cheaper, the scarce skill is deciding what is worth building. Cagan wrote in 2026 that building is no longer the hard part.
• Output stopped proving anything. Teams using AI to speed up the old feature roadmap ship more and see no better results (Cagan, "The AI Productivity Paradox", 2026). Cagan quotes Hilary Gridley's line that it has never been easier to run fast in the wrong direction.
• So the strategy's job of saying no grows. When a team can build three things in the time one used to take, the temptation is to build all three. The not-do list, the one to three outcomes, and checking each proposal against them are what keep cheap building from turning into scattered work.

Sources

• Richard P. Rumelt, Good Strategy Bad Strategy, Crown Business, 2011; "The perils of bad strategy", McKinsey Quarterly, 2011. Summaries read 2026-10-22: Perdoo's and Kellblog's reviews of the book.
• Richard P. Rumelt, The Crux: How Leaders Become Strategists, PublicAffairs, 2022. https://www.hachettebookgroup.com/titles/richard-p-rumelt/the-crux/9781541701243/, read 2026-10-22.
• Marty Cagan, "Product Strategy Overview", SVPG, 2020. https://www.svpg.com/product-strategy-overview/, read 2026-10-22.
• Marty Cagan, "The Product Operating Model: An Introduction", SVPG, 2023. https://svpg.com/the-product-operating-model-an-introduction, read 2026-10-22.
• Marty Cagan, "Team Objectives: Overview", SVPG, 2020. https://www.svpg.com/team-objectives-overview/, read 2026-10-22.
• Marty Cagan, "The Alternative to Roadmaps", SVPG, 2015. https://svpg.com/the-alternative-to-roadmaps/, read 2026-10-22.
• Marty Cagan, "The Inconvenient Truth About Product", SVPG, 2013. https://www.svpg.com/the-inconvenient-truth-about-product/, read 2026-10-22.
• Marty Cagan, "Predictability vs Outcomes", SVPG, 2026, and "The AI Productivity Paradox", SVPG, 2026. https://www.svpg.com/predictability-vs-outcomes/ and https://www.svpg.com/the-ai-productivity-paradox/, read 2026-10-22.
• Chris Jones and Marty Cagan, "Stakeholders and the Product Model", SVPG, 2025. https://www.svpg.com/stakeholders-and-the-product-model/, read 2026-10-22.
• Marty Cagan and Chris Jones, Empowered, Wiley, 2020; Marty Cagan and others, Transformed, Wiley, 2024.
• John Doerr, Measure What Matters, Portfolio, 2018; "OKR meaning, definition and examples", What Matters. https://www.whatmatters.com/faqs/okr-meaning-definition-example, read 2026-10-22.
• Google re:Work, "Set goals with OKRs". https://rework.withgoogle.com/en/guides/set-goals-with-okrs, read 2026-10-22.
• Christina Wodtke, Radical Focus, 2016, 2nd edition 2021; "The Art of the OKR", 2014, and "Monday Commitments and Friday Wins", 2014, Eleganthack. https://eleganthack.com/the-art-of-the-okr/ and https://eleganthack.com/monday-commitments-and-friday-wins/, read 2026-10-22.
• ProdPad, "About us" (Now-Next-Later). https://www.prodpad.com/about-us/, read 2026-10-22; Janna Bastow interview summaries, read 2026-10-22.
• Andrew Ng, "AI Product Managers Will Be In-Demand", The Batch, 15 January 2025. https://www.deeplearning.ai/the-batch/ai-product-managers-will-be-in-demand/, read 2026-10-22.

Prioritising, saying no, and checking work against the strategy

The strategy does most of the prioritising: it names the few outcomes and what the team will not do. The methods below only order what is left inside it. Each gives a number that looks precise and is built from guesses. Use them to sort a long list and to start the conversation, then decide in the conversation with the evidence in view. Sources at the end, each read on 2026-10-22.

Methods and their limits

Appetite and estimate differ. An estimate starts from a design and ends at a number; an appetite starts from a number (the time the problem is worth) and ends at a design that fits it. Ask for the appetite first: it turns "how long will this take?" into "how much is this worth to us?".

A short way to order work inside the strategy

1. Drop what doesn't belong. Anything on the not-do list, or serving no outcome, comes off, with the line it conflicts with.
2. Write four facts per item. The outcome it serves; the evidence behind it, by kind; its appetite; what waiting a month costs.
3. Sort. High cost of delay and strong evidence first. An item with weak evidence goes to discovery before it gets build time (the product-discovery skill).
4. Score only to break ties in a long list, and show the inputs beside the score so anyone can question them.
5. Decide together, and write the order and the reasons where the team will find them.

Saying no

• The not-do list. Jim Collins argued that a stop-doing list matters as much as a to-do list (2003). Each entry names something people want, why not now, and when to look again. Revisit it each quarter, and read it aloud when the next big request arrives.
• Saying no to a customer or a colleague. Thank them, and name the line of the strategy the request runs against. Say what you can do: the problem behind it goes onto the discovery tree, and there is a date to look again. Never offer a delivery date to soften the no.
• A big customer's request is weighed by the strategy like any other. If it should change the strategy, propose that edit openly so the team can agree to it; slipping it into the roadmap moves the strategy without anyone deciding.
• The backlog. Shape Up keeps no central backlog: ideas that matter come back. At the least, close anything untouched for two cycles, with a note saying why.
• Cheap building makes no harder to say. Since AI tools made building faster, teams can say yes to more, and scatter. Each yes still costs attention, support and upkeep, and pushes something else out.

Checking a proposal

Answer each proposal in this shape, citing the strategy's sections:

**[The proposal]** ([who asked, where, date])

- Serves: [which outcome], or none.
- Fits the guiding policy: yes or no, because [the line, with its address].
- On the not-do list: yes or no.
- Pushes out: [what the team would stop or delay].
- Cost of waiting a month: [what], or not known.
- Evidence: [its kind: opinions, requests, data, tests, launch data].
- Appetite: [the time it is worth].
- Verdict: fits, to discovery | fits, into Now | doesn't fit ([line]) | challenges the strategy: propose [edit].

A proposal can fit and still wait: "fits, to discovery" is the usual answer for an idea with little evidence behind it.

Sources

• Sean McBride, "RICE: Simple prioritization for product managers", Intercom blog. https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/, read 2026-10-22.
• Itamar Gilad, the confidence meter and ICE. https://itamargilad.com/the-tool-that-will-help-you-choose-better-product-ideas/, read 2026-10-22.
• Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas, 2009.
• Joshua J. Arnold, "Cost of Delay Divided by Duration", Black Swan Farming. https://blackswanfarming.com/cost-of-delay-divided-by-duration/, read 2026-10-22.
• Noriaki Kano and others, "Attractive quality and must-be quality", 1984.
• Anthony W. Ulwick, "Turn Customer Input into Innovation", Harvard Business Review, January 2002. https://hbr.org/2002/01/turn-customer-input-into-innovation, read 2026-10-22.
• Ryan Singer, Shape Up, Basecamp, 2019, chapter "The Betting Table". https://basecamp.com/shapeup/2.2-chapter-08, read 2026-10-22.
• Jim Collins, on the stop-doing list, USA Today, 30 December 2003. https://www.jimcollins.com/article_topics/articles/best-new-years.html, read 2026-10-22.

The strategy document, and a worked example

One document holds the strategy, its outcomes and its roadmap, so nobody has to reconcile three. Keep it to a page or two; a reader should get the choice in a minute.

The template

# [Product] strategy, [period]

- Status: draft | agreed [date] | replaced by [document]
- Owner: [who]
- Agreed by: [who, and when]
- Next review: [date]

## Vision

[One or two sentences: the future for customers that this strategy moves toward.]

## Diagnosis

[What is going on, what makes it hard, and the crux: the part that matters most and that we can act on. Each claim with its source and date.]

## Guiding policy

[One or two sentences: our approach to the crux.]

Considered and set aside:
- [Another approach], because [why].

## Coherent actions

1. [Action]. Owner [who]. Needs [people, money, time].
2. [Action that supports the first.]

## What we will not do

- [Something people want or have asked for]. Why: [reason]. Look again: [date or event].

## Outcomes

| Outcome | Measure | Today | Target | Guardrail |
|---|---|---|---|---|
| [What customers or the business will do differently] | [How it is counted, and where] | [Reading] ([date]) | [n] by [date] | [What must not get worse] |

## Roadmap

**Now**: [problems teams are working on this cycle, each with its outcome]
**Next**: [problems being shaped and tested]
**Later**: [directions]

Dated commitments: [only real ones, each with the reason for the date and the discovery it rests on].

## Insights this rests on

- [Insight] ([source], [date]). Evidence | belief.

## Changes

- [Date]: [what changed, and why].

A worked example (invented)

Crumb is an app independent bakeries use to take pre-orders from their regulars. It has nine people: a product manager, a designer, three engineers, a salesperson, a customer success lead, and the two founders. All names and numbers here are invented.

The first draft, reviewed

The founders' draft for the fourth quarter read: "Our strategy is to grow to 200 bakeries, launch a marketplace, add point-of-sale integrations and become the leading platform for bakeries."

The review, in short:

• Strong: it is short, and it names a number the team can track.
• Goal mistaken for strategy: "200 bakeries" is where they want to be. Nothing says what stands in the way.
• No diagnosis: the draft never mentions that a large share of new bakeries cancel within three months (numbers/retention, 20 Oct).
• Fluff: "the leading platform for bakeries" commits the team to nothing.
• Bad strategic objectives: three large bets for three engineers, pulling in different directions.
• Suggested fix: start from why bakeries stay or leave, choose one approach, and say what Crumb will not do this quarter.

The strategy, after the founders took the review on

# Crumb strategy, Q4 2026

- Status: agreed 24 Oct 2026
- Owner: the product manager
- Agreed by: the whole team, 23 to 24 Oct
- Next review: 9 Jan 2027

## Vision

Every independent bakery knows on Wednesday what its regulars want on Saturday.

## Diagnosis

Bakeries stay with Crumb when their regulars pre-order every week: of the 18 bakeries taking 20 or more repeat pre-orders a week, one has cancelled in six months. Most others use Crumb for holiday cakes and drift off, because their regulars still order at the counter: 26 of the 61 bakeries that joined from April to June had cancelled by October, and 24 of those never passed five repeat orders a week (numbers/retention, 20 Oct). In seven interviews, owners said they have no time to move regulars over (discovery/interviews, Sept and Oct).

The crux: getting a bakery's regulars to move their weekly order to Crumb in its first month. It is hard because regulars have a habit and owners have no time. It is within reach, because onboarding and the ordering flow are ours to change.

## Guiding policy

Make Crumb the weekly ordering habit for a small bakery's regulars, and judge every piece of work by whether more regulars order every week.

Considered and set aside:
- Chains: bigger contracts, but they need reporting and integrations far from regulars, and we have three engineers.
- A marketplace to match Ovenly's: it brings bakeries new customers, while owners told us their problem is keeping the ones they have.

## Coherent actions

1. Onboarding ends at the first ten regulars, with a counter card and a message the owner sends to their list. Owner: the designer, with the customer success lead.
2. The product trio works only on the weekly repeat order this quarter (discovery/regulars-reorder.md). Owner: the product manager.
3. Sales goes to independent bakeries that already have regulars, and pauses outreach to chains. Owner: the salesperson.
4. The customer success lead calls every new bakery in its third week to check how many regulars order. Owner: the customer success lead.

## What we will not do

- Multi-store reporting for chains. Why: it serves chains, which we are not pursuing. Look again: when 100 bakeries take 20 or more repeat orders a week.
- A marketplace. Why: the problem owners describe is keeping regulars. Look again: Q2 2027.
- Point-of-sale integrations. Why: three engineers, and they serve counter sales. Look again: if ten of the bakeries with 20 or more repeat orders ask.
- Custom work for a single bakery.

## Outcomes

| Outcome | Measure | Today | Target | Guardrail |
|---|---|---|---|---|
| More bakeries' regulars order weekly | Bakeries taking 20+ repeat pre-orders a week | 18 (20 Oct) | 45 by 31 Dec 2026 | No-shows on pre-orders stay under 5% (3% today) |
| New bakeries reach their regulars fast | Share of the month's new bakeries with 10+ regulars ordering in month one | 29% (Sept) | 50% by 31 Dec 2026 | Support tickets per bakery do not rise (1.2 a month today) |

## Roadmap

**Now**: regulars forget and retype their weekly order (outcome 1); onboarding to the first ten regulars (outcome 2).
**Next**: owners can't tell how much to bake for the weekend; pick-up queues.
**Later**: regulars bringing friends; bakeries with two or three shops.

Dated commitments: Christmas pre-orders open by 20 Nov, because the season sets the date; last year's holiday flow works, so only the copy changes.

## Changes

- 24 Oct 2026: first agreed version.

If Crumb used OKRs, the first outcome would read: Objective, "Bakeries' regulars order through Crumb every week"; key results, "18 to 45 bakeries with 20 or more repeat pre-orders a week" (stretch) and "29% to 50% of new bakeries reach ten regulars in month one" (committed).

Agreeing it

The product manager hands the strategy out for agreement. The salesperson's part is the not-do list and action 3; the customer success lead's is action 4 and the second outcome; the trio's is the first outcome and the roadmap's Now. Before the review date, the product manager asks the salesperson and one of the engineers separately to say the strategy in two sentences. Both mention regulars ordering every week; the salesperson forgets the guardrail, so the next version moves it next to the target.

Checking proposed work

Three proposals arrive in the following week:

**Multi-store reporting for Hearth Bakeries** (the salesperson, sales notes, 18 Oct)
- Serves: none of the outcomes.
- On the not-do list: yes ("Multi-store reporting for chains").
- Verdict: doesn't fit. Reply to Hearth with the date we look again.

**Loyalty points for Rise & Co** (the salesperson, 14 Oct)
- Serves: outcome 1.
- Fits the guiding policy: yes, if it gets regulars ordering weekly.
- Evidence: one customer's request, low on the confidence meter.
- Appetite: two weeks at most.
- Verdict: fits, to discovery (discovery/regulars-reorder.md), beside other ideas for the same problem.

**A redesign of the bakery dashboard** (the designer, 21 Oct)
- Serves: none directly; outcome 2 only if it shortens the way to the first ten regulars.
- Pushes out: onboarding work for outcome 2.
- Verdict: doesn't fit this quarter as proposed. Consider reshaping it around the first ten regulars, or put it in Later.

What went right. The draft's goal became one outcome with a date and a guardrail. The not-do list answered the chain's request in one line, without a debate. The loyalty request went to discovery instead of the sprint.