Saying no in writing
Lesson 20 of 24, level 01Index
Engineering says two months. You have three weeks and you do not know enough to argue.
Decide the appetite, then design to fit
Design inside the appetite
- Appetite: Time worth spending
- Must work: The one core job
- Not now: Explicit scope cuts
The usual process asks how long something takes and then negotiates. The better one decides how much the problem is worth, states that as the appetite, and designs to fit inside it.
The most valuable part of any scope document is the section that says what it explicitly does not include. That is what stops the thing growing back.
Scope is the set of behaviors you commit to deliver, including failure handling. Cutting scope should preserve the smallest useful end-to-end outcome rather than leave half of every feature unfinished.
Use your chosen course project throughout. The additional examples below are fictional practice cases; transfer the method to your own evidence.
Find the complete slice
Describe one user completing one valuable job. Keep the path from entry to confirmed outcome intact, including the most important recovery states. A narrow working slice teaches you more than several polished screens with no completion path. Write explicit exclusions so the team can recognise new work when it appears.
Trade breadth before reliability
Consider fewer account types, one supported import format, or manual operations behind the scenes. Do not automatically remove error messages, accessibility, or safe retry behavior to meet a date. Those may be necessary for the selected slice to work at all. Discuss the real delivery cost with the people implementing it.
Give deferred work a reason
Record what you cut, why the current slice still creates value, and what evidence would justify revisiting it. “Later” without a condition becomes a second backlog no one understands. If a cut undermines the target outcome, reduce the ambition or change the deadline rather than hiding the gap.
Cut breadth, keep the job whole
- Keep: Complete useful outcome
- Defer: Additional breadth
- Protect: Recovery and clarity
Doing it with AI, and where it breaks
Simulate the engineering lead. Argue until you find the cut that gets it inside your appetite without making it pointless.
The simulated engineer will agree too fast. Instruct it to hold its estimate unless you remove actual scope.
Your AI workbench
Start with your own notes or clearly labelled practice data. Remove private details before sharing. Replace the placeholders, run the prompt in your chosen AI tool, and keep the output beside its source.
Given this outcome, deadline, and feature list [paste], propose a complete thin slice. Separate essential user behavior, safe failure handling, optional breadth, and deferred work. Explain what value survives each cut. Do not assume engineering estimates or remove accessibility and recovery without discussion.
Before you use the output
- One valuable job remains complete
- Exclusions are explicit
- Deferred items have a revisit condition
Stuck? Try this next
Ask AI to walk through the proposed slice as a user who hits an error halfway through. If the user cannot recover or understand what happened, the cut needs another pass.
Keep a brief AI log: input used, useful output, what you checked, and what you rejected. The decision remains yours.
Build it
A scoped version one with three explicit cuts and the reasoning for each.
Checkpoint
If you did the build, these take two minutes. If you cannot answer one of them, that is the part to go back to.
Moving on marks this lesson complete. Finish the build first, it is the part that counts.