design for service - affordances

In thinking about the importance of how space was set up, both for staff and customers, in design for service - spaces I  wrote that one of the components of service is the affordances created in the spaces in which people work, provide service and are served.

I’m not in UX, so I’m not entirely certain how “affordance” is used technically, but I’ll just assume it’s a reasonable derivation of the original term from cog pysch. If you’re at all curious, I’d recommend going to the source and reading J. J. Gibson’s The Ecological Approach to Visual Perception. It’s a good book. 

//Side note: if you’re curious at all about anything, get as close to first sources [like reading declassified excerpts of Boyd’s work instead of the hundreds of faulty third- and fourth-hand derivative applications of OODA] as possible—either reading inwards from derivations or outwards from original sources. It’s better for our brains and better for the world when we know what the **** we’re talking about before words come out of our faces.

As a way to explain affordances, I’m going to use the near-perfect design of my 11 year old, no longer made Spire messenger bag.

Start with the front of the bag. There’s a zippered outside compartment where we can store whatever. It’s good for things we might want without opening the bag, that’re ephemeral in possession, that aren’t valuable—like a newspaper.   

Now look up to the handle. There’s a handle. Because sometimes we’ll just pick the damn thing up without slinging it over a shoulder.

To the left, where the strap attaches, a hook. If we happen to favor one shoulder, we’ll flip the strap easily. [By the way, that original hardware has stood up to severe abuse over a decade through many travels across a dozen countries.]

On the strap, a pad that floats. The strap, the whole bag, can move while the shoulder pad stays put on a shoulder. This means that the bag can be pulled to the front of the body or pushed to the back without repositioning the strap. Good for when we’re rushing through airports and crowded town squares. The strap itself is thick, sturdy, wide enough to not dig into skin when the bag is heavy [the way seatbelt straps do]. With an unfancy [no seatbelt buckle, ratchet, or plastic latch here] adjustment mechanism that simply works and is simply easy to use standing or on the go.

Back down to the bag. Two buckles. We’ll loosen them when we’re holding more and tighten them to keep things tucked in when there’s less. Unbuckle one and notice there’s no velcro holding the flap down. For an actual bike messenger, I can see why velcro would be useful to prevent the flap from, well, flappingand being a literal drag. For the rest of us, having velcro here is baffling—two fastening systems to keep the same part down, but the velcro preventing us from reaching in to the bag when it’s buckled to get something out while on the move. But that’s very much the convention with today’s popular bags.

Under the flap, a zippered mesh pocket to see in to. Quick access, good for keeping smaller objects that we might need to see. And above that a pull to change the size of the opening of the main compartment. Hold more, hold less, always secure.

Inside the main compartment, four front pockets. Bigger ones closer to the front outside. Smaller ones below with mesh. Obvious places for writing implements, notepad, phone, water bottle etc. [I bought this bag many years before owning a mobile, so don’t be surprised that there aren’t mobile or tablet specific pockets.]

Another compartment inside the main compartment. For laptops, or whatever. The bag came with a sleeve that was kept in via that velcro strip. But note that it wasn’t built in. So we could take it out. Replace it with a different one when tech changes. Or not use it and just have a larger main compartment. An option that provides function but doesn’t saddle us with something that has an inherently short useful life. Which might not look intentional, but notice the pull that can change the size of the opening and secure it. That wouldn’t be necessary if it was designed for a fixed single use of a particular laptop sleeve size and configuration.

Each of these design elements give us function, not take it away. They afford us ways of using the object which don’t collide with each other. The net experience is one of leverage, value from the very act of using the thing, and never having the design prevent us from getting value.

--

These ideas can’t be new. The thinking is rough, but it serves.

Aneel's razor for design-- Do not create affordances beyond necessity.

• First corollary: Do not create affordances that countervail natural patterns of use.
• Second corollary: Do not create affordances that countervail conventional patterns of use.
• Third corollary: Any affordance that does countervail natural or conventional patterns of use will create a cognitive barrier that must be overcome through
  • Education
  • Some bridging, stepwise path to transitioning to the new pattern from the old
  • Psychological support during the process of achieving competence at, and habituating of, the new pattern

what aws is not

In 2004, SQS and AWIS beta-ed.

In 2005, MT beta-ed.

In 2006, S3 and EC2 beta-ed.

From there, the pace of releases has skyrocketed (something we should put value on). AWS started by turning basic computation services into utilities. They've since done the same to a wide range of technology capabilities--dozens of services, hundreds of options, a combinatorial explosion of capabilities. So far so that we could reproduce all the functions and services provided by any data center anywhere.

That's where AWS is. AWS is not a commodity, though specific AWS services may become commodities. AWS is not basic computation services. AWS is not just for startups or web2.0 or mobile or small shops or transient projects or marketing or unregulated.. etc.

AWS is the successful utility-isation of ever more, and ever more valuable, technology services.

They are building the AWS of next year or further out through utility-ifying whatever it is that their ecosystem (customers included) is telling them (through behavior) is worth paying for. 

To really compete, you'd have to: match the ecosystem play and exert margin pressure. The former you could do through co-option--which would require taking over the service supply chain--or through drawing your own ecosystem to some core differentiation (e.g. live migration on GCE or seamless public/private experience on Azure). The latter can only be afforded by a few organizations (Google and Microsoft).

Hat tip: Most of the thought above is a direct result of, or informed by, Simon Wardley.

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.

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.

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.