How to Identify a Successful Product

by Viacheslav Kovalevskyi

Have you ever asked yourself: if there are any product attributes that can tell you if it will be successful or not?

This question is such a hard question that many leaders tend to answer a more straightforward question (especially in the IT field): are the tools that we picked to deliver the project will allow us to deliver it successfully? While the latter question is also important, I rarely see wrong technical decisions as for product failure. Quite the opposite, I've seen many products that are horrible from the technical perspective to end up being quite successful. Such observation boils down to a simple statement: it is better to solve the right problem with the wrong tools than to solve a wrong problem with right tools.

Just several examples:

  • RethinkDB (excellent technology but failed product) vs. MongoDB (highly successful product but horrible technology)
  • Microsoft Zune - everyone who used it, loved it. However, the product failed
  • Airbus A380 - it is a state of the art engineering that is a complete failure as a product (BTW case of A380 we will be using a lot in this article)

Okay, so the product needs to be solving the right problem. But are there any other aspects of a potentially successful product? And what does it mean "right problem"? In this article, I'm going to introduce you to the high-level criteria of any successful product. They are so simple and generic that my site has a page (uodp.club/successful-product/) to have them outlined for you so you can get back to them whenever it is needed. I would advise you to bookmark it and revisit time to time (I'm very occasionally updating it).

So, a successful product is a product that (rev Mar.08.20 is used here):

  • Solves a real customer's problem
  • Solves one of the primary customer's problems
  • Solves a problem that will exist (and will remain primary problem) by the time it is delivered
  • Easily pluggable in the existing customer's infrastructure
  • Cost of adopting the product should be smaller (ideally: drastically lower) than the benefits that customer will get

While this might look like a small list of things, you would be surprised how easily people can get items from this list incorrectly.

Instead Of a Disclaimer

One thing to notice before directing each item one by one. If the product does not qualify as a successful product, it does not mean that it can not become a successful product in the future. On my site, I will be calling such products(a product that is not qualified as a successful product now): "Moon Shots". We will dive into the "Moon Shot" definition later, but for now, let's say that "Moon Shot" is a product that has minimal chances of becoming a successful product.

Also, the definition of success, in this case, is minimal. I am only defining it as a product that will have usage among customers on the initially expected level (or more). However, such a definition does not even say if such usage level would also give any reasonable ROI.

With these caveats in mind, let's proceed...

Solves a Real Customer's Problem

A problem that the product is solving has to exist today and now. It does not mean that you should not innovate. A user might not know that the problem exists since there are no solutions to it, and therefore everyone just settled on compromises that they see. However, do not confuse "existing problems that customers are not thinking about" with "nonexisting problems that you think customers will have in the future". Since identifying first is much harder than latter frequently, we tend to come up with an imaginary future that will have new problems and start solving them.

If you are focusing on forecasting the market, you are doing "Moon Shot" by design. Let me give you an example. Airbus A380, a disaster that never generated enough money even to compensate for all the investments. Probably excellent high-level overview of the failure can be found in this short video:

In short: in ~1988 Airbus performed a market analysis and made a bat on the transportation model that turns out to be a mistake. This analysis shows that even companies with multi-billion budgets for market evaluations can not predict the future. We will speak about why that is later.

Solves One of the Primary Customer's Problems

This requirement is much-much harder to satisfy, comparing to the previous one, and here is why. Almost any product/feature that succeeds (or failed), with a high level of certainty, can be traced to a real problem that product/feature was solving.

I'm sure that the essential phone or Amazon fire phone had a real customer's problem that they were solving. Airbus A380 had a very well defined and evident problem in mind.

I love the following military analogy: imagine general commands to open fire, and imagine that no one does so. Now, imagine that the reason why no one starts doing as commanded is that there are no bullets. In such a situation, it does not matter what other problems you will solve. If you are not going to solve the problem around bullets, no other solution will probably be adopted.

Solving one of main problems is the key to success. Whoever solving the main problem usually has ultimate access to customers and customer's trust. Such a situation, by itself, makes you the first candidate to ask for help with solving other problems tomorrow when the main problems of today will be resolved.

Solves a Problem That Will Exist

It is very-very hard to make sure that existing problems still exist and still one of the main problems. Need to predict the future is the critical aspect of why it is theoretically impossible to have a 100% certainty that the product will be successful.

Easily Pluggable in the Existing Customer's Infrastructure

Let's come back to the example of A380. Here is another video that shows a slightly different angle of the same problem:

In short, A380 became a logistical nightmare. It was not possible to use it within the existing infrastructure. Even today, there is a tiny amount of airport capable of working with A380. To show how important for the products to be pluggable with existing infrastructure, let's also look at Boeing 777x. This airplane has amazing foldable wingtips. And the main reason why they got created is so the size of the aircraft on the ground would allow it to tax in smaller airports.

Watch it in action:

Afterwords

Unfortunately, as I have mentioned earlier, it is theoretically impossible to satisfy all the items in this list with 100% certainty. At least you will never be sure that the problem (even if you got the problem right) will exist by the time your product delivered. However, this list gives you an excellent framework to focus on, Northstar. I've used it so many times to pivot my products in the early stages of development even before writing any lines of code. I've also been using it on many product technical reviews, but this is a different topic for the next article.

Home Work

I would suggest to allocate some time and do a quick analysis of all the products that you own to figure out if any of them meeting all the required criteria or not.