HaaS on SaaS

Jonathan Haas

I'm a product manager at Vanta with a passion for security and privacy. I write about SaaS, startups, and security.

First, Do No Harm: When Not to Ship Features

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

A book open on a desk

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.”

The Siren Song of Feature Requests

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.

The Hidden Costs of Wrong Features

Building the wrong feature isn’t just a waste of resources—it’s actively harmful in several ways:

  1. Technical Debt: Each feature adds complexity to your codebase. Wrong features are particularly toxic because they deliver negative value while still requiring maintenance.

  2. Cognitive Load: Users must navigate around features they don’t need, making your product harder to understand and use effectively.

  3. Support Burden: Even unused features generate support tickets and require documentation, training, and maintenance.

  4. Opportunity Cost: Every hour spent building the wrong feature is an hour not spent building the right one.

Making the Hard Choice

So how do we balance responsiveness to customer requests with product integrity? Here’s my framework:

1. Understand the Root Problem

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.

2. Evaluate Strategic Fit

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:

  • Does this align with our product vision?
  • Will this solution scale across our customer base?
  • Are we the right team to solve this problem?

3. Consider the Full System Impact

Features don’t exist in isolation. Every addition affects the whole product ecosystem:

  • How will this impact the user experience for other customers?
  • What maintenance burden will this create?
  • How might this limit our future options?

4. Learn to Say No (The Right Way)

Saying no is essential, but how you say it matters immensely. When declining a feature request:

  • Acknowledge the underlying need
  • Explain your reasoning transparently
  • Offer alternative solutions where possible
  • Keep the door open for future discussion

Finding the Balance

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.

Conclusion

“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.