The Cranky Admin

The Risky Business of a Tech Startup

Conquering the 'science project' dilemma.

• By Trevor Pott
• 05/01/2017

Tech startups are hard, but not always for the same reasons. A large part of my day job is producing content for -- and advising -- startups working through the early stages of life. One thing that has been made perfectly clear to me is that getting beyond "science project" -- or at least the perception of it -- is as much luck as capability.

There's a reason I put "science project" in scare quotes. This is due to a memorable anecdote that I feel sums up far too much of the tech industry.

The story: a large Tech Titan entered into an agreement with a fledgling startup. This startup, in turn, stopped all business development to seek out new partners and devoted themselves to integration with the Tech Titan's hardware. The Tech Titan used its connections to get the startup's solution in front of some very prominent, influential -- and large -- potential customers. One of those customers, after thorough testing, threw the combined solution out, saying it was "a science experiment".

This proceeded to go viral within certain community circles, and it was quickly discovered that this sentiment was shared by others who had been engaged in proof-of-concept deployments. That was in early 2016. To my knowledge, the Tech Titan has yet to see a win with their pet startup's solution, and the lack of such victories has cost them dearly; their rivals march ahead and they are now more than five years behind.

None of the startups I'm working with today are actual science projects; they're all proper solutions ready to handle your workloads. Unfortunately, reality doesn't matter so much as perception. Operations teams are highly risk averse; nobody wants to be among the first customers, even if they desperately want the solution on offer. And it's those first few customers that really matter.

Startup A: The Paralysis Problem
Without naming names, let's consider a few practical examples. Startup A has built an absolutely amazing hybrid cloud-in-a-can solution. You can consume it as a service from the vendor's own public cloud offering, build your own service-provider solution out of whiteboxes or get a hyperconverged cluster with the software pre-loaded. All in all, it's a pretty slick solution. They even have a few notable customer wins worth bragging about.

Startup A has been obsessed with perfection. Instead of beating the streets about their solution and throwing rocks at the various Tech Titans that are still six months behind them, they are constantly holding off on any major campaigns until the solution they offer is "perfect." They're terrified of being labelled a science experiment, and it has paralyzed them; tragic, in my opinion. Now's the time to strike, before everyone else catches up.

Unfortunately, one can't simply slap them in the face with a salmon and say "hey, this is stupid!" Their fear isn't entirely unjustified. If they leave any attack surface exposed and the wrong person labels them a science experiment, all their efforts could be for naught. At some point, achieving victory requires taking risks; but in our increasingly social-media-enabled industry, those risks need to be carefully calculated.

Startup B: Getting the 'Right' Customers
Startup B has a software-defined storage solution that can take any storage you happen to have and lash it together. When I first started working with them, I was really skeptical. They promise a host of features and capabilities that I've dreamed of my whole career, but never thought I'd see in a single product.

The months passed, and the startup in question not only fixed bugs but pushed out a number of new features. The product went from interesting to exciting to "I don't know how I ever lived without it." It's still a little rough around the edges, but a science experiment it is not.

Sadly, while Startup B is willing to get out there, take risks, and get their solution in front of anyone who is willing to give them the time of day, they're not having an easy time of it. Nobody wants to even talk to them until they have a list of big "Name" wins as long as my arm.

Potential customers are so afraid that Startup B is peddling a science experiment that they aren't willing to give them a look. This very typical tech industry Catch-22 risks depriving us of a truly great product.

This isn't to say Startup B doesn't have customers. They do. Unfortunately, survival requires getting enough of the "right" customers to make it from one funding round to the next; that is always a struggle, no matter how good the technology is.

Startup C: Fear of Overhaul
Startup C is functionally an API gateway. While they market themselves under various other monikers, including copy data management, the reality is that they are a highly sophisticated abstraction layer between IT practitioners and their infrastructure.

Operations teams use Startup C's technology to create profiles that govern resource limits, data protection requirements, data locality, number and type of copies; even data masking, encryption and privacy requirements. Developers then can consume resources, data copies and even entire environments across multiple storage devices, databases and clouds using a single self-service portal and/or API.

It's a bit overwhelming, but it solves a number of difficult and time-consuming problems efficiently and easily. A major Tech Titan has even signed an OEM deal to resell the solution under their own brand. There's good reason for this company and its product to exist, and those who have given it a chance find they can't go back.

Despite this, Startup C faces its own problems and represents the third version of the science experiment problem. They have no fear of being labelled a science experiment. They have more than enough customer wins that only fools would call them a science experiment. Instead, customers worry that by adopting Startup C's solution they will become a science experiment; taking proper advantage of Startup C's offering usually requires modernizing everything from testing regimens to business practices to staff hierarchies.

Finding the Diamonds in the Rough
The problem in all cases is our reaction to risk. Startup A is confrontation averse. Startup B is the victim of widespread aversion to the unknown, while Startup C struggles with being the catalyst for change. All of these are understandable, and yet all are problematic not only to vendors but to everyday organizations and practitioners.

IT is constantly evolving. The technologies, practices, products and even vendors of yesteryear fade into the past with disconcerting speed. Our businesses rely on IT. More today than yesterday and more tomorrow than today. Our competitive edge over the competition largely comes from the uniqueness and efficiency we bring to the utilization of technology, be that in automation or in simply delivering a more satisfactory customer experience.

We can't afford not to take risks. We need to be constantly challenging ourselves to move beyond our technological comfort zones, and we should be constantly evaluating new technologies. Some of those technologies we will have to throw out for being science experiments. But amid the dross there are proper gems. It's our job to find them.