According to Harvard Business School professor Clayton Christensen, a whopping 95% of all new products fail.

While the numbers are shocking, it raises the obvious question: what are the 5 percent who succeed doing differently?

Do they simply have a better idea? Do they somehow have a means of understanding the market better than others? Are they in on some secret the others don’t know?

Well, sometimes, something that isn’t common knowledge can be called a secret, isn’t it?

Here are 3 secrets that can exponentially increase the chances of your product succeeding:

1. Don’t be a ‘me-too’ player

One of the core principles we follow at Akrity is: “Don’t build what you don’t need.”

One of the grave mistakes many entrepreneurs make is to try and build a replica of a successful product: what we call a ‘me too’ product (no relation to the MeToo movement: this one’s no good). 

In the process, they tend to add in all the features they see in another product. Frankly, it’s a recipe for disaster.

In their minds, people think users would expect these features because the other product like ours has them. Or maybe they believe if their product has all the features of the successful one, people will start using it. 

Unfortunately, it doesn’t work that way.

Let’s take an example. Let’s say you are building a new social networking app to connect entrepreneurs and VCs.

The minute people start thinking about social networking, they might think I need to build an application where everybody will have a profile (after all, Facebook, Instagram, and LinkedIn have profiles and they are social networking apps, is what the first instinct is).

The question is: do you really need a Profile? If you don’t, what else do you NOT need? 

How do we judge that?

Well, the core idea is that your product should first and foremost solve a major pain point for people. The main focus is on solving that burning problem your user has, something that is preventing users from doing something they really care about–something they are unable to do TODAY.

Solving just that problem well is good enough for your product to start getting usage.

Your product may not be aesthetically pleasing, your product may not be extremely user friendly, it may be really sparse — but all that is fine, as long it solves a burning problem well. 

Let’s go back a few decades–back when calls and SMSs cost us a lot of money. If you wanted to text a friend abroad, the prices were exorbitant. 

Enter Whatsapp. They came in and solved that specific problem (people with Wi-Fi could now chat with their lover in Belgium for hours).

Now, did Whatsapp offer end-to-end encryption? No. Were people even worried about it? No! Could you send voice notes or files back then? No. Did people still use it? Absolutely.

They have now evolved and have a dozen other features, but back then, when starting out, Whatsapp was focused on only solving one, very specific problem. As Kan Koum says ”The problem people faced with SMS was that people were finding it really hard to send SMS internationally- because it was very expensive. It was a pain for them.”

The main problem, if you want to build what you don’t need is that as a startup, you have a very limited number of resources. 

What this means is building even a few unnecessary features and trying to fine-tune them might cause you to end up in a do-or-die situation. 

You might find that you have run out of resources and time but your product is nowhere near ready.

Now, you might ask, fine, we don’t replicate another app and we just focus on the core feature and build that really well. What if we miss some key feature in the process?

There are broadly four features you need to focus on:

1. Revenue-generating feature
2. Security-enhancing features
3. Software stability features
4. Marketing-related features  

Revenue-generating features include all features that help you in making transactions. This is a no-brainer. If you don’t have these features built-in, you basically do not have a way of making money.

Your Security-enhancing features will ensure a completely safe and secure environment for your users.

Your Software Stability features will help ensure you have a robust smoothly functioning system.

The Marketing-related features are ones that help you spread the word about your product, enabling you to invite people from other platforms, say.

So, once you divide all your features to fit into any of these categories, you will have a disciplined view of what feature is required for your end user and what feature is not. 

Another extension of our ‘Don’t build what you don’t need’ philosophy is ‘Don’t build things that are not the core of your application’. 

What that simply means is that if it’s an auxiliary feature, you don’t need to write the code for it yourself. You can simply integrate those particular functionalities to your product from other vendors or pluggable software infrastructure.

Let’s take the example of the social networking site for VCs and entrepreneurs. 

Let’s say the core problem we have focussed on is “finding the high-quality entrepreneurs” for the VC because VCs spend a lot of time sifting through several low-quality leads. In addition to merely providing the platform, you will also need some features that will enable them to send messages to each other, hold conversations, or set up meetings.

Now, since setting up their communication is not the core value proposition of your product, you can simply use an external tool or integrate with other chat plugins for it, instead of spending time and resources writing it from scratch.

So, since helping VCs find high-quality entrepreneurs is the core problem you are solving, build that bit all by yourself, to the highest sophistication level possible. 

The auxiliary features, however, can be just set up using existing communication tools, or integrated with other efficient readymade solutions. 

Another example is login. Do you need to build a unique login for your product from scratch? If not, you can simply log in with Google, or Facebook. If that doesn’t suit you, you can simply use one of the many open-source libraries available for the login module itself. 

Our Hallmark as an engineering team is to find these plug-and-play components that you can integrate with your product so that you don’t waste time building everything. 

You only build the core logic of your product and just build the plumbing for all else to work. 

2. Focus on the right early adopter segment

It is imperative that your product solves the problem of a particular group of people with a specific problem.

Let’s take that same example, where you are building a networking platform for VCs and entrepreneurs. Say one group of VCs says their problem is finding high-value entrepreneurs.

Another group of VCs perhaps is looking for only women entrepreneurs, and a third group is merely interested in coverage and not looking for high-quality entrepreneurs at all. 

Finding the people whose needs YOUR product will solve is an important judgment call.

You can segment the market and look at the people who are most affected by the problem you are trying to solve and solely focus on them in the first few years of your product. 

You will need to select a small group of people as your early adopter segment and solve their problem really, really, REALLY well. You need to listen to them, you need to pay a lot of attention to their needs, and you need to create success for them.

How would you measure that success? That brings us to the third point.

3. Make a transaction happen

What is the outcome you should be aiming for with your early-stage product? The answer is a transaction.

Often, entrepreneurs get lost in building an MVP, which is only demo-ready. 

It can be used to show the demo around for feedback from users. But calling it an MVP? Nope.

The goal of an MVP is to create a transaction.

It is not to create an interest among potential buyers, it is not to create a promise about a transaction in the future–an MVP’s aim is to create a transaction–no matter how big or small.

It is a true indicator of the client’s interest and how much of a problem your product actually solves. Always ask yourself if you are staying true to that.

Conclusion

To sum it up, the three rules you need to follow while building a new product are:

1. Don’t build what you do not need just because another successful product has those features. Focus mainly on solving one major pain point for your users. 
2. Choose a small segment of customers that are currently underserved and service them really well. 
3. The true indicator of whether your product is solving a problem or not is a transaction. Instead of a demo, build an MVP, with the sole goal of getting you a transaction.

There are several other rules when it comes to developing a new product, but following these three rules will definitely skyrocket the chances of your product being a success…being in the elusive top 5%.

What other secrets can lead to the success of a product? Let us know in the comments below.