When to Say No

The hidden cost of yes

Every feature you build:

• Must be maintained forever
• Adds code to understand and debug
• Creates UI that users navigate around
• Takes time from other features
• Makes the product harder to learn
• Increases testing surface
• Might need documentation, support, onboarding

Features are easy to add and hard to remove. Once users depend on something, removing it is painful.

When to say no

It doesn’t align with your core purpose

You’re building a task manager. Someone requests:

• Calendar integration ✓ (related to tasks)
• Team chat ✗ (Slack exists)
• Expense tracking ✗ (different product)

Ask: Does this make our core thing better, or is it scope creep?

It serves edge cases, not common cases

“We need to support 17 different date formats because one customer uses them.”

Ask: How many users want this? Is this a general need or one person’s workflow?

Build for the 80%, not the 20%. The 20% can often adapt or use workarounds.

The complexity cost exceeds the value

Adding multi-currency support sounds simple. Then you need:

• Currency selection UI
• Exchange rate updates
• Rounding rules per currency
• Display formatting per locale
• Historical rates for reports
• Testing across all currencies

Ask: Is the value to users worth the ongoing complexity?

It conflicts with existing decisions

You built a simple, linear workflow. Someone wants branching logic.

Ask: Does this change fundamental assumptions? Can we support both well, or will one suffer?

You’re the only one who wants it

You think it’d be cool. No users have asked. No data suggests it matters.

Ask: Am I building for users or for myself?

It’s solving the symptom, not the problem

“Users want a ‘select all’ button for bulk operations.”

Maybe. Or maybe your individual operations are too tedious, and batch operations are a bandaid.

Ask: What’s the actual problem? Is there a better solution?

How to say no

“Not now”

“Great idea. We’re focused on [current priority] right now. Let’s revisit after that.”

Acknowledges value, defers without closing the door.

“Here’s what we’re doing instead”

“Instead of building a full chat feature, we’re adding comment threads on tasks. That solves the collaboration need without building Slack.”

Shows you heard the underlying need.

“Help me understand”

“Interesting request. Can you tell me more about the problem you’re solving? How are you handling this today?”

Often the first request isn’t the real need. Dig deeper.

“We intentionally don’t do that”

“We’re a simple task manager. We don’t do project management features—there are great tools for that. We focus on individual productivity.”

States your positioning clearly. Some users aren’t your users.

“That’s a different product”

“Building video editing into our photo app would be a major shift. That’s really a different product. We’re staying focused on photos.”

Polite but firm boundary.

Saying no to yourself

The hardest nos are the ones you want to say yes to.

The shiny new technology

“We could rewrite this in Rust for better performance!”

Ask: Is performance actually a problem? Is the rewrite worth months of work?

The clever solution

“I could build a custom state management system that perfectly fits our needs!”

Ask: Would a standard solution work? Is cleverness worth complexity?

The premature optimization

“We should design this to handle 10 million users from day one!”

Ask: How many users do we have now? Will we ever have 10 million? What’s the cost of not optimizing now vs later?

The completionist urge

“I just need to add one more feature before launch…”

Ask: Can users get value from what exists now? Is this essential or just nice-to-have?

Removing features

Sometimes the right answer is to remove what you already built.

Signs a feature should be removed

• Almost no one uses it
• It complicates the product for everyone
• Supporting it takes disproportionate time
• It conflicts with the direction you’re heading
• It was built for a use case that no longer exists

How to remove features

1. Check usage data: How many actually use it?
2. Communicate early: “We’re considering removing X”
3. Provide alternatives: “You can accomplish the same thing by…”
4. Give time: Deprecation warnings, migration period
5. Remove cleanly: Don’t leave dead code paths

The courage to simplify

Removing features feels like going backwards. It’s actually moving forward.

A product that does 5 things well beats one that does 15 things poorly.

The opportunity cost lens

Every yes is a no to something else.

If you build this feature:

• What won’t you build?
• What won’t you improve?
• What technical debt won’t you pay down?
• What bugs won’t you fix?

Make the tradeoff explicit.

The “what would we stop doing?” question

Before adding anything, ask: “If we do this, what will we stop doing or delay?”

If you can’t answer, you’re in denial about capacity.

Strategic nos

Positioning

You can’t be everything to everyone. Saying no defines what you are.

• “We’re not for enterprises” → You can stay simple
• “We don’t do integrations” → Less maintenance burden
• “We only support English” → Faster development

Clear positioning loses some customers but wins others who value your focus.

Focus

Startups die from doing too much more often than too little.

One product that works beats three half-built products.

Sustainability

Can you maintain this forever? If not, don’t build it.

That cool feature you can’t support becomes tech debt and user frustration.

The no template

For feature requests you’re declining:

Thanks for the suggestion! I understand you want [restate their need].

We're not planning to build [specific feature] because [honest reason:
- it doesn't fit our focus on X
- the complexity outweighs the benefit for most users
- there are existing tools that do this well].

What we're focusing on instead is [what you are doing].

[Optional: If lots of people ask for this, we'll reconsider / 
Here's a workaround / Here's an alternative tool]

Quick decision framework

When asked to build something:

1. Does it align with our purpose? No → Decline
2. Do many users need it? No → Probably decline
3. Is the value > complexity cost? No → Decline
4. Can we maintain it sustainably? No → Decline
5. What’s the opportunity cost? Too high → Decline

If you pass all five, consider building it.

Further reading

• Prioritization frameworks : How to choose what to build
• Technical decision making : Evaluating options
• The art of done : When to stop polishing and ship
• How to slice work effectively : Building less to learn faster