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

Creating Career Options in Tech

The Geek Whisperers is a great podcast focused on the non-tech side of tech careers — mentorship, career building, leadership, etc. They had me on a couple of GlueCon’s ago to discuss how to think about career options and advancement in tech. You can listen to the whole thing here. 

Get exposure

In general, you can’t really know what all your career options are. But what you can do is set yourself up in a situation or create an environment where options present themselves. You can sort of maximize the serendipity and the optionality around you. For me that was moving from a role that was buried in an organization to a role that exposed me to a larger diversity of people and projects.

In an engineering position I had to deal with architects, so I became an architect. As an architect I had to deal with product managers, so I became a product manager. As a product manager, I had to deal with marketing roles so I moved to one of those.

Take adjacent roles

It’s hard to totally jump two or three degrees from what you’re doing, but what I think you can do relatively easily is to move to an adjacent discipline. Then you get exposed to a bunch of new things, from which you can pick another adjacent discipline.

I have a personal mantra associated with this: if you think someone (or everyone) in a particular role is an idiot, you probably don’t understand it so you should go do it to figure it out.

Of course, my journey has been totally accidental. In each case I was either unhappy with what I was doing or unhappy with what people in the adjacent job were doing and wanted to fix it. Or sometimes both. So I would just start doing the job until it was self-evident that people would have to fire me to stop me from doing it.

What I’ve found consistently in tech is that you can basically do any job you want, if you just go ahead and do it. The person you’re working for right now might not let you do it, but someone else is going to let you do it.

“You can basically do any job you want, if you just go ahead and do it.”

That’s a privileged statement. I don’t know if that’s actually true for non-white-or-asian-males. And if it is , the barriers to entry or transition are likely much higher.

In any situation, there’s someone on the other side of the table from you. That’s adjacent. Whoever that is, whatever that role is, you should be able to do some part of it. If you’re not able to start doing it, it’s probably too many steps away.

Tweet without intent

Twitter is responsible for my entire career. Unbeknownst to myself, I built a reputation and people started approaching me to take on new roles because of my interactions there.

What is it about Twitter that builds credibility? My theory is that the validation provided by someone’s public persona expressing what it is that they do on a regular basis is kinda like establishing bona fides in a meeting. But constantly, every day.

Everyone has an individual style. My style is to try not to have an intent in any forum where I’m representing myself (and not a business). I try to use Twitter the way I would use a party, or any other social situation. Whatever I would normally do. I tweet when I have a coffee because in a social situation it would be normal for me to walk up with a cup of coffee, so doing it on Twitter is normal.

I know people who do use Twitter with intent: intent to get a job, to raise their profile, etc. It works for them. So I’m not saying you shouldn’t do that. It just doesn’t work for me.

Promises, Microservices, and Intent

Last year, after a bit of wrangling and lots of editing by the fantastic Jenn Webb, O’Reilly published a discussion Mark Burgess and I had on one of his trips through the Valley as a podcast.

The audio is iffy, which is entirely my fault. I have zero experience recording for any purpose other than capturing notes from interviews for my own use later.

I’ve referenced Mark’s work before in talks and presentations like this one at O’Reilly Velocity two years ago.

The interesting thing about Mark’s view is that he approaches systems as a physicist, looking at systems as phenomena, as things that happen, as something that behaves with behaviors that can be described. My highlights from our conversation below.

Measuring Intent

It all goes back to scales, the order of magnitude we look at. When you measure, observe, and characterize the world you have to find something to measure it by. The descriptions of systems are often qualitatively different at different scales. This is not something we tend to understand in a clear way in CS.

In CS, you’re mostly focused on intent — what we call semantics. There’s no numerical measurement. We simply write code. In physical phenomena, changes in measurable things have scales. Part of my work has been to figure out how we could invent scales and measuring sticks for semantics. This is how Promise Theory came about.

A promise is a description of intent that you share with someone. Until you share it, it’s just an intent. As soon as you share it, it becomes a promise. In a promise-oriented view, you look at what are the agencies capable of bringing about state (making promises). In the most abstract sense, an agency is anything with a purpose or function with some semantics and behavior — machines, people, tools.

Microservices’ Promises

The purpose of a promise is to describe that behavior and be able to break it down into constituent parts. It provides a language for systems that allows us to describe the elements of a system and what happens when you put them together, like atoms into molecules, etc.

Microservices are a modern incarnation of this idea.

There are two ends of a promise: the offer of a service and the acceptance of it. You may choose to accept less than is offered. This is another way of talking about autonomy of the actors in a system. This is a good representation of how the world actually works. You simply cannot force your will onto another actor, or device, without attacking it in some way. Ultimately, it’s up to that agent to act the way you want.

This drives you to understand all the communications pathways in a system and exposes all the failure modes that can manifest.

Humans Feed Back

They’re also a great example of where humans enter the picture.

We cannot understand computer systems without taking into account humans, because they are an integral part providing not only input, but feedback (and modification). It’s a symbiosis. Microservices are an example of how you can break things down to smaller, more manageable pieces in order to scale the human.

If this kind of thing interest you at all, read Mark’s books: In Search of Certainty andThinking in Promises.

Always Be Refactoring

We have a tendency to treat things that have already come to pass as if they’re permanent features of the universe. Taking them for granted, like we do with mountains, electricity, and the postal service. We all know that everything break down over time. Yet we don’t generally act to prevent it until we’re directly impacted or impeded. We can’t help but to ignore maintaining the most basic things we rely on. But mountains move, electricity flickers, and sometimes mail doesn’t show up.

This is closely related to the mechanics of technical debt:

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on.

But the mechanism seems more general… and inevitable. There’s always debt. Even thoroughly thought out plans meticulously executed, thoughtful of corner cases, eventually drag us down and blow up. As time goes on things change, assumptions that held cease to hold, and the magnitude of risk becomes volatile.

Every decision to build, do, or be something involves a tradeoff — not just at the time of the decision but ongoing over time and over multiple dimensions:

• There are things you cannot build on top of what you’ve already built. Being a neurosurgeon does not lend itself to a future career as a trapeze artist. Decisions you make today have tradeoffs tomorrow.
• Context and facts change over time. Concrete erodes and breaks down under pressure, bridges collapse. Today’s tradeoffs become different tradeoffs tomorrow.

These mechanisms are general and show up everywhere: psychological debt, business model debt, org structure debt, cultural debt, regulatory debt, etc. All our past decisions haunt us.

The only method I’ve found for dealing with this is to commit to refactoring as a way of life. Which implies constant reassessment against the environment to determine the nature and extent of refactoring required, the risks posed by doing more or less, sooner or later. And supports the general notion of holding strong opinions weekly.

Strong opinions held weakly as a principle implies a commitment to disproof of theory and anti-dogmatism. Which requires not investing our personal identities, not seeing ourselves made up of, whatever things we might have built or believed in the past.

This is how we arrive at one of the operating principles in this discussion of applying theoretical tools like OODA, Mapping, and Antifragility to practice: always be refactoring.

Going down the rabbit hole of collapse
The collapse of complex systems comes from somewhere. Problems have to encounter fissures that concentrate and magnify their impact, giving small or unexpected events huge leverage (Black Swans).

In natural systems, this is both a given and generally useful to the protection of the overall system over time. Periodic collapse at all layers is required for evolutionary progress for living systems and for greater stability (finding newer/better local/global valleys over some time period).

In human systems, the fissures need to be constantly found and repaired or manipulated to reduce their blast radius (failure domain) — which changes over time. Thus increasing our ability to deal with them through constant testing/failure/repair (antifragility).

But undergoing this constant cycle requires not being attached to any particular abstraction or model of how the world works. Because every model hides discontinuities at the lower level and glosses over handoffs, gaps, and fissures between objects at the more granular scale (because they appear continuous at the scale of the model).

It requires being willing to abandon the abstraction when reality proves it no longer applies, has become wrong, is broken, etc. And it requires constant checking of any model at any scale against the things over which it is abstracting at the lower scale for fissures (risks) that need refactoring.

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.

Embracing the reality of every thing and one

Our mental capacity is limited. There are only so many things you can see, so many things you can hear, so many thoughts you can think, so many ideas you can have, so many people you can remember, so big a family you can manage, so complex a system you can understand all of — at any moment.

The things we have to deal with, understand and make decisions about every day outstrip our capacity. We are limited in bandwidth. The bounds Shannon discovered for signal processing and communication systems apply every bit to us.

We are signal processors and communicators

But evolution has given us tools to overcome our limited capacity, similar to the tools we’ve built to overcome the limited capacity of our communications and storage systems — a kind of compression. We find ways to cram more information into less space, less concepts, less words, less ideas, less Dunbar slots. This is essentially the purpose of abstraction (generalizing).

Think of a table you’ve sat at today. There are infinitely many tables. But we don’t have to learn that every new variation of a table that we see is a table. “Table” the abstraction subsumes all actual tables. Every real table is compressed into the “table” in our brains so we can recognize all tables as being tables without having to maintain an infinitely large catalog of objects, each separately labeled as “table”. The world of tables isn’t simple and continuous. But our abstract “table” is.

Think of google maps. It gives us a model of the world sufficiently granular to get us from point A to point B, assuming the world hasn’t changed too much since when that picture was built.

If we only ever learn to navigate from the map, we may not be able to deal with a world that’s changed in big (or even small) ways from the map. Or with a world that changes faster than the map does. Or with a world that’s simply different when you’re on the ground dealing with the actual terrain. Our interface with the world is often at the wrong level of abstraction.

Our interface with the world is often wrong

Treating abstractions as if they are the real world works fine until the real world does not conform to the model. What do we do then? If we’ve only ever interacted with the model and never learned the ways in which the world regularly deviates — the range of ways in which it can deviate — from our maps, we’re at a loss. Like the stereotypes and biases we rely on when thinking about people of different ethnicities and backgrounds that don’t at all apply to any given person we meet. Which happens. It always happens. It always will.

When we encounter a new table, we don’t hesitate to adapt how we behave to fit its specific dimensions, placement, etc. It’s clear that trying to let go of the coffee cup at four feet in the air when the table tops out at two feet won’t end well. That is, we actually observe the characteristics of the new thing and treat it according to its real properties — and not those of some idealized abstract table.

Being able to not only create abstractions out of things, but then also treating each individual thing — from the systems we create to the people we encounter — according to their distinct character is thecore skill (and challenge) for the world we’ve created.

Embracing the reality of everything and everyone is the core skill — and challenge — of our world

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.

minimum usable product

A lesson from 9ish years in and adjacent to product work.

Minimum viability is very much a product-outwards perspective: what’s the least amount of work we can do to find out whether going down this line of thinking is a business idea that’s worth being invested in. It has nothing to do with viability for users.

It’s a well worn notion that the right way to build a product is to iterate through stages of development, where at each stage you deliver something that, on it’s own, provides real incremental value by accomplishing the user's goal appreciably faster/cheaper/better than was possible before. A functional approach.

What makes a product viable for use is something that’s more usable at each stage of creation; that creates experiences of greater efficacy at every turn; that provides incremental wins that add up to something much greater—a sense of joy. [Something I’ve seen enough times to say it with a straight face.] This is distinctly not a product-out orientation—but instead a user-in orientation.

We have to make up for the pain we put users through--our stumbling attempts at building something useful, the suffering of (re)learning how to do something, breaking their workflows--with some pleasure on the other side. 

Leading to questions that should be answered (see the HEART framework for thoroughness):

• What is the qualitative, subjective improvement from the perspective of the user? Does it feel better? Does it yield results of higher quality?
• What is the quantitative, objective improvement from the perspective of the user? Does it get the task done faster? Does it yield more results?
• What is the quantitative, objective improvement from the perspective of the product? Is it faster? Does it do more of what users want?

Make Minimum Usable Products.

we are not who we think we are

Presented at Velocity NY 2015. About 2/3rds of the way through, I lost my way. But it seemed to work anyway. What I attempted to do was to put the subtext on the slides while I was presenting the overt part.

Let’s talk about the epistemology of the self. 

We, as human beings with human brains and human mechanisms, build models. It’s how we understand the world. Our models influence what we perceive, how we grasp it, and what we can make of those interactions with the world. They are the boundaries beyond which we’re simply unable to grasp what we encounter (and frequently reject), the basis of all bias, why we fail to understand each other.

We take the world and divide it up into neat little categories, according to our models, that seam whole and complete and seamless, with hard black and white boundaries. These categories make it easier to understand and deal with the multivariate complexity of the world. They make it easier to scale our brains. 

BLACK AMERICAN EUROPEAN GEEK MALE FEMALE TRANS HOMOSEXUAL DESIGNER  LESBIAN BI ASIAN CREATIVE NERD WHITE ANALYTICAL INTP ENFJ NERD HISPANIC WASP FOB ABCD CONSERVATIVE GOTH LIBERAL RAVER AD NAUSEUM

And we do this to ourselves. I am a set of labels and categories and group memberships. These are a kind of index, that helps me place myself in the world, in my model of the world, relative to everything else. It gives me a comforting feeling. It’s the comforting story I tell myself about who and what I am. A kind of self-myth.

FIRST GENERATION SON OF IMMIGRANTS FIRST TO GO TO COLLEGE INTROVERTED SOCIALLY AWKWARD HUSBAND STEP-FATHER STEP-SON FISCALLY CONSERVATIVE SOCIALLY LIBERAL CYNICAL REALIST CLOSET OPTIMIST ADAPTABLE INDEPENDENT GROWN ASS MAN LOVING SUPPORTIVE EMPATHY-ABLE ONE OF THE SMARTER PEOPLE IN ANY ROOM CAN UNDERSTAND ANY TECHNICAL THING SPECIAL STRONG WILLED

It's a useful and important myth. Without the self-model, we'd have no way of understanding anything. It’s the ultimate frame of reference. Without it, you wouldn’t know how far to move your fingers to hit the keys or how to communicate with anyone.

And it's built on truths--I am all those labels. They're just not necessarily complete or accurate. The messy, less clear cut bits that get abstracted away by the model inevitably make themselves known in ways we can’t even see most of the time.

GREW UP FATHERLESS -> TRUST ISSUES

GREW UP POOR -> FINANCIAL INSECURITY AND NEUROSIS

It’s not just that there are things below the surface that we don’t know about each other. It's that there are things below the surface we don’t even know about ourselves. They come out in our assumptions, our biases, our automatized behaviors.

EMPATHY IS NOT TO BE EXPECTED, SO DON'T HAVE ANY

SUPPORT WILL NOT BE GIVEN, SO DON’T GIVE ANY

YOU ARE AN OUTSIDER, SO MAKE OUTSIDERS OF OTHERS

Other people don't really see you; they see what you present. You can't really see yourself; you only see what you present to yourself.

EXTERNAL: CONFIDENT AND COMPETENT HIGH ACHIEVER

INTERNAL: UNDERDOG AND PERENNIAL OUTSIDER

UNDERNEATH: DESPERATE FOR ACKNOWLEDGEMENT 

People go to extreme lengths to preserve the external identities they present to the world. We can go to similarly extreme lengths to preserve the internal identities we present to ourselves, to not be faced with the gaps between who and what we think we are and who and what we actually do.

Think about what happens when someone points out something you say or do that doesn't fit with your self-model. What do you do? I tend to dismiss it, explain it away, deny it--even completely fail to see it, blinded by my own myth. Our deep need to rationalize who we believe ourselves to be with what we actually end up doing leads us to covering up the reality of what we are. 

LOGICAL, SO DON’T DEAL WITH EMOTIONS

GOOD INTENTIONS, SO DON’T CONSIDER CONSEQUENCES

OPEN MINDED, SO DON’T CREATE DIVERSITY

That reality is exactly what needs to change when need to understand something new, when we need to see things differently, when we need to do and be different. It's not enough just to change categories and labels. And to change the reality means to first see it, acknowledge it, and accept the fact of it. 

Like holding strong opinions weakly to be open to new ideas, maybe we should hold strong identities weakly. 

Instead of valuing who we are, we should value what we do. 

Because we are not who we think we are, but we can’t help becoming what we do.

Maybe we can take our self-labels, self-categorizations, self-models, and self-myths--with a grain of salt. Maybe we can unmake ourselves, in order to remake ourselves. Models can be taken apart and new models built out of the pieces. A kind of dialectic of the self.

INSECURE AND FATHERLESS -> CONFIDENT THROUGH FATHERHOOD

What would happen if you unmade yourself?

---

This presentation was built out of the pieces of other presentations given over the past year: 

• OODA.MODELS.CODE.VELOCITY @ Velocity Santa Clara 2015
• The Psychological Demands of Change @ Monktoberfest 2014
• Unicorns and the Language of Otherness @ Velocity NY Ignite 2014