Where Start-up Companies come from

Start-up companies arise because the founders have an idea on how to improve on an existing way of doing things or fill a void.  The best invention is one that completely disrupts the industry and changes it forever.  A great example is the invention of the light bulb.   The light bulb completely disrupted all the other competitors that were focusing on how to build better candles that burned brighter and longer and very quickly the candle industry was decimated.   Sometimes the inventions can just be a better delivery system.  Amazon, for example, started out selling books, but you could get any book you wanted faster and cheaper than from existing brick and mortar bookstores.

While it can be easy to identify a missing need or a better way to do something, execution – delivering that solution to the market and making money at it, is often no so easy.  I have worked with dozens of start-ups over my career and the ones that end up being successful possess a few “must have” characteristics; a team of qualified accomplished founders, capital, a focused vision and a good understanding of how they can monetize their idea in the marketplace.  There are millions of ideas every day that are great ideas, but without a team to build it, fund it and distribute it, those ideas typically won’t go anywhere.

Software Start-ups

When it comes to a software invention there needs to be laser focus and dedication to the vision.  It is too easy to veer from the vision, or have a vision that is too broad.  I remember in 1989 sitting in a board room with a start-up company that had a unique approach to develop a graphical chip that was smaller and more efficient than anything else currently in the market.  I listened while they described the 6 different types of chips they were building to address the various applications, yet none of them were close to release.  Before we left that board room we were all in an agreement to focus on one single chip, get that done and get it to market and put all the others on hold.  That was successful and that company became one of the largest supplies of graphical chips in the world.

While chips are considered hardware, software projects and ideas can more easily get off track.  As the software is being developed, it is very easy at each weekly update meeting to revisit the feature set and adjust the release dates to the point where the product may never get release.  You must avoid this at all cost.  Ask yourself if it is better to get a product to market that you feel has all the features you think the market wants or get out a product with a fraction of the features – then receive true feedback from your users and build another release that has what the customers actually want.  Not what you think they want.

Defining your Software Product Feature Set

If you want to release a scaled down version of your product, you have to establish what your definition of your Minimally Viable Product (MVP).  The MVP is the minimum feature set that must be included in this first release.  For example, if you are building a mobile app think about whether you need to have integration with some of the native mobile features in the first release.  Is the camera integration a key component to the first release or a “nice to have?”  Is the geolocation services functionality required for this first release?  This all depends on what your application is.  If you are building a social media app you probably want the camera integration in your first release but not the geolocation services.  Be specific.  Be rigid.  And be committed to defining your MVP, establishing a timeline and sticking to it.

Should we build a Prototype?

Now that you have defined your MVP, decide how you want to build it.   Do you want to build a working prototype first to prove the concept or do you want to build it out in the ultimate platform?  What is the difference?  You may have a goal to have your application run on the ultimate platform and have 1 million hits per day on your application and have it hosted in the cloud (e.g., Amazon Web Services) with redundant backups, etc.  This is great, but at what cost?  To handle that much traffic you need redundant servers, clustered SQL databases, etc.  This can get very expensive just to build this, and before you have one customer, or before you actually prove to your investors that someone actually will pay for this service.

A prototype is another option.  A prototype can usually be built for about one tenth the cost of the ultimate platform solution and in one fifth the amount of time.  The prototype can have all the features as defined in the MVP, except it will have limitations.  Maybe it can only handle 5,000 users and it is not running on the “Gold standard” as defined for the ultimate platform.

The Benefits of Building a Prototype

The benefits of the prototype approach should be obvious.  It allows you to get a product out in the market quickly and at a substantially lower cost than waiting the 6 months to a year to get the product built and out using the ultimate platform solution.  If time and money are not an issue to you, then you don’t need to consider building a prototype.  The prototype also allows you to get the product into the hands of some targeted users, to allow them to give you valuable feedback.  This feedback can be used to tweak your vision or maybe even identify an entire new direction that you never thought about.  During this time you can also tweak your prototype and continue to get more information and feedback from your users.

The Drawbacks Associated with Building a Prototype

Most prototypes are built using technology that allows for rapid application development (RAD) sometimes using existing frameworks or shared hosting provider applications.  While this is a great way to get your product built quickly and cost effectively, it may not be able to handle the millions of users you aspire to.  This means that any costs associated with building the prototype are throw away costs.  If you build a prototype, get some paying customers and they like it, you then have to start to build the solution from scratch on the ultimate platform, essentially duplicating those costs.  Therein lies the challenge.  For example, should you spend $25,000 now to build a MVP prototype to have it ready in 2-3 months, OR do you spend the $250,000 to build a MVP on the ultimate platform, acknowledging that it make take 6 or more months and you will probably not get any valuable feedback for almost a year?

Some clients have chosen to build the ultimate platform first and then after it is done, they actually discover that the void in the market was different from what they initially thought and built and then had to throw away the development to date.  Ouch.  If they used the prototype first they would have saved a bunch of cash and found out a lot earlier that they needed to shift their focus.  Other clients that have built a prototype have learned to adapt their focus very early in the process.  One Company modified their product definition within 3 months from the start, whereas if they choose to build it out in the ultimate platform, today they would still not have users and may not have any idea that a shift is coming.

Whatever you are building there is always at least two ways to do it.  I recommend choosing the lower cost solution first to get to market faster and get feedback so you can make any midcourse revisions if you need to.

Skip to toolbar