The First 90 Days — Align, Design, Build ก่อนขยายอะไรทั้งสิ้นThe First 90 Days — Align, Design, Build Before Scaling Anything

🤔 If day 1 of your AI programme is the day you buy a platform, what will you know on day 180 that you do not know today?

The previous post, Suppliers, Cost and Footprint, ended on a sentence that is uncomfortable to read and impossible to argue with: an organisation can outsource the work, but it cannot outsource the accountability. Everything this series has walked through over seventeen posts — the six layers, the recurring decisions, workflow redesign, the AI and data factory, the release gate, one evidence system, cost and carbon footprint — eventually has to land on a real calendar with real dates, with people's names on it, and with a day on which everyone comes back to the table. Otherwise it is only a better-looking deck.

The short answer to the whole post is this: the first 90 days are not the time for building things, they are the time for deciding what would count as evidence — align the work so it has an owner and so the organisation can see the truth about what AI it already runs, design the decision and its thresholds in full before a line of code exists, then build the smallest system that can be measured and reversed. All three phases produce evidence rather than features, and that is precisely what gives the second 90 days something to judge.

1. No Law Prescribes This 180-Day Sequence

Let me say the most important thing in the very first line, because this is the claim most easily misquoted in a meeting room: no law and no standard prescribes this 180-day sequence. The book AI Transformation as an Organizational Core calls it what it is, in its own words — an author synthesis — which in the playbook's evidence-label system means "a practical model developed in this playbook from the cited evidence and the AI-as-a-Core concept"^[1]. It is not a requirement issued by any regulator, and it is not a timetable mandated by any international standard.

The book's own boundary sentence reads: "No law or standard prescribes this 180-day sequence. It is an author synthesis combining the AI-as-a-Core concept with lifecycle risk management, continual improvement, workflow redesign, evaluation gates, and workforce participation. Legal obligations apply throughout."^[1] — read that last sentence carefully, because it is the part readers skip most often. The calendar belongs to the author, but legal obligations do not wait for a phase. No organisation is permitted to defer personal-data questions, supplier contracts or employee rights to "phase two" merely because the plan says it is still day 12.

The number 180 is therefore not a measurement of anything. It has no denominator, no sample, no comparison against the "normal" length of a similar programme, and the book makes no claim that 180 days is faster or slower than any alternative^[1]. What it is, is a calendar designed so that one learning loop completes before anything scales — six phases of thirty days, of which the first ninety are align, design and build, and the last ninety prove, prepare and decide. I would ask readers to hold it the way they hold a sprint length: an agreement about cadence, not an empirical finding.

If it is not law, why keep the calendar at all

Because a calendar is an instrument of self-binding. In the reviews I am asked to run for organisations, the problem is almost never that the team does not know what it ought to do. Everyone knows there should be a baseline, that there should be an owner, that you test before you release. The problem is that no date is attached to any of it. Without a date, "we will do it properly" means "we will do it when we have time", and in an organisation racing to do something about AI, spare time is the one thing that never arrives. The book therefore offers 180 days not as a formula but as a frame that forces the question "what do we actually know now?" to be asked six times in half a year, instead of once, when the budget runs out.

The line the book prints under its chapter title states the intent in a single sentence: "Prove one complete learning loop before launching a large portfolio and let evidence decide what earns the right to scale."^[1] The book prints that standfirst in English only — the Thai track of this post carries my own expansion of it rather than a translation the book endorses — and its substance is this: prove the learning loop through one complete turn first, then let evidence decide what earns the right to scale. Not the enthusiasm of an executive sponsor, and not the size of a platform contract.

The objection I hear most often is "one loop is too slow, our competitors are running ten things at once." I understand that pressure. But turn it around. An organisation running ten things at once with no baseline, no threshold and no stop condition is not learning ten times faster. It is not learning at all — because when the results come out ambiguous, nobody can say whether it was the model, the workflow, the data or the user group. The problem is not the number of projects. It is the number of hypotheses left floating at the same time.

💡 My view: the first of this chapter's five operating principles is written very briefly — "One learning loop before a large portfolio Depth before breadth."^[1] I treat that sentence as the first exam question for every AI plan that lands on my desk. If the plan opens with a list of twenty use cases all starting in the same quarter, I do not need to read page two, because a plan like that is not designed to learn. It is designed to look busy.

The same cadence appears in the masterclass the book grew out of. Late in that episode the presenter explicitly does not recommend that an organisation just starting out should open by collecting a hundred use cases, because a long list is not a strategy; instead, find a decision with clear value and clear feedback, redesign the workflow around it rather than bolting AI onto the existing step, then capture the feedback, close the learning loop, and only afterwards extend the capability to other decisions^[2]. The cadence he lands on as the segment closes is the one this series has used across all twenty posts — start narrow, learn fast, scale deep. That episode runs 52 minutes, was published on 28 August 2026, and its deep link at 46:37 still resolved when I checked on 5 September 2026^[2]. Let me be explicit that this whole paragraph is a paraphrase of the video rather than a transcription, and that the video contains no 180-day plan, no phase names and no gate structure of any kind. The six-phase calendar is the book's alone.

For anyone joining the series at this post: AI transformation here does not mean installing tools across every department. It means making an organisation's recurring decisions demonstrably better, and the first 90 days are where the whole word "demonstrably" gets its foundation. If you want to review how to choose which decision enters this programme, post #5 Decision Portfolio, on the decision portfolio, is the selection instrument this chapter assumes you have already used.

2. Six Phases, and One Rule That Applies to Every One of Them

The image that follows is the whole programme on a single page. Six cards, left to right, are the six phases of thirty days each, and the dark bar beneath them is the one rule that applies to all six equally. This post stays with the first three cards; the last three are the subject of the next post.

Read quickly, it looks like an ordinary Gantt chart. What stops it being one is the columns that are missing — there is no "headcount" column, no "percent complete" column, and no "features delivered" column. What each phase has to deliver is evidence. The table below gives the name and the substance of all six phases as the book sets them out. I include all six so that the full route is visible, even though this post expands only the first three.

The rule running under all six cards is the sentence the book prints: "Every phase produces an artifact owner threshold and stop condition"^[1] — printed, as you see, without commas. Four words, short enough to read straight past. I would like you to use them as a checklist against the AI project your organisation is running right now, one word at a time.

Artifact is something you can hold at the end of the phase, not a progress report. If the first month ends and what is delivered is a slide summarising the meetings, that is not an artifact. If it is a register of the AI systems the organisation actually runs, with vendor names and data paths attached, that is an artifact. Owner is one person's name, not a department's, because a department does not attend meetings and does not sign anything. Threshold is a number or a condition written down before anyone sees the result. And stop condition is the sentence that says in advance what would make us quit. Of the four, the last is the one most often missing in every organisation I have reviewed.

This chapter's five operating principles

The first is already in the 💡 box above. The book writes the remaining four as follows. Principle two: "Business and risk ownership cannot be delegated to the AI team Accountability follows the decision." — accountability follows the decision, not the technology. The AI team can build the system, but it cannot carry the consequences of a business decision on the line owner's behalf. Principle three: "Instrument outcomes before scaling usage Login is not adoption and usage is not value." — that sentence should be taped to the side of every dashboard, because the number of people logging in is the easiest number to obtain and the one that tells you least.

Principle four: "Build reusable capability from proven need Avoid platform speculation." — reusable capability has to grow out of demonstrated need, not out of a guess about what the future will require. And principle five: "Stop weak initiatives visibly and without stigma Portfolio discipline frees capacity for value."^[1] — stopping has to be done in the open and without marking anyone's card, because if stopping is equivalent to admitting personal failure then nobody will ever stop anything, and the organisation will pay maintenance on things nobody uses for ever. The five are one set and the book does not rank them, so I do not reorder them.

How this programme differs from an AI management system

The question executives ask the moment they see the six-phase picture is "does this replace ISO?" The answer is no, and the two sit at different levels. An AI management system under ISO/IEC 42001:2023 is about installing a management system across the whole organisation — planning, setting objectives and continually improving — for entities that provide or use AI-based products and services^[3]. The book's 180-day programme is a way to start such a system with one real piece of work, instead of starting by writing the full policy set and then looking for somewhere to apply it.

On status: ISO/IEC 42001:2023 (Information technology — Artificial intelligence — Management system) has a publication date of December 2023 and, checked in a real browser on 5 September 2026, is Edition 1 with status Published at stage 60.60, maintained by ISO/IEC JTC 1/SC 42^[3]. I deliberately quote no clause text and no control from it anywhere in this post, and I want to repeat the warning the book itself gives from its first chapter: "These frameworks support the discipline of a loop; they do not promise a financial return."^[1] Completing all six phases does not mean you are certified, does not mean you have passed an audit, and does not mean you will get the return anybody promised you. What it gives you is the discipline of the loop.

3. Days 0–30 · ALIGN

The book compresses the entire first month into one paragraph: "Days 0 to 30 establish mandate and truth. Name an executive accountable for value and risk and a business decision owner with operating authority. Form a small cross-functional core across business, operations, data and AI, architecture, security, privacy and legal, risk, change, and workforce representation. Inventory deployed, procured, experimental, and employee-adopted AI. Map vendors, data flows, obligations, and past incidents. Choose one to three target decisions and document outcome, cycle time, quality, cost, risk, affected groups, and feedback delay. Publish interim acceptable-use rules and a safe route to disclose shadow use."^[1]

Two words in that first sentence carry the month: mandate and truth. The first is authority, the second is information, and the month can fail for want of either. An organisation with authority but no truth will issue instructions built on a wrong picture. An organisation with truth but no authority will produce an accurate report that nobody acts on.

Two roles that need a person's name

The first role is an executive accountable for both value and risk. The word that matters is "both", because the moment the two are split — one person chasing outcomes, another chasing risk — the organisation gets a war between two camps instead of a decision. The person who has to answer both "why have we seen no results yet?" and "why did you let this happen?" is the same person, and that is the person who can genuinely weigh one against the other.

The second role is a business decision owner with operating authority. Operating authority means they can order a change to the way the team doing the work actually works, not merely attend the meeting. I meet this case constantly: an organisation appoints an excellent AI programme manager who has no authority to change the operations department's SOP. The system is built, nobody changes how they work to receive it, and it ends its life as a screen left open beside the old one.

Around those two roles sits a small core team whose nine dimensions the book names in full — business, operations, data and AI, architecture, security, privacy and legal, risk, change, and workforce representation^[1]. The last is the one always cut first when somebody says the team is too large, even though worker voice is what tells you in month one what a workflow designed on paper will meet in reality, and what keeps the change from being resisted on release day.

An inventory that has to include what employees brought in themselves

The book requires four kinds of AI to be surveyed at once: what is deployed, what is procured, what is experimental, and what is employee-adopted^[1]. The first three are not hard to find — they are in the procurement system, on the asset register, or in the innovation team's slides. The fourth is the category that makes most of the inventories I have seen wrong from the first day, because they count only what the organisation knows it has.

In practice, employees open a browser tab, find a free tool and paste work content into it every day — not out of deliberate defiance, but because it gets the job done, and because the organisation never told them what is and is not allowed. That is exactly why the book pairs two things in the last sentence of ALIGN: interim acceptable-use rules and a safe route to disclose shadow use. The first says what is permitted; the second makes telling the truth something you do not have to pay for. Rules without a safe route do not produce abstention. They produce the same use, more quietly.

Alongside the inventory sits a four-layer map — vendors, data flows, obligations and incidents. The vendor layer answers who holds what. The data-flow layer answers what data leaves the organisation and where it comes to rest. The obligation layer answers which legal, contractual and sector duties are attached. And the incident layer answers what has already gone wrong. The last is routinely skipped because nobody wants to dig up old business, but it is the layer that tells you most precisely where this organisation breaks repeatedly.

Choose one to three, then write the baseline down before touching anything

ALIGN forces a choice of one to three target decisions^[1], each recorded against seven baseline values — outcome, cycle time, quality, cost, risk, affected groups and feedback delay. Not because three is a magic number — the book never claims to have measured three as the best figure, and the number has no denominator behind it — but because the second failure pattern the book names is "collecting hundreds of ideas", and a long list is not a strategy.

The value I would underline among those seven is feedback delay, because it is the best predictor of whether this programme can learn at all. If a decision takes nine months to reveal whether it turned out well or badly, the learning loop will not complete inside 180 days no matter what else you do. Choosing work whose feedback returns in days or weeks is therefore not choosing the easy work; it is choosing the work this programme can learn from in time.

And the baseline has to be written down before anything is touched. The sentence is so obvious it is boring, but the failure pattern "omitting a baseline" is on the book's list for a reason. With no baseline, every discussion afterwards ends at "it feels faster", and nobody can prove or disprove it.

Does NIST AI RMF say the same thing

It does, but in a different form. The GOVERN function of NIST AI RMF 1.0 has 6 categories and 19 subcategories, and several of them line up exactly with what ALIGN demands^[4]. The difference is that NIST writes them as outcomes that must obtain, not as a sequence of steps and not as a calendar. The table below is a mapping I made myself between ALIGN's demands and NIST's subcategories, so that teams who have to report to a board can show that the first month's work does not float outside the international frame.

That last row matters as much as the nine above it, because when people build a slide comparing their programme against an international framework, the temptation is to drag everything into alignment. No GOVERN subcategory speaks directly to a safe route for disclosing AI used outside the sanctioned stack. It is the book's proposal, and it should be cited as that.

On the status of this framework: NIST released the AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1) on 26 January 2023, and when I checked on 5 September 2026 it remained at version 1.0 — a framework NIST itself describes as voluntary, rights-preserving, non-sector-specific and use-case agnostic, neither a law nor a certification^[4]. NIST also writes that users may select among the categories and subcategories as suits them, so those 19 subcategories are not a checklist to be ticked off inside the first month. And as with ISO/IEC 42001, this framework promises no business return at any rate. What it gives you is a common language for describing how an organisation governs.

4. Days 31–60 · DESIGN

The second month is the one people most want to skip, because it is the month with nothing to demo. The book writes: "Days 31 to 60 design decisions controls and work. Decompose each decision into estimate, judgment, action, outcome, and feedback. Redesign normal cases, exceptions, appeals, and human authority. Complete proportionate privacy, security, legal, ethical, workforce, supplier, and environmental assessments. Define the baseline, evaluation cases, Thai-language and subgroup tests, release thresholds, monitoring, and stop conditions before building."^[1]

The last two words of that paragraph — before building — are the whole month. Everything listed has to be finished before the first line of code, not for the sake of tidiness, but because a threshold set after the result is seen is not a threshold. It is a description of what already happened.

Decompose the decision into five parts

The book asks that each decision be decomposed into estimate, judgment, action, outcome and feedback, which is the same frame this series has used since post #2. The value of the decomposition inside a 180-day programme is that it tells you immediately where AI belongs and where the human belongs. Estimate is where a model does its best work. Judgment is where goals and consequences have to be weighed, which is human work. Action is the point at which a real effect reaches the outside world. Outcome is what follows from it. And feedback is the path along which that outcome walks back to become data.

Teams that skip this decomposition end up building a system that does all five things at once inside one box, and when the results are poor nobody can say whether the estimate was wrong, the judgment was wrong, or the feedback never came back at all.

Normal cases, exceptions, appeals and human authority

These four have to be designed together, not the normal case first with exceptions considered afterwards, because in real work the proportion of exceptions usually determines whether the system helps or becomes an additional burden. A system that handles the normal case beautifully and throws every exception back to a person with no context makes that person's job heavier even as the volume falls, because what is left is nothing but hard cases.

Appeal is the channel through which an affected person can contest an outcome, and it has to exist from the day of design, not from the day of the first complaint. Human oversight has to state precisely what authority a person holds at each point — observe only, approve, veto, or amend. Those four words are not remotely the same thing, and writing "a human is in the loop" without naming which one is the most popular way of manufacturing the appearance of oversight where there is none.

Impact assessment, proportionate

The book names impact assessment across seven domains and adds the word "proportionate" at the end of the sentence. That word works in two directions. In one, it prevents low-risk work being weighed down by an inch of documentation. In the other, it forbids high-risk work passing on a one-page form. In practice I recommend deciding the intensity of the assessment in the first week of this month and recording the reason, because when somebody later asks why this piece of work was assessed only to this depth, the best possible answer is a note written while nobody was under pressure.

• Privacy — what personal data enters the system, who can see it, how long it is kept, and where it leaves the organisation
• Security — who can reach the system and the data, whether there are unintended ways in, and how you would know if you were attacked
• Legal — the statutory, contractual and sector duties attached to this particular piece of work
• Ethics — who gains, who loses, and whether that difference can be explained by a reason anyone would accept
• Workforce — whose job changes, how it changes, what retraining it needs, and who tells them
• Supplier — which providers sit on this path, what the contract says, and how hard it would be to leave
• Environment — the energy cost and carbon footprint of the option about to be chosen

Six things that must be finished before the first line of code

The last part of this month is the part I regard as the most important in the whole first 90 days. The book names six things that must be defined before Build, and I set them out here as a table with the question each one answers and what happens if it is missing.

5. Days 61–90 · BUILD

The third month is the first with something to hold. The book writes: "Days 61 to 90 build and test in a bounded environment. Create an instrumented minimum viable workflow using approved architecture. Maintain a system card, release manifest, data lineage, access controls, traces, evaluation set, and rollback. Test offline, challenge credible failure modes, review privacy and security, and use shadow mode where practical. Train the pilot group on verification and escalation."^[1]

What "instrumented minimum viable workflow" actually means

The phrase has three parts and every one carries weight. Minimum means as small as it can be while still answering the question, not as small as you can finish in the time available. Viable means it runs the whole loop for real, from intake through to outcome, rather than a prototype that works only along the path prepared for the demo. And workflow means the whole chain of work, not one step — which is the entire argument of post #6: we redesign the workflow, we do not bolt AI onto the existing step.

As for instrumented, that is the part cut most often when the time runs short. It means a system with observability built in from the start rather than added afterwards. If we build the system first and then work out what to measure, what we get is a system that measures whatever happened to be measurable, which almost never coincides with what we need to know on the day of the decision.

Seven things that must exist from the first day the system runs

Of these seven, the one I see deferred most often is rollback, on the grounds that "we are not live yet, we will do it later". The trouble is that the day you need it is not a quiet day. It is a day when something is going wrong, and a route back that has never been rehearsed will not work exactly then.

Test before the real world sees it

The book names four kinds of test for this month. The first is offline testing against the set designed last month. The second is challenging credible failure modes — not imagining catastrophes, but taking the failure modes that have a real reason to occur in this particular work and testing them one at a time. The third is a privacy and security review, which has to be carried out by people who did not build the system. And the fourth is shadow mode, running the system in parallel with the existing process with no real effect on the outside world, then comparing the two paths.

Shadow mode is my favourite instrument of this month, because it yields data from real work without asking anyone to carry real risk. But it has a condition to watch: if the people doing the work know a shadow system is watching and begin to adjust their behaviour to it, what is measured is no longer the system's effect. And the book adds the words "where practical" for a reason — some work genuinely cannot be shadowed, such as work whose outcome depends on live interaction with a user.

The month's last item is training the pilot group on verification and escalation. Notice that the book does not say train them on "how to use it". It says verification and escalation. That difference matters a great deal. Usage training teaches people to press the right button. Verification training teaches people when not to believe what they see. Escalation training teaches people whom to tell, and within how many hours, when they meet something abnormal. The latter two are what turn the pilot group into a source of evidence rather than merely the first set of users.

6. Workshop: The 180 day commitment room

Everything in the three phases above will make an agreeable read and change nothing at all, unless there is a room in which it is genuinely decided. The book therefore closes the chapter with a working session it calls The 180 day commitment room — and I like the name because it is not called a planning room. What has to leave this room is not a plan but a commitment, and a commitment differs from a plan in having a person's name attached and a date.

The agenda of this room has seven steps in the order the book sets them out^[1]. I have added the column "what has to come out of it" myself, so that readers can check whether each step actually finished, or merely finished talking.

The output of the 180-day commitment room is therefore not a deck. It is a set of 30-day commitments and a first Executive Review with a real date on the calendar^[1] — which is literally the workshop's last step as the book writes it. I stress the words "invitation has been sent" in the table because experience says that a review date agreed verbally in the room, with nobody pressing send, has an alarmingly low rate of actually happening.

The step I would watch most carefully is the sixth. Protected Time does not mean putting a person's name on the programme. It means genuinely releasing that person from existing work in the proportion stated. If an organisation names five excellent people while all five remain on their day jobs at a hundred per cent, the programme will run on the time left over from everything else — which means it will run only in weeks when nothing is urgent, and in most organisations there is no such week.

The gate table for the first 90 days

The word Gate in this table is a compressed form of the release gate, the point at which one named person decides, on evidence declared in advance, whether the work goes on. The gate in full is the subject of post #15; what a 180-day programme needs from it is the date and the owner.

The way I recommend reading this table is to read the stop condition column before any of the others, because it is the column that shows how serious the organisation is. A stop condition that reads "if the results are unsatisfactory" is not a stop condition. It is a blank waiting for the loudest person in the room to fill it. A stop condition that reads "if the Trace cannot reconstruct an event" is a sentence you can check in thirty seconds and cannot argue with.

The other thing this room has to settle is who holds the authority to call a stop. In many organisations the person who spots the problem is not the person who can stop the work, and the gap between those two people is where small events become large ones. For a stop condition to work in practice, there has to be a named person who can press stop without asking permission from someone with an interest in going on.

7. The Metrics That Matter in the First 90 Days

The book gives this chapter's metrics as one long set under the instruction to "use a balanced view", without saying which one belongs to which phase^[1]. The first four of that list are the four that can genuinely be measured inside the first 90 days; the rest have to wait until the system is in use. I therefore take only those four, and add a Scorecard column so that it is visible which square of the organisation's six-square scoreboard each one moves — the mapping to scorecard columns is my own editorial judgment, since the book prints this as one undifferentiated list.

Of these four, the most easily misread is Inventory Coverage, because it is a number that is very easy to make beautiful. A unit that answers "we have no AI use outside the sanctioned stack" improves the coverage figure while in practice signalling the opposite: that the disclosure route is not yet safe enough for anyone to dare use it. I therefore recommend always reading this number alongside the count of items disclosed through the safe route. Zero disclosures is not good news.

The other one to read carefully is Time to Classification, because it is a metric you can flatter by redefining the denominator. If this month is three times faster, the first question to ask is not "how did we do that?" but "what did we count this month, and what did we stop counting?"

Failure patterns

The book lists ten failure patterns for this chapter^[1]. I include all ten, because each points at a different moment in the programme, and I have seen almost every one of them with my own eyes at least once.

• Beginning with a platform purchase — deciding the tool before knowing which decision is being fixed, so that everything afterwards has to be justified against something already bought
• Collecting hundreds of ideas — a list long enough to look like a strategy, with nobody having the time to prove even one of them through a full loop
• Choosing only low-value demos — picking the easy work so there is something to show, after which the organisation concludes from low-value work that AI returns little
• Assigning everything to IT — pushing the whole thing to a function with no authority to change the business line's workflow, then being surprised that the workflow does not change
• Postponing legal, security or workforce work — holding those three back because they slow things down, then having to rebuild the design close to release
• Confusing logins with adoption — reporting user counts as evidence of acceptance, when all they show is that somebody opened it
• Omitting a baseline — starting without recording what today looks like, which turns every later conclusion into a story
• Scaling before feedback — expanding to the second and third unit before the first unit's results have come back, and so scaling the mistake along with everything else
• Refusing to stop weak cases — letting work with weak evidence run on because stopping is read as a person's failure rather than the evidence's verdict
• Building a platform so large that no decision improves in six months — the last of them, and the most expensive

That last one should be read next to this chapter's own 180-day figure, because six months is roughly the same window; the only difference is what it was spent on — spent building a platform, or spent making one to three decisions demonstrably better. And let me repeat the caution the book itself observes: these ten are a pattern list drawn from practice, not a study. The book does not say how often each pattern occurs, in how many organisations, or with what probability. Anyone who takes this list and writes a percentage in front of each item is adding something the original does not contain.

8. The Road Ahead

If the whole chapter had to reduce to a single change of practice, I would choose this one: change the opening question of an AI programme from "which tool do we start with?" to "on day 90, what evidence will we be holding, and who is holding it?" The first question produces a procurement contract. The second produces a programme that can decide when the time comes.

Three things can be done next week. One, write two people's names on a piece of paper — the executive accountable for both value and risk, and the decision owner with operating authority. If you cannot write them, that is your first piece of work, not the choice of model. Two, open one spreadsheet and start the inventory with the fourth category first, the things employees brought in themselves, because the first three are already retrievable from the procurement system. And three, pick up the most recent AI project approval document and look for the line marked "stop condition". If there is none, write one line today, while nobody yet has an interest in the answer.

What the first 90 days do not give you is the answer to whether this work should scale. They give you only a system ready to be judged. The second 90 days — prove, prepare, decide — are the part that lets the real world answer, with a test set the team has never seen, with a narrow and reversible release, and with a day-180 review that has to choose one of a small number of moves. The last of the book's eight leadership questions asks it directly: "What deserves to scale reshape pause or stop"^[1] — what deserves to scale, be reshaped, be paused or be stopped. One small observation worth recording is that the summary page of the book uses the word pause while Chapter 12 itself uses hold. I quote whichever source I am naming in each place, and I do not fold the two words into one.