For leadership
Four decisions only you can make
Twenty minutes, and you leave with four questions for your next review.
On this page
Who this page is for, and how to use it
The sponsor, the executive, the head of product or engineering: whoever owns the outcome and the budget rather than the implementation.
Take four questions to your next review, and know a good answer from a bad one when you hear it.
- Read the four decisions. Each card has the question, a healthy answer and a bad one.
- Open a card for its test: a sort, a ladder or a calculator.
- Run the six-control check with the team, then put the first thirty days in your calendar.
P0 to P3 where your four decisions fall
- 1What is AI workP0 · Frame
- 2What it may do alonewhere P0 hands over to P1
- Your team writes the specP1 · Design & Spec
- sign-off (the hard gate)
- 3What counts as evidenceP2 · Build & Prove
- 4What you fund past cycle oneP3 · Run & Learn
Take each decision to your next review
Each one trades a business risk against a business return, so nobody below you can make it. Open a card for the test that goes with it.
1
In P0, before anything is builtP0
Which work is genuinely AI work
AskWhich of these are rules? Show me the AI-fit record for each.
A healthy answerTwo or three of your top five come back as rules, on record.
A bad answerEvery item is an agent, and nobody wrote down why.
Ask it of the roadmap, not of one feature, and expect most of it to come back as rules. A team under an agent-first directive will build agents for things a rule does better. It will not tell you, because you asked for agents.
- Is there a genuine judgement call?Could two competent people differ on the answer?NoA rule. Code does it, cheaper and provably.
- Is the volume high enough?Enough cases to carry evaluation, gates and a harness.NoA person. Below the volume line, a person is cheaper.
- Is a wrong answer recoverable?Can someone undo it, quickly and cheaply?NoAssisted. The model drafts, and a person acts on what cannot be undone.
- Yes to all threeYesAn agent, with the steps that cannot be undone still gated.
How it works
Three questions in order, and the first “no” ends it. Is there a genuine judgement call: could two competent people differ? Is the volume high enough to carry evaluation, gates and a harness? Is a wrong answer recoverable? Only yes-yes-yes is fully agentic; the rest is code, a person, or an assisted mix with the unrecoverable steps gated.
2
Where P0 hands over to P1P0 to P1
What the agent may do without a person
AskWhat may it do without a person, and who decided?
A healthy answerA level for each action, set by what a mistake costs and whether it can be undone.
A bad answerOne level for the whole product, set by what the model can do.
Per action, never per product, and it follows what a mistake costs and whether you can undo it. Set it per product and you force everything to the strictness of the riskiest action, or, worse, to the looseness of the safest.
The levelAt a fictional airline, for example
- 1Acts aloneShows a passenger the rebooking options.
- 2Acts, and is monitoredRebooks the same day, on the airline's own flights.
- 3Acts inside a veto windowRebooks onto a partner airline, held before it commits.
Reversibility is the hinge. Above this line a mistake can be undone. Below it, it cannot.
- 4A named approver, every timeRefunds a fare above $400.
- 5Not delegatedChanges a passenger's identity details.
Then ask: show me the cap. If somebody opens a prompt file rather than code, you have found a gap.
How it works
Five rungs: acts alone, acts monitored, acts inside a veto window, named approver every time, not delegated at all. Reversibility is the hinge. Levels rise on evidence, one step at a time, and an incident drops the level of the action involved automatically.
3
In P2, before traffic widensP2
What you will accept as evidence
AskWhat is the score on each kind of case (each slice), with its lower bound?
A healthy answerA score per slice against its own bar, and a shadow run beside the people doing the work.
A bad answerOne accuracy number from a demo, with no sample size.
This is the decision that most often goes by default. If you accept a demo, you will be shown demos. If you accept a single accuracy figure, the slice carrying the risk will hide inside the average.
Read it this way: the bar is not a target somebody chose. It falls out of what a mistake costs. Push the third slider. That is a person checking the work before it takes effect, and it is why a gate is a commercial instrument rather than a brake.
How it works
Accept a score per slice against a derived bar, reported with its lower bound, plus a shadow-run comparison against the humans doing the work today. Reject any single headline number, and reject a score quoted without its sample size.
4
In P3, at the end of cycle oneP3
What you will fund past cycle one
AskWhat are the two numbers: the time saved and the money spent?
A healthy answerBoth, from the team, every cycle, with review hours and re-runs beside them.
A bad answerTime saved every cycle, and the spend arrives later, from finance.
A first cycle that saves time and costs more is normal. Funding it past that point should depend on a trajectory, not a promise: the review load falling, and the re-run count falling with it.
The term to watch is review. Drag it and you will see why a pilot that worked can stop working at scale. Saving and token cost both scale with volume. The review load only falls if somebody is deliberately making it fall.
The report you should receive
| Measure | Baseline | Now | Change |
|---|---|---|---|
| Person-days per story | 8.0 | 4.6 | −43% |
| Token spend per story | none | $310 | |
| Review hours added per story | 1.2 | 2.0 | +0.8 |
| Re-runs per story | none | 1.4 |
Three rules make that table trustworthy. The baseline is taken before the pilot, which costs an afternoon and is unrecoverable afterwards. The review row stays visible, or cycle two reads as a regression when it is the recovery. And the re-run row stays visible, because it is where leaks appear first.
The failure mode to name out loud. Every cycle shows time saved and none shows spend. Then finance computes the token bill on its own, and arrives at a review with a number nobody in the programme has seen. The credibility of the first number dies with the second. This is usually done by people trying to protect the programme.
How it works
The value line nets the token cost and the review load off the gross saving. Review is high in cycle one because the artefacts are rough; it falls as specs, bars and context files sharpen. If it does not fall by cycle three, the artefacts are the problem, not the model.
How you will know it is working
Four questions, asked consistently, and most of the failure modes in this manual cannot survive in your organisation. They take ten minutes a cycle.
| Ask | Of what | A good answer looks like |
|---|---|---|
| Which of these are rules? | The roadmap, not one feature | Two or three of the top five come back as rules, on record |
| What may it do without a person, and who decided? | Per action, with a reversibility column | Someone opens a tool signature when you ask to see the cap |
| What are the two numbers? | Every cycle, together | Person-days saved and money spent, with review hours and re-runs beside them |
| What level are we, and what is the next control? | Not how many tools we adopted | A number out of six, and the name of the first missing one |
Run the six-control check in ten minutes
Tool adoption is the metric that rewards the least mature behaviour available. This is the replacement: six controls that a team either has or does not, each verifiable by asking to be shown it.
Tick only what you could be shown in ten minutes.
Next control to build:
How it works
The level is the count. It is deliberately unweighted, so a team can read as level four with the two hardest controls missing: read the list, not the number. The next control to build is always the first unticked one.
Seven things to escalate on
None of these is a failure. Each is a signal that a decision is being made by default, somewhere below the level that should be making it.
| Signal | Why it matters | The question |
|---|---|---|
| A single accuracy number in a board pack | The slice carrying the risk is small, and small slices vanish into averages | Ask for the score per slice, with its sample size |
| A cap that lives in a prompt | It is a request, and a model can be talked past a request | Ask to be shown the cap. Prose or code decides it |
| A launch date agreed before a shadow run | The date will win the argument against the evidence, every time | Make the window a condition, not a milestone |
| Tool adoption reported as maturity | It rewards the least mature behaviour available | Replace it with the six controls |
| A postmortem that produced a name | The same class of incident will return, worded differently | Ask which enforced control would have made it impossible |
| A cost number that arrived from finance | The team either did not know or did not say. Both are worse than the number | Two numbers, from the team, from cycle one |
| Boards that stopped moving while submissions continue | Something silently stopped reporting, which is how drift hides | Ask when the last row was written |
Roll it out over ninety days
This is the sequence that works, and each stage has one trap that reliably catches capable teams. It is deliberately unglamorous in the middle.
Choose one feature, and choose it for provability rather than for value. The instinct is to start where the prize is largest. That is usually the hardest slice: the one that cannot clear its bar or be proven inside a quarter.
- Run the three AI-fit questions across the top ten candidates. Publish the ones that came back as rules: that list is the most credible thing you will circulate all year
- Pick a feature with high volume, low damage per mistake, and an existing human process to compare against
- Take the baseline now. Person-days per story, today, before anything changes. An afternoon, and it cannot be recovered later
The trap: starting with the flagship. It has the highest bar, the least tolerance for a first attempt, and the most spectators.
This fortnight produces documents, and it is the fortnight that decides the outcome. Teams skip it because it feels like overhead beside a working demo.
- The eight-field spec. Five of the eight will be undecided, and those five are the value of the exercise
- The acceptance bar per slice, derived from damage and saving
- The authority budget: what the agent may do alone, per action
- A context file in the repository, so every session starts informed
The trap: a demo exists by now and it is persuasive. A demo is the easy 20%. What it cannot tell you is how often it is wrong on the cases you did not choose.
A shippable slice a day, each one proven before the next. The point is not speed; it is that a wrong turn costs one day instead of a fortnight.
- Day one is a walking skeleton with no model in it, to prove the pieces connect
- Caps move out of prompts and into tool signatures, with two tests each
- The golden set reaches fifty real cases, tagged by slice, running in CI
- Review routes by risk band, from a path rule rather than from an argument
What you should see: something merged most days. The trap: the demo is still the only evidence at day 45, which means the slices are not slices.
Run it next to the people doing the work, deciding but never acting. You cannot reason your way to knowing whether it agrees with them.
- Shadow for a fixed window agreed in advance, compared per slice and read daily
- Money actions stay gated regardless of what the shadow shows
- Rehearse the rollback before the cut-over, not during
- Cut over at five percent and widen on live evidence rather than on a date
The trap: a launch date that arrives before the window ends. If it does not match, you learned that for free, which is the whole argument for the window.
Two numbers, both of them, from the first cycle. Then the loops that most organisations never close.
- Cost is a design question, not a finance escalation: a surprise bill closes back into the design, and the fix order is arithmetic
- An incident produces a control, a record and a brief, never a name
- Drift is watched weekly like any business metric, and an alert re-opens the release gate automatically
- Re-run the maturity check each quarter and build the first missing control
The trap: reporting the saving and not the spend. The signal that it took: the second feature needs less of your attention than the first, because the artefacts now exist to copy.
What you will hear along the way, and what answers it: the resistance you will actually meet.
What to do in your first thirty days
Six actions, in order, none of which needs a budget approval. The list prints on one page.
- Ask the four questions at the next review.Which of these are rules · what may it do without a person, and who decided · what are the two numbers · what level are we and what is the next control. Then say nothing for ten seconds.
- Ask to be shown one cap.Pick any limit the team says is enforced. If somebody opens a prompt file rather than a code file, you have found the gap that produces incidents.
- Take a baseline on whatever starts next.Person-days per story, today. An afternoon, and it is unrecoverable once the pilot begins.
- Run the six-control check yourselfwith the team in the room, ticking only what can be shown in ten minutes. The number matters less than the argument it starts.
- Name who owns governance.It spans the whole lifecycle and no delivery role owns it. If the answer is "we all do", nobody does.
- Fund the gateway.A fortnight of platform work that turns every future cost conversation from a mystery into a diagnosis.
What none of this asks for. No reorganisation, no new function, no platform migration, no vendor commitment. The whole protocol is a set of artefacts and four questions, and the artefacts are each about an afternoon's work.
Where to send people
Each role has its own steps: eight for a delivery role, twelve for the forward-deployed engineer. Send each person to the steps for the work they own.
| They own | Send them to |
|---|---|
| What gets built and whether it shipped safely | The product manager's eight steps |
| The shape of the system and what may be probabilistic | The architect's eight steps |
| Building it, and the boundary in code | The engineering lead's eight steps |
| Whether it actually works, with a number | The QA lead's eight steps |
| Making it repeatable, observable and reversible | DevOps and platform's eight steps |
| The outcome inside a customer's organisation, end to end | The forward-deployed engineer's twelve steps, in three stages: Frame, Deliver and Evolve |
| Wanting the artefacts, not the argument | 52 templates · 146 prompts |
| Wanting to see it happen to somebody else first | The workbench's thirteen episodes: the worked case, day by day |
| Chairing a gate, and wanting to know what may halt it | The gates, in the workbench · what a complete evidence pack holds |
| Wanting the maturity conversation with a number | The maturity self-check · is this work for a model at all? |
Read the full argument, one fold at a time
The reasoning behind the four decisions, in nine parts. Each stays closed until you open it.
Why this matters to you now
The economics, the risk and the organisation all moved
If you lead an organisation, large language models have already changed the economics of building software. Drafting is nearly free, judgement is the bottleneck, and part of every product you ship is now right only a share of the time. This page shows what that does to your teams, your costs and your risks, and how to run product development as one operating model across the whole organisation: four phases, P0 to P3, the same for every team.
The economics moved
A model drafts a spec, a test suite or a customer reply in seconds, so the cost of producing work is close to zero. The cost has moved to judgement: deciding what to build, checking what was drafted, and proving it works. Organisations that keep paying for production and skimp on judgement get more output and worse outcomes.
The risk moved
Part of your product is now probabilistic: right most of the time, wrong fluently, with no error message. That is survivable when a mistake can be undone and expensive when it cannot. The control is not more accuracy; it is a person, or a cap in code, on every action that is a one-way door.
The organisation has to move with it
Five teams each adopting a tool is not a strategy. One operating model, P0 to P3, gives every team the same phases, the same gates and the same evidence, so a product manager's spec, an engineer's slice and QA's proof fit together. It also creates a role of its own, governance, and that one is yours.
Five things that change, in one sentence each
The claims under the four decisions, with the reason for each
Most of your backlog is not AI work.
Three questions settle it: is there a genuine judgement call, is the volume high enough, and is a wrong answer recoverable. Expect two or three of your top five to come back as rules that code does better, cheaper and provably.
Why: A rule with published criteria is a CASE statement. Putting a model on it adds a token bill, an evaluation harness, gates and a probability of being wrong, and buys nothing. The AI-fit record is what lets a team decline an agent-first directive with evidence rather than as an opinion.
“It works” stops being a yes or a no.
It becomes a number per kind of case, derived from what a mistake costs. You will be asked to accept 80% on one slice and require a person on another, and both can be correct.
Why: The bar is damage ÷ (damage + saving), per slice. A human hold on the risky step lowers the damage and therefore lowers the bar, which is how a feature ships safely at 71% instead of waiting for a 98% nobody will reach.
Autonomy is decided per action, and it follows reversibility.
Not per product, and never from what the model is capable of. Showing options and moving money are different decisions and belong at different levels.
Why: A cap written in a prompt is a request a model can be talked past. A cap written into the tool's signature raises and cannot be argued with. The difference is invisible on a slide and total in production.
A first cycle can save real time and cost more.
That is survivable if it reaches you from the team. It is fatal if it reaches you from finance. Insist on two numbers from cycle one.
Why: Time saved and money spent, with two rows that keep them honest: review hours added, which is high early and falls, and re-runs, which is the leak signal. Cost turns positive from cycle two as the artefacts sharpen.
Maturity is control, not tool count.
A team with nine AI tools and no gates is less mature, ships less safely and costs more than a team with one tool and tight control.
Why: Six controls, each present or absent: a context file, a spec with a bar and an owner, a harness gating the merge per slice, caps in tool signatures, a redacting trace, and production evidence by segment with drift watched.
Your teams, transformed
Eight functions: what changes, what they use, the gain to expect
The same four phases run through every function. What each team does in them, the level of tooling it needs, and the gain you should expect to see.
| Team | What changes in how they work | What they use | The gain |
|---|---|---|---|
| Product management | Frames the work as measured pain and rules on AI fit before anyone builds; writes specs a machine can build from | Low effort: a chat assistant with your documents | Fewer wrong bets; a backlog where most items come back as rules, cheaper than agents |
| Engineering | Builds from story files with coding agents, a shippable slice a day; caps live in code, not prompts | High effort: coding agents and agent frameworks, behind a gateway | Cycle time in days, not fortnights; a wrong turn costs a day |
| Quality | Owns the bar per slice, the golden set and the harness that gates every merge | Mid effort: evaluation tooling wired into CI | Quality you can quote with a number and a lower bound; fewer incidents that reach a customer |
| Platform and operations | Runs one gateway, a per-call log, a trace that redacts, and a rehearsed rollback | High effort: the platform under every agent | A bill attributable per feature; an incident contained in minutes |
| Customer operations and support | Lets an assistant draft and propose, and keeps a person on every action that moves money or cannot be undone | Mid effort: an agent platform with holds | Handling time falls on the high-volume cases; the risky ones stay human |
| Finance | Receives two numbers every cycle, the saving and the spend, and can read a bill as four habits multiplying | Low effort: the reports, not the tools | No surprise invoice; cost that turns positive from cycle two |
| Legal, risk and compliance | Signs the authority budget: what the agent may do alone, per action, and the trace that proves it | Low effort: the records and the trace | Auditability by design; a regulator's question answered from the log |
| Sales, marketing and every other function | Drafts, summarises and restructures with a chat assistant, under one rule about what may enter it | Low effort: a chat surface | Throughput on written work, with no access to systems and no new risk |
The effort levels, low, mid and high, are explained in LLMs across the board below, and each role's steps are on its own page.
Where the money is: efficiency, cost, or both
Five levers, and what to ask for on each
Five levers. Start with efficiency on high-volume, low-damage work, where a first cycle pays for itself in time; take cost through the gateway, because without a per-call log a bill cannot be diagnosed.
| Lever | The mechanism | Gain | What to ask for |
|---|---|---|---|
| Drafting time | Models draft; people check. Review hours are high in cycle one and fall as specs, bars and context files sharpen. | Efficiency | Person-days per story, before and after, with the review row visible |
| Cycle time | Work ships in slices of a day, each proven before the next, so a wrong turn costs a day rather than a fortnight. | Efficiency | Something merged most days by day 45 |
| Cost of quality | A bar per slice, derived from what a mistake costs, and a lower bound that must clear it before traffic widens. | Both | Incidents that reached a customer, per quarter |
| Run cost | Context discipline, routing to cheaper models, a cache that hits, and a retry breaker: four habits that otherwise multiply into a bill 4.4 times its estimate. | Cost | Token spend per story, decomposed into its four factors |
| Cost of risk | Every action that cannot be undone has a person or a cap in code on it, so the expensive mistake is impossible rather than unlikely. | Cost | The authority record, and the cap shown in code |
A first cycle that saves time and costs more is normal and survivable, if the two numbers reach you from the team. Fund the second cycle on a trajectory: review hours falling, re-runs falling.
The value line nets token cost and review load off the gross saving. Review falls as artefacts sharpen; if it has not fallen by cycle three the artefacts are the problem, not the model. The calculator under decision four lets you drag each term.
What changes in your organisation, and what does not
Nine activities, each marked changed or unchanged, with why
Less than the market implies, and in sharper places. The honest list, so nobody has to rebuild a working discipline to adopt this.
| Activity | Verdict | Why |
|---|---|---|
| Deciding what is worth building | Unchanged | The judgement is yours and always was |
| Writing down what it must do | Changed | A machine now reads it and cannot ask what you meant, so ambiguity becomes defects |
| Knowing when it is finished | Changed | A measured share per slice, with a confidence bound, replaces a yes or a no |
| Estimating and planning | Mostly unchanged | The unit shrinks from a two-week sprint to a day, because building is faster than reviewing |
| Reviewing work before it ships | Changed | Depth follows the risk of the action, not the size of the change. More is produced; the same people read it |
| Releasing | Changed | Run beside the humans first, then five percent, then widen on evidence rather than on a date |
| Security | Mostly unchanged | Least privilege still applies. One genuinely new threat: everything the agent reads can act as an instruction |
| Knowing it still works next quarter | Changed | Behaviour drifts with no deploy and no error, so it is watched like a business metric |
| Accountability | Unchanged | A gate is a person's name against a decision. No model holds one |
The pattern. Everything that changed, changed because part of the product is now probabilistic. Everything that did not, did not. If a proposal in front of you changes something in the unchanged column, ask what it is actually solving.
Who does what, and the boundary that moves
Five delivery roles, the shift in each, and the role that is yours
Five delivery roles. None of them is new, and none of them disappears. What moves is the boundary between them, and the two places it moves are worth knowing: the product manager stops approving things they cannot evaluate, and QA gains a veto that is arithmetic rather than opinion.
The forward-deployed engineer carries all five to a customer's site; that role has its own guide.
Product manager
Decides what is worth doing and what counts as good enough
The shift: Stops approving pull requests. Starts deriving a bar from what a mistake costs.
Owns: Owns the intent and release gates, autonomy per action, and the acceptance bar per slice
Solution architect
Decides the shape, and which steps may be probabilistic at all
The shift: Stops specifying model settings. Starts specifying behaviours and where the caps live.
Owns: Owns the exact/best-guess map, the authority budget, and the decision records
Engineering lead
Builds it, and makes the boundary real in code
The shift: Stops treating a prompt rule as a control. Starts shipping a slice a day.
Owns: Owns the context file, the harness in CI, and caps inside tool signatures
QA lead
Says whether it actually works, with a number
The shift: Stops signing off on a demo. Starts reporting a lower bound, not a score.
Owns: Owns the behaviour and expansion gates, the golden set, and the injection suite
DevOps and platform
Makes it repeatable, observable and reversible
The shift: Stops treating a prompt as config. Starts treating it as a deployable artefact.
Owns: Owns the gateway, the per-call log, the trace and the rollback
Governance is yours. It spans the whole lifecycle and no delivery role owns it. If nobody is asking the four questions below every cycle, nobody is.
What the frameworks mean for you
AI-DLC, AIDD, BMAD and spec-driven development, in leadership terms
Four named methods are in the market, and each is right about part of the lifecycle. You do not adopt four. The SkyWays PDLC takes the part each does best, keeps them in one order with one owner per phase, and adds the devices none of them carries: one hard gate, a bar per slice, an authority budget and the two-number report.
AI-DLC, from AWS
Run only the lifecycle stages a change actually needs. The judgement of depth is made per change, by an architect, which is what stops a one-line fix from costing a programme.
AIDD
The daily craft of building with coding agents: context files the agent reads, story files it builds from, review by risk, and the cost habits that keep the bill flat.
The BMAD Method
Named commands, called skills, in your coding tool: five agents and one Build loop that plans, builds and reviews a change, with documents added as the work grows. Right for complex, audited work; a small change goes straight to Build.
Spec-driven development
The specification is the asset you maintain; code is generated from it and regenerated on change. It is the backbone every other method plugs into.
How the four merge into P0 to P3, with the picture.
LLMs across the board, at three levels of effort
Low, mid and high: who uses what, and the control on each
Most of the value in an organisation comes from the low and mid levels, and most of the risk lives at the high one. The products change every quarter; the three levels and the control on each do not.
| Level | What | Who, for what | The control on it | The rule |
|---|---|---|---|---|
| Low effort | Chat assistants: Claude, ChatGPT, Gemini, and the same models inside your office suite | Everyone, any function: drafting, summarising, restructuring, arguing with a plan | No access to systems; the output is a draft by a capable stranger | Nothing enters it that you would not email externally |
| Mid effort | Agent platforms with your documents and workflows: Copilot Studio, Bedrock Agents, Dify, n8n and their peers | Product, analysis, support, operations: proposals grounded in your data | Read-only by default; it proposes and a person decides and signs | Named documents only, never the whole drive |
| High effort | Agents you build: LangGraph, LangChain, Strands, CrewAI, behind your own gateway | Engineering and platform: the agent inside your product | Caps and confirmations in tool signatures; reads open, writes gated; every consequential action leaves a trace | Review by risk band; money paths get two readers, always |
The decision to take centrally is that every model call in production passes through one layer you own, so routing, budgets and the per-call log exist in one place. Teams then choose their own editor.
A coding assistant reads a committed context file at session start: CLAUDE.md for Claude Code, AGENTS.md for Codex, .github/copilot-instructions.md for Copilot. The file drives autonomous actions, which is why it is committed and reviewed rather than personal.
One thing worth funding centrally on day one: the model gateway. It is unglamorous, it takes a fortnight, and without it a surprise invoice is a mystery rather than a diagnosis.
Try it: which level fits which task, an exercise per department in the workbench.
The resistance you will actually meet
Six things you will hear, what is underneath, and what answers each
| What you will hear | What is underneath | What answers it |
|---|---|---|
| "This slows us down" | Usually true for the first feature, and untrue by the third | Show the artefacts being reused. The second spec takes an hour |
| "The model is good enough already" | Judged on curated examples | Ask for the score on the slice nobody picked, with its sample size |
| "We already have gates" | Approvals, not gates, clicks without evidence | Ask what evidence was in front of the last approver, and what would have made them say no |
| "Engineering says the cap is handled" | Handled in a prompt | Ask to be shown it. Prose or code decides the answer |
| "We cannot measure a baseline, we have started" | True, and recoverable on the next feature | Say so in the report rather than being caught. Then take one next time |
| "Our people will resist automation" | Often the opposite: they resist being measured by it | Put the frontline in discovery first, and credit their requirements by name |
The change-management move that does most work is unglamorous: credit every requirement to the person who raised it, in writing, before consolidating any of them. A voice that felt dropped in week one comes back in week five as a constraint, and it arrives with the authority of someone who was ignored.