What kind of software business can you build today?

I took a couple of months “off” before joining Honeycomb — spent mostly doing go to market consulting work for pre-launch startups and talking to people about what’s interesting, clocking 2–5 meetings a day.

Exhausting. Interesting.

TL;DR

You can either build a marketplace or be vertically integrated.

What you cannot do is build a platform, unless it’s for some completely un[der]served market.

Platform plays are hard

This should be a truism. How do you compete with Amazon, Google, or even Twilio? If we take them on head on, we lose. There’s nothing you’re going to build that they can’t copy. Witness the snap-ification of all Facebook properties.

Users who come to you first, an entirely new generation, may stay with you. But the vast population using an existing platform will prefer to use that platform’s copy of your feature because the value to them generated by the network effects (and their own personal investment) of the incumbent platform is not worth abandoning to start from scratch on your thing.

Platforms tend to be subject to winner-take-most-if-not-all dynamics and you have to find somewhere where a winner has not already taken the most.

Thus un[der]served markets. It seems there’s plenty of space to build non-generic platforms for specific markets with their own needs, language, culture, and particularities. Of course that’s TAM limiting — and unless there are premiums to be charged (high relative margins) — maybe not fit for venture capital.

Be vertically integrated

Instead of building wide, build deep. Although I think this applies more to existing software businesses rather than someone building something new. Unless it’s in an unserved niche, in which case maybe you can build deep before attracting too much attention from outside the market you choose to operate in.

If you look at Salesforce’s acquisitions, ignoring the usual failed forays, what stands out is that they are going deep in go to market. They’re buying up bits of the funnel, including customer success/support for the world of MRR/ARR driven GTM machines.

Build (or modernize) marketplaces

Connect supply and demand that haven’t been connected before, or electro-internet-connectify a marketplace that’s still run off paper-faxes-and-phone-calls. Usually in the process you’ll either become a new (hopefully) value-adding intermediary or disintermediate incumbent rent-seekers.

See Haven and Grand Rounds.

What is the critical differentiator for incumbents, and can some aspect of that differentiator be digitized? If that differentiator is digitized, competition shifts to the user experience, which gives a significant advantage to new entrants built around the proper incentives Companies that win the user experience can generate a virtuous cycle where their ownership of consumers/users attracts suppliers which improves the user experience— Aggregation Theory by Ben Thompson

Product [Marketing] is Managing Expectations

There’s a natural tension in the act of building a product. We have our projection of who we’re building it for (usually ourselves and not anyone else), what we want to build, what it will do, and how it will be used, etc. Users have their own projection of what they want us to build, who we’re building it for (them and not us), what it will do, how they will use it, etc.

Bridging the gap, finding the middle ground between these perspectives is why product / product marketing exist. It’s a constant effort in calibration, because:

• Who we think we’re building for doesn’t end up being the only, or many times even the biggest, constituent
• What we want to build is rarely exactly what’s wanted by users
• How we think it will be used is only a subset of how people actually use it

Our imaginations are small and the number of “corner cases” large — less like corners and more like whole edges we just can’t conceive of.

Doing this well is a matter of communication. In both directions.

The problem with communication is the illusion that it has occurred. — Jennifer Pahlka, 6th Blitzscaling class

Usually what we’re doing is not communicating. It’s broadcasting. And what we push is for our own utility as sellers-of-goods:

• Who the user and buyer is, so people can rule themselves in/out
• What the value is, so people can be convinced they’ll be better off
• What the product/solution is, so people can compare the thing to other things and categorize it
• What the technology is, so people can be bamboozled by buzzwords or impressed by our engineering chops
• What the use cases are, so people know how they will experience the value
• What the pricing or buying process is, so people know how they will consume it

What we tend not to communicate is expectations.

• How do I think you’re going to use the product?
• What the range of inputs I expect?
• What range of outputs you can expect?
• What have I imagined you doing?
• What have I imagined you not doing?
• Where are the cracks and fissures in the product, in the experience?
• How should you interpret the expected and unexpected outputs?
• How do you think you’re going to use the product?
• What do you expect it to do when you use it?
• What don’t you expect?
• What do you think the value is? Etc.

We can’t manage expectations we don’t communicate

Without communicating and consuming expectations from users, we can’tmanage them. I’ve found this to be one of the central causes of [undesired] friction and poor user experience.

Theory in Practice — OODA, Mapping, Antifragility

Based on a talk presented at Velocity 2016 in Santa Clara, this post tries to show the practical application of concepts like OODA, Wardley Maps, and Antifragility with examples from my day-to-day work at a startup.

Theory

OODA — Observe Orient Decide Act

Observe the situation, i.e. acquire data. Orient to the data, the universe of discourse, the operating environment, what is and isn’t possible, and other actors and their actions. Decide on a course of action. Act on it.

Typically, you hear people saying that we’re supposed to go through the loop [O -> O -> D -> A -> O -> O…] faster than others. Let’s break that down.

• If we traverse the loop before an 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 outdated model of the world.
• If we traverse the loop before they 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.
• If we traverse the loop at this faster tempo continuously, we frustrate their attempt to orient — causing disorientation — changing the environment faster than they can apprehend, much rather act.
• We move further ahead in time. Or to be more exact, they’re falling further backwards: unable to match observations to models, change orientation, have confidence in decisions, or act meaningfully.

This is what Boyd called operating inside someone’s time scale.

Our main means of connecting the components of the loop is via models (and projections of cause/effect based on those models). Observations are tied into and given context via models.

Another way to think of models is as maps.

Mapping

This is a Wardley, or Value Chain, Map. It’s the most useful model I’ve encountered for building products or businesses. Watch Simon’s OSCONkeynotes or read his blog to really dig in to the concept.

It starts with a user need at the top. What problem are we solving? How are we going to make someone’s life better.

Then it goes deep, laying out the supply (dependency) chain of components needed to service that need. The further down, the less visible and exposed the component is to our end user. For example, if we’re building a SaaS product, users are never (or should never) be exposed to the systems running the code. This is the Y axis.

The X axis is where it gets interesting. It provides stages of development that components map into. Nearly everything naturally moves from the left to the right over time as invented or discovered things become standardized, well understood, built by more producers competing for market share, until some eventually become absolute commodities or provided as utilities. It’s a kind of natural evolution.

• Genesis [stage 1]: something that’s being discovered/built from scratch
• Custom Built [stage 2]: built out of existing technologies but highly customized for a specific use case and not generalized to broad use
• Product [stage 3]: COTS software, something bought from someone else vs self-built
• Commodity [stage 4]: something that’s effectively fungible, for which there are multiple equivalent providers, that may be provided as a utility

Individual components, regardless of their stage, can be expanded into finer grained production pipelines, marked as something that’s either provided or consumed, and aligned with methodologies like in-house-agile-developed vs outsourced-to-cloud-provider.

Finally, each component can be treaded as a piece on the field and moving them around as functions of product strategy, attempts at changing the competitive landscape.

For example, open sourcing something to try to commoditize it or create a de facto standard. Or providing something as a utility / platform / API in order to build a moat (that you can also consume) out of the ecosystem that you engender around it

[Anti]Fragility

But everything is constantly changing. Which means our map can become stale fast. Which makes us fragile — exposed and unaware — to ever more risks. Black swans.

A black swan is only a black swan if you can’t predict it (or assign it a probability). They’re inevitable. As our maps become out of synch with the real world, non-black swans become black swans. It’s possible to be fragile to one kind of black swan but not another. There are activities or patterns that will make us fragile with respect to something. And those that will make us antifragile.

There’s no such thing as absolute antifragility. It’s contextual. A severe enough stressor over a short enough time period will destroy anything.

Maps can be made robust (to some scale) through adaptive mechanisms, learning and correcting to match for change in the world.

But beyond some scale, every map is fragile. The world can change faster than, or so severely that, any attempt to update the map fails. Events can get inside a map’s timescale.

Systems can be antifragile (to some scale) through constant stress, breakage, refactoring, rebuilding, adaptation and evolution. This is basically how Netflix’s chaos army + the system-evolution mechanism that is their army of brains iterating on the construction and operation of their systems works.

For example, here’s our model of the APIs or services we rely on — smooth and reliable, with clearly defined boundaries and expected behavior. This is also the model that those things have of the APIs and services they rely on. All the way down

But this is how most things actually look. Eventually in the course of operation, the gaps line up in such a way that a minor fault event becomes magnified into systemic failure.

Systems, software, teams, societies — everything eventually crumbles under the weight of it’s own technical debt.

Which is why we should be refactoring, paying down technical debt, or what I just call “doing maintenance”, all the time at every layer.

Practice

Caveats: My views don’t represent those of my employer or anyone else and a great deal of detail is left out.

Example: mapping at work

I’ll build a map for a new feature SignalFx just released in beta.

Starting with the user need which I describe as “discovering known and unknown unknowns.”

A lot is left out, but generally speaking: on the top left we have the need, immediately connected to that is how that need is served and proceeding out from there is a generalized view of the supply chain of components needed to make it so.

Some things worth noting:

• We rely on utility or commodity technology and services for all our infrastructure hardware and software, like operating systems, and also middleware — using things like AWS, Linux, Kafka, Cassandra, Elasticsearch, etc. This is standard behavior for a software as a service company.
• We rely on relatively standard means of getting data into the system, in our case collectd, StatsD, Dropwizard metrics, etc., and a host of plugins and libraries that conform to open APIs and use well known open, or public, protocols.
• We can see that there’s a lynchpin without which the map would fall apart, the streaming real-time analytics engine.
• In order to build what was needed to serve that user need we started with, we needed to build many other things: a specialized quantization service, lossless + real-time message bus, specialized timeseries database, a high-performance metadata store, real-time streaming analytics engine, and an interactive real-time web-based visualization for streaming data, etc.

Many of the components we built are, if they were generalized, standalone products that others build entire companies on. In this specific case those are all the open source technologies — Kafka, Cassandra, Elasticsearch, etc — that we built our highly customized components out of.

Given all of that, I have one important positive question each day: Given the amount of time I’m going to spend working today, what one thing can I do to move the needle in serving this user need through what we do?

And one negative one, seeking invalidation: Is there any evidence that our map, our hypothesis, our approach, have been invalidated?

• Is our projected user need real? Will people pay for it? Is it the problem they actually want solved? Do people really not want leverage? Do they not want to be given more power and time through tools? Do they want thinking to be replaced, instead of force-multiplied?
• Is our lynchpin really the point of leverage and differentiation we believe it to be? Has it become a commodity and we’re just fooling ourselves into thinking we’ve built something novel?
• Has the territory changed in any way, through macro trends or the actions of players in the ecosystem, such that we need to rework our model?

Example: knowing what’s possible

Imagine we want to build a personal relationship management [PRM] system to meet some a need for people to manage their complicated and ever-growing network of contacts.

The top left is where we’re starting from. The y-axis is basically features or sub-capabilities that add up to something. The x-axis is what they add up to: products or capabilities that are in and of themselves valuable. The bar for something belonging in the leading row is being a viable sub-product. Everything in the column below are the features needed for it. Where the line is for being able to declare that we’ve built a minimum usable product may be different per column, as may the line for what constitutes an MVP.

We have limited time, people, and money. So we can only build so many things at once. Let’s say we can only build one column at a time. We have to get to usability and viability in each column to be able to expand users and business sufficiently to build the next column.

But every single thing we build limits our options for the next thing we build. We can go down and we can go to the right.

We can scrap everything further below and further to the right of the point we’re at today and figure out something else to build from where we are. This is effectively a pivot.

But what we can’t do is go from 3 steps down in the 2nd column [a graph of your contacts that’s auto generated based on your communications with them over Gmail, Twitter, LinkedIn, Facebook, and Outlook email that shows degrees of separation] to, say, a restaurant reservations and point of sales SaaS product. There’s no getting from here to there. But you can get from here to a product referral network.

Seeking invalidation:

• Is a personal relationship management service still the best way to serve the user need? Is there a better way?
• Can we build to that better way from where we are?
• Have we built an minimum usable product? Is it viable? Can we generate enough business (or funding) from what we’ve built to build the next thing?

Example: hiring for antifragility

The core principle of antifragility, as I see it, is to arrange things such that we get stronger through stress. More or less how muscle growth works.

How do you build that into an organization? How do you decrease brittleness? The only way I’ve ever found is through diversity. Inclusion, and forced exposure, to different points of views is absolutely necessary if we don’t want to get stuck — stuck in a way of thinking, stuck in a way of dealing with issues, stuck with a pattern of response, stuck in a point of view that makes us blind to threats and opportunities.

Think of it this way. We have to stir the pot in order to not get trapped in a local maximum. Not once, but constantly. Even a hint of homogeneity — whether it’s of people or ideas or practices or anything — is a clear signal that we are fragilizing and becoming brittle.

For my team, here’s what that looks like: no one in my org has a background in tech except for me. My background is both deep and wide, but it’s 90% tech. There’re just a large swath of things I’m blind to. What I’ve got is people who’ve studied art, biology, english lit, who don’t look like me or think like me. Things that I’m fragile to, they’re not. As a group, we’re way stronger than if I was hiring copies of myself.

Seeking invalidation:

• Is this the right team? Can they do what we need to do right now? Can they do what we need to do in a quarter, in a year, in 5 years?
• Are they the wrong team, or am I failing at
• Helping them get from where they are to where I need them to be?
• Getting the most out of their perspectives?
• Creating a safe environment for them to bring their best to the table?

Questions

John Allspaw asked if it’s possible for a person to be anti fragile. I don’t think so. I don’t think any given person or component of a system can be antifragile. I think groups and systems can be made antifragile. Complexity can be a symptom of the build up of antifragility in a system. Beyond some envelope, it’s also a harbinger of collapse.

Peter van Hardenberg asked where I set the bar. Assuming baseline functional competence (can do the job at hand), the next thing I look for is differentness. What do you bring to the table that’s unique from what we already have?

---

Wrapping up, here are the daily operating principles arising from this study:

Always be refactoring

Diversity has intrinsic value

Territory > Map

Seek invalidation

---

The above builds on ideas in these previous talks and posts:

• The Dangers of Models
• Change hurts
• Unicorns and the Language of Otherness

The original abstract was way too ambitious for a 40 min time slot. The presentation suffered quite a bit from me erratically moving through the material, trying to pack in too many ideas.

product rails

I’ve written about not forgetting the future you dreamed of to settle for the present you’ve made.

On the way to building something great, we inevitably build other (hopefully useful) things. We’re swayed by what customers claim to want, what engineers say can or cannot be done, what we can figure out how to market and sell, what investors think will make money, what the press gets excited by, etc.

It’s challenging to keep in mind where you intended to go when you’re working hard to just take the next step. Here's a way to think about it.

The top left is where we’re starting. Z is the vision. The y-axis is basically features or sub-capabilities that add up to something. The x-axis is what they add up to: products or capabilities that are in and of themselves valuable. The bar for something belonging in the leading row is being a minimum usable product subset of Z. Everything in the column below an MUP is what's needed for it. Where the line is for being able to declare that we've built an MUP (the depth needed in a column) may be different per column and needs to be called out. Where the line is for something that has go-to-market viability per column may be different still. All of which is different from the depth we want to go to. Z is realized when the whole matrix has been built.

Everything’s a hypothesis:

• Is each of the “products” sufficiently valuable that someone would pay for them on their own?
• Is the minimum usable depth we project actually sufficient for someone to experience value?
• Is the minimum usable depth sufficient to get the product to get the product to the point of go-to-market viability — we can market, sell, and close business against it? If not, how much further?
• Is going any deeper than that worthwhile for the customer or the business?
• Are these the right capabilities in the best order?

To some degree, the order doesn't matter. The ideal case is to get to something in each column that provides enough tangible value and positive experience that someone would pay for it before moving on. But as long as we don’t leave the matrix, we’re still progressing towards the vision.

At every step, we need metrics for success and failure. In my view, it’s more important to know what constitutes disconfirmatory evidence than confirmatory—so we know when it’s time to cut our losses and move on.

There's also an existential question: is Z the right thing. Are we building it for its own sake, or to solve some specific problem in the world? Assuming we’re driven to fix something, to make someone’s life better — what happens if there’s a better way to do it than this one? How do we even know? This is impossible without actively seeking disconfirmation.

This is where going to market matters the most. It’s the sensing mechanism to discover how the map compares to reality.

A final note: what we build today limits what we can build tomorrow. We can go deeper and broader. And we can stop where we are; discard everything that might follow, build a new vision to a new place. But that new place has to be reachable from where we are right now. Every thing we build closes some doors and opens others. It’s near impossible to do something completely discontinuous.

fantasy founder - elder interfaces

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

Over the years, I’ve tried to teach my grandmother to use computers, dumb phones, smart phones and tablets--with no success. She will learn one or two things (command sequences) to get something done for a little while, but nothing sticks.

Facts:

• English is her 5th language (depending on how you count subcontinental languages).
• She hasn’t had much schooling, up to 5th grade maybe.
• But she’s sharper than most people I know, having cogent conversations about geopolitics and doing relatively complex financial math in her head.
• Her formative years were in a developing country, traumatized by mob rule, lynchings and the like.
• Her first personal exposure to computers was in her 40s, and her first attempt at using computers was in her 60s.
• Recently, she had a stroke and lost some significant English comprehension circuitry.

Desktops, folders, files, that there are different kinds of files, applications, trees of objects, windows, visual controls, input controls, control contexts, focus, local vs remote, online vs offline, different affordances in different mediums, different affordances in different contexts on the same medium, contextual clues built into small variances in visual presentation, the boundaries that separate one object from another, the different kinds of boundaries presented for different kinds of objects in different mediums or contexts—are all bound to and presume a certain cultural context and assume a certain set of preexisting models of how the world is organized and works.

The cultural assumptions built into our interfaces render them incomprehensible.

How we might overcome them:

• No files: If you didn’t grow up with computers or with desks and file folders, the metaphor doesn’t work. It doesn’t translate into the model which tells you that this thing is an object and the same form of object can have different content, etc. Better would be just apps which find and organize related content, the Apple way — stepping away from having to know how things are made and work to only needing to know what it is you want to do.
• No exposure of the filesystem: An extension of the last point: no folders, no browsing, no object tree, no files—just actions. That’s what the machine exists for and that’s why we go to it, to do something. Tool and action are fundamental enough concepts to transcend cultural context.
• Feedback on every action: I noticed that my grandmother would frequently do something on a computer or tablet and not know that she had done it or not believe that it had happend, especially things that are ephemeral like copying text. When you don’t have a model for how the system works, you need explicit feedback that the thing you’re trying to do was done or that you’ve done a thing, period. Strong visual, tactile and/or audio feedback for every action taken to tell you not just that you have actually done it, but that the intent has been registered by the system.
• Larger tolerances: Because fine motor skills deteriorate with age, getting shaky fingers right on a button is an unreasonable expectation, soclose enough has to be sufficient.
• Space between things: Corollary to the last point, what defines close enough should be consistent and big enough that it becomes intuitive (as an affordance) and feels easy. Which means sufficient space between all control elements to allow for not getting right on the button — as in, the whole grid square where the button is present is an active control.
• No menus: Big buttons with big words and/or big icons, all the way; because glaucoma, macular degeneration, etc.
• Less distractions: Wallpapers with objects in them or that could be confused for objects, window-dressing, flashy-visual-effects that look pretty but don’t help in navigation, orientation, or feedback create noise that makes it harder to adapt to a new environment. It’s like when you’re learning a foreign language—it’s much harder to understand what’s being said in a crowded, noisy cafe than it is in a quiet setting where you can focus on the one signal that matters instead of on trying to filter out the dozens that don’t.
• Click or no click: The whole overloaded clicking — left, right, middle, double, triple, click+drag, blah blah blah — imposes a significant burden on the user to understand and remember all the things that can be done with a single input element. Pair that with deteriorating fine motor skills, deteriorating sight, and lack of clear feedback on whether or not an action was taken and you have a recipe for confusion. Better: there is just click, or no click.
• Limit controls and contexts: Even when I would teach my grandmother something successful, frequently how I showed her to do something in one application would not translate at all to a different application or to a different context, like manipulating files. This is challenging in the extreme when you have no way of knowing that the context has even changed because you don’t have a mental model for the thing you’re looking at. The number of controls available in any given app should be stripped to the minimum, so there’s less to remember; the number of contexts (app vs app vs system) stripped to the minimum so there’s less to remember; and the variances between contexts (different control in different contexts) stripped to a minimum so there’s less to remember.
• Fullscreen everything: That apps need to be opened or closed may even be an unnecessary metaphor. If every app took up the whole screen, was open all the time, and there was an ever-present mechanism to switch between them—then that’s a few more things that don’t have to be remembered. We could reduce the cognitive burden down to: which of these dozen things do I want to do right now/next -> select.

Mobile interfaces are moving in the right direction.

If I put my product hat on and make my grandmother the target user, what she really wants out of a computer comes down to a managed communications experience which empower her to:

• Get in touch with the family and friends easily. Contacts as actions, the faces of the people she wants to contact as buttons on a screen that get in touch with them via video, phone or text. We, as relatives, need a way to remotely keep those contacts up to date via push to her device or a centralized service that propagates to her device.
• Keep up with loved ones when we’re not talking. Facebook without the Facebook, a timeline of updates from loved ones, pictures and videos and text, shared directly to her device, in a single app, blown up full screen. A feed that any of us can push content to or that can consume and present content from things like Facebook.
• Have important information and reminders without having to look for it. Emergency and medical information as collaborative app, pushed to the device by doctors and loved ones for consumption by all parties involved in care, including her for things like “Hey it’s 10am, take the blue pill!”.
• Let loved ones help. Shared calendar that loved ones and caregivers can push events onto, like appointments and birthdays. Delegation of control for all apps and services so she can say to her banking app that I am designated to make sure her bills get paid. Or, so I can have an Uber pick her up to take her to the airport and have the notifications go to her device instead of mine. Or, so a caregiver cantake over her device and it’s capabilities (like the camera) and show her things on it remotely or check in on her.
• Stay in touch with the world. News and entertainment, in one of the languages she understands, including: newspapers, streaming tv and movies, and games. The usual stuff that everyone enjoys. ☺

Why this doesn’t exist is beyond me. There’s a fortune to be made for someone with the single-mindedness to build interfaces for people who are older or didn't grow up with computers or lack our cultural metaphors or have zero exposure to computers outside of phones etc. 

fantasy founder - identify me

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

This is a recurring idea that’s been bouncing around my brain (and written about) since the days of using ICQ plugins to talk to every messaging system there was (irc, usenet, email, aim), more or less consolidating identity into that one application. 

This would only be useful in the case where you want or need to be identified. 

Consider this:

• Most of us have multiple online identities that don’t serve a purpose, other than there’s no infrastructure to do otherwise in a way that’s satisfactory to everyone who wants to be identified or everyone who wants to identify us
• Centralized password control exists through things like OnePass, but then we’re dependent on OnePass to stay up, serve our interests etc
• Services like Facebook let us log in to other things using our FB identity, which is convenient but gives FB ever more data about what we do, where we do it, etc.. all for purposes that aren’t necessarily in our interests
• What if we could have consolidated virtual identities that all services, including things like Google and FB, used but that were under our control?
• What if it was completely decentralized and could be run on our phones, with the actual profile itself encrypted and replicated across multiple cloud services (DropBox, Google Drive, S3 bucket, etc) or our own servers (VPS, colo, net-attached-Drobo, etc) for storage?
• Plus a password or passphrase to decrypt the profile for modifications and an (or any) editor to modify it
• We could have a standard (extensible) profile format that could be mapped to/from any given service
• And a way, like with Facebook application security settings, to allow/disallow access to specific parts of the profile on a per-service basis—so maybe Facebook can see your name, birthday, company, home city but LiinkedIn can only see your name and company
• We could have elements of the profile tagged so one could say something like: name is ok for handing out to social networks but home address only goes to merchants that have to verify credit cards--thus having a mapping or filter by service type
• Services could request certain profile elements and we could either auto-approve based on the above tagging or individually allow/disallow usage or allow creation of if they don't exist or maybe only send back acceptance of a subset of what was asked for

This would require some kind of protocol for asking for and finding an identity that would route the request to the right place. Something like DNS. We could call it ID-NS!

Amazon, Google, Facebook, LinkedIn and Twitter’s auth services could work like this. But the problem is that all those services value our identities and the ability to tie actions to those. I want a service who’s single and only utility is to hold and distribute identity per my authorization. 

If such a utility existed and gained mass popularity, I’d bet we as end users wouldn’t have to pay for it. Vendors would pay 1) to access it and 2) to be allowed to tie your actions to it.

I'd call it IdenitfyMe (points if you catch the reference!).

It’s interesting that the SSA hasn’t already built this, given that they more or less serve as the identity clearinghouse for the government.

//Side note: There are plenty of providers that do federated identity for federated authentication (single sign on), though no one talks about it that way. I really don’t think SSO matters. It’s a different problem altogether from having a single virtual identity. Authentication != Identification. How you authenticate someone’s virtual identity to arrange for SSO across multiple services is a related, but distinct, problem with it’s own set of hurdles.

fantasy vc - grand rounds

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

A few months ago, my friend James joined Grand Rounds. Most of Silicon Valley spouts a fountain of bullshit claiming change-the-world status. This team actually does it.

Consider this: 

• It takes a very long time for studied, tested, proven and well known advances in medical and surgical practice to actually become conventional and prevalent—as in, a decade or more

• The industry, as a whole, is set against advancement because advancement usually means more precise diagnoses and less money due to fewer surgical procedures, even though quality of life improves

• There is no way to connect those who need information about new discoveries, new test, new procedures with those who lead the field and discovered the advances—people go to the doctors and practitioners they have access to

• Those PhD/MDs doing the research, creating the studies, going through FDA approvals and fighting to make a better life for all of us want to accelerate the process—they’re desperate to get the life-saving discoveries, tests and procedures they’ve developed adopted by the world

• What is a second opinion from one of those experts worth?

• What is it worth to us, as individuals?

• What is it worth to the companies that fund their own insurance programs (every big one)?

• What happens when $1M worth of unnecessary procedures and hospital visits are replaced by a $10,000 outpatient visit? How much is that worth across an insured employee base? What if that happened a dozen times a year? A hundred times a year?

10% of the cases drive 66% of the costs for employers, and employers don’t have the right tools for resolving them. Obesity or smoking cessation programs are great, but the reality is that a small number of truly complex and expensive cases emerge in the workforce every year and account for a majority of a company’s overall healthcare spend.

As I’ve said, there are two ways to disruption: either you disrupt by doing something new or you disrupt by changing the supply chain, removing middlemen, disintermediating or consolidating intermediaries. Grand Rounds short-circuits the supply chain of medical information. And by so doing they’ve already saved lives. How many other startups can you say that about?

--

None of this is to say that they're guaranteed success. Or won't get crushed by entrenched interests. Or even scooped up before they become too successful. Just that I would've placed that bet.

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

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.