Skip to main content

Startups and Early Adopting Customers

Any product, no matter whose it is, will only meet a fraction of your needs. Working with early startups gives you the ability to influence a product early in its life cycle and increase that fraction. You get to nudge a product in a direction that matters to you, while the startup gets unvarnished, raw, but valuable product feedback.

In a recent post on Security for All, Joseph Webster describes risk to innovation that startups face when transitioning to established corporations. From the point of view of a customer of startups, the transition that the startup needs to make is also interesting:

In a small startup everyone is intimately familiar with the customers, whereas large corporations have to make concerted efforts to allow a design engineer to even have marginal contact with a customer - and that’s usually second hand through either a sales or marketing initiative.[1]

As a customer, I’ve seen both ends of the spectrum. My team was one of the early customers of LogLogic back when the founder, VP, and the guy who came on site and racked up the appliance were one and the same. We had pretty good response from them on bug & feature requests, sometimes overnight, at least until they hooked up with some vastly larger customers. Once they hooked up with large customers, the startup correctly judged that focusing on the large customers would keep them in business.

On the big corporation side, Microsoft has a free customer-developer program called ‘Frontline’, where Microsofts own engineers and developers come on site to see how their customers are using their products. This gives individual developers & engineers access to customers in an informal one-on-one setting, where in theory each can learn from the other. We’ve had a couple of Microsoft SQL database developers on site as a part of that program and are planning on doing it again. The feedback loop in a program like that isn’t anywhere near as direct though.

There are also times that for some reason the early customers of a startup don’t seem to be able to influence the product. We are one of the earliest and largest customers of a small software company. It is surprising how little influence we seem to have on moving critical features and functionality forward within that company, even when we team up with the rest of the large customers and present a unified, prioritized feature request list. They are small and agile startup, so they should be able to do much better than what they are.

Many of us are big enough that we probably can influence a small startup if we get connected up early enough, but we are small enough that we’ll lose our influence once the startup catches a big customer, hires executives and moves to Silicon Valley. At some point in time, as Webster indicates, the lead engineer no longer calls on customers directly and at best can only focus on a few of the largest, if any. The feedback loop from customer to engineer to product isn’t simple and direct anymore, and the ability to move the product in a direction that solves your problems declines.

The transition point is about when you start getting sales calls from someone you’ve never met and who can’t pronounce your name.

[1]"The dark side of post startup innovation", Joseph Webster,Security for All


Popular posts from this blog

Cargo Cult System Administration

Cargo Cult: …imitate the superficial exterior of a process or system without having any understanding of the underlying substance --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.
The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:
Failing to understand the difference between necessary and sufficient. A daily backup …

Ad-Hoc Versus Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to…

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. These …