Some observations on Startups / Angels Funded Company

In the last 2 years, I have been involved as a consultant with 4 startups – some for direct cash, some for equity. In the DotCom boom days, I interviewed around to literally dozens of startup, declined offers from several of them, and ended working for one Startup doing corporate software which eventually folded 18 months after 9/11 because corporate IT Budgets were still severely constrained. When it folded, I checked back on the status of all of the other start-ups that I interviewed with and all of them had already failed except for one. The reason that I declined offers from other startups were because I evaluated the odds of their success to be very low. The typical issues were:

• Service Company trying to become a product company: product development mentality and contracting/consulting mentality are opposites. What you seek in employees in one is what you do not want in the other.
• Yet Another Monkey-See Monkey-Do: The product they were trying to create was imitating other products. They had no IP (i.e. patents to protect their market impact). This is the “Starbucks, Seattle Best” imitation syndrome. 
• You can be successful with a coffee-shop chain – locally we have two thriving chains: The Woods Coffee (9 shops) and Cruisin Coffee (13 shops) with many outlets in two counties only.
• Imitation with variation can work if you have an appropriate niche strategy to separate you from the big ones:
• Cruisin Coffee has 24hr drive thrus
• Woods Coffee has atmosphere and targeted towards the local culture (University Students, Whatcomites – which has a very strong “buy local” movement).

The recent startups that I’ve been involved with had Patents and in some cases, needed several Ph.D.’s in numeric methods to write the code. They were viable which simply means that the odds of them succeeding was likely over 20%. The interesting thing that I observed was that the greatest threat was organization issues. Some examples:

• CEO and Sales disconnected from development reality. Some examples:
• Promising things that development was unable to deliver on schedule.
• A good dev shop should make deliverables 90% by the original date. Failure to deliver usually means a  breakdown in communications (or ability to understand the issues involved) somewhere between management levels.
• I still remember one case where the CEO was fired by the board and while the CEO was still on the floor, the entire staff broke out to cheers and pounding on the desk in joy.  Both sides were frustrated, the CEO because dev did not deliver; the devs because they were expected to do the impossible.
• Product was done with quick-to-market, no analysis under the disguise of AGILE or other in vogue terms. The result was that after 2 years of business they were struggling with inflexible code written in a needlessly complex manner. Effectively AGILE has become a spaghetti factory. Release cycles had become so short that no refactoring-as-needed happened (an essential for Agile to be successful), instead, a new layer of code was widget on top of the older code to make delivers.
• Often advocating analysis before development will be attacked as trying to force Waterfall on the project. This is both bogus and may reflect a preference to avoid accountability. A good analysis done by a product manager in not waterfall and essential for planning and creating a schedule that people can be held accountable to…
• Picking key players with disjoint technology skill stacks. This can arise especially when a non-technologist (or academic) is the founder. There are a few folks around that are respectful and plays well with others, but in general these are rare. If you hire two senior development types: one from the C#/SQL Server world and one from the PHP/MySQL world, you are setting up a situation of constant conflicts unless there are clear boundaries. For example, the following could be viable
• Database: SQL Server
• Web Site: PHP
• JSON, SOAP, WCF Interface: C#
• Android/Blackberry Development: Java
• Mobile Phone: C#
• BUT it may depend on whether PHP developers will freely accept SQL (instead of MySQL) as the back end; if not, you are creating an in-fighting and complaining scenario.

Often I’ve heard the excuse “we can’t afford to do A,B,C”. The reality is that it is actually cheaper to do A,B,C – the problem is usually “the discipline to do A,B,C. Doing this is either a ‘bummer’ or they do not know how to go about it (knowledge gap)”.

 

It’s interesting to note the recent Ig Nobel prizes which found “"the best ways for improving the efficiency of a given organization are either to promote each time a random agent, or to promote randomly the best and worst members" .. Speaking of which, Sales forces are often referred to a slime by some developers – we now know “slime moulds can find the fastest path through a maze to find food”, so there may be some truth in the use of the term ;-)