A One-Page Quality Strategy, Annotated: A Real Example You Can Copy

A quality strategy is a small set of decisions, not a pile of practices — and if you've read Building a Quality Strategy from Scratch, you already have the argument for why it fits on a page. What that piece didn't give you was the page itself. This one does.

Below is a complete, realistic one-page quality strategy for a team small enough that most "enterprise QA" advice is useless to them. Then I annotate it block by block: not to admire it, but to show the thinking that produced each line — so you can produce your own, this week, from your own team's reality instead of a template.

The team is invented. The failure modes are not.

Meet Loamly

Loamly is a four-person plant-care subscription startup: two engineers, one designer, and a founder who still writes the occasional cron job. No QA hire. A few thousand paying users who get monthly plant deliveries and care reminders. In the last quarter they've had two incidents that got leadership's attention:

• A billing bug that double-charged a batch of customers on renewal day.

• A reminder system that silently stopped sending for three days before anyone noticed — caught only when a customer emailed asking why their fern died.

Neither was catastrophic. Both were the kind of thing that erodes trust in a subscription business, where the entire product promise is "we handle this so you don't have to." Leadership wants "a quality plan." The engineers are terrified that means a 40-page process document and a Jira board with fourteen mandatory checkboxes.

It doesn't. It means the page below.

(Developed example — composite scenario.)

Loamly Quality Strategy — Q3 (the full one-pager, verbatim)

What "good" means (RANKED): Reliability (zero Sev-1 on billing, reminders, or login) > Correctness of money (a customer is never charged the wrong amount) > Maintainability (no critical area only one person dares touch) > Performance / usability / accessibility (hold the line, don't invest heavily this quarter). Where we're most exposed: Billing has no automated tests and already caused an incident. The reminder job fails silently — no alert, no dashboard, no way to know it stopped except a customer complaint. Our bets this quarter (max 3): Non-negotiables: Revisit: last Friday of the quarter, 30 minutes, whole team.

1. Billing under end-to-end tests that run on every deploy.

2. Alerting on the reminder job — we find out in an hour, not three days.

3. A written release checklist the whole team follows.

• No release ships with an open Sev-1.

• No billing change merges without a test and a second reviewer.

• No merge without green CI.

That's the artifact. Five blocks, one screen, no appendix. Now here's why each block reads the way it does — and how to write yours.

Why "good" is ranked, not listed

Every team can produce a list of quality attributes: reliable, correct, fast, maintainable, accessible, secure. The list is worthless because everything is on it. The moment two of those attributes compete for the same afternoon of engineering time — and they always do — a list gives you no way to choose.

Ranking forces the choice while it's cheap to make: in a planning meeting, not at 11 p.m. during an incident. Loamly put reliability above correctness-of-money, and correctness-of-money above maintainability, on purpose. When an engineer has to decide whether to spend Thursday hardening the reminder job or refactoring a gnarly module only one person understands, the rank answers it: the reminder job wins, because reliability outranks maintainability. No meeting required.

Notice what the bottom of the rank does. Performance, usability, and accessibility aren't dismissed — they're explicitly parked with "hold the line, don't invest heavily this quarter." That sentence is doing real work. It tells the designer not to open a performance audit this quarter, and it protects the team from the guilt of "we're not doing enough about accessibility" by making the deferral a deliberate, revisitable decision instead of an accidental gap.

Do this on your draft: write your quality attributes on one line, then force them into a strict order with > between them. If two feel genuinely tied, ask which one, if it broke, would make you drop everything — that one is higher. If you can't rank them, you haven't decided what you're building; you've listed what you'd like.

Why exposure is read from the incident log, not brainstormed

Here is the block most teams get wrong. Asked "where are we exposed?", a team will brainstorm a risk register — twenty plausible-sounding risks, weighted by whoever spoke most confidently in the room. It reads well and predicts nothing.

Loamly did something narrower and far more honest: they read their own incident history and their own test coverage, and wrote down what those two facts already proved. Billing has no automated tests and caused an incident — that's not a hypothesis, it's a measurement. The reminder job fails silently — they know, because it did, for three days. Exposure here isn't imagined; it's the intersection of "what has already hurt us" and "what we currently can't see."

This is the discovery move, and it's the load-bearing part of the whole page. You do it in two concrete passes:

1. Rank what "good" means — so you know which failures actually count. A slow settings page is not a Sev-1 for Loamly; a wrong charge is. The rank is the filter.

2. Read the incident log and the coverage map against that rank — so exposure is evidence, not opinion. Where has a high-ranked attribute already failed, and where can't you even detect failure?

Do those two passes and the bets don't require a brainstorm. They fall out. Billing: high-ranked, already broke, zero tests → test it. Reminders: high-ranked, already broke, invisible → make it visible. You didn't choose the bets so much as the evidence chose them for you. This is the discovery-first pattern the whole site keeps returning to — you can't test your way out of a risk you never located, and you locate it by reading what already happened, not by guessing at what might.

Do this on your draft: open your incident tickets from the last two quarters and your CI coverage report side by side. Write one sentence per exposure that names both halves — the attribute that failed and the reason you couldn't catch it. If a line has only the first half ("billing is scary"), it's a feeling; find the second half or cut it.

Why the bets are capped at three

The cap is the point. A team of two engineers has roughly one meaningful quality investment's worth of slack per person per quarter, and the founder's cron-job time doesn't count. Four bets means one silently doesn't happen — and because nobody decided which one, it's whichever felt least urgent in week nine, which is usually the one that mattered.

Three named bets, each traceable to a specific exposure, means each has an owner and an end state you can check. "Billing under end-to-end tests on every deploy" is done or it isn't — you look at the pipeline and see the job. "Alerting on the reminder job" is done when a killed job pages someone within an hour, and you can verify that by killing it in staging on purpose. Contrast that with an uncapped list of "improve testing, add monitoring, tighten releases, review architecture, upgrade dependencies" — none of which has a definition of done, so all of which stay perpetually 60% complete.

The cap also protects the rank. If you find yourself wanting a fourth bet, you're being told one of two things: either your rank is wrong (something you called low-priority is clawing for investment), or you're smuggling in work that belongs to next quarter. Both are worth knowing in August rather than discovering in October.

Do this on your draft: write every improvement you want, then cross out everything below line three. The three that survive are your quarter. If crossing out line four physically bothers you, that reaction is the exercise working — sit with which exposure you're actually willing to carry unmitigated, and write it down so the revisit meeting can reconsider it on purpose.

Why non-negotiables are separate from bets

Bets are things you're building this quarter. Non-negotiables are things that are already true and must stay true regardless of what you're building. Collapsing the two is a common and costly mistake, because it makes your standing floor look like optional quarterly work.

Loamly's "no billing change without a test and a second reviewer" isn't a project — it's a gate that applies to every billing change from now on, including the ones nobody planned. The distinction matters most under pressure. When a hotfix needs to ship at 5 p.m. on a Friday, the bets are negotiable (the release checklist can wait until Monday) but the non-negotiables are not (that billing hotfix still gets a test and a second set of eyes). Writing them as a separate block is what lets the team say "no" to a bad shortcut without relitigating the whole strategy — the page already decided. For the mechanics of gates that actually hold when someone leans on them, see Quality Gates That Actually Gate.

Keep this block short and absolute. A non-negotiable with an "unless" in it is a guideline, and guidelines don't survive Friday.

Do this on your draft: list the rules you'd want enforced even during your worst week. For each one, imagine the specific pressure that would tempt you to break it, and check that the wording gives no room to. If it has an "unless," either delete the unless or move the item down to bets — don't let a guideline wear a non-negotiable's uniform.

The four blocks, and what breaks without each

The one-pager is really four decision blocks plus a revisit date. Each answers a distinct question, and each has a specific failure mode when a team skips it — which is exactly how you audit a strategy someone hands you.

Block	The question it answers	Failure mode if you skip it
What "good" means (ranked)	When two quality attributes compete for the same hour, which wins?	Every tradeoff gets relitigated ad hoc; the loudest voice or the latest incident sets priority.
Where we're most exposed	What has already hurt us, and what can't we currently detect?	Effort spreads evenly across imagined risks; the real, evidenced gaps stay unaddressed.
Our bets (max 3)	What are we actually investing in this quarter, and how will we know it's done?	An uncapped wish-list; work stays perpetually 60% done with no owner and no definition of done.
Non-negotiables	What must stay true even during our worst week?	The standing floor erodes under deadline pressure, one "just this once" at a time.

If a strategy you're reviewing is missing a block, you now know precisely which failure it's exposed to. A page with bets but no rank will thrash on priorities. A page with a rank but no exposure block is guessing at where to spend. Use the table as a checklist against your own draft before you circulate it.

Why a revisit date, and why it's on the page

A strategy without a review date is a document that quietly goes stale and then gets cited as gospel six months after it stopped being true. Loamly's "last Friday of the quarter, 30 minutes, whole team" does three things: it makes the page explicitly temporary (this is Q3's plan, not eternal law), it creates a moment to check whether the bets actually landed, and it gives the parked items — performance, accessibility, that scary module — a scheduled hearing so deferring them stays a decision rather than an accident.

Thirty minutes is deliberate. A quality strategy this size does not need a half-day offsite to review; it needs a short, honest look at three questions: Did the bets land? Did the exposure change? Does the rank still hold? If any answer is "no," you write next quarter's page — which, because the format never changes, takes an afternoon.

Do this on your draft: put a specific date, length, and attendee list on the page right now — not "quarterly" but "Friday, September 26, 30 min, everyone." A revisit without a date on the calendar is a revisit that doesn't happen.

How you'll know your page is working

The measure of this strategy isn't whether it looks thorough. It's whether it changes a decision. Watch for these signals over the quarter:

• Someone resolves a priority argument by pointing at the rank instead of escalating to the founder.

• A bet gets checked off with a verifiable artifact — a pipeline job you can see, an alert you triggered on purpose in staging.

• A Friday hotfix goes through the billing non-negotiable without anyone treating it as bureaucracy.

• The revisit meeting actually happens, on its date, in thirty minutes.

If none of those happen, the page is decoration, and the fix is almost always the same: the exposure block was brainstormed instead of read from evidence, so the bets don't connect to anything real. Go back to the incident log. For the broader question of which signals are worth watching at all, Quality Metrics That Actually Matter is the companion piece; for the philosophy underneath the whole approach, What We Mean by "Shift Quality" is the root.

A one-page strategy earns its length by being read, argued with, and used to say no. Write yours from your own incident log this week, cap the bets at three, and put the revisit date on the calendar before you close the file.

Sources

• Loamly is a composite scenario — a realistic but invented four-person startup, used to make the one-pager concrete. It does not represent a specific real company, and the incidents described are illustrative.

• No external statistics are cited in this piece; the argument rests on the reasoning above and the composite example, not on quantitative claims.

Keep learning. This article is part of the Quality Management Fundamentals path in the ShiftQuality Learning Center.