"It's just a small feature" is never just a small feature. 🎣
The Trap: Stakeholders see a simple UI change. You see: • Database schema updates • API modifications • Security considerations • Testing requirements • Documentation updates • Performance implications
The Hidden Iceberg: 🔸 10% visible: The UI change 🔸 90% hidden: All the infrastructure work
Your Response Toolkit:
1. The "Yes, And" Approach "Yes, we can add that feature, and here's what it involves..."
Then list the full scope. Most requests die naturally when people see the real cost.
2. The Trade-Off Question "Which existing planned feature should we delay to accommodate this?"
Forces prioritization discussions instead of scope creep.
3. The Technical Debt Warning "We can rush this, but it will cost us 3x more to change later. Do you want the quick version or the maintainable version?"
4. The Data Request "What problem are we solving? What metrics will tell us if this feature is successful?"
Often reveals the request isn't actually needed.
5. The Prototype Offer "Let me build a quick prototype so we can validate the concept before full implementation."
Sample Response Template: "I understand this looks simple, but here's the full scope: • Backend changes: 2 days • Frontend work: 1 day • Testing: 1 day • Security review: 0.5 days • Documentation: 0.5 days • Total: 5 days
This would delay [other priority] by a week. Should we proceed or schedule for next sprint?"
Red Flags to Watch: • "Just" or "simply" in feature requests • End-of-sprint feature bombs • Requests that bypass the normal process • Features without clear success metrics
The Nuclear Option: "I'll implement this, but first let me document why this is a bad idea so we can learn from it."
(Use sparingly, but effective for repeat offenders)
Remember: Your job isn't just to build features—it's to build the right features at the right time.
How do you handle last-minute feature requests? 🤷♂️