X, The Innovator's Software Dilemma

You have a great business idea.  There is a huge unmet demand for your product and you have the expertise and perhaps even the money to get it started.  You have planned out the prototyping process, and you have great ideas on how to enter the market and how to scale it.  You have taken care of the web site, the social marketing, blogs, and maybe even a developed an iPhone App.  However, there is this one software or web piece just needs to do ‘X.’

X may be, initially at least, something as innocuous-seeming as a mobile app that grabs a user's GPS location and stores it on a server so that you can perform business function 'A.'  Or perhaps it is a combination of similarly simple steps that have been lumped together into the requirements for a software application.

So you call several software consulting companies, get quotes, weigh the options carefully, and select the best group.  It’s a little more than you wanted to spend, but the company you picked has smart people with impressive resumes who touts a litany of similar, completed projects.  With this piece out of the way, you are ready to refocus on the core components of your new venture.  All in all, you are cautiously optimistic about your decision.

Hang on to that feeling.  It doesn’t last long. 

For the dozens of tech-related start-up companies that I have worked with both as a software architect and a private equity investor over the past 14 years, this approach is by far the most common.  I have done it many times myself. 

The problem is that it usually fails for innovative concepts.  Sometimes it brings a new company down with it.  As with mercury poisoning, it usually takes a while and, ironically I might add, it has a similar psychological effect.  There is a very obvious reason for this... in hindsight.  Many of these decision makers are truly brilliant, thoughtful people, and this approach for acquiring software does seem to be the most rational.  And it is, for many things.  But novel, innovative software solutions is not one of them. 

The simple reason is that your unique piece of software that does X is not a commodity or product, by definition.  So not only is it harder to define and communicate than you may think but also it cannot be shopped.  In other words, the marketplace has not produced a group of competitors who produce X (as a product, custom-built or customizable solution), who all pretty much agree on the defined problem, and with whom you can comparison shop.  The dilemma is that, if X were a commodity, this approach to requisitioning your software piece would probably work.  However, all it would be for you at that point is another cost of doing business.  So you wouldn't be very interested in it.

Further, it is because of this novelty and lack of market definition that X is almost certainly tied to the core strategic value of your company despite it’s apparent cog-like appearance.  So you really do not want to treat it like a product either.

If you like reading about other people's misery, you can see an example of all this in my case study on a start-up company to which our small group allocated $3.75MM in start-up capital.  I won't bore you with the details (here, I do that somewhere else).

Anyway.  Yada, yada, yada, this (previously cash-flowing) company went bust and the partners lost millions.  Trust me, Seinfeld fans, I did NOT yada yada the best part.  

Instead, I will save you a continuous stream of morning headaches by providing a list of problems that I have experienced in one capacity or another. As an aside, DC7, of course, provides a definitive solution to each of these.

In no particular order...

Inherent and Often Unintentional Problems With Software Consulting Companies

Charging to build custom solutions that already exist and are often free or very inexpensive

A non-prioritized development approach.  Agile is a wonderful methodology, but it does not deal directly with the inherent problem of getting prioritized business risks in sync with development work flow.  Most business people and software people know very little about each other.

Undefined software cycle release schedule.

Reusing and reselling your source code or parts of it

Paying for someone else’s solution through overlapping or similar assignments

Language & Communication Barriers

The platform and architecture makes no sense for your business or it uses technologies that will force you to totally redevelop the application later.

Little foresight into strategic reasons for architectural decisions for your company.  Nearsighted, with a focus on technical solutions known to that particular team.  Software developers like to design software and write code-- they are just not that interested in the business risks associated with, say, a custom-built solution over an emerging product category.

More Pernicious Problems With Software Consulting Companies

- Vendor Lock In: Slippery 'Deliverables' contracts which allow the company to provide, for example, only the source code or executable (not the development and server environments and configuation, documentation, etc).  Basically, this locks you in to that company.

- Theft of your idea.* 

- Theft, reuse, and reselling of your source code or parts of it.  (especially overseas)*

- Theft of your data*

- Unenforceable legal agreements with team members overseas leading to flagrant violation of contract

* These are by no means uncommon.  Plagiarism is fully ingrained in some cultures and is sometimes even expected as a cost of doing business.