Why 95% of the products fail and how to beat the odds — Part 1: Not all products are created equally.
This is part 1 of a planned series on a summary of my experiences during almost 10 years as Venture Builder, Founder, Co-Founder and Senior PM in “Product Development” and some suggestions to avoid the same mistakes I have made along the journey. Please feel free to reach out if any suggestion or point I’ve missed.
It is not a big secret that around 95% of products fail (quick google search), but interestingly, very few people who develop a product are actually aware of it or they act like it doesn’t apply to them.
It’s ok, if you hear it for the first time. I’ve been there, too. (Damn you Dunning-Kruger effect.)
Bad news is; unfortunately, there is no quick way, no shortcut or no “5 steps to create a successful product” guide; in fact it is one of the most difficult things to do and statistically you are destined to fail (which is ok as long as you can learn from it and don’t fail too expensive. More on that in a different post). But if you still want to do it, there are some heads-up’s.
Let’s start;
Experiencing “Achieving Failure” first hand.
When you run a start-up, especially for the first time; you’re full of ideas, 1000s of features to add, endless possibilities and you are almost certain that you found the next billion dollar thing (because you’re so f* smart); but for most of times there is no or limited money, no or limited team, you don’t know how much time you need to build it or how to build it. Where to start?
As you’ve been taught in school, your first instinct is to create project plans, business plans (which require historical information) to enable at least some kind of visibility and have checkpoints to follow, which unfortunately don’t mean much, because you make things up! There is a constant chaos and everyday you’re putting out fires while moving forward.
Some can find a way out of this maze, but most can’t… This is the game.
Reid Hoffman once described startups as, “jumping off the cliff and building an airplane on the way down.” But unfortunately you don’t see it during the fall. It only makes sense when you look back.
During this chaotic period, it’s really difficult to objectively observe and assess events as they have been described in “Lean Methodology”. Wtf is a “MVP”, how is it possible to “achieve failure” or how on earth “customer development” should work exactly?
When you develop things for someone else, with someone else’s money and you are already given a plan to follow; things are completely different. You’re building only a part of the airplane, but this time you’re on the ground and you’re not the one who’ll fly it. Your biggest concern is to follow the plan and get things done “on time, on quality, on budget”. You surely want that the plane will fly, but you won’t go bankrupt if it doesn’t.
I was unfortunate enough to experience both of those situations… multiple times. And after a while, one start to see things differently and identify some patterns. (just like operators in Matrix)
"Unfortunately, no one can be told what the Matrix is. You have to see it for yourself.”
- Morpheus
Let me give you an example;
A long time ago in a galaxy far far away, I found myself working on a new product for a well known large company. Within the team we had managers who knew the market very well, unlimited potential market reach, an established brand we could use, enough budget to fund 5+ early stage startups and a great team with experts on their own fields.
We’ve been handed over a detailed business plan with a sales target for hundreds of millions and a solid feature-set in our backlog handcrafted by C-level upper management people. Only thing we had to do, was to build it as planned. The sales projections were starting right after the project deadline and we were not supposed to generate throw-away code, since it’s inefficient and effects team velocity. But the plan was generated by upper management and they were very confident about it; what could go wrong?
A couple of things did actually;
- When the project started, all our experts within the team started to do what they always did, exactly how they always did it. Designers started creating a full scale design library to use for the upcoming 5 years and custom & difficult to build user-interactions to make sure our product will stand out; backend developers were designing a scaleable infrastructure for millions of users, while fronted developers were trying to figure out possible accessibility issues.
I remember saying to myself:
It looks like a bunch of musicians, playing different songs which they are good at, in the same room, at the same time. And unfortunately, none of them were playing the song we were performing…
But that wasn’t our biggest issue and could manage it at the end.
2. Yes,
- we had managers with market knowledge, but the new product required different channels and revenue models. The existing tools they had to predict the market were useless,
- we had unlimited market reach, but had to aim “everyone” since we were already a large company,
- we had a company brand, which came with a lot of functional and non-functional requirements like scalability, design and tech restrictions.
3. People, who were making critical final decisions were senior managers and they were only part time on the project. As a result, decisions were made based on personal opinions of upper management who believed that they exactly knew what customers want (Eric Ries has a cool name for it; a “reality distortion field”).
Nobody wants to argue with a C-level, which often leads to HiPPO -Highest Paid Persons Opinion.
With some luck, tears and blood we managed to complete the development, on time, on budget and on quality; celebrated our huge achievement. We really had a beautifully designed product working like a Swiss-made clock and could handle a lot of users.
It was time to get our baby into users’ hands and collect appreciations. Leveraging companies connections, we’ve carefully selected our first pilot users, since they were the lucky ones and we were doing them a favor.
As you may guess from the spoiler on header, unfortunately users didn’t use it, since it wasn’t solving any of their problems. It was designed to solve our company problem -which was to make more money-, but for some reason, customers didn’t care much about that.
Eric Ries describes “Achieving failure” as “successfully building the wrong thing”. In our case, it was delivering a product “on time, on budget and on quality”, which people didn’t use as expected, because we never asked them.
“Product” doesn’t always mean the same thing.
How good or efficient you build something doesn’t matter much if no one uses it. I believe it is really really important to start with the question “wtf is the purpose of this product” to assess the type of the risks and plan accordingly to make sure that it will have a chance on the market.
After developing a lot of products over the years, I could identify 3 main clusters of them which require different approaches, methods and tools to develop according to their product-market fit risks:
- “Improvement to an existing product” is the most common type of product development. This is where you know almost everything about your market and domain. You know your customers, how many they are, how much they can pay, your competitors, your marketshare, your costs, how to build it and plan everything accordingly in detail.
Our entire university education -beside managing an existing product-, project planning methods, metrics, etc. are mostly based on this one and the biggest risk is the efficiency. - “New product for an existing business model”: This is where traditional market researches, focus groups and R&D departments come in play to predict the future. In this case, you already have a pretty good idea what market needs are (since it’s still the same market) and try to address a slightly different segment of a different problem.
There is a bit of product risk but it’s still mostly manageable. Consulting companies are often experts on this. - “New Product with a new business model”: This is where execution stops and entrepreneurship begins and things get interesting.
Missing this point is really easy and if not done right, it will result with applying wrong methods, tools and processes which usually doesn’t end well like my experience above.
Lesson learned: Make sure you build the right thing, before building it right.
So, make sure you identify to which category your product belongs and plan accordingly.
I’m not much of an expert for the first 2 categories, but may have some hints about how different the 3rd one is and “why”. Let’s tackle this in the next post.
Cheers!
Burak
