In the early days of a startup, it is tempting to build a feature as soon as one person requests it. You're hungry for new users and building the features they ask for seems like a logical approach to getting them signed up for your product. But this is almost always a big mistake.

As a general rule, building your product based on feature requests results in more pain than progress.

There are several reasons why you shouldn't build a feature for just one customer:

1) Products need to be built with a vision

As a product builder, you have a vision of what your product will become. Achieving this vision requires immense focus. If pleasing this one customer compromises your product vision — even just a little bit — then over time you're product will creep further and further from your intended direction.

This mentality of accepting every customer request distorts your product vision. The tasks you focus on will increasingly be low priority for the rest of your target customers and your team will become progressively more frustrated with your constantly changing expectations.

You can't solve every problem. Knowing when to say "no" is immensely important. Steve Jobs — arguably one of the greatest product visionaries of the last 100 years — is known for his dedication to product vision above all else. He famously said, "People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are."

By default, the answer to feature requests must be "no." That being said, you need to balance this tunnel vision with open-mindedness, a willingness to be wrong, and the ability to pivot iteratively. It's a matter of using your initiative to navigate complex situations. This is what makes building a startup so difficult and product success so rare.

At Kissmetrics, a startup that completely reinvented the analytics category with its funnel tracking product in 2010, the team used to call these feature request distractions 'Hiten Bombs' — named after their Founder and CEO Hiten Shah.

"Every week — actually it was usually daily — I would drop a bomb on someone in the company. It would be some new idea, some new direction, some new brilliant thing I came up with — something we absolutely had to do right now."

In hindsight, Hiten admits that allowing product vision to slip creates confusion within the team and impacts a startup's most important asset; speed. "We didn’t prioritize our product development with the right data. Our execution slowed. We were no longer innovating and staying ahead of the curve.

"The winning product is based on focus and planning. Continuous unbiased research and goal-focused development." Feature requests from just one customer are the most common (and easiest to blindly follow) 'Hiten Bomb' you'll come across when building a product; avoid them at all costs.

2) Resources at any startup are limited

Every time you make a decision to build a new feature, you're deciding not to spend time improving existing features, testing for bugs, or solving more important customer problems. Every action at a startup has an opportunity cost and prioritization is the key to success in this game.

Instead of saying yes right away, take a step back to think about whether you can solve this customer’s problem in a different way. Quite often you'll realize that there is an alternative solution to the problem that doesn't require an additional build, such as simplifying an existing feature, linking to a blog post, or improving your product support documentation.

As Hiten from Kissmetrics explains, following every new feature idea took a heavy toll on the Kissmetrics team, "The team would rush to execute my new idea as priority. They’d huddle together to figure out the best and fastest way to accomplish it. They’d pull in more teammates and add it to our growing list of competing features to build, bugs to fix, and customer requests. I didn’t realize it at the time, but to my team the barrage of random ideas seemed like they were coming completely out of left field."

Intercom, on the other hand, is a great example of a team that doesn't siphon away resources for features that aren't an existing priority. Intercom regularly gets requests from customers to turn off their messenger widget outside of working hours. Instead of allowing the frequency of this feature request to alter their roadmap, the Intercom support team helps customers to set their office hours and expected response time. Intercom is the first to admit that this is not always what customers want to hear, but the workaround is usually enough to satisfy what customers originally asked for. Remember — customers buy solutions, not features.

3) You should build for the many, not the few.

Impulsively building features is a consequence of short-term thinking. You need to build features that will add maximum value for the largest number of people long-term.

Product builders often fall into a mindset of "but we will lose the customer if we don't build this." The truth is that if one customer has that much influence over your company, you need to think about diversifying your revenue stream — especially if you're dealing with a small overall amount of revenue.

When you don't have many (or any) customers yet, it can be easy to think that one customer's requirements are representative of all future customers. In reality, there's no way to know for sure without having sufficient data. We almost made this mistake at OpinionX by adding a feature to our stack ranking product for buying survey participants. When we first heard the request from one customer, we thought it was an interesting idea. Within a week, we had 3 more identical requests. Understandably we were pretty confident that this was the correct move for us.

We set up introductory calls with panel recruitment providers and mocked up how the feature would work, the user flow, and the different recruitment segments our users would need. The deeper we got, the more we realized how big this project would be. It was going to take our entire development team almost three months of work before we could ship the first version to users.

We were shipping big features every single week around this time. Three months of not shipping stopped us in our tracks to properly consider this project. Two things snapped us out of this delusion:

1. We measured how important recruitment was to our users

   In the early days, the product builder's job is to repeatedly solve the biggest barrier for users to successfully adopt their product. We set about measuring how high on the list of barriers this was to our users. We turned all the feature requests we had received over the previous month into problem statements and asked users to vote for the biggest problems they were having with OpinionX. During the stack rank, they also added new problems for others to vote on which highlighted problems we never even knew about, but that's a story for another time...
   

   Within a few hours, we could see that participant recruitment was right in the middle of the stack rank — not a burning problem but more than a mild inconvenience. This validated that we shouldn't jump into building this feature, but we wanted to understand where the request was coming from.
   

2. We searched for overlap between this feature request and our paying customers

   We knew that participant recruitment was a 'middle of the stack' priority for the average user, so who was it a priority for? We had a small premium customer base at this stage and a quick glance showed that none of these users had any issues with finding survey participants. Digging into this further, we realized that we had two different user segments competing for different features — founders without users wanted recruitment so they could validate their ideas, product teams with users wanted us to add more analysis and moderation tools.

   Our customer base at that stage consisted of more product teams than founders, so we prioritized that segment in our roadmap decisions. Instead of spending three months building the recruitment feature, we wrote a blog post on free techniques for finding survey participants and continued to prioritize our product roadmap for our paying users.

4) It adds complexity to the product

Product builders think that by making a feature optional, they get the best of both worlds — satisfy the feature request without overburdening other customers. But that's not how it works...

Each extra feature makes your product more intimidating for new users, increases the time users need to find the feature they're looking for and adds even more information that users have to remember next time they use your product.

To make matters worse, the paradox of choice says that adding more options actually causes more stress and delays decision-making. We've all experienced this; that overwhelming paralysis where you spend 20 minutes scrolling through Netflix and end up not watching anything at all.

Successful features depend on successful user adoption. Your features are all competing against one another for that sliver of time that users commit to spending on your product. The more features you build into your product, the harder it is for each feature to become part of a user's product habit.

Instead of overburdening your users, you want to prioritize the features that solve your customers' biggest problems and optimize from there for the smoothest product experience. Make it obvious to your users what is expected of them. In the words of Steve Krug, "don't make me think."

5) It might be harder to build than you think

The Planning Fallacy is a term psychologists use to describe our tendency to underestimate the amount of time it will take to complete a task. The funny thing about this fallacy is we never seem to learn from it. Even though your last 10 projects went 3+ weeks over schedule, you still don't account for this when you decide to 'quickly' build that feature a customer just requested.

Roger Buehler, a social psychologist, conducted a study in 1994 where a group of college students was asked to estimate how much time they would need to finish writing their theses. The students estimated 33.9 days. Then they were asked for an optimistic and pessimistic estimate, to which they answered 27.4 days and 48.6 days respectively. The number of days that it took to complete their theses was actually 55.5 days! Interestingly, this trend was observed in everything from fixing bicycles to writing letters and cleaning bedrooms.

Things are rarely smooth sailing when building something new and the time required for a new feature rarely stops once development is finished. There are bug fixes, user education, and ongoing customer support for this feature that will siphon away your time forever (especially if it falls outside your long-term product vision).

Think twice before you say yes to a feature request by telling yourself 'it won't take too long.' Your time is precious at a startup; use it wisely.

6) Will they even use it?

This might be the most important of all. Most feature requests mask an underlying problem that users are trying to tell you. But there's an even more dangerous type of feature request — when people say something for the sake of saying something or to sound smart. There is a good chance that after you build the feature and enthusiastically email that customer, they'll never even respond. Trust me, you don't ever want to experience that kind of pain...

When should you consider building a feature for just one customer?

Is there ever a time where you should build a feature for just one customer? The answer is a strong maybe 🥴 As discussed above, it's always best to avoid building a feature based on a single or even just a few customer requests. That being said, there are a handful of very rare occasions when you should consider building a customer's feature request:

1) The feature aligns with the product vision

You'll notice that some of your more visionary customers request features that are already on your product roadmap. This is a beautiful feeling and indicates that your ambitions are aligned with users' needs.

If you receive a one-time feature request from a customer that happens to be already on your roadmap and aligns with your vision, it could be worth prioritizing over features that haven't yet been mentioned by customers.

We had this experience at OpinionX. It was on our roadmap to add a feature that would allow stack rank creators to approve statements added by participants before they get sent to other participants to vote on. We knew this would be important but had other priorities on our plate first. After it was highlighted to us that this feature was super important by a couple of users, we pulled it to the front of our queue and built it straight away for those customers. (but this particular feature request was special... I'll explain below).

2) It requires minimum resources and is super simple

We already discussed that most things take longer and are harder than you expect. But in some cases, you just know from experience that this feature will be of huge value to your customers and requires minimum investment from you (aka it has almost zero downsides).

In the case of this approval feature request, our product team was confident they could build the feature within two days. It wasn't rocket science or time-consuming, so we decided it would provide more benefit than risk. During those two days, we started getting loads more requests for this same feature, validating our initial decision to start building it.

3) You have already validated the problem with other users

Sometimes, even though the feature hasn't been requested before, the problem has already been validated. Through your user research, you know that the problem likely exists for most of your customers. In these cases, you can consider implementing the feature — although I would encourage you to investigate whether this specific feature is actually the best solution to the problem. There is always more than one way to solve a problem.

We 'dogfood' OpinionX (ie. use our own product on ourselves) all the time at our startup, so we knew first hand that not having this approval capability could lead to embarrassing moments where low-quality opinions were automatically sent to other users to vote on. By using our own product, we knew that other customers would benefit from this feature too. When the first feature request came in for approving opinions, we felt confident that it was the correct thing to do.

4) You're going to make a loooot of money

On rare occasions, a single customer is worth so much to you that building the feature will generate enough revenue to pay off the opportunity cost and make it all worthwhile. You can invest this money back into your original product vision.

In reality, this really only applies to startups with an enterprise sales focus (ie. they sell to a small number of really big companies). For product-led companies (which typically focus on building a much bigger user base with a smaller amount of revenue per customer), following a big cheque like this is usually little more than a giant distraction.

If you find yourself in this situation, I'd encourage you to investigate whether this is really a one-time big-ticket customer or if you've actually stumbled upon a really profitable customer segment (if you've already taken the money, I hope for your sake that it's a really profitable segment 🙃).

At OpinionX, we were presented with this opportunity once. An enterprise-size customer wanted a heap of integrations that we didn't have and had no intention of building for at least a year. We understood that building these features for this one user could be profitable in the short term and extend our runway, but ultimately we decided that we needed to stay focused on the vision of helping early-stage startups to find product/market fit faster.

Make decisions based on problems, not features

The underlying theme throughout this article is that it's your job as a product builder to identify the problem underlying your customers' feature requests and determine if they represent the most important problems faced by your broader customer base.

As mentioned, we almost made a huge mistake by jumping into a 3-month build for a feature requested by only a handful of people before discovering that the problem was not a high-priority pain point for most of our other users. We used OpinionX to really quickly figure this out — it enabled our users to stack rank all the barriers they had with using our product so that we could identify the most urgent friction points to resolve.

Instead of spending 3 months working on that feature, we spent 3 hours writing a quick blog post to help that small subsegment of our users and dedicated our focus towards solving the most urgent problems that most of our users were struggling with.

Stack ranking is a really simple framework for prioritizing your time as an early-stage product builder. It gives you data that you could never find from user interviews so that you can be more confident in your decision-making. It's free to create as many stack ranking surveys as you need on OpinionX — get started right now and within a few hours, you'll have the data you need to decide whether or not you should build that feature request :)