In Depth App-to-Market: The Business of Risk

Description: Your life isn't like the movies. In the real world even the best ideas can fail spectacularly if the risks aren't managed. It's time we talk about risk and what it can mean for success or failure of your app.  

Remember that scene in Risky Business where Tom Cruise stays upright as he slides across the floor in socks and tighty-whities, lip-syncing Bob Seger? In the alternative universe, sometimes he slips and falls. Some startups will slide through and succeed, and others might just land with a thud. That's real life.

Whether you're a developer taking your first step or a seasoned veteran of dozens of startups: Taking your idea from app to market is risky business. That's the subject of this ongoing series: How technologists take on risk in their startups and how risk affects your business.

What is Risk?

Risk is a term that gets thrown around a lot, but what does this mean?  The general definition of risk is the potential to lose something that has value, or to have a decrease in the value of something. 

Discussions of risk tend to be very subjective.  What is risk to one person, might not be considered risk to someone else.  I have also seen risk defined as anything associated with an unknown – it was a popular way of defining it when I worked at The Coca-Cola Company in Atlanta.  In fact, TCCC would pay extra just to remove risk.  I saw many things that were about the elimination of any risk no matter how small.“It’s not real money, it’s Coca-Cola money, so we should do this," is how my boss there would justify it. "It eliminates risk.” 

That's the thing: Completely eliminating risk can be very expensive. If you are at a large company and have money that is not yours, that may be okay.  But most startups don't have the resources of a large company like TCCC, and we definitely don’t have the money to completely eliminate risk. There is typically a tradeoff with risk of money and/or value. Taking the appropriate risks can result in the creation of value or at least some type of savings.  Startups can easily create value, as well as cost saving, by knowing when to take risks.  Let’s look at several types of risk that are commonly found in startups/business.

Angels and Venture Capitalists

The world of angels and VCs tends to be filled with risk.  Look at most of the financial news and you'll see lots of angels and VCs  making a lot of investments, but very few get reported on as being successes.  Why would anyone want to get into that world?  It just makes no sense.  However, by managing that risk, success can be found.  Let’s look at these investments by the numbers:

Let’s start with the assumption that the angel/VC is not a fool and does not just throw their money away in bad investments.  Assume that the angel/VC can get a 10 percent success rate.  Ten percent of the investments rest in a successful company, and 10 percent of their investments will lead to a successful exit.  That means that a single investment is unsuccessful 90 percent of the time.

To keep the numbers simple, let’s assume that the angel/VC makes 10 investments.  This means that .90¹⁰ is the probability of complete failure.  This equates to roughly 34.8 percent, and so this means that there is a roughly 35 percent chance that nothing will be successful.  This is a worst-case scenario.  And guess what? It is a bit worse than it appears.  For a technology startup, the results are typically either win big or get nothing.  Any software that is written is not typically salvageable.  This is different from something like a real estate investment where if the investment does not work out, there is typically some land or a building that can be worked with. 

From a mathematical standpoint, the surest way to success is to continually invest in companies.  Each investment will knock down the probability of total failure.  This goes along with the view in the investing world that the surest way to success is deal flow.  The more investments that an angel/VC makes, the higher the probability there will be some number of paybacks.  Increasing the number of their investments reduces their risk and tends to increase their income.  From the standpoint of math, this makes sense.  When it is your money, it is a different scenario, and you can be a bit gun shy to continually toss money into what looks to be a losing set of investments.

Let’s assume that an angel/VC is making 10 investments of $50,000 each.  This means that there has been a total investment of $500,000.

Investments tend to have a return distribution where one out of 10 is a great return.  A great return for an early-stage investment would be something like a 40x return.  A couple of them are good investments that return three times the investment, and the rest are dogs that return nothing, like this:

$50k x 40 = $2 million return

$50k x 3 x 2 = $300k return

A total return of $2.3 million

The numbers can change depending on the situation.  For example, if there is only a one-in-20 chance of making a great return, then the projected return would be $1.3 million.

In looking at the numbers, the only thing that really matters are the big winners.  The small wins just don’t matter that much.  This is the reason why angels/VCs chase what are called "unicorns."  The big returns (unicorns) make an investment fund work.  This is one of the counterintuitive things about investments.  Good wins, where you return 2x, don’t tend to matter.  For the VC system to work, you have to have big wins.

Over the course of a VC fund, it is looking to make multiple investments in a company  If a series A was made by a fund on day 1, then several years later, it is looking to make a follow on investment.  If a VC doesn’t make a follow on investment, that tends to look bad to other potential investors.  The VC will need to keep some money in the fund for those follow on investments.

So, let’s analyze this series of investments.  These returns sound great until the time value of money is factored into this.  With the time value of money, a dollar today tends to be worth less than a dollar tomorrow.  This is due to inflation and the fact that there are other investments out there. 

Angels and early stage VCs tend to have a long time from investment to a return.  As of late 2015, the time frame for a payback can be as much as 8-to-10 years.  Assuming that there is an average 10-year timeframe to get money back, it depends on the options if this is a good investment or not.  Assuming a 7 percent return in a relatively safe investment vehicle, an investment of $500,000 would become $983,000 over the same timeframe.  The investment roughly doubles, the money is much more available, and the investment tends to be safer. 

If there is a big winner out there, an angel/VC can be a big winner.  If there are no big home runs in the investment portfolio, the fund will be a loser.  Remember at the beginning, there is a 35 percent chance of having no return in a series of ten investments. 

So, which makes more sense for an investor?  High tech investors will understand these probabilities.  However, I have watched investors -- who did not understand technology investments -- put $25 million into technology investments and come out with nothing. I wish I had gotten in on receiving that money.  The investors wish that they had made other investments now in the aftermath.  I’ve also watched others make this work, because they understood the risk and how to manage it. 

A word of warning: Just because someone dresses nice and is in a pseudo-government position, it does not mean that they understand technology investments.  But let's move on…

How can you work better knowing this?  The key to you and your startup is to show the angel/VC community that you can be the next big winner for their investment.

Software Choices – Technology Risk

While technology choices don’t matter a lot to the success of a startup, there are some choices that do matter.  One of the goals in a startup should be to eliminate as much technology risk as possible.  What is technology risk?  Tech risk is often thought to be any type of risk associated with the technology.  This could be one of several issues including:

·       The technology does not get supported long term.  An example of this is Silverlight in the area of cross platform software web development.  Silverlight looked really great in 2007 in all the demoes that were done showing off cross platform development.  Unfortunately, the technology landscape changed with mobile (iPhone and Android).  With no ability to get on mobile devices, the technology languished and finally died by 2012.

·       Developers that want to look cool by doing something different.  It may seem that it is “micro management” to define the libraries that are allowed to be used.  Unfortunately, developers tend to think of solving problems now, and don’t necessarily look at the tools that will be there long term.  For example, I was working for a startup once.  We needed to do some HTML dom manipulation.  Even in 2007/8, it was clear that jQuery was the solution for this.  No, somebody else wanted to use a library called Scriptaculous.  Why?  Because jQuery was too popular.  A little bit of thought and it was obvious that Scriptaculous was a loser and that jQuery was going to win.

·       Just adding libraries -- with, at best, questionable benefits -- to a project because it is cool or innovative is not acceptable. One can easily find the various code repositories rife with cutting edge or nifty open source libraries that have been abandoned or not updated in the last 5 to 8 years.  So, just because a library saves developers a couple of lines of code doesn’t mean that that library should be added to your project. When you add a library, choose the most popular one, not the fourth-most popular one.  The key in such a scenario is not to add libraries because you want to explore a library; instead, use more common libraries with lots of community support and momentum in the marketplace.  Even then, common libraries can still be dangerous if support for them stops -- I’ve seen that happen, too. And then what happens when you need to upgrade libraries? So, use as few external libraries as possible and when you must go outside of what is provided “in the box” be very careful with your choices. 

·       I often see code written that tries to take advantage of some new or little known feature of a language/platform.  Unfortunately, trying to be clever often leads to more problems than it solves.  While the person who wrote the code will think that it is great and is obvious to everyone else, the reality is often quite different.  If you have your startup poised to launch with some code written using some unknown feature of a framework, what happens when someone else has to take over that code?  Is it going to be clear to them?  Code should be written with a thought that someone else needs to come behind you to make it work, fix a bug, add a feature, or something else.  Code not written with this in mind may see delayed bug fixes, delayed features, or a need for a possible rewrite depending on the nature of what was originally done.   Bottom line: Your code needs to be as simple as possible to solve a problem.

I know it now sounds like I have said that you should not do anything new, try any new library, or do anything besides use what comes in some software installation package. But that's not what I'm implying at all.  If something is needed, then clearly use it.  However, you must understand the choices that you make. It all comes back to risk.

·       How do you minimize/eliminate Technology Risk?  There is always risk out there with everything.  However, the keys to minimizing Technology Risk are:Build your Minimum Viable Product.

·       Add features to your MVP.

·       Be careful with the technology choices that you make.

·       Iterate, iterate, iterate.

·       Keep talking to users.

What About New Choices?

New choices are an interesting thing.  They don’t have track records.  They are by definition new, do not have a community behind them, and do not have any type of track record of success.  How is a developer going to determine what the best mechanism to go forward is?  I’d like to share my views on what I chose to do with two products that came out within a year of each other with the idea that this might help you in choosing what to do in a situation going forward.  Hopefully looking at the decisions that were made will help you make the right decisions and reduce risk in the future for you:

·       Silverlight.  One of the problems of cross-platform libraries is that they have to provide native device features.  Users expect that applications built with a tool will take advantage of all of the features of that platform.  For Silverlight to be successful, it had to have full platform support in various operating systems, including Windows, Mac, and the up and coming mobile platforms of the iPhone and Android. 
My concerns on Silverlight were that it did not seem to have the ability to reach beyond the Microsoft community.  Apple was already making noise that browser plugins were not going to happen in their war on Flash.  How would Silverlight be any different?  Silverlight lacked support from platform vendors outside of Microsoft.  Neither Apple nor Google were going to be involved. Silverlight also presented a non-native UI when it ran outside of the browser.  For these reasons, I did not invest a lot of my time in it beyond customer requests.  That was a good non-investment and blind luck for me.

·       Xamarin.iOS/Monotouch.  While Xamarin.iOS’ success today is obvious, it was not necessarily obvious in 2009 under the wing of Novell.  It was clear that I could write native apps that looked, smelled, and tasted just like every other iOS app back then.  These apps were downloaded by users from the Apple iOS App Store just like every other app.  These apps used what are called native APIs.  A UITableViewController in ObjectiveC looked, smelled, and tasted just like a UITableViewController in Xamarin.  The only difference is that between a developer’s code and the underlying UITableViewController is a C# callable layer and somewhere in there is the Mono/.NET Framework.  The key is that for the users there was no visible difference between an application written with Xamarin.iOS and an application written in ObjectiveC/Swift.  From a user standpoint, there is no difference.  For the users, there was no user risk. 
For the developer, there was a certain degree of risk.  Apple could disallow apps not written in their tools which might have happened due to a one time misunderstanding in the language in Apple’s developer SDK.  Something could happen to Novell, which did happen but got cleaned up.  Any of these issues could have required a developer/company to rewrite the app and to lose some amount of money/value due to this rewrite.  Thankfully, all’s well that ends well.  Xamarin has been going well for the last 4+ years out on its own growing and becoming a better tool each and every day.  Finally in early 2016, Microsoft purchased Xamarin.  This definitely eliminates risk.
What’s the advantage to taking on this risk of using Xamarin?  There are several.  You don’t have to learn a new language or IDE.  This saves significant time.  For me personally, this was months saved in the learning process.  There is no need to switch between languages, which also saves time when development is happening.  With the advent of Xamarin.Android, I can now design my application for iOS, properly segment it, and be on my way to already having an Android application and vice versa.  This was a good (and lucky) choice that I made, and it has resulted in payback.
Note:  I’m not trying to say that I am clairvoyant or brilliant.  I’m just going back through two major decisions I went through in the 2008 – 2011 timeframe.  I have some less than stellar decisions also in my past.

·       To be more general in all of this, the question of risk associated with building web applications with <>.  Tools built on standards tend to not have much user risk associated with them.  Users won’t be able to tell the difference between an app generated with PHP, Ruby on Rails, Node, ASP.NET MVC, or any other framework.  These tools and frameworks don’t have much risk of going away either.  What happens when you are looking at a new tool?  That’s where the problems can come in.  Using a new framework depends on a number of factors and there is no one choice that will eliminate risk.  There are valid reasons to go with something new that depend on your specific situation.

Summary

Risk is all around you.  Your investors and project managers have to deal with risk every day.  For investors, risk can affect their choice as to whether or not to invest.  Project Managers can look at this risk regarding what platforms they choose to use.  Developers also have to deal with risk in the choices that they make.  You need to understand the risk that you are involved with, so that you can properly manage the risk in your given situation.  Good luck with the choices that you make and how they affect your startup.