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.
Perfectionism is the slow sin. Sin #8 (new-feature-itis) and Sin #9 (polishing past the point of value) together produce projects that never ship — or ship 6 months late with features no one asked for. The cure is brutal scoping discipline: a small, named set of features in the v1 box, and an explicit cutoff for polishing. Cohen's insight: every additional feature past the core MVP costs disproportionately more time than it adds value.
The scope creep ratchet and the polishing curve.
Use these three in order. Each builds on the one before.
Explain in one paragraph the difference between Sins #8 and #9 — both are perfectionism but they're different failures.
Walk me through how scope creep (Sin #8) cascades into a 6-month project slip even when each individual addition seems small.
Given a team mid-project that's added 4 features past the v1 plan and is now 3 months late, how do you (as the PM) rescue the project?
SIN #8: NEW-FEATURE-ITIS
The pattern:
v1 plan: features A, B, C. Ship by date X.
Month 3: "We should add D — it's only a small change."
Month 5: "D is great. Now let's add E for parity with competitor."
Month 7: "While we're at it, F would be trivial..."
Month 9: Original date X has passed. Features D-F not done.
Why it happens:
- Adding feels productive (more is more, right?).
- Sales/marketing keep adding requests.
- Engineers want to build the cool thing they imagined.
- PM can't say no.
Cohen's cure:
- A locked v1 feature list with names attached.
- A change control board: any addition requires explicit acceptance of a slip.
- "We can do D in v2" should be the default answer.
SIN #9: NOT KNOWING WHEN TO QUIT POLISHING
The pattern:
Product 90% done at month 5.
Months 6, 7, 8 spent on:
- Cosmetic UI tweaks
- Edge cases that affect <1% of users
- Performance optimization no one asked for
- "Just one more iteration of the case design"
Why it happens:
- Fear of shipping (and being judged).
- Pride: "I want it to be perfect."
- Lack of pressure from a clear ship date.
Cohen's cure:
- 95% rule: ship at 95% quality, not 100%.
- Time-box polish: 2 weeks max after v1 feature-complete.
- User testing > polish: real users find bugs you'd never have polished anyway.
HARDWARE TRACK:
Cohen's example: connected device team adds 3 features in months 3-5
(scope creep), then spends months 6-8 polishing the enclosure shape.
Ships at month 9. v1 had launched, market reception was lukewarm,
competitor shipped at month 7 with worse hardware but identical UX.
The hardware penalty for polishing is large:
- Each enclosure revision: $10-30k tooling spend.
- Each PCB revision: 4-8 weeks + $1-3k.
- Polish in v1 → no money for v2 improvements.
SOFTWARE ANALOGUE:
Software has the same sins but lower revision cost. The pattern shifts to:
- Scope creep: backlog grows infinitely; sprint scope keeps swelling.
- Polish: "we'll redo the design system before launch" syndrome.
Software polish trap:
- 5 designers in Figma at month 6, no users in production yet.
- 3 refactor passes on the same code path before any user touches it.
- "Performance optimization" before there's any load.
Better:
- Ship at "good enough." Iterate on what real users complain about.
- Linear-rule: backlog is a graveyard; only what's in the current
cycle counts.
THIS MODULE'S FOCUS:
Two questions to ask yourself this week:
1. What was in the v1 list 90 days ago? What's in it now? (Sin #8)
2. If we shipped today at 95%, what would actually be missing? (Sin #9)
The answers usually reveal one of the two sins live.