10/21/2024
Exploring the delicate balance between customer requests and product integrity through the lens of "first, do no harm"
Written by: Jonathan Haas
In medical school, students take the Hippocratic Oath, pledging to “first, do no harm.” As product managers, we’d do well to adopt a similar mindset. While we’re not dealing with life-and-death situations, our decisions can significantly impact user experiences, business outcomes, and team morale. The pressure to deliver features requested by vocal customers is constant, but sometimes the bravest decision is to say “no.”
Every product manager knows the scenario: A major customer threatens to leave unless you build their requested feature. The sales team forwards urgent requests from prospects who’ll “definitely sign” if you just add this one thing. The feature request backlog grows ever longer, each item seemingly critical to someone’s success.
The temptation to acquiesce is strong. After all, isn’t customer centricity a core value? Aren’t we supposed to be solving user problems? Yes, but with an important caveat: we must solve them effectively.
Building the wrong feature isn’t just a waste of resources—it’s actively harmful in several ways:
Technical Debt: Each feature adds complexity to your codebase. Wrong features are particularly toxic because they deliver negative value while still requiring maintenance.
Cognitive Load: Users must navigate around features they don’t need, making your product harder to understand and use effectively.
Support Burden: Even unused features generate support tickets and require documentation, training, and maintenance.
Opportunity Cost: Every hour spent building the wrong feature is an hour not spent building the right one.
So how do we balance responsiveness to customer requests with product integrity? Here’s my framework:
When a customer requests a feature, treat it as the starting point for investigation, not a solution specification. Often, the requested feature is just one possible solution to an underlying problem. By understanding the core need, we might find a better way to solve it—or realize it’s not actually the problem we should be solving.
Every feature should advance your product’s strategic goals. A feature that perfectly solves one customer’s problem but takes you off your strategic path is still the wrong feature. Ask yourself:
Features don’t exist in isolation. Every addition affects the whole product ecosystem:
Saying no is essential, but how you say it matters immensely. When declining a feature request:
The art of product management lies not in building everything customers ask for, but in building the right things that truly solve their problems. Sometimes this means saying no to good ideas because they’re not the best ideas for your product right now.
A useful metaphor is thinking of your product as a garden. Adding features is like planting new species—each needs space, nutrients, and ongoing care. Plant too many, and none will thrive. The skilled gardener knows that pruning is as important as planting.
“First, do no harm” doesn’t mean never taking risks or never building new features. It means being thoughtful about what we add to our products and being willing to disappoint in the short term to build something better in the long term.
The next time you face pressure to build a requested feature, remember: The harm of building the wrong thing often outweighs the harm of building nothing at all. Our job as product managers is not just to build things, but to build the right things.
And sometimes, that means having the courage to say no.