Skip to main content

On Saying No to Features

· 3 min read
Robin Lobo
Developer

The most useful product skill I've developed this year isn't writing code faster. It's saying no to features — including the ones I want to build myself.

The feature that almost broke Patchwork​

Three months after launch, I had 80 customers and a growing list of requests. The most popular: a visual query builder. A UI for filtering entries without writing a query. I was excited about it — it seemed technically interesting and customers wanted it.

I spent four weeks building it. It worked. It also introduced three bugs in the existing editor, confused new users who encountered it before understanding the basics, and was used by exactly nine of my eighty customers.

Four weeks, nine users, three bugs.

The question I wasn't asking​

The right question isn't "do customers want this?" It's "what happens to the customers who don't get this if I spend four weeks on it?"

While I was building the query builder, I didn't:

  • Fix three known onboarding friction points
  • Build the Vercel integration that three paying customers had specifically asked for
  • Write documentation for the API (mentioned in five support emails)

The query builder felt like a feature. The other stuff felt like maintenance. But the "maintenance" would have helped every customer. The feature helped nine.

How I decide now​

I use a simple question: does this help all my customers, or does it help some of them?

Things that help all customers: faster load times, better error messages, clearer onboarding, reliable webhooks, good documentation. These compound. Every customer benefits, and the improvement doesn't become obsolete when you add the next feature.

Things that help some customers: the visual query builder, CSV export, a mobile app, Slack notifications. These are fine to build eventually. They're not fine to build at the expense of the universal improvements.

The features I'm most glad I didn't build​

  • Teams and permissions — requested early, would have taken two months, the customers requesting it ended up not needing it
  • A native mobile app — obvious request, zero actual demand when I asked customers to pay extra for it
  • SSO / SAML — sounds like a serious enterprise feature, the customers asking weren't going to pay enterprise prices

The harder version​

The really hard version of this is saying no to features you want to build. I have a running list of things I'd find genuinely interesting to work on. Some of them are good ideas for the product. Most of them are good ideas for me to feel productive without moving the thing that matters forward.

The question isn't whether it's a good idea. It's whether it's the best use of the next four weeks.