Overview

Remove every feature noun from the statement -- if a testable behavior claim still stands (a change in what a user does), it's outcome-framed; if nothing is left, it was only ever an output claim. The distinction matters because a roadmap full of shipped features says nothing about whether the business or the user is actually better off.

The user, the circumstance, and the desired outcome. It deliberately withholds the solution, so the space of possible answers stays open for whoever reads it next, not just the person who wrote it.

The circumstance/job the customer is making progress against -- not their demographic profile. A job story names the circumstance ("when "), the motivation ("I want to"), and the expected progress ("so I can ___").

Ask about a person's real past behavior and specifics; never pitch the idea or ask them to predict the future. "Would you use X?" fails because it costs the respondent nothing to say a kind, non-committal "yes" -- that answer predicts nothing about real adoption.

Outcome, opportunities, solutions, and assumption tests. A solution is orphaned if it doesn't trace upward through exactly one opportunity to the stated outcome.

Value, usability, feasibility, and business-viability risk. The discipline: test the riskiest -- most uncertain -- of the four most cheaply first, not the risk the team happens to be most comfortable estimating (often feasibility).

(Reach × Impact × Confidence) ÷ Effort. Reach: a count over a stated time window. Impact: a discrete scale (this topic uses Intercom's 3/2/1/0.5/0.25). Confidence: a percentage. Effort: person-months.

"Not this timebox" -- not a permanent rejection. Misreading it as "never" can make a contributor whose idea landed in "Won't" feel rejected outright and disengage from bringing future ideas forward.

A fast, five-minute first-pass triage across many candidate items to surface quick wins. Its limitation: it's a coarse folk tool with no scored comparability -- it can't distinguish finely between two items that land in the same quadrant the way a RICE score can.

Must-be (absence dissatisfies severely; presence is merely neutral), performance (linear: more is steadily better, less is steadily worse), and attractive (presence delights; absence causes no dissatisfaction, since it was never expected).

WSJF = Cost of Delay ÷ Duration. It ranks by value delivered per unit of time the team is committed to it, not by absolute payoff alone -- a short job with the same or lower Cost of Delay as a long job returns that value with far less time tied up.

It qualifies the hypothesis under test -- the learning bet -- not the smallest version of the final shippable product. A concierge service or a landing page with a waitlist can be a valid MVP even though neither is real, working code.

Validated learning, not features shipped. A measurement leads to either pivot (change direction) or persevere (double down) -- and, as Worked Scenario 17 shows, different parts of the same bet can receive different verdicts.

It ships independently useful value on its own, and it returns a signal distinct from every other slice's signal.

Exactly one hypothesis, exactly one primary (OEC) metric, and at least one guardrail metric distinct from the primary.

Release (short-lived, removed after full rollout), experiment (short-lived, removed after the experiment concludes), ops (long-lived, an operational kill switch), and permission (long-lived, tied to a customer entitlement).

A north-star is durable and doesn't rotate as the team's focus changes -- it stays the company's single measure of delivered value. An OMTM (One Metric That Matters) is deliberately stage-specific and temporary, rotating as the team's current focus shifts.

Acquisition, Activation, Retention, Referral, Revenue. The practical value: it locates exactly where a product's funnel is leaking, so the fix targets the right stage instead of a vague "growth is slow."

It ties a chosen metric back to a stated product goal via an observable signal, rather than a metric being picked because it's easy to chart. This helps prevent Goodharting (co-22): a metric with no goal behind it invites gaming the first time it's inconvenient.

It doesn't represent a first genuine value moment -- a login costs the user almost nothing and doesn't correspond to the product actually replacing whatever process it's meant to replace. A valid activation definition needs to be precise and falsifiable, tied to real delivered value.

A stated change in an actionable metric would trigger a specific, named decision. A vanity metric is one where no plausible change in its value would change what the team does next.

"When a measure becomes a target, it ceases to be a good measure." The fix: pair every target metric with a guardrail metric and ongoing judgment, rather than optimizing the target metric blindly.

It forces early, cheap clarity on customer value -- a weak or unclear value proposition becomes obvious while writing a compelling announcement is still hard, which is far cheaper to discover before the build than after it.

Splitting into a separate "discovery team" and "delivery team," where one group hands pre-decided requirements to another. The guard: one continuous, cross-functional team performs both discovery and delivery at once.

Appetite is a fixed time budget set before the problem is shaped -- not an estimate derived from the scope. A circuit-breaker is a pre-agreed fallback: what happens if the work isn't done when the appetite runs out, so unfinished work stops on schedule instead of silently overrunning.

Worked Scenario 16's greedy-scheduler alternative -- instead of a 6-week ML pipeline, an engineer proposed a 1-week rule-based scheduler capturing roughly 80% of the demonstrated value. This changed the shape of the MVP, not merely its timeline.

"What changed in what customers actually do because of them?" A good answer names a measured behavior change (co-01) -- a bad one restates the feature list, which is exactly the output framing the question is meant to expose.

Check for a named channel or technology in the "problem" statement -- "Slack" is present, so a solution has already been chosen (co-02). The real, unwritten problem is probably closer to "employees don't reliably see time-sensitive shift alerts," which admits far more possible solutions than Slack alone.

JTBD's unit of analysis is the circumstance, not headcount or role (co-03). If both managers hit the same circumstance -- rebuilding an entire week's schedule after a big change -- the same job story applies regardless of company size; a persona-by-headcount approach could easily miss that shared circumstance.

This is a Mom Test violation (co-04) -- asking for a wishlist, not real past behavior. The compounding cost: any opportunity-solution tree (co-05) built from these answers now rests on unvalidated wishes rather than real, evidenced opportunities.

They're skipping value risk in favor of jumping straight to feasibility (co-06) -- the risk engineers are usually most comfortable estimating. The fix: concierge-test the value question first, cheaply, before committing real ML engineering time.

RICE-score the three tied items for a finer-grained, comparable ranking (co-07, co-09). The 2x2 is a coarse, five-minute triage tool -- it can distinguish quadrants but not fine differences within one quadrant.

They treated a must-be feature as if it were a performance feature (co-10). Past the "meets the expected bar" threshold, further investment in a must-be feature returns almost nothing in satisfaction -- that same sprint spent on a performance or attractive feature would likely have paid off more.

Job A: WSJF = 20 ÷ 1 = 20, versus Job B's 20 ÷ 4 = 5 (co-11). Same absolute urgency, but Job A delivers that value while tying up the team for far less time.

"Minimum" should have qualified the hypothesis under test, not the finished product (co-12). A cheaper, faster test -- possibly not even shippable code -- should have preceded the four-month build to confirm the underlying bet before spending that much time on it.

It destroys distinct signals per feature (co-14). If the combined release underperforms, the team has no way to attribute that result to any one of the five features -- unlike thin, independent slices, which each would have returned their own interpretable signal.

This violates the "exactly one OEC" rule (co-15). The team should have picked one primary metric in advance and treated the other two as secondary or guardrail metrics, with an explicit rule for which one wins if they disagree -- decided before the results came in, not after.

Check its toggle category (co-16) before deleting anything. If it's an ops-category kill switch, a long lifespan is by design, not evidence it's dead -- verify actual current usage and a named owner before removing it.

Suspect Goodharting on the input metrics (co-22) -- the levers are being optimized in a way that no longer actually rolls up into the north-star, or the Goals -> Signals -> Metrics chain (co-19) tying those inputs back to real value has quietly broken.

Focus on week-2/week-3 retention drivers -- precisely defining and investigating what changes for a user right before they drop off (co-20). Don't focus on the signup funnel or the activation flow (co-18); both AARRR stages before retention are already confirmed healthy, so effort there is misplaced.

A PR-FAQ (co-23), which forces stating the customer problem and answering the hardest objections before a single line ships; and a Shape Up pitch with a stated appetite and circuit-breaker (co-25), which forces naming a concrete fallback instead of an open-ended "we'll figure it out" commitment.

This violates dual-track discovery and delivery (co-24) -- a hand-off between two teams instead of one continuous cross-functional team -- and it denies engineers early feasibility input (co-26). The delivery team ends up as order-takers, and any cheaper, feasible alternative an engineer might have surfaced early (as in Worked Scenario 16) never gets the chance to change the spec.

After: "Managers who run the same weekly shift pattern build next week's full schedule in under 2 minutes, instead of re-entering every shift by hand."

Root cause: the "before" version states a feature, not an outcome -- co-01 requires a testable behavior claim (time saved, effort avoided) to survive after every feature noun is removed. The "before" ticket, stripped of "bulk shift-copy," leaves nothing behind.

After: RICE = (200 × 2 × 0.5) ÷ 4 = 200 ÷ 4 = 50, not 200.

Root cause: co-07 requires the arithmetic to actually equal (Reach × Impact × Confidence) ÷ Effort -- the "before" version appears to have skipped the division by Effort entirely, silently inflating the score fourfold.

After: "SSO is a Won't for this release -- not this timebox, not permanently rejected. It's back on the table at the next quarterly planning cycle."

Root cause: co-08 requires "Won't" to be explicitly scoped to the current release, not implied or stated as a permanent verdict. The "before" phrasing risks the engineer disengaging from an idea that was only ever deferred, not killed.

After: without each job's Duration, no WSJF sequencing is possible at all -- co-11 requires the ratio Cost of Delay ÷ Duration, not raw Cost of Delay alone. If Job A takes 8 weeks (WSJF = 5) and Job B takes 2 weeks (WSJF = 15), Job B actually sequences first despite its lower Cost of Delay.

Root cause: sequencing by Cost of Delay alone (ignoring Duration) is exactly the mistake WSJF is designed to correct -- it silently favors big, slow jobs over quick, almost-as-urgent ones.

After: a two-week concierge test -- manually track points for 20 volunteer teams in a spreadsheet and email them a weekly summary -- to confirm anyone actually wants a loyalty-points system before building any of the three tiers.

Root cause: co-12 requires "minimum" to qualify the hypothesis under test, not the smallest version of the eventual finished product. The "before" version is a full build wearing the label "MVP" without actually testing anything cheaply first.

After: add a guardrail -- for example, "30-day refund-request rate must not increase" -- a must-not-regress metric distinct from the primary, guarding against a redesign that boosts conversions by creating confusion or buyer's remorse.

Root cause: co-15 requires at least one guardrail alongside the single hypothesis and primary metric. Without one, a version that increases conversion while quietly increasing refunds could ship as an unqualified "win."

After: "A team is 'activated' once a manager publishes their first complete weekly schedule within 3 days of signing up" -- measured as a timestamp delta with a stated threshold.

Root cause: co-20 requires an activation definition to name the first genuine value moment, not merely account creation. Creating an account costs a user almost nothing and doesn't correspond to the product delivering any real value yet.

After: add the question the team is actually nervous about -- for example, "Q: What happens to a customer's existing data if they don't opt in before the deadline?" -- and answer it honestly, even if the honest answer is uncomfortable.

Root cause: co-23 requires the FAQ to answer the reader's most likely objections or risks, not only easy, comfortable questions. A FAQ that only answers questions with flattering answers has skipped the entire point of writing one before the build.

An MVP's job is to test a specific hypothesis as cheaply as possible, not to be a smaller, worse version of the eventual finished product. "Incomplete" here means scoped precisely to the question under test -- everything else is deliberately absent, not sloppily missing. Calling that a "quality compromise" mistakes the MVP's actual goal (fast, cheap validated learning) for the finished product's goal (durable, polished value), which it was never trying to be yet.

Exhaustively de-risking every assumption before committing to anything is not more rigorous -- it's a different, more expensive way of avoiding the one question that actually matters most. Rigor here means correctly identifying which uncertainty is most load-bearing (the riskiest assumption) and resolving that one first, cheaply -- pragmatism in service of getting to a trustworthy answer fast, not an excuse to skip real validation altogether.

A MoSCoW pass is a scoping decision for one specific, time-boxed release -- it is not, and was never meant to be, a permanent verdict on an idea's merit. Pragmatism means matching the strength of the call to what's actually being decided: capacity for this timebox is genuinely limited and worth deciding firmly; the idea's long-term worth is a separate question this particular pass isn't equipped to answer, so it stays open rather than being falsely closed.

Product decides the "what" and engineering builds the "how," but the how is not free information -- an engineer's feasibility knowledge can reveal that a cheaper mechanism achieves nearly the same policy goal, or that a seemingly simple policy hides an expensive mechanism cost nobody scoping in isolation could see. Keeping engineers out of scoping treats mechanism as a black box that policy never has to consult, which throws away exactly the information most likely to change the policy decision itself.

The original policy decision (build an ML-based suggestion feature) was made before anyone had surfaced that a much cheaper mechanism (a rule-based greedy scheduler) could deliver most of the same value. Once an engineer supplied that mechanism-level fact, the policy itself changed -- the MVP's actual scope shifted -- rather than mechanism simply executing whatever policy had already locked in. Information flowed upward from "how it could be built" into "what gets built," not only downward.

The rule assumes the "what" can be fully decided before anyone consults the "how," but co-26 and Worked Scenario 16 both show the how can cheaply reveal a better what -- a feasibility-aware alternative can turn a six-week bet into a one-week bet carrying almost the same learning value. Treating the two as strictly sequential and separately owned forecloses exactly the collaboration that produces the strongest, cheapest-to-test version of a product decision.