technology analyst 101 for startups - introduction

At Gartner, I spent a fair bit of time with startups. Many of whom didn't know what to do with analysts. Now that I'm other side of the table, here's a 101 on tech analysts for startups.

Tech Analyst 101 for Startups

Part One - introduction to analysts / what they do

Part Two - why you want to talk to them / what they can for do you

Part Three - how to engage with them / what you should do with them

Part Four - wrapup / tl;dr and tips from analysts

--

Part One - Introduction

If you're going to deal with analysts at all, you should know what they are and what they do. 

Although blogging and byline articles blur the lines, Analysts are not Press.  

Press may do analysis (the best do). Analysts may report on news (the worst do). But analysts are not press AND press are not analysts. Both may be pundits, though. 

Also, technology analysts are not financial analysts. Although the latter are frequently customers of the former. 

"Independent" analysts are rarely independent. They tend to be pay-for-play and rely too much on vendor cash to keep afloat. It's hard to cobble together a living as a firm-less pundit without being compromised. There are exceptions, but not many.

Many analyst firms are pay-for-play. Many will write whitepapers and "advertorials" that are underwritten by vendors. I find these (after too much experience) highly suspect and particularly worthless. But YMMV, because depending on your target audience, they can be effective "offers" that convert SEM dollars into form submissions.

Top tier analyst firms, the ones that command the highest premium and respect, tend not to do those sorts of things. They run on reputation and can't afford to tarnish it. Typically, they'll fire any analyst found to be trying to shake down vendors for cash (directly or indirectly). Or they'll fire any analyst found to be hiding a conflict of interest (e.g. personal financial stake in a vendor in the analyst's coverage area). 

What they do:

1. Provide independent analysis on technology areas and vendors and products. This includes things such as trends in a specific tech (e.g. MDM), vendor position in the marketplace (e.g. Magic Quadrants), and product fitness for particular purpose or use case or end user. This analysis is typically published in written form (and spreadsheets) and includes both quantitative (e.g. unit sales) and qualitative (trend derived from end user interaction) "research"--which frequently incorporates actual primary (the big firms have in house primary research functions) and secondary research.
2. Provide "advisory" services to those who subscribe to the research products. This is typically in the form of "inquiry" on the phone where a client will call up and ask to speak with or get routed to an analyst covering a specific topic to discuss a particular issue in depth (e.g. Can you replace ProductX with ProductY?). It can also be in the form of in-person sessions with presentations.
3. Run conferences.
4. Provide consulting services (usually an independent arm of the firm) which produce written reports and the usual high-end IT consulting work products.

Who they serve:

• Users: technology buyers-- typically the bigger end of SMB up through the largest enterprises and state/federal agencies
• Makers: technology vendors-- early stage startups through the biggest, most entrenched incumbents
• Investors: who invest in makers-- VCs, investment banks, merchant banks, private equity, hedge funds, institutional investors

How they are used: 

• Should I upgrade X or wait a cycle or bring in an alternative for a POC to use as a lever to get better license terms for the upgrade or abandon this line of inquiry altogether and let X age out before replacing it with Y from a promising new startup?
• Is it the right time to get behind trend X? What kinds of impacts will my current spread of development, operations, organization, and applications suffer?
• Etc.
• How do I prioritize these 10 features on the product roadmap and position myself best for what end user of type X sees as the gaps in all the products out there today?
• What is the right arrangement with my channel partners to get new product X into new market Y? And which partners are the right ones that hold the highest degree of influence in that market?
• Etc.
• Which of these 5 startups are likely to survive the next 2 years and make it to the point of being acquired and who will most likely acquire them and what are the competitive dynamics of big players A-D that will impinge on their success?
• How will the rise of technology X affect legacy business Y of incumbent Z?
• Etc.

Fundamentally, what analysts provide is decision support for procurement, product, and investment.*

Fundamentally, what analysts do is information arbitrage. 

Their perspective, domain expertise, and context should allow them to draw conclusions that are very hard to reach otherwise and then to present those conclusions in grokkable form to clients. 

--

Next, a look at what analysts can do for startups and how you should engage them.

*There are exceptions, such as firms that are purely vendor focused or specialize in very targeted areas (e.g. RedMonk - read their guide!).

fantasy vc - cumulus

Continuing a series on startups I'd put a bet on if I could. 

Pundits and analysts like to cite SDN, NFV, Open Compute Networking, and the ever greater capability (thus usage) of merchant silicon as harbingers of commoditization. I think "commoditization" is the wrong word, used loosely without any regard for what it actually means. Rather, what we're seeing is [maybe] the onset of a kind of x86-ification or open-systems-ification of networking. Given networking (telegraph, 1844) is historically behind compute (Babbage, 1830) systems, this is not without precedent. ;-)

So my second Fantasy VC bet is Cumulus. My introduction to Cumulus was JR pulling up the OS on his laptop and handing me a bash prompt.  

Either you disrupt by doing something new. Or you disrupt by changing the supply chain, removing middlemen, disintermediation (or consolidation of intermediaries unto yourself?). When was the last time any significant disruption happened in networking? Arista looked like it was going to stir some things up, but has more or less ended up as a niche version of the typical vendor. But it did take a step in the direction Cumulus continues down by abandoning spinning it's own silicon and focusing on Linux-based OS and hardware packages. 

[This is where people with history in networking start berating me for glossing over all the other attempts and examples and acquisitions and research and….] 

Put these things together:

• Network management is a mess, has been a mess, and continues to be a mess
• Config automation is ascendant
• Application-centrism is ascendant
• Network gear is made up of specialized computation machines; why should it be isolated from the same historical progression as has happened with other kinds of computation machines?
• There's precedent for OS/hardware independence
• Has anyone ever cut out OEM's before and made distributers/VARs into the only packagers for product? What happens when Channel gets to command the margin?
• There is a market [small but potent] for mix and match network hardware and operating systems
• Every network incumbents' margin structure is someone's opportunity and those margins are fat
• Mainframes, Power Systems, Superdomes, etc., are niches while most servers sold are a variety of x86 hardware + standard OS packaging exercise

That's not to say that they're guaranteed success. Or won't get crushed by an incumbent or other party. Or even scooped up before they become too successful. Just that I would've placed that bet.

Disclosure: Cumulus is not in my former coverage area and I have no financial interest in them.

whiskey and gin

Do you know how whiskey is made? 

Something I learned from a my friend Dave the professional spirits geek: it takes significant up front capital and enough in the bank to wait it out years before having the real product. A terrible product is easy to come by in a few months. What anyone in their right mind would call whiskey takes time, indie-hipster-micro-distillers notwithstanding.

So what do you do in the meantime if you're not a retired banker or a trust fund kid? You make gin.

On the way to making whiskey, some of your product can be made into gin which is sellable at a hefty enough margin to keep things humming along while the real stuff is maturing, finding its character. [No offense to gin.] 

Witness the good work of the New York Distilling Company. 

And witness Uber (maybe). Here's Kottke repeating Michael Wolfe on Quora [notes in brackets mine]--

If you think of Uber as a town car company operating in a few cities, it is not big. [Gin.]

If you think of Uber as dominating and even growing the town car market in dozens of cities, it gets bigger. (Data point: there are now more Uber black cars in San Francisco than there were ALL black cars before Uber started). [Gin.]

If you think of Uber as absorbing the taxi markets, it gets pretty huge. [Gin.]

[...]

If you think of Uber as a giant supercomputer orchestrating the delivery of millions of people and items all over the world (the Cisco of the physical world), you get what could be one of the largest companies in the world. [Whiskey.]

The hard parts:

• Not getting distracted making the gin.
• Not dipping into your final product before it's ready.
• Not siphoning off too much of your product into gin making before it hits the barrels.
• Not being so successful with gin that you abandon the warehouse of hard work and hard won patience altogether.

What are you making?

fantasy vc - metacloud

Kicking off a series about bets I would've placed if I had the money. This is something I very much wanted to do--very much could not do--when I was at Gartner.

I don't know the numbers on "real" (read: revenue generating) OpenStack adoption, growth, etc. . 

I do know there's real traction. 

Suspicion: it's with very very few vendors. Money is being made but success is concentrated.

There are only two startups in the space I would bet on. One, I have a conflict of interest regarding. The other is Metacloud. Both aren't really OpenStack companies. OpenStack is just a vehicle for the thing they actually do.. In Metacloud's case, what they do is remote ops (as a service!)

Put these things together:

• There is a market for private cloud (whatever that is)
• There is a market for AWSish public cloud
• There is a market for AWSish private cloud (Eucalyptus are still in business, aren't they?)
• There is an existing use case for AWSish private cloud in most enterprises (web, mobile, dev)
• There is a fundamental our-bottom-line-at-stake use case for AWSish private cloud in some subset of enterprises (a few hundred?) today
• There is a general lack of operational skill for AWSish private cloud
• One of the core things public cloud provides is a managed service
• There is a market for on-prem remote-managed AWS (the three letter agency thing is a public example)
• The Metacloud guys are ops guys who understand enterprise, scale, web, mobile, open source, AWSish cloud
• There just aren't a lot of hats (big or small) in this particular ring right now 

That's not to say that they're guaranteed success. Or won't get crushed by an incumbent or other party. Or even scooped up before they become too successful. Just that I would've placed that bet.

Disclosure: They're in my former coverage area. But I believe with some certainty that I'd come to the same conclusion without that background. I have no financial interest in Metacloud. I really like them. Would have a beer with that crew any day. 

provided vs exposed

If you're offering infrastructure as a service, you have to have infrastructure to offer and it has to be exposed.

But if you're offering something else, then:

The infrastructure doesn't need to be exposed, THUS you don't need to have it.

Examples:

• You offer VMs, so you need to expose VMs, a management console for VMs, and (hopefully) APIs to connect to and operate them
• You offer a runtime, so you may or may not have VMs--but who cares since what you need to expose is the runtime, a management console for that runtime, and (hopefully) APIs to connect to and operate it
• You offer an application, so you may or may not have VMs or a particular runtime--but who cares since what you need to expose is the application, a management console for that application, and (hopefully) APIs to connect to and operate it

It gets a little more complicated when someone wants to build something else on top of what you offer. Then they probably want and/or need more exposure to, and more control knobs for, the underlying stuff.

Basically, this is what makes IaaS (specifically VMaaS) different in kind from anything else. 

What you provide guides what you expose dictates how you can build.

What you've built limits what you can expose dictates what you can provide.

generating signal

Courtesy @epc, I went to the July New York Tech Meetup. For the most part, consumer/social/mobile/web/fashion startups aren't my bag. But here's something interesting..

@NYTM: Deliver the right message to the right person. @Knodes http://t.co/AWLrqdjOiO #NYTM 

The same technology used to sell our eyeballs to advertisers is flipped into a tool for us to reach deep into our own networks with the backing of our personal social credit. This flips the noise generating system into a signal generating system.

Instead of us filtering out all the noise to find the signal, the signal filters out everyone to whom it is noise. The signal finds you.

the value of feature velocity

We don't put a value on feature velocity. Not our own, but the public cloud's.

Maybe we should. Being on a public cloud like AWS exposes us to new capabilities faster than most internal IT departments can begin to provide. We may not need any given capability, or even want it. But here's the thing: you will never know what you could do with it if you're not exposed to it. 

There's some inherent value to that. To being exposed. 

And there's an opportunity cost to not being exposed. 

Are you putting a value on that? 

the misogyny in technology

Maybe it's cause I was raised by a single mother.

Maybe it's cause I've worked under managers, directors, vice presidents, general managers, and senior vice presidents who happen to be women. Maybe it's cause I've worked with engineers and technologists with advanced degrees who were experts in their fields who happen to be women. Maybe it's cause I know CEOs, CMOs, COOs, and CIOs who happen to be women.

Maybe it's cause I'm secure in my person and don't find anyone else's success as a threat to my own. Maybe it's cause I don't think life is a zero sum game.

But…

• Walking into a room and telling the first woman you see to get you a cup of coffee IS NOT OK.
• Drunkenly texting "your room or mine" to the woman CEO of a successful company whose business you can impact IS NOT OK.
• Rewriting the history of an organization to cut out the women leaders and founders in order to aggrandize the men IS NOT OK.
• Attempting to put down a woman who has obviously kicked your ass in a technological argument by calling her ___ or ___ IS NOT OK.

I come from a culture that is historically not good to women and I don't seem to have a problem with this.

Mr. Senior _____, Mr. VC, Mr. Distinguished _____, Mr. CxO--what's your excuse?

conservation of lock in

Every hardware, software, runtime, programming language, database, management tool, cloud, etc ad nauseam decision involves lock in. The idea that you can do away with lock in is utterly bogus. All we do is shove it around from one layer to another. 

Every decision comes with a switching cost (even when that switch is an undo). The extent of that cost is your lock in. And ultimately you cannot remove lock in. The total lock in you are under is the cumulative cost of switching every last thing. Or even simpler, changing. This is also the beginning of technical debt. This is also why ultimately things end up getting thrown out and we start from scratch. This is also one reason why composing systems and operations of smaller units of deployment/consumption/operation/failure is useful.

You cannot eliminate lock in. But maybe we can minimize the scope of any given piece of lock in (and change costs).

And any vendor who sells freedom from lock in which does not also include freedom from that vendor ("go ahead, we'll make it easy for you to replace us") is just playing on your failure to accept the simple reality that there is always lock in.

Lock in is conserved. Conservation of lock in.

the three cloud questions you have to answer

The bit about 3 lines in "what we don't know about private cloud" seems to be making sense to everyone I discuss it with (end users, vendors, investors), so I've reformulated it as a set of questions.

Taking an application portfolio perspective.. looking across the entire set of apps you run, you have three decisions to make:

1. Of that set, what do you NOT want to develop or run, period?
2. Of the remaining set, what do you NOT want to develop or run on your own infrastructure?
3. Of the remaining set, what do you NOT want to manually provision and have manually requested?

The consensus on these questions, if one ever emerges, will produce the actual (vs pick-your-pundit's projected) terraforming of the tech landscape.