Don’t build that feature.

Product-market fit.  Most of the time, we think about it in terms of what to build.  But sometimes, what you don’t build is just as important.  Saying no is an under-appreciated act.  Awards aren’t given for what wasn’t created, but anything great is as much about what is left out, as about what gets in.  So today’s post is an ode to not building it. It goes out to all those who said no.  Before we get there, though, let’s see a reminder of what can happen when the answer is yes.

A desktop phone that tells the weather is a great idea -said no one ever

Most people who have a deskphone have desk. And most people who have a desk have a computer. Most people who have a computer have internet access. And a google search for ‘weather’ reveals 1,430,000,000 results.

Which makes it easier to get the weather?

And yet despite the fact that nearly everyone who uses the Avaya 9408 has a desk, and a computer and the internet (and a mobile phone with 3G just in case), I can get the weather from my Avaya phone.

So how did the Avaya phone come to tell the weather?  Undoubtedly, the idea came from the most sacred of all places: the customer.  Any great company is pulled into the future by its customers.  Listening to customers is a GOOD thing and companies need to do more of it.  But the customer isn’t always right.  Sometimes customers want to do things that they shouldn’t with your product.  Sometimes customers want to externalize onto you their unrelated problems that your product shouldn’t solve. These things happen.  It doesn’t make customers bad, it makes them human.

They said they wanted a smart phone.

When confronted with a product request from a customer, ask yourself these questions:

  • Will this feature help a significant number of my customers? Or just this one?
  • Will this feature make it harder to develop and maintain the product once it’s released?
  • What hard problem does this feature solve?
  • What gets pushed back if we build this?

If the Avaya team had asked these questions, would they have built the weather into their phone? I doubt it. Remember, you can always say no.  You might even end up with 20 million users despite it.

Pinterest launches search for your own pins. Wait, they didn’t already have that?

The idea for this post came this summer when I noticed a bunch of people on Twitter talking about Search coming to Pinterest.  This comment is pretty typical of what I was seeing when it came to level of excitement

Wait, what? I said.  You can’t search your own pins on Pinterest already?

Turns out, no.  Despite search being a fundamental building block of any content site, Pinterest users weren’t able to search their own pins.  And many users had 1000s of pins.

It is unimaginable to me that after 2 years, and 20 million users, Pinterest had just launched search for a user’s own pins.  That seems so obvious, and easy to build. Just put a filter next to the search bar with 3 options: everything, just me, just [user name that autocompletes as I type]. Duh!

That fact that they didn’t release this feature sooner is…pure awesome.

Would Pinterest have been better with this feature 12 months ago?  Yes.  Was it a bad user experience not having it?  Yes.  Does any of that matter?  No.

Because Pinterest nailed the essential feature that makes their app addictive: sharing.  People don’t pin (just) for themselves, they pin for others.   It’s not private, searchable archiving that drove Pinterest to be one of the fastest growing apps of all time.  And so user-based search wasn’t necessary.  Because it wasn’t necessary, they didn’t build it, even though thousands of people must have requested it.   And despite that, they grew like crazy.

What will you (not) build?

The point of this post isn’t that you should ignore what customers are asking for.  Or that by not building something, your users will love you more. It’s simply that in every app, there are features that probably should never have been built.  We all need to get better at saying no.  Because focus grows out of no. And greatness grows out of focus.

The easy thing to do is say yes to customers and users, especially when what they are asking for is legitimate (like searching their own pins). The problem is that easy things are always harder than you expect, and every new feature adds a new moving part that needs to be maintained, upgraded, and scaled as you grow.

So the next time you’re updating your sprint plan, or your roadmap, or whatever you use to manage your product development time, what will you leave off?  And what awesome thing will you now have room to add in?

  • jlouvel

    Excellent post Michael. It would be nice to have tools to assess the value of new features on multiple axis (number of customers, urgency of the need, expected difficulty, etc.) and rationale the decision process, to make it easier to say no and explain why.

    • Michael Ferranti

      Yeah, that would be awesome! In my experience, unfortunately, most of those decisions come down to gut. Like Henry Ford said, if you asked people what they wanted, they would have said a faster horse. That’s what makes building a great product so difficult. Its a combination of intuition and data. I definitely hear you on having good data when telling customers no. That is never a fun conversation!