fantasy vc - knodes

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

At New York Tech Meetup last year I saw a presentation by the founders of Knodes. It got me then and, eight months later, I still think about it.

Facebook, Pinterest, Instagram, etc., are utilities [eventually] optimized for advertising revenue. This means they must generate noise to make money from our captured attention. I’ve asked: what if we were paid directly for our attention rather than those middlemen?

Knodes asks: what if we could use those noise generating systems to generate signal?

Put these things together:

• It’s become a truism that there’s too much information, too much of which is noise and most of which is filtered out automatically by people on social media, in searches, etc
• Word of mouth, recommendations from friends and trusted advice have the greatest leverage when it comes to commanding high-value attention, the kind that leads to actual action and stickiness
• "High-value" attention because all attention is not made equal, which is (hopefully) intuitively self-evident
• The social capital of trusted networks (or whatever)—a friend you know knows a thing or two about something—can turn something from a bit of noise into a bit of signal
• The demographic, interest and activity profile matching used for ad targeting can (and should) be used by trusted networks to reach each other with greater leverage
• For example: I don’t know who in my network is really interested in supporting autism research, but some of them must be so instead of hitting all of them with noise—support this because I want to—I can target the ones that care with a signal—support this because they want to—without having to know who they are ahead of time

In generating signal I wrote:

 

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.

Jeff Jonas has been saying this for more than a decade: the data must find the data and the relevance must find the user. Go read him. If you get the chance, talk to him.

That is the promise of Knodes.

Generate signal.

--
None of this is 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.

the web in twenty minus five

My friend Stu tagged me to answer these questions five years ago:

• How has the Web changed your life?
• How has the Web changed business and society?
• What do you think the Web will look like in 20 years?

Here are my answers, with minor edits and some commentary in []'s. The original post is here.

---

Ok, but 1) I don’t think I have anything unique to say and 2) we’re all wrong about what it’ll look like in [15] years.

How has the Web changed my life?

It’s strange to talk about the web as if it is the internet. I grew up in the late 80’s through the 90’s along with the emergence of the web as the dominant realm of the net. When I first connected, it was all about email, usenet, irc, and bbs’s. “Web” was an afterthought. Overnight, pretty much, it become the primary interface to the net. And then, the primary platform.

It’s the platform part that has impacted us most. My life is enriched by unprecedented access to commerce (amazon! threadless! zappos!), content (youtube! hulu! gutenberg!), people (facebook! twitter! linkedin!), and publishing (blogs! twitter! tumblr!). The last two have mattered most to me.

[I’ve gone from a nobody buried inside of IBM to a very-minor-somebody embroiled in #startuplife.] 

How has the Web changed business and society?

First off, we’re not talking about all businesses or all societies—really only a minority of either that are the majority in most of our spheres. There are plenty of people who could use some very simple, basic necessities that the web can’t supply. [But the internet has had an impact—see M-Pesa.]

So business and society: web as platform for connecting, producing, publishing, consuming, and trading on values. It’s a lever with a positive multiplier effect on reach and a negative multiplier on cost of achieving that reach.

The web has created a whole field of startups that require next-to-nothing to get going. It’s given a whole slew of people who would’ve once just been company (wo)men an alternative.

It has created a way to organize and collaborate that’s enabled everyone (good, bad and ugly) to come together with others along any lines for any reasons with however much anonymity for however long on any terms.

What will the Web look like in [15] years? 

• It will remain a platform with immense multiplier effects
• Web/desktop/here/there/os/app/interface lines will [blur for users and] only exist to the technology plumbers and enthusiasts
• More embedded and ambient devices creating new interaction points
• More ambient triggers for sensors and sensing
• Touch and voice as natural interfaces
• Physically responsive interfaces enter the real world
• Consolidated [but distributed] virtual identities
• Won’t solve poverty
• Won’t solve despots/theocracies/totalitarianism/etc [but It’s certainly thrown a wrench in the works]
• Won’t solve disease
• Won’t solve people hell bent on destroying other people
• Won’t solve exuberant-irrationalism

fantasy founder - beta club

Continuing an occasional series about products and companies that I’d like to build or see built someday.

Tech decision making does not scale. The last mile of commitment always comes at the price of actual use and trial. That’s why we have pilots, proof of concepts, bake-offs.

If that last mile is the part we have to do, then the rest needs to be compressed—both the front end of qualification-to-selection to the back end of implementation-to-operation. Why some companies buy things that take months-to-years to get up and running baffles me. Why some companies spend months to figure out what to try (with generally worthless RFx processes), when ultimately those things may not even work in practice, also baffles me.

Analysts help a little bit. One of the decision support roles they're supposed to serve is answering whether a particular technology or vendor is the right fit for an organization and problem. There are some that do this with startup tech, like 451, Redmonk, Jonah or Lydia. But very few have insight or access to tech before it hits the market. That takes personal networks, connections to investors and the concerted efforts of dedicated people employed for just that.

What if that was taken care of? And you could just join a buyers’ club of sorts?

Something like this:

• Be dedicated to experimentation and actually trying things, because we’ve accepted that there’s no shortcut
• Believe that tech is worth investing in, can render a competitive advantage, and want to try new things when they’re new
• Once a quarter, answer a short questionnaire about 3-4 pressing tech problems that are unserved or underserved by existing vendors
• Get matched to a startup product, on the market or stealth, released product or pilot/alpha/beta—matching not just for capability, but for technological fit
• One followup meeting, within a month, to get the best fit and work out details
• Shortly thereafter, have licenses, code, etc., from the best matches in hand to get cranking in test
• There could be packages, free to try, support and feedback arrangements, good terms for logos and press releases, etc.

Highly personalized, curated new tech? Something like that. Sounds hipster-tastic, but oh well. 

It could manifest as just a mailing list. It could be blind, so neither the startup nor the member knows who the other party is until things get in the lab—to make it purely about solving the problem.

I’m guessing it would be most useful for non startups, non large financial services, non large tech co’s, non already-big web/social/mobile. Aside from communication, the whole thing would be done manually by someone. thus naturally limiting absolute scale at any given point in time and speed of scaling over time. Which is ok. 

I call it Beta Club. 

If it provides a steady stream of real, useful pilot opportunities and pre-launch logos—investors and founders would bite. If it provided a steady stream of real, useful early access to game changers—tech buyers would bite.

design for service - spaces

And now for something completely different. If you interact with me (or my twitter feed) to any degree, you might’ve noticed…

coffee

— Aneel (@aneel) February 23, 2014

Drinking a Fantôme Saison D'Erezée - Hiver by Brasserie Fantme - http://t.co/bxo2Gmhoud

— Aneel (@aneel) February 24, 2014

I spend a fair bit of time in bars and coffee shops. Service in these places is interesting because although the formula seems straightforward--produce what’s ordered efficiently with sufficient pleasantness (or unpleasantness if very hip)--it’s multivariate and at least one of the variables is utterly uncontrollable. Skilled labor, number and type of staff on, complexity of menu factoring to time and consistency of production, complexity of menu factoring to time to educate and serve customers, work space, work space set up, service space, service space set up, customer space, customer space set up, steps to produce items, distance traveled to produce items, flow of customers in time and numbers (demand), flow of orders in time and numbers (demand), flow of orders vs complexity of orders (demand vs fulfillment), inventory location, inventory availability, staff incentives, margins, desired and prompted customer behavior, desired and prompted staff behavior, work space affordances, service space affordances, customer space affordances, etc. 

We can design around everything except for demand. Coffee shops and bars can’t scale to meet demand infinitely. Service does not scale. Not in space, not in product, not in staff. There is no utility provision of beverage services [coffeops! beerops!] that underlies the actual production of product and servicing of customers for these businesses. So we have to find a service sweet spot in a normal operating range that can degrade gracefully during demand peaks and demand valleys.

But maybe we can create spaces and codes and empowerment that generally get one to the stateof good service experience. I think. 

My favorite coffee shop in SF is Sightglass. My favorite beer bar here is MikkellerBar. Both are startups. Service at both is good-to-excellent most of the time. Under severe load or severe lack of load, interestingly enough, service at both degrades the same way: down decent-to-good.

Notice something similar?

Check out how much room there is behind the bar. More than a full complement of staff can move around and do everything necessary for service in their workspace without running into each other. You might also note that some key stations are mirrored on either side of both bars—sinks, points of sale, espresso machines. Neither place could operate effectively at high customer load without that sort of slack in physical space. Both places tend to have four people behind the bar when busy, plus a fifth and occasional sixth (usually a manager plus an extra pair of hands that were doing some other business). Sightglass will have a standard fifth to run the pour over station, while Mikkeller’s fifth is the shift manager helping out or waitstaff doing their own bar service. At both places, all staff seem to be trained to do all things and take up service backlog as needed, transitioning smoothly from function to function without stepping on each others’ toes.

In front of the bar, out in customerspace, there’s also a lot of slack. In the case of Mikkeller, since all parts of the bar that are not the bar itself are servicespace, that makes it relatively easy to navigate and get beer and food out promptly. In the case of Sightglass, most of the space is not servicespace but provides enough room for customers to get out of the way once they’ve ordered and not present navigation problems for each other. The upstairs at Sightglass is a servicespace for certain parts of the day and the same bit about slack holds there. 

One final thing, look at how many different kinds of customerspace exist to afford different kinds of use: standing, sitting, alone or in groups or communal, in high or low traffic areas, face to face or face to service or face to space. For every kind of customer, a space.

P.S. Much of this thinking comes from time spent with industry people discussing the mechanics of service in the context of the needs of a business. They’ve been kind enough to tolerate my incessant curiosity. Thanks Dave, Paul, Tim and Jesse!

ooda redux - digging in and keeping context

Putting together some thoughts from a few posts from 2012 on OODA [one, two, three]. For some reason, the idea had been getting a lot of airtime in pop-tech-culture. Like most things that get pop-ified, the details are glossed over—ideas are worthless without execution; relying on the pop version of an idea will handicap any attempt at its execution. 

I’m not an expert. But, I’d wager that Boyd: The Fighter Pilot Who Changed the Art of War is the best read on the subject outside of source material from the military.

OODA stands for Observe, Orient, Decide, Act. It’s a recasting of the cognition<->action cycle central to any organism’s effort to stay alive, focused on a  competitive/combative engagement. 

Get the data (observe). 

Figure out what the world looks like, what’s going on in it, our place in it, our adversary’s place in it (orient).

Project courses of action and decide on one (decide).

Do it (act).

The basic premise is that, in order to best an opponent, we have to move at a faster tempo through the loop. Boyd used a more subtle description—operate inside the adversary’s time scale. 

First: If we traverse the loop before the adversary acts, then whatever they are acting to achieve may not matter because we have changed the environment in some way that nullifies or dulls the effectiveness of their action. They are acting on a model of the world that is outdated. 

Second: if we traverse the loop before the adversary decides, we may short circuit their process and cause them to jump to the start because new data has come in suggesting the model is wrong

Third: if we traverse the loop at this faster tempo continuously, we frustrate the adversary’s attempt to orient—causing disorientation—changing the environment faster than the adversary can apprehend and comprehend it, much rather act on it. We continue to move further ahead in time while the adversary falls backwards. By operating inside the adversary’s time scale.

Another detail from Boyd—all parts of the loop are not made equal.

Fundamentally, observation and action are physical processes while orientation and decision are mental processes. There are hard limits to the first and no such limits to the second. So, two equally matched adversaries can both conceivably hit equal hard limits on observation and action, but continue outdoing each other on orientation and decision. 

But realistically, adversaries are not equally matched. We don’t observe the same way, using the same means, with the same lens, etc. We don’t act the same way, with the same speed, etc. And being able to collect more data, spend more time orienting, leads to better decisions and actions. Being able to move through different parts of the loop faster, as needed, renders the greatest advantage. Compressing the decision-action sequence gives us a buffer to spend more time observing-orienting. Nailing observation gives us a buffer to spend more time orienting-deciding. We can come up with the best--not the fastest--response and act on it at the optimal--not the fastest--time. Getting a loop or more ahead of our adversary gives us a time buffer for the whole thing. It puts us at a different timescale. It allows us to play a different game, to change the game. 

Deliberately selecting pacing, timescale, game—strategic game play.

Ops/devops analogs:

• Observe - instrumentation, monitoring, data collection, etc.
• Orient - analytics in all its forms, correlation, visualization, etc.
• Decide - modeling, scenarios, heuristics, etc.
• Act - provision, develop, deploy, scale, etc.

Startup analogs:

• Observe - funnel, feedback, objections, churn, engagement, market intel, competitive intel, etc.
• Orient - analytics in all its forms, correlation, assigning and extracting meaning from metrics, grasping the market map and territory, etc.
• Decide -  modeling, scenarios, heuristics, etc.
• Act - prioritize, kill, build, target, partner, pivot, fundraise, etc.

Those are analogs. It’s worth keeping in mind that OODA was developed for the context of one-to-one-fighter-jet-to-fighter-jet combat and not anything else.

fantasy founder - relationship management is engagement management

Continuing an occasional series about products and companies that I’d like to build or see built someday.

There’s a natural cadence to communication. We meet or talk or email or txt or whatever. And we do it over some topic, even if it’s just catching up. The mixture of who we are to each other, the last time we connected, how often we connect, and what we connect over plus our personal contexts (and some other stuff) make up how much of an impression is left and for how long. At least for a moment, you get to front of mind. 

Nothing new there. We can maintain different sizes of connections in our brains. Social butterflies are great at wide swaths of shallow relationships. Most people are good at small numbers of deep relationships, bigger number of casual or business relationships, etc. See Dunbar.

But social networking and freelancing blow all the numbers away. How do you both organize the people you want to keep in touch with and maintain the connection? How do you deal with the fact that relationships wax and wane and change?

• Personal social networks let you organize people and give you the updates about them that are prompts to connect
• Professional CRM systems let you organize people and track communication for the purpose of getting someone through the funnel and keeping the money flowing
• Professional social networks (taking LinkedIn as the only example that matters) don’t really do either
• Contact managers let you organize people
• Communications apps let you connect
• We need to keep track of who matters to us and why
• We need to keep track of when we talked to them
• We need to remember to talk to them again
• We need to be true and authentic to actually have real relationships (nothing’s going to do that part for us!)
• We forget to stay in touch with people we want to
• We want some relationships to grow
• We don’t care if others drift off
• Some relationships change without us even noticing

So what do you do? Actively manage relationships? There’s prior art here: Nimble, Mingly, Contactually, fellowup, Promptivate, CRUMBtrail, Highrise, Google Plus, ICQ (way ahead of it’s time). And I pitched the idea a few years ago to ___, which didn’t work out. But the idea of personal relationship management hasn’t really taken off. Everyone either charges too much, doesn’t have a functional enough (or any) free tier, or is just a poor man’s CRM.

The things I want:

• Integration with email, messaging, contact lists, social networking for both comms recording and metadata acquisition
• Inferring relationship tiers in terms of depth and frequency of communication, but not assigning any meaning—example: you talk to someone infrequently but consistently, which might mean a great old friend or a casual connection you see at a conference every year
• Arbitrary tagging or categorization, because real life is full of Venn diagrams
• Indicators that say, “hey, you’re normally in touch with this person every week and now you’ve dropped off to every month.. is that what you want?”
• Reminders that say “hey, you’ve said you want to be in touch with this person every week, so go talk to them”
• Unobtrusivity
• Refusal to turn into a CRM replacement, integrate with SFDC, Marketo, etc.. if it gets to that point, make another product**
• Freemium, with either a contact number limit or some feature based limitation

**And now it gets interesting. There’s a generalized application here, that for some reason is missing. In a world of SaaS, social networks, and mobile apps—the same relationship persists between the app and the user. Any user has some attentional budget and the same cadence of communication applies with the app. We call this “engagement”. The same ideas and algorithms that are needed for a good PRM would work well for a kind of engagement management (EM). You could set engagement targets (this many high value touches a month, that many low value touches a week), infer engagement quality and relationships status, prompt the user to engage, prompt the app to engage, prompt sales/marketing/account/whatever to engage, etc.

Added Feb 12th: P.S. The CEO of Nimble got in touch after reading the post. Check it out. Although it is targeted at professional use without a fremium model, it does go a long way towards what I'm talking about here. 

communication in the service and api supply chain

Another thought about “the service and api supply chain” —how do we know what an API provider or servicer can do? It’s unlikely that any given servicer of an API will service the same subset of that API as any other servicer or be able to keep up with all the changes that are introduced by the API originator.

Can you ask an API endpoint:

• Hey, what can you do? 
• What APIs do you originate and provide? 
• What 3rd party APIs do you service? 
• What subset of those APIs? 
• What are your SLAs?
• Etc.

Can the API endpoint tell you:

• I’m running out of capacity to service X?
• There’s a degradation of service Y?
• You can send these calls to these other endpoints I own?
• This is how much I charge per call for Z?
• Etc. 

We could use a (roughly) global language with some basic terms for services that describe what they do, what they service, how they do it, with what kinds of commitments. An analog to Wolfram Language for distributed services. 

We could use a (roughly) global protocol for handshakes and mutual understanding so services can talk to each other, advertise and discover what they can do, what they can service, how they do it, with what kinds of commitments and interrogation mechanisms. An analog to ethernet autonegotiation for distributed services.

Plenty of API providers don't want this to exist. But the competitive advantage that could be generated by programatically dealing with an API should draw a significant ecosystem. So I wonder why this hasn't been done, especially be near-first tier providers like GCE and Azure. I can only guess it's because they haven't figured out how to do ecosystem-based strategic gameplay for cloud services yet. And of course, AWS has no need to do such a thing (yet).

fantasy vc - virtustream

This fantasy vc post comes from something I wrote about in “what we don’t know about private cloud” and “the three cloud questions you have to answer”: 

The line between what we do in the public cloud vs what we do in the private cloud vs what never goes to a cloud model will be moved—both in time and in scope—by the cloudification of legacy applications.

In the space between public cloud for cloud-native applications and on-prem virtualization plus automation for non-cloud-native applications lies a big space for remote hosting of non-cloud-native applications. 

Some of this is satisfied by what can best be called managed hosting for virtualization, which is what most VMware-oriented service providers (even those that use the word “cloud”) do. And some of it is satisfied by VMware-oriented service providers that actually have managed to build a self-service, usage-based service model (like the very successful Tier3, recently acquired by CenturyLink).  

Yet despite the promise of being able to forklift a legacy app to a cloud provider and switch from a perpetual license model to a usage-based model to pay for a particular bit of software as a service—that is something that is rare. Enter Virtustream.

Put these things together:

• Many enterprise apps cannot be re-architected to be “cloud-native”
• There is demand to forklift enterprise apps to hosted infrastructure
• There is demand to pay for those apps on a resource-consumption model
• Many of those apps are only supported virtualized on VMware
• Many enterprises don’t have the expertise to do the forklifting
• Many service providers don’t have the expertise to do the forklifting
• Many (most?) VMware-oriented service providers can’t figure out how to get the automation and resource-consumption parts done in a way that generates a sufficiently cloud-like experience for their customers
• VIrtustream solves for this

The interesting thing about Virtustream to me is the apparent focus they’ve had from the beginning: these exact customers, this exact problem space, those exact applications. And nothing else. Period. 

The technology they built is fundamentally an enabling mechanism to make the resource-consumption model granular enough on VMware to achieve the cloud-like experience. The model they built is predicated on doing the hard work of the full life-cycle of an enterprise pre-sales/sales/post-sales consultative service. And they do the hard work.

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: Virtustream, as a whole, was adjacent to my coverage area at Gartner—but their xStream cloud management platform was squarely in my coverage area once it was commercialized.

the service and api supply chain

When we visit a site, start an app, or do just about anything online—what lives behind that one object is 10s, sometimes 100s, of services.

As Mr Krugman notes, the great transport and communication innovations of the past generation did not necessarily reduce shipping costs. Rather, they reduced shipping time while also making international coordination of shipments cheaper and easier. The result has been, in Richard Baldwin's phrase, a "second unbundling". The first unbundling represented globalisation's geographic separation of production and consumption more than a century ago. The second is the geographic separation of stages of production. And one then has to ask how stories of the determinants of international trade apply to each of these various stages.

- Hyperglobalisation and metropolitan gravity, Free exchange @ The Economist [emphasis added] 

We’ve seen a steady unbundling on the web, on our phones, and in our apps. It’s the separation of technological stages of production of apps and services. And it’s turtles all the way down.

When we bought all our software and ran it on our own systems, we controlled the software supply chain underlying the ultimate business apps we used. But if we rely on a SaaS app that relies on other services accessed via APIs which may themselves rely on other services accessed via other APIs—how do we manage this new supply chain? How do we figure out how to manage the risk of our services’ services’ services’ services?

With actual manufacturing, if a supplier stops delivering or goes out of business, you find another maker of the same component or ship your specs off to another manufacturer who can make that very same part you need. 

In the API economy, if the provider of a service goes under or simply stops providing the service, what can we do? 

• Suffer and recode to a new API for a competitive service (if one exists)
• Build an abstraction (maybe our own API) to make that easier
• Use two or more similar services via our own abstraction with some ability to switch if one fails, which still involves building the drivers (as it were) for each service’s API

What we can’t do is ship the API calls to another provider to service, or put a service spec plus API out to bid, or create an ecosystem of multiple suppliers for each service layer. 

Why not?

Where’s the alternate service provider who will service the AWS APIs? Where’s the alternate service provider who will service the Twilio APIs?  Where’s the alternate service provider who will service the Dropbox APIs? 

Added Feb 12th: Where's the communication mechanism to discover services, APIs, nodes and negotiate transactions? More on that question in another post.

There’s an opportunity in there somewhere.

fantasy vc - apprenda

Considering the press and recent funding round for my friends at Apprenda, it seems a bit disingenuous to fantasy vc them. But no matter.

I’ve been convinced of their success since the first explanation of the product and target. There were plenty of PaaSes at the time, but they were mostly targeted at developers and mostly public. Press releases from analysts firms like this notwithstanding, the market wasn’t taking off and didn’t look like it was going to take off any time soon.

Put these things together:

• There is a lot of in house development in the enterprise—though no one knows how much exactly, it’s at least enough to support a couple of private PaaS players
• That development is mostly Java or .NET on Linux or Windows
• And it runs on fleets of servers, storage, networking, and data centers that are not at end of life
• What’s developed is custom apps for core business/ops, paperwork apps, extensions to COTS with SDKs, glue to connect together these things and/or legacy apps and/or cloud apps and/or cloud services and/or…
• There was and is very little “private” PaaS competition
• There was no private PaaS for .NET applications at the time that I knew of and there are only a few today 
• There was little that provided the experience of a distributed runtime on prem out of the box
• Virtualization is not required
• Apprenda was (and is still the only?) private PaaS supporting .NET that doesn’t predicate itself on some hypervisor

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

- me, provided vs exposed

To me, that last point was the killer. Before the renewed popularity in [the old technology of] containers, Apprenda leveraged Linux container tech and figured out how to get a workalike on Windows to underpin their PaaS. Thus totally foregoing the overhead of hypervisors and the overhead of VMware’s margin.

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: Apprenda is not in my former coverage area and I have no financial interest in them. But Sinclair and I do share an alma mater.