Protecting the product.
WHY IT MATTERS
Every accepted feature costs building, maintenance and complexity forever.
WHAT COMPLEXITY COSTS
Slower development More defects Harder onboarding for new users Higher support burden
WHAT TO ESTABLISH ABOUT ANY REQUEST
The underlying problem How many people share it What it is worth
WHAT TO DO WHEN THE ANSWER IS NO
Say so, clearly, with the reason.
WHY CLEARLY
Vague deferral produces repeated asking.
WHAT VAGUE SOUNDS LIKE
It is on the roadmap.
WHAT CLEAR SOUNDS LIKE
We are not planning to build this, because it serves few customers and adds substantial complexity.
WHAT TO OFFER INSTEAD
A different way to achieve the outcome, if one exists.
WHAT TO DO ABOUT REQUESTS FROM LARGE CUSTOMERS
Assess them the same way, then decide commercially.
WHY
Building for one account produces a product that serves nobody well.
WHAT TO DO IF YOU BUILD IT ANYWAY
Recognise it as a commercial decision, and account for the ongoing cost.
WHAT TO RECORD
Requests declined, and why.
WHY
The same request returns, and consistency matters.
WHAT TO WATCH FOR
A declined request recurring from many customers.
WHAT THAT INDICATES
Your assessment may have been wrong.
WHAT TO DO ABOUT EXISTING FEATURES NOBODY USES
Remove them.
WHAT THAT REQUIRES
Notice, and a route for the few who do.
