This product is great…for someone else.

The kiss of death.

Entrepreneurs are constantly testing out their messaging.  They are constantly pitching to their family and friends, and they are always prepared to pitch to investors.

An entrepreneur’s pitch usually starts out with the problem in the marketplace, describes a ginormous total addressable market, then says how they are going to solve this problem and be a huge success.

One of the most deadly responses an entrepreneur can hear is some version of “that is a great product – for someone else.”

Remnants of a failed startup.

Several years ago, I had the ‘opportunity’ to join a startup company. The company’s premise was about instrumenting software code and reporting statistics about it.

Essentially, our software would “watch” someone else’s code and identify places where the performance could be improved.  We identified bottlenecks that slowed down the code, generated reports detailing the problems in the code and the severity of the problems.

Our goal was to make programmers much more efficient and help then create much better software.  Everybody wants the best software, right?

We did all the right things.  We attended meetups for programmers, gave out t-shirts with our logo, sponsored three-day events for hackers, and did everything we knew to get the word out.

The response: crickets.

Our one subscriber. Yes, only one subscriber.

We had a product in the market for nearly a year, did every trick in the book to get people to use it, and we – literally – had one subscriber.  One subscriber at $29 for a whole year’s worth of marketing.

The subscriber bought a subscription over a weekend.

One weird thing about the subscriber: we tried and tried to contact them to get their feedback, and they never would respond.

Throughout our journey as a startup, we would constantly hear great news: our value proposition was fantastic!  It would be great to find all the bottlenecks in our software!  Look at that great performance increase after running your diagnostics!  We thought we were onto something.

There was something missing, however, in all the feedback we got.

Here’s the killer…

Everybody thought it would be a great tool and could see how it was useful.  But they thought it would be great for someone else.  Nobody wanted to buy it for themselves.

We talked about this sales problem internally quite a bit.

Who really wants to know if their code is bad?  Not the programmer.  They know there are plenty of skeletons in the closet, and they do not need to be reminded of them.  In fact, they would be embarrassed and ashamed that their code was not perfectly optimized.

Does the programmer’s manager want to know where all the bottlenecks are?  Maybe.  On one hand, the manager needs to know what needs to be fixed so they can deploy resources.

But on the other hand, what happens when the manager runs our diagnostic code and they have documented evidence that their department was worse than their rival manager in a different department?  How does that play out in the mid-level management staff meeting?  Who will get the next promotion when there is documented evidence that their group is under performing?

Maybe there was a scenario where someone working over the weekend to meet a tight deadline is under the gun to finish their project.  If they are at wit’s end and really need some help, maybe, just maybe, they will break down and try our product to see where their code is broken.

The product made the customer feel bad.

The fundamental problem was that our product made our customer feel bad.  Worse yet, it showed in glorious detail how incompetent our customer was.  It showed them where they screwed up and what they need to re-do.  Our product always delivered bad news.

Countless people heard our pitch and immediately agreed that this was great technology and provided a very meaningful and important service.  Without fail, each person said “that’s a great idea” but left off the “for someone else.”

We talked about running our diagnostic code on the endless open-source software in GitHub.  We could generate scores for the best and worst open-source code out there.  We would have a “wall of shame” for the bad coders, and a “wall of fame” for those programmers whose code did well in our analysis.

As much as that publicity stunt would have generated a lot of talk, I did not like it because we were essentially embarrassing people unnecessarily.  Our product would become criticized by anyone whose score was not perfect (meaning: everyone), and we would have an even worse reputation.  Thankfully, we never implemented this idea.

The most telling sign of all…

The most telling sign of all: one key person, who did much of our coding, never once ran our software on his own code.

This person was afraid of finding out that his code was not very good.  Although he boasted of his incredible computer programming skills, he did not want to find out if that was true.

Of the countless lessons I learned at this startup, the biggest one was misaligned interests.

On one hand, our customers all wanted to create the best code.  On the other hand, they did not *really* want to know if their code could be better.  The fear of looking bad to themselves, to their coworkers, to their managers, was far, far more powerful than any altruistic desire to write the best software.

What was the result?  The company somehow blew through three million dollars, even though nobody was taking a salary.  On my end, I had written 100 patent applications in two years.  The company was recapitalized, and I got a 10:1 cramdown for my two years of free service.  The patents were sold for *less than the filing fees* to raise a bit of capital and make the claim of being a “profitable” startup, and the company was rebranded and refocused in a new direction. After several ‘rebrandings,’ the company has ceased operations entirely.

Many “good ideas” sound very plausible and super useful.  But anytime someone says they think it is a good idea, not for them, but for someone else – the idea has problems.