If you're chasing features, you're chasing the wrong thing

Are you feature rich but users poor?


The problem isn’t with what you’re trying to build. It’s that you’re trying to build too much.

Everyone falls into this trap in the beginning when they’re building something new.

In the early stages of a product, people are looking for growth and adding new features is one of the tangible things to achieve. They are easy to track, and you’re able to see how work going in results in new features coming out.

With new features being launched it feels like there’s momentum building around the product.

We have more today than we did yesterday.

However, this focus on features might mean you’re missing another critical aspect of the development of your product.

Finding people who will actually use and ultimately pay for it.

while things were done quickly, they may have set you back more than they pushed you forward.

A common perception is that development is the bottleneck when it comes to launching a product.

However, that isn’t true, especially in the beginning.

In the beginning, you’ll be able to build new features much faster than you’re able to acquire new users. And you’re better off not thinking you’ll have one of those viral campaigns that take off and builds you a massive email list. Those are usually full of people who wouldn’t be your actual customers anyway.

The thing is, the features you’re building are often part of an outline based on a hypothesis about a market that may or may not be true. And because it takes longer to validate those features, teams often move on to building the next feature on the list.

Again, it’s the quickest way of seeing growth, but it’s growth with the wrong intention.

It’s growth for the size of the product, instead of the quality of the offering.

Which plays into another misconception, that if we build everything, then there will be something for everyone. However, the flip side of that is if you build something for everyone, you’ve built something for no one.

The first time I learned this was when I was building my first serious MVP with my development partner, Nick. It was an approval management system for creative agencies to help them manage the flow of content and communication between the team and their clients. 

Coming from that industry we were solving a problem we knew existed because it was our problem. We were experiencing it every day and we thought we knew exactly what we needed to do to fix it.

So we focused on features. We had a six month roadmap of everything we needed to get done and a plan to launch once we got there. 

We knew what the problems were and the type of product that would make our lives easier. We believed if we could make things better for ourselves, we could make them better for everyone else too.

With that belief in place, we were able to start strong and stick to our timeline. But that only lasted so long. I think we only got 3 or 4 months in before we were burned out and decided to wrap things up. It no longer felt right.

Looking back now I can see our problem wasn’t that what we were building was wrong. In fact, I’ve seen a handful of companies come out with similar products. One of which has marketing language you could mistake for ours.

But no one but me would know that. And that was the problem. That’s why it didn’t feel right. We were working in an echo chamber and without truly releasing anything into the world to validate our product with real people the echo became to loud to bear and caused us to shut down not truly knowing why it didn’t work out.

So, I’ve seen it first hand and while it’s a lesson I only needed to learn once. I still fall victim to focusing on features more than I should — though it’s a little less each time. And it’s why when we now work with other founders and companies we are the first to stress how important it is to define a small but valuable feature set to build while focusing mainly on finding and building relationships with the people who might one day become a customer.

It’s why not validating new features with real people who might use your product is the real bottleneck in the beginning.

When you skip this step to sprint out ahead, you run the risk of ending up with a product where people only find value in a handful of the features you built. Or worse, none at all.

So, while things were done quickly, they may have set you back more than they pushed you forward. You may now have to backtrack, take things out, and reset before moving forward again.

A way to protect against this is to be more intentional as you’re building.

Instead of having your metric be new features, qualify it, so it becomes validated features. With this in mind you’ll do two important things at once:

  1. Proving (or disproving) your hypothesis of what will be valuable to the market

  2. Building up a group of qualified users who might pay for your product


It’s small shifts in thinking like this that can help keep a team on track to deliver something that people genuinely want instead of chasing every potential opportunity hoping that something might stick.

 

Get more articles like this.

Business strategy and product insights published every week.