The art of saying no: How we shipped 40% faster
Last quarter, our product team made a radical decision: we would say "no" to 60% of feature requests. The result? We shipped faster, built better features, and our team satisfaction scores went up by 35%.
For years, we operated like most product teams, trying to say "yes" to everyone. Customers wanted features. Stakeholders had priorities. The sales team needed that one thing to close deals. We built a roadmap that looked like a wishlist, and our velocity suffered for it.
The problem wasn't our execution. It was our inability to focus. Context switching between too many initiatives meant nothing got the attention it deserved. Features shipped half-baked. Technical debt piled up. Our team was burned out from constantly shifting priorities.
The turning point
Everything changed when we ran the numbers. We analyzed our last six months of work and discovered something shocking: only 23% of the features we shipped were being actively used by more than 10% of our users. We were building a lot, but building the wrong things.
That's when we implemented what we call the "Sanity Filter": a simple framework for evaluating every feature request.
- Does this solve a problem for at least 30% of our users?
- Can we measure the impact within 30 days?
- Does it align with our core mission?
- Can we build it without compromising existing features?
If the answer to any of these questions was "no," the feature didn't make it to our roadmap. Simple as that.
What we learned
The first month was brutal. Saying "no" felt uncomfortable, especially to long-time customers. But we committed to transparency, explaining our reasoning and sharing our decision-making framework publicly.
Three months in, the results were undeniable:
More importantly, our team felt energized again. They had time to do things right. To refactor. To experiment. To actually think about what they were building instead of just shipping features on autopilot.
Making it stick
The key to making this work long-term was creating a culture where "no" wasn't seen as negative. We reframed it as "not now" or "here's why this doesn't align with where we're going."
We also made our roadmap transparent. Anyone could see what we were working on and why. This reduced the pressure to say "yes" to everything because people understood our constraints and priorities.
Today, saying "no" is second nature. It's not about being stubborn; it's about respecting our team's time, our users' experience, and our product's integrity. Sometimes the most productive thing you can do is decide what not to build.
Continue reading
Asana vs ClickUp vs SaneHQ: Which Is Actually Better for Small Teams?
Asana and ClickUp both show up in every shortlist. For small teams, the better question is which one you will still open after three months. Here is a direct comparison.
Best Project Management Tools for Small Teams (2026)
Lists love feature counts. Small teams need fast setup, fair pricing, and a tool people open without dread. Here is a practical shortlist and how to pick.
Minimalist project management. Do you really need all those features?
Feature-rich PM tools promise flexibility but often add friction. Here is how to tell what you actually need, and when less is more.