Challenge: Micro ISV Mistake #1

As the distinguished gentleman Gavin pointed out yesterday in Micro ISV Mistake #1 (you might want to read that first), he believes that it's a bad idea "thinking your idea needs to be kept secret". Initially I was fully supportive of this concept - I'm doing it myself - but then I got to thinking about it more as I followed some of the comments.

Ben, Duane, and Chas all pointed out simple scenarios when the oppsite applied. They boiled down to variations of: Prior to your alpha, keep your mouth shut. And I think they're correct.

Everyone knows that execution is everything and that an idea in itself doesn't have much value. This is why patents in the US require a design that *should* work. The concept of the Space Elevator has been around for a century, but only in recent years is it beginning to look feasible. The concepts of human flight, tanks, etc go all the way back to Leonardo Davinci, but it's only been in the last century that these concepts have taken form.

When an idea is embryonic without implemenation, design, or even a fleshed out concept, I believe that it makes perfect sense to keep your mouth shut. Putting your idea out there will give you some early feedback, but it also begins to level the playing field.

In this sort of scenario, I would start discussing my ideas publicly if I had one or more of the following:

  • Personal knowledge, involvement, or connections which would be difficult for another to gain quickly (read: weeks or months).
  • Resources to devote fully and completely to the task very soon.
  • Support and/or endorsement from a large player in my target market or industry (read: if Steve Jobs, Bill Gates, the Pragmatic Programmers, Tim O'Reilly, etc endorsed me, my company, my product, or my idea, I'd make *sure* that you read about it).
  • If being an early mover was huge factor in success, I'd start talking soon and loud.

On the other hand, some things that would make me stay a bit quieter:

  • If I don't have anything besides an idea. Without an execution plan, there's not much value and it would be easier to be duplicated.
  • If all of the pieces or concepts were available and my idea was a new way of putting them together. This might lend itself to fast duplication... which may make it a weak idea anyway.
  • If my idea, code, business was wholely dependent on using information or API's from another group such as Amazon, Google, etc. Asking forgiveness...

Just some food for thought.

Almost

That's a good summary of the strategic side of it, but it seems to assume that the idea is always unique. If it is a truly great unique business proposition, i.e. not just a better execution of an existing idea, and not just unique because no-one else is crazy enough to do it, then I think it has to be treated as a special case.

I'm sure many Micro ISV's ply their trades in markets which are already populated, or in niches which are too small to serve a major corporation, yet still keep their products to themselves until launch. Even in those cases I agree with the three things that would make you stay a bit quieter, but not entirely with the general "Prior to your alpha, keep your mouth shut" statement.

If anything, I think I would change the line in my article which states "as soon as you know what your product is going to be" to something which more clearly defines the moment when you have identified your product and committed yourself to the project. I would also have tried to put a greater emphasis on choosing an appropriate level of disclosure at appropriate times.

I think that's the key

I would also have tried to put a greater emphasis on choosing an appropriate level of disclosure at appropriate times.

I think this is the key. When the extent of your product is a series of pretty drawings on Subway napkins and a sketch on the whiteboard, your disclosure should be pretty tightly controlled to select people.

As you start getting resources in place, it may be time to start talking about overall concepts.

Once you have people in place and are starting to build the overall architecture, schemas, data structures, etc, talking about features might be a good idea.

Once you're into the alpha stages, it's probably time to talk about the *specific* details of the product along with showing screenshots. This is when you need to get people talking and convince them to open their wallets.

Actually that's the opposite stance

I completely disagree (hey we've got a good discussion going here :). It is especially before the alpha that it is good to discuss the idea as widely as possible. Picture the young inexperienced but passionate software enthusiast coming up with an idea that he thinks is so revolutionary and exciting that it is burning a hole in his brain. If he keeps it only among his closest friends, this idea will likely suffer from myopia. We're dealing with the need to hone your idea to the target market -- again I find the notion that your idea is going to be stolen at this stage is very naive and detrimental (in fact, it is fueled by narcisism). It is only much later after the alpha that you might be getting into issues of negotiation or marketing strategy that you need to become much more careful and possibly secretive. Some people mistakenly think they are going to copyright or patent their idea when it gets to alpha. If you are a MicroISV you won't have the resources to try and protect your patent anyway, although keeping your name a secret until you've obtained the domain (and possibly registered your trademark) is important of course.

Varying definitions

I completely agree with you that "the notion that your idea is going to be stolen at this stage is very naive and detrimental", but some of the arguments for occassions when you should keep quiet have also been persuasive. However, I feel like there are different concepts of a Micro ISV. Many of the arguments against being public seem like they would be more appropriate to the old dot com startup business model, whereas your arguments for it (and my original post) focus on the idea of a passionate developer on a shoe-string budget.