Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Fuzziness is the slow killer. A team can survive an assumption being wrong (you'll find out and pivot). It cannot survive 'we never quite agreed what we were building.' Cohen's three sins of fuzziness — lack of requirements, lack of plan, no clear owner — together produce projects where everyone is busy and nothing converges. The cure is unsexy: write things down, name owners, draw a line on a calendar.
The three fuzziness sins and their cures.
Use these three in order. Each builds on the one before.
Explain in one paragraph what the three fuzziness sins are and how to diagnose each.
Walk me through how Sin #5 (no plan) leads to a 6-month slip by month 4 — what's the cascade?
Given a 30-person team mid-project with weak ownership (Sin #6 live), how do you introduce ownership without political friction?
SIN #4: LACK OF COMPREHENSIVE REQUIREMENTS
Diagnostic question:
Can you, right now, write down what the product DOES in one page?
If no: you have Sin #4.
What goes wrong:
- Engineer A thinks the wake button is short-press, engineer B thinks long-press.
- Marketing thinks battery life is 7 days, hardware thinks 24 hours.
- Each subsystem ships its own interpretation. Integration is hell.
Cure:
A MARKETING REQUIREMENTS DOCUMENT (MRD) — what the product must do, from
the user's perspective. Tested against. Specific. Trade-off-explicit.
SIN #5: LACK OF A GOOD PROJECT PLAN
Diagnostic question:
Can you name the date by which the product ships? With confidence ±2 weeks?
If no: you have Sin #5.
What goes wrong:
- Surprises in week 14 ("oh, the BLE chip is unobtainium")
- Vendor lead times you didn't know existed
- Certification cycles you didn't budget for
- Dependencies between subsystems missed
Cure:
Even a CRUDE plan beats no plan. A gantt or critical-path that lists:
- Major deliverables
- Owners
- Estimated time
- Dependencies between them
Updated weekly.
SIN #6: NOT ASSIGNING RESPONSIBILITY
Diagnostic question:
Who decides the antenna gain target? Who decides API auth model?
If you can't name a single person per decision: Sin #6.
What goes wrong:
- Decisions become committee meetings.
- Action items are owned "by the team" — i.e., no one.
- Tasks drift; no escalation path.
Cure:
A RACI matrix or equivalent. For each decision/deliverable, name:
- Responsible (does the work)
- Accountable (owns the outcome — ONE person)
- Consulted (input needed)
- Informed (told after)
HARDWARE TRACK:
Cohen's specific example: hardware project where the firmware engineer
assumed the EE owned the bootloader, the EE assumed the firmware engineer
owned it. Three weeks lost waiting for the other person to start.
Single owners. Always. Even if multiple people work on something.
SOFTWARE ANALOGUE:
Same three sins, different artifacts:
Sin #4 → No PRD (Product Requirements Document).
Sin #5 → No roadmap, no committed dates.
Sin #6 → No DRI (Directly Responsible Individual) per feature.
Software's particular pathology: agile-as-anti-planning, where "we're
adaptive" becomes "we have no commitments at all."
Even an adaptive team needs a 90-day horizon with named owners.
THIS MODULE'S FOCUS:
Pick one project you're on. Diagnose:
- Do you have one-page requirements? (no → Sin #4)
- Do you have a date and a critical path? (no → Sin #5)
- Can you name owners of each major decision? (no → Sin #6)
Each "no" is a leak. Plug the cheapest one first.