Should you build that new feature? Ask yourself these 3 questions.

I didn’t think much (if at all) about “product management” until after working at a startup. Maybe it’s because the word “manage” is usually unwelcome in the startup environment. Looking back, product management in essential in any businesses, even it’s actually a cofounder or engineer filling the role. Surprisingly, one of the primary reasons to have a product manager is to decide when NOT to build. Hopefully this post can help in making that decision.

Consider product management an art of balances. You have to balance the time to build vs. time to ship, which features to build now vs. which to build later, requests from customers vs. requests from your team vs. requests from your stakeholders, etc. The list goes on and on. Just take a look at Henrik Kniberg’s summary of the agile product management process:

(check out the video on Youtube)

If you’re a product manager, you can relate to many of these points. You can also relate to how overwhelming this art of balances can get, so you have to take things step by step. In this post, let’s focus on one small aspect of the big picture. One that I think is the most critical in building your product:

In other words, “Should we build that new feature or not?”. As a product manager, you’re the central point of communication, meaning you get the feature requests from everyone — other product managers, your CEO, your developers, your designers, yourself, the customers, heck maybe even your mom has some suggestions.

As a builder yourself, it’s exciting to hear about new ideas and think, “Oh yeah, we can do that, too!”. But if you take that approach, you’ll soon find that your pipeline is clogged, your team isn’t able to deliver the product on time, or in the worst case, you’ve built all those features but done them poorly.

When asked to add a new feature, stop yourself from the instinctual “Yes!” and say “Let me think about it” (or better yet, say “No for now”). Then to decide whether you should build that feature or not, ask yourself these 3 questions:

(1) Is this feature a nice-to-have or a must-have?

Tim Ferriss likes to say, “If it’s not a ‘Hell Yeah,’ it’s a No.” I couldn’t agree more. Your team’s time is limited, so you should prioritize for the features that are a no-brainer to include. If you’re building an app for people to track their running, the product obviously needs a timer and a GPS. It would be nice to connect with a person’s social media profile, but is it really a must? If not, save it for later or scrap it.

(2) If we had to ship our new product in 1 week from now, would we include this feature?

When you self impose constraints, you’re forced to choose only the most important features. As in the first point, you’ll prioritize what really needs to be finished over what can wait. You’ll also think more creatively. Perhaps one of your features can be simplified or built in a much easier way. Perhaps you can come up with a feature no one else has thought about but would add significant value. As DHH, cofounder of Basecamp, says, “Constraints are your friends.”

You can imagine other constraints besides time to simulate this idea. If I had only half as many engineers, would I ask them to build this feature? If we had to choose only one feature, would this be it?

(3) Will this feature be used by the majority of our users?

The old 80/20 rule. If you have a tool to track the features most frequently used by your customers, you’ll probably find that 80% of customers use only 20% of your product’s features. When you build a new feature, ask if you’re building for 80% or more of your customers. If not, don’t build it. You’ll save your time and also avoid confusing your customers with new features that don’t matter to them.

Another way to think about this point is to focus on the things that won’t change, a framework made famous by Amazon’s CEO Jeff Bezos. Customers will always want products that work faster and are simpler to use. When in doubt about what to build next, maybe you should just make your most popular features work even better.

Product management is all about prioritization, focusing on business value, and communication. Sounds simple enough, but it’s hard not to get lost in the details. Always make sure you’re building the right product. That means deciding which features to build vs. not build, as well as which features to keep and which ones to remove. When presented with a new feature request, ask yourself the 3 questions above to hone in on what’s important and forget about the rest.