Build for the majority

So you’re at an early-stage startup trying to figure out who to go after and how to do it. You’ve identified the users you want to go after…

So you’re at an early-stage startup trying to figure out who to go after and how to do it. You’ve identified the users you want to go after by focusing on the segment of users who have shared complaints and pain points, and you’ve chosen the segment that is the most dissatisfied.

The reason why it’s important to make sure you define the user base correctly is that it directly impacts the next concept I’ve been thinking about lately, which is that whenever possible, you should really build for the majority, not the minority. Now this seems obvious — if you’ve been to any product management events, they’ll tell you that one of the vectors that you can use to prioritize features is the number of users who would use it. However, it’s not always so easy to build for the majority.

To illustrate why defining your target users is important and closely tied to building for the majority, consider if you defined your users too broadly. In that case, you’d be building for everyone, which doesn’t quite make sense. You need to remember to build for that shared use case. Now imagine that you’ve narrowly defined your target users to the point that you end up building a product that the majority of a very small user base want. Also not optimal. So I guess as is true with everything in life, everything in moderation.

Further, a lot of common techniques can create traps that make it easy for you to accidentally build for the minority instead of the majority. For example, sometimes the minority pays more.

Imagine that you’re a startup, and an enterprise is SUPER interested in your product, but they need LDAP integration and want you to jump through 10,000 enterprise security hoops. Sure, if you’re looking to get acquired by said enterprise, this might make sense, but if you aren’t, you will be wasting precious time. That being said, as long as enterprise requests align with your strategic goals, it never hurts to get paid :)

Another common trap is to prioritize features based on the number of requests, but not all requests are equal and many commonly requested features are rarely used. I’m sure you’ve experienced this before — competitor X has a feature that you don’t. Every other conversation with a customer results in the customer bringing up that feature, but you know none of them will use it in the near term. However, it’s clearly a barrier.

It’s easy to use these data points to push for the feature to be developed, but I’ve found that what can often result is a lot of work invested into a product feature that no one is ready to use.

Final example — another common thing PMs do is create customer advisory boards. These are deeply engaged customers who provide great value. However, if your customer does not reflect the needs of your overall target market, the advisory board could lead you in a direction that diverges from your long term roadmap. Be careful!!

So does this mean that you shouldn’t build a feature if you aren’t sure it will be used by the majority? My view (that may change with time) is that it depends. Obviously, building a feature everyone will use is great, but sometimes you need to build a feature that everyone thinks they will use. A feature that gets people excited about your product, even if they don’t need it on Day 1. Or, a feature that prevents a large group of people from using your product. So I guess it’s about building to the majority’s wants, and not necessarily their rational needs.

Most importantly, always be forwards looking! It’s not about building for the users you have now, it’s building for the users you wished you had now. I think being forwards looking is important for startups because existentially, being able to adapt quickly and innovate quickly is a necessity. Also, it helps with team morale, which is super important when you have a small team.

Finally, I’ll nerd out a bit. I’m taking a computer architecture class where we are learning about Amdahl’s Law. Essentially, it states that you can keep improving a small segment of a program, but the other segments that haven’t improved will ultimately limit overall improvement. Equally, optimizing a small segment of users 10x isn’t always better than optimizing everyone 2x.

The problem with this topic though is that table-stakes features are by definition impacting the majority of users, so does this mean you only invest in those features? Hell no! Which will bring us to our next, and potentially most important topic for a startup: investing in differentiators. Until next time.