Reaction Wheel

If a startup founder wants the best chance of succeeding, they must choose to start a company that faces uncertainty in some crucial way. This allows them the time and competitive space to build without having to compete with better resourced incumbents. Uncertainty here means unpredictability, as distinguished from mere risk: risky things are predictable if you do them often enough. They are insurable. Risk is quantifiable; uncertainty is not.

The problem with uncertainty is that if you can’t predict what will happen when you do something, you can’t decide what the best thing to do is. You can’t plan. At least not in the sense that traditional business strategy recommends. And if strategy is supposed to be the first step towards creating a plan, then creating your traditional business strategy in an uncertain environment was just a waste of time because you didn’t end up with a plan anyway.

We are going to talk about building a strategy that helps you make decisions, even under uncertainty. It will help you decide which actions to take even though you won’t know what the results of those actions are. You won’t have a plan—something where action a leads to action b leads to action c, and so on until you inevitably (or at least statistically) reach success. Instead you will have a framework that guides you to decisions that carefully mitigate uncertainty as efficiently as possible while building a sustainable competitive advantage for the time when the uncertainty is gone and competition arrives. This post will lay out the method. We will look at the details in the next few posts.

---

What Uncertainty Is, Where it Comes From, and How it Affects Startups

The ability to predict the future is a spectrum. At one end is certainty. This can only be available when the universe is deterministic. When you move away from this end of the spectrum you start to see more frequent and more severe inconsistencies between what you predict and what happens. At first you can find patterns in the inconsistencies. You may, for instance, find that the errors between what you predict and what happens follow the Normal distribution, or other common distributions. Take, for instance, predicting the number of heads that you’ll flip if you flip a coin 100 times. You would probably predict you will get 50, if the coin is fair. You will almost certainly be wrong, but you can predict how often and by how much you will be wrong using a binomial distribution. This idea of knowing how wrong your predictions will be was the question that drove the development of statistics in the first place.

The important thing about this type of predictability is that even while you can’t predict the outcome, you can predict how wrong you will be and how often. You can also, with most distributions of outcomes, narrow how wrong you will be by repeating the experiment many times. If you flip a coin 200 times, you will be less wrong in your prediction than if you flip it only 20 times.

But as you move further out the spectrum away from certainty you lose even the distribution of errors. You might retain boundaries on the errors for some time—the knowledge that your prediction won’t be more than a certain distance from the actual—but eventually you lose even this. This end of the spectrum, where you lose even the distribution of errors, is what we are calling uncertainty. I make the distinction between risk and uncertainty because once you lose the distributions, you can no longer even insure the outcome. Or, to think of it another way, you can’t hedge your mistakes by doing multiple trials. Your life insurance company has no idea when you will die, and if they insured only you that would be very bad business. But if they insure 100,000 people whose times of death are uncorrelated, they would have very predictable expenses. This is a fine business.

The risky part of the spectrum is covered by standard business theories. We are focusing on the other part, the uncertain part.

Your task, building a startup, is finding a way from the world as it is today to a world with your successful startup in it. The actions you take change the world step by step to take you closer and closer to your desired state of the world. This is somewhat like finding your way through a maze¹. If you know how every action will change the state of the world—if you are in a deterministic world—you can simply plan out what to do ahead of time. If some of the actions you take lead to different states of the world with different probabilities—a risky world—you can still calculate the best path to take. Even more, if none of the intermediate steps are irreversible, you can keep trying until you inevitably succeed in reaching your goal. If, on the other hand, you have no idea what states of the world some actions will lead to, or if there are some actions you could take that you don’t know about, or if the states of the world or the actions change unpredictably, you are in an uncertain world.

I am going to distinguish between two sorts of uncertainty here. To get there let’s roll out some dollar-store epistemology. Think of the knowledge you need as either known, unknown, or unknowable². Known means you know it, someone else knows it, or you can figure it out from what you or other people know. Unknown means you don’t know it and you can’t figure it out from what you know, but someone else might know it, or you could discover it. Finally, unknowable means you can’t know it, at least not for good.

Known is easy. You know what you know. And the easier part of Unknown—things other people know—is straightforward. What is known, but not by you, can be found by investigating and reasoning. The knowledge might be in other peoples’ heads, though it might not be exactly the knowledge you are looking for. Customer interviewing, the kind where startup experts tell you to figure out the customer’s problems, not ask them for solutions, is like this. You find out what these customers know and then you reason from it to find out what you need to know. This may be unknown to you before the exercise, but it is knowable.

The other kind of Unknown means that if you want the knowledge, you have to go out and create it. The knowledge is knowable, it’s just that nobody knows it yet. This is the source of the first kind of uncertainty, novelty uncertainty. Novelty uncertainty is when there are things you just don’t know, even after doing all your research and thinking things through to their logical conclusions. I call it novelty uncertainty because it is especially common when someone does something for the first time. Doing the thing creates the knowledge, so this kind of uncertainty is mitigated through doing things. Early explorers may have had no way to predict what was across the ocean, but once they sailed there, they knew. If the novelty uncertainty is about what will happen when you do something, you do it and see what will happen. If it is about how to reach a desirable state of the world, you try different things and see if they get you closer to it, if they don’t you try something else. While this sounds pretty straightforward, the devil is in the details.

The unknowable, on the other hand, stays unknowable, even after trying things. This often happens when things are changing. You might try something and see what happens, but the next time you try it something different happens. I call this complexity uncertainty, because unpredictable change happens when you interact with complex systems. In a complex system, even once you have learned what an action does or what a state of the world looks like, they can change. They might change because there is a reaction to something else you have done or because others—competitors, customers, the government, etc.—are doing things that change the state of the world in ways you can’t predict. Many businesses operate in complex ecosystems and have complexity uncertainty to some degree.³

There is also a deeper unknowable: information that existed and no longer exists. What did Zog the caveman say to his wife in 10,000 BC? We’ll never know.

The two primary types of uncertainty we care about are novelty novelty—when you can’t predict something because no one has done it before—and complexity—when you can’t predict something because the system you are in is changing in an unpredictable way.⁴

My distinction between novelty uncertainty and complexity uncertainty isn’t exactly identical to unknown and unknowable. The unknown is comprised of both things other people know that you don’t and of things that no one knows yet. The first is readily attacked with straightforward means (i.e. research and thought) while the second required creating the knowledge. The unknowable is both knowledge you can get but is subject to change and knowledge that can not be gotten. These latter are generally things that are causally untied to the rest of the world. This makes them completely uninteresting for our purposes, and we will leave them to the theologians.

Novelty uncertainty, in my taxonomy, is static. And complexity uncertainty is dynamic. In the real world things are not always so clear cut. Most of the more interesting problems business people face are hard because the network of customers, competitors, financiers, regulators, the media, and everyone else who uses, relies on, supports, or otherwise affects the business, is obviously a complex system. But interactions with the system may be more static or more dynamic, or somewhere in between. One way to think about it is that all learnings are static, until they are not. What is important is how long they are static for. Math and logic seems to never change. The laws of physics don’t seem to have changed since the Big Bang. Etc. But the weather is pretty dynamic. Having an idea of how long you can take advantage of something you have learned is important. Strategies to deal with uncertainty are generally mixed between those that deal with novelty uncertainty and those that deal with complexity uncertainty, the mix depends on how static or dynamic they are. We will talk about strategies for each separately, and only later talk about how to mix them as needed.

Working with Uncertainty

Entrepreneurs build startups around uncertainties. The uncertainty should be about something that would provide some tangible benefit to the company or its customers if it ends up resolving in a certain way. It should be in a key aspect of the business if is to deter competition. But uncertainties are a necessary evil. They provide a barrier to competition, but they also create significant problems. A startup takes on uncertainty, but must then manage so that it eventually dispenses with the uncertainty but ends up with a moat. Our hero descends into the deep, dark cave that others will not dare and emerges with untold riches. But our hero does not then make it a habit to descend into other deep, dark caves; they set themselves up as king or queen and live happily ever after. Fables have a selection bias: they are not about the heroes that descend into the deep, dark cave and never come out. Those people don’t have their tales told and are not generally regarded as heroes; they are regarded as fools. Objective reality has no selection bias and startups that take on unnecessary uncertainty will often find the things they couldn’t predict are bad things. You must brave the uncertainty to build a company, but once you have built the company you’re better off not taking on more uncertainty than you have to.

This suggests the outlines of a plan to deal with uncertainty. It begins with embracing an uncertainty and ends with the company becoming a ‘regular’ business: one with a moat.

Embracing Uncertainty

The strategic process begins by thinking about what important uncertainties you will embrace. The uncertainty can be in any part of the business (though the main places that uncertainties seem to manifest in startups are in the product, the market, the competition, resources, and the socio-political environment the startup is operating in; see the box below.) But if you’re like most people, you aren’t going out looking for an uncertainty, per se, you are looking at an idea you like and trying to figure out why no one else has tackled it. You’ll either find that they haven’t because it’s a bad idea, or that they haven’t because there’s some major uncertainty preventing them from knowing whether it’s a good idea or not. If it’s the latter, great! Now figure out what the uncertainty is. Look through the categories below and ask yourself: what do I know, what don’t I know, and what can’t anyone know? This will lead you, as discussed above, to the uncertainties.

A framework like Osterwalder’s business model canvas can help you find the uncertainties. Osterwalder wrote his PhD thesis building a taxonomy of business models and found that they could generally be categorized using nine dimensions. These became the boxes on his canvas. The greatest benefit of this sort of framework is that it makes you think through each part of your business, not just the ones you find most interesting. As you think through the parts, ask yourself: can I accurately predict whether I can do this part, or not? Is the information I need to predict it Known, Unknown, or Unknowable? Which of these things is uncertain, and is it novelty uncertainty or complexity uncertainty? If I learn the knowledge, how quickly will it change? You will end up with a list of things that are uncertain to various degrees.

If you end up finding that you face many uncertainties, you should try and see if they are all, in fact, aspects of some more basic uncertainty. If they are not, if they are many disjoint uncertainties, then you should step back and evaluate. One major uncertainty is as good a moat as several, and since uncertainties take time and effort to resolve, most startups should limit how many different uncertainties they take on when starting. If there are several, you may want to see if addressing just one would be enough to build a great business.

If, on the other hand, there are no uncertainties, you need to ask yourself two questions:

• Am I fooling myself believing I know things I can’t actually know, because they are unknowable?
• If this opportunity is so certainly valuable, who else is pursuing it already?

Once you know the uncertainties you will face, you should think about whether they are primarily novelty uncertainties, complexity uncertainties, or some of both. Think about how dynamic the uncertainties are. You can often tell where important uncertainties will manifest by looking at the natural cycle of the technologies you are depending on. Very new technologies lead to novelty uncertainties while startups using more mature technologies generally rely on complexity uncertainties. We will talk about this in more detail in a future post, but you can get the gist by reading The Deployment Age.

Isolate and Decouple the Uncertainties

Smart managers don’t try to fix all their business’ problems in one fell swoop. Deciding what engineering should work on and what accounting should work on are usually separate decisions, guided by the overall business strategy. Keeping the decisions separate makes the manager’s job easier: they cut the problem at the joints. They decouple decisions but keep an eye out for places where different parts of the organization must interact. Treating these interactions as exceptions rather than the usual course of business is both cognitively easier and less work for the manager. Top management can concentrate on the most important strategic decisions, and the exceptions.

This rule is, in my experience, usually implicit and learned tacitly. This is too bad, because we should better appreciate its merits. Decoupling different work flows allows each to be managed better and more quickly improved, a general characteristic of modularity in a complex system. Organization designers can even push this modularity further by actively decoupling different workflows. If the joints aren’t organizational boundaries, they reorganize. We talk a lot these days about having more communication flows between different parts of a business, and there are various merits to this, but there are also reasons to standardize communications and decouple.

This is especially true when one workflow has uncertainties and the other does not. Managing uncertainty is difficult, results in much work that comes to nothing, and leads to unpredictable outcomes. It also requires employees who are willing to put up with vague and changeable goals and requirements.⁶ You may have to accept this in, say, your product organization or your marketing organization, because the uncertainties have to be somewhere, but if you can keep that uncertainty from migrating to your finance organization or your distribution operations, or vice-versa, as the case may be, then you are better off.

You do this by actively decoupling the parts of your organization that are dealing with uncertainty. There are two parts to this: the org chart and the interfaces.

Once you know what types of uncertainties you will face, you can determine which roles in your company will have to deal with them. These roles should be managed separately from the roles where there is no uncertainty. This management should also be much more closely managed by the CEO. In many startups, the role of COO has come to mean “the person who manages things that are not uncertain.” (Though not always, of course.) In these companies, the COO reports to the CEO alongside whoever manages the uncertainty-bearing organizations: the CMO, CTO, and/or head of product, etc.

Even within these departments there may be employees who deal with uncertainty and those that do not have to. It may be inefficient to entirely decouple. But the more decoupling that can be done, the easier the management task.

The second piece is building interfaces. An interface is something that standardizes interoperability between different workflows. This would include things like standards (as in the standard rail gauge for trains), APIs, protocols, backwards compatibility, required reporting, sign-offs, etc.

Interfaces ease decoupling. If you are to cut a problem at the joints, first you need joints. These are the interfaces. To decouple uncertainty, you create interfaces between the uncertain part of the business and the more predictable. If the interface itself remains predictable to the workflows that do not bear uncertainty, then the uncertainty does not leak across organizations. The uncertainty-bearing organization can be impossibly chaotic, but as long as they observe the interface, the effects are isolated.

This is a huge burden on the interface, of course, and most interfaces can not be designed to guarantee predictability. But decoupling should be one of the goals of organization design when uncertainty is present.

This may sound buzz-wordy, but large businesses have many of these interfaces in place, even if they don’t call them that. One of the goals of hierarchical organization in general, and the job of middle-managers in particular, is preventing every little change in one organization causing corresponding little changes in every other organization. If there were ten departments in a company and each decided to change one thing, then each of the others would have to make nine other changes besides the one they originated. The number of changes would swell from ten to 100. These 90 secondary changes might result in even more tertiary changes, etc. Chaos ensues.

Instead, organizations create interfaces that prevent this. Departments may ‘batch’ their changes, changing what they need from or give to other parts of the business only periodically. The product organization in a fast-changing company might release a new version every week or month. But accounting will probably change what information they need from other departments maybe once a year (and get complaints if it’s that often.) Departments also have standardized ways of communicating important information to other departments, with middle managers focusing on exceptions. These standards may be formal or informal; they may be software, paper, meetings, or through understandings between key players. We have all seen them, and they’re obvious once you look.

Any ambitious person who has worked for a large organization might see the problem here: sometimes you have to bypass the official communication channels to get things done. Interfaces can be bureaucratic, they can enforce unnecessary requirements and work, and they can stifle change. This happens because the managerial benefits of decoupling through interfaces is so high that there is resistance to changing the interfaces. Top management must keep track of the interfaces to make sure they evolve to meet changing goals without spreading the uncertainty too widely. Interfaces must be changeable, but managers must also know that interface change can be especially disruptive because it can force fundamental change to the organizations of everyone who interacts through the interface.

A startup is not yet a big business, and it might be years before you have things like middle managers. But this doesn’t mean that you should just let uncertainty spread to parts of your business that don’t need to be uncertain. It just creates more work and more headaches. Your decoupling may start out as simply telling some employees not to worry about things that may seem to them chaotic; reassuring them that this is a normal part of creating something new, not dysfunctional thrashing. You can save the bureaucracy for when the company is big enough to need it.

Like everything else in business, rules have to be interpreted thoughtfully in light of circumstances. The rule here is to decouple workflows as far as possible, and especially uncertain workflows. But you have to do this in a thoughtful way, mindful of other business constraints. Interface design is crucial, and difficult.

Resources and Goals

Sun Tzu said in his Art of War, a staple of military strategy, “If you know the enemy and know yourself, you need not fear the result of a hundred battles.” This is bad advice in an uncertain world. You should never assume you know your competitors and would-be competitors, and you should never assume you know what you have and what you want.

A business strategy is meant to take you from the resources you have to the goal you set. But resources are not a set thing, and knowing what to consider a resource and what not to begs the strategic question: if you don’t know what you have to do to succeed, how can you know what will be useful in helping you do it? And if you have a single set goal, what will you do if it turns out to be impossible to reach it, as seems to be the usual case in startups?

An entire school of strategic thought is based around the idea that a company’s fate is determined by its resources, because the unique resources a company controls are its only enduring differentiation. A firm’s resources can be its physical assets, the employees who work for it, the know-how it has gained, patents it holds, its brand, etc. This Resource Based View (RBV) of strategy says that if a firm is to create value it must have a strategy that is different from others in the market, and if it wants to prevent imitation it must have different resources. It also assumes, for the most part, that resources cost what they are worth, so developing or buying new resources can’t create value. RBV (and the related capabilities based theories, which I will conflate here) advises that firms must develop new resources, and this requires expensive searches that find new uses for and ways to combine existing resources.

But in uncertain environments you may not know what you are searching for and may not know when you find it. If you do not know what technologies will work or what product customers will accept, the ability to explore that technology or build that product may not even register as a resource at all. For instance, Intel had the capabilities to produce a microprocessor in the early 1970s but, because top management did not think microprocessors were going to be a big market, they did not see these capabilities as resources. The decision by Gordon Moore to allow Federico Faggin, et al. to exploit this capability anyway is an object lesson in dealing with the unpredictability of how big the market for a general purpose computer on a chip would be.⁷

What constitutes a valuable resource depends on what goals are valuable. But the viability of some goals depends on whether resources exist to achieve them. Similar to so-called “wicked” problems, problems that must have candidate solutions before the problem itself can even be articulated, , this recursion can make analytic search processes pointless.⁸ The process of setting goals and valuing resources is a joint one.

We may not be able to recognize achievable goals until we achieve them, and we may not be able to assign a value to those goals even then. For instance, when Steve Jobs said, when raising venture capital for Apple Computer, that every household in America would own a personal computer, there was no way to know—even in a probabilistic way—if this goal was achievable. He couldn’t even know if the problem, “who will own a personal computer?”, even made sense because the industry was still defining what a personal computer was. From our vantage point, most households in America do have a personal computer, and if you stretch the definition to include desktops, laptops, tablets, smartphones, voice assistants, and smart appliances, most have several. But a personal computer in every household could not have been a goal back in the ’70s, at best it was some sort of vague ideal.

Jobs did not have a single goal, despite how we interpret what he said with hindsight. He had something fuzzier. There were many goals that would fit his criteria of success. They all had some version of a personal computer in every household in common. Where personal, computer, and household could change meanings to suit whatever was working. Jobs did not have a goal, he had a goal set. This goal set was delimited (it did not include things which were not computer, for instance) and progress towards it was measurable, in a sense. This idea of a goal set, instead of a goal, is key to dealing with uncertainty.

When you think of your goal as something fuzzier, a goal set, you begin to make progress on determining needed resources. Your goal set must be bounded in some way. Think of your goal set as a blob of conceivable end-states in some n-dimensional space. The dimensions are key attributes of what you are trying to do, and the boundary of the blob determines the ranges these key attributes can take and still have you end up within your goal set. The resources you need to achieve your goal set are then those that can best help you shape the values of these key attributes. Knowing what you need your resources to do lets you determine which resources to buy, hire, make, find, or partner to get.

Determining resources and setting goals is key to any strategic process. Our process, though, will bend the meaning of “determine” and “set” to account for the inability to know that uncertainty brings. We will explore the development of resources and goals in an uncertain environment more in a later post.

Mitigating Uncertainty

Uncertainty makes everything harder: hiring, raising capital, getting customers, forging partnerships, getting distribution, etc. This is offset by its reduction of competition. Managing a startup means counterbalancing these forces over time. You are better off if the uncertainty is mitigated, as long as you have some other moat in place once it is.

If you are facing novelty uncertainty, then reaching your goal-set means you have rid yourself of that uncertainty. You asked “can this be done?”, but it is something you have to do. Reaching the goal-set can only come after mitigating the uncertainty. There were things that were unknown and by doing them you create new knowledge. This is how you mitigate novelty uncertainty, by creating new knowledge. This may include observation, deduction, and induction, but often has at its core the generation of new facts through trial and error. We will talk more about this in the next post.

If you are facing complexity uncertainty, you are trying to hit a moving target. You don’t necessarily need to mitigate this uncertainty: in some situations, hitting the target just once may be enough. You could just keep trying until you get lucky. There are subtle but important distinctions between this kind of trial and error and the kind where you are creating new knowledge, and we’ll talk about those in the trial and error post, but broadly, this way of dealing with uncertainty complexity requires far more trials and so is much more time and labor-consuming while being far less efficient. The better path is often to manipulate the system to reduce the complexity, slowing the rate of change and bounding its range. This is a far more subtle and social process because it requires restructuring the interfaces—the relationships—between different actors in the system. Strengthening some links, breaking some others, creating new ones. This is harder in practice than in theory, because it involves telling compelling stories, and finding consensus among nascent competitors and other parties with wildly disparate views. We’ll talk about it in detail in a future post.

How you mitigate the uncertainty determines both how quickly it is mitigated, how visible the mitigation is to potential competitors, and how difficult it is for your organization to maintain the mitigation. All of these things factor into how and what type of moat you can build.

Building a Moat

Since uncertainty is what is keeping unbridled competition away, once your startup has mitigated the uncertainty you will face competition unless you have built some other moat. Which moats are available depends greatly on whether the uncertainty the startup is resolving is novelty or complexity uncertainty.

If you are facing novelty uncertainty, then the key question is “will it be evident to potential competitors when I resolve the uncertainty?” That is, if they can see how you resolved the uncertainty by discovering new knowledge, can they learn this new knowledge just by looking at your product? If so, they can easily copy it. In this case, you have your work cut out for you to protect your innovation. Patents might be your moat, but they only work in specific instances. Other moats, like complementary assets and other types of partnerships may be a better bet.

If would-be competitors can’t see how you solved the problem, but can see that you have, this can be a spur to them figuring it out themselves. Sometimes the biggest uncertainty is not how to do something, but whether it can be done at all. The most effective moats in these cases include slowing down their R&D while you quicken the pace of improvement inside your company. Tacit knowledge achieved through learning by doing, and being able to keep some of the new knowledge secret in the face of employees leaving the company are some of your best bets.

The important thing to remember about resolving novelty uncertainty is that it can happen quite suddenly. One day it is unresolved, the next day it is. This means you have to be prepared ahead of time to protect the value you are creating.

Complexity uncertainty, on the other hand, is resolved over time. Because it involves processes that aren’t transparent to outsiders, it can be hard for competitors to tell if you have resolved the uncertainty or are just acting as if you had. For instance, in a complex system uncertainty breeds uncertainty. If your customer is uncertain about your company’s viability, because whether you can continue to be funded is uncertain, you now have not just resource uncertainty but customer uncertainty. You may begin to untie this knot by convincing your customers that you are, indeed, a viable stand-alone company. From the outside, it may be difficult to tell if this is true or just a narrative. But internal to your company-customer relationship, reducing the perceived resource uncertainty reduces your sales uncertainty.

It’s much easier to build a moat when you are resolving complexity uncertainty. The very process of mitigating it lends itself to moat building: you can build trust with your customers by working with them over time, you are forging partnerships that will deny needed resources to competitors, and you are building scale that makes you more efficient. But you still need to build these moats intentionally while you are navigating the uncertainties.

I talk more about moat building in A Taxonomy of Moats and Productive Uncertainty.

Pulling it Together

I recently flipped through a new textbook on entrepreneurship. There were chapters on marketing, operations, selling, and accounting. These are all crucial skills for an entrepreneur. But they are crucial skills for any business manager. High-growth potential startups are different from other small businesses which are primarily meant as a way to become self-employed. Most startups that become large and successful over a short period of time have the opportunity to do so because they face substantial uncertainty. Managing this is the key skill you need that people running small businesses do not. There was no chapter in that textbook on managing true uncertainty.

This post is an outline of a framework to manage true uncertainty in a high-growth potential startup. Sorry that it doesn’t have some catchy acronym.

1. Embrace the uncertainty. Determine what important uncertainties you are likely to face and figure out what kinds of uncertainty they are;
2. Isolate the uncertain parts of the business from the parts that are more predictable;
3. Determine your available resources and goal-sets;
4. Mitigate the uncertainties:
   • Make a trial and error plan, and
   • Make an ecosystem engagement plan;
5. Defend your innovations by building a moat.

Easy to say, harder to do. We will talk about several of these in the next few posts.