7 Reasons Why Most Products Fail

Over the last 30 years, I’ve helped launch over 60 products across nearly as many companies, from small startups to Fortune 100. While every project is unique, there are universal truths that can make or break a project of any size.

I am sure my comments will blow up with dozens of things I am not including, these are the ones I see over and over again.

1) Do one thing well.
Most products start with a great idea. Great ideas tend to spark other ideas which spark even more. Before you know it, your original idea has become a blazing inferno. Your simple product now has more bells and whistles than the Salvation Army at Christmas.

The biggest mistake I see is companies trying to build their final idea for the product rather than their initial idea.

Building and launching a complex product is a surefire recipe for failure.

The term MVP (minimum viable product) is often thrown around, but a successful team will break the product down to the single most-essential feature and start there.

Jeff Bezos had the vision for Amazon to sell every product online. But he started with books.

Instagram started with just posting a single photo with professional-grade filters. There were no carousels or stories or messages or reels.

The best products can be explained simply, ideally as “the ___ for ___”, e.g. “The Netflix for books” or “the Uber for food delivery”.

If your MVP has more than one feature or module, you are far more likely to fail.

2) Fail fast.
Start with a small proof-of-concept. Launch. Get people using it. Don’t worry about how you will monetize it. Just make sure it works and, more importantly, that people want to use it.

Do you really have product-market fit?

Have you proven that your solution is the solution that the market wants?

3) Is this what your customers want?
Related to the point above, sometimes entrepreneurs see a valuable problem, but the solution they devise is not the best solution or not what their potential customers want.

Build with your customers, not just for your customers.

Involve them in the development of the product. Have them test early POCs or even run through prototypes with them.

Get as much feedback as you can.

But don’t react to every critique. Just listen. Digest. And compose. And then respond.

4) You get what you pay for.
While the main job of an entrepreneur when they are first launching a product is to spend as little money as possible, I regularly see companies needlessly over-spending in some areas and being foolishly cheap in others.

So where should you spend? First, don’t dismiss spending some money on research — early market research and then some UX research can save you countless months of building the wrong product or heading in the wrong direction. I’d dedicate at least 10% of my budget to this.

Once you have the right direction, spend nearly equally on engineering and sales and marketing.

I frequently see teams raising money to build the product, but during the months the product is being built, they spend little to no time and money on developing a go-to-market strategy, marketing plan, and training a sales team. If you’ve proven your concept, you should consider marketing and selling before you build — get some customers committed before you spend too much on building.

And don’t skimp on engineering. More often than not, projects pass hands from one team to another before they finish. This is costly. And usually caused by one of two things — either the company tried to cut corners and hired a team that wasn’t capable of delivering, or they failed to…

5) Clearly define the scope and requirements.
Imagine asking a chef to make you dinner. They vanish and come back two hours later with an incredible 5-course surf and turf dinner for 4. But you’re a vegetarian. And you are eating alone. Who’s fault is this?

You failed to clearly define what you wanted.

Should the chef have asked more questions? You bet.

But until you have all of the details flushed out, don’t ask someone to start cooking.

Figure out exactly what you want and then hire the engineering and product team to build that.

Or, better yet, hire the right team to start and let them help you figure it out.

A top chef will be able to devise a much better vegetarian meal for you than you can imagine alone. So engage you engineers or team to help you define what to build. And keep it stupid simple (see point #1).

6) Too much of a good thing can be bad.
I nearly made this two separate points, but that goes agains what I am preaching here.

The right balance needs to be found in both communication and management.

Constantly asking the team for progress updates and micromanaging the team will not get a product built faster any more than shouting at a pot of water will make it boil faster.

Good communication is essential — the stakeholders should be brought in on decisions that will affect the final product — and this avoids surprises down the road and reduces the risk of the team delivering something the stakeholders didn’t expect.

But too much communication zaps productivity.

Let engineers code and do their work. Every time they need to stop and answer a question or give a status update or estimate how long something will take not only takes away from their work, but the task-switching costs time and only adds to frustration.

A weekly update is reasonable. A daily update is not.

Likewise, too many meetings can lead to worse communication. Imagine if John needs to meet with Susie to discuss what Chris said to Steve. Now 4 people are having 3 different conversations about the same topic. Take those 3 meetings and turn them into 1 meeting with all 4 parties. Forget aligning the team before a meeting — align AT the meeting so others can take part in the debate or discussion.

And the same goes for management. Waterfall and micromanagement died at the turn of the century and Agile systems prevailed. But while Agile and Scrum (a system to incorporate Agile principals into your company) proclaim to be “non-prescriptive” and merely “guidelines”, many companies have taken Agile to newer levels and the Agile process has become its own thing to manage at many companies.

I’ve seen many growing companies collapse as they make their Agile processes more and more prescriptive. Engineers leave. And productivity tanks.

Keep Agile systems loose and let them evolve with each team.

7) The right leader for a company depends on the size.
The CEO that built a company might not be the right one to grow the company. I’ve lead many companies from 0 to 1 (meaning starting from nothing to having a profitable product) and helped grow companies from 1 to 10 (roughly $1M revenue to 10x), but I would not be the right person to run and grow a $1B company.

Similarly, just because a CEO once grew a company from $100M revenue to $1B revenue, they would probably not be the best person to launch a new product (0 to 1).

In Summary
The ideas above are not radical. Most people that have launched dozens of products preach the same (or similar) ideas.

And most entrepreneurs know these truths. But they swear their product is different.