Loops: dead or alive

There are two important shifts to consider when examining a setting. The first is the shift in my needs. Over time, as my customer-vendor loop develops, I will find that the choices I made early on are no longer as useful as they were. For example, I may want to continue accelerating my capacity to build a Product, and the tools of the setting that I started with have hit their limit. In such a situation, I will want to examine alternatives for these tools and rethink my choices. I will want to change my setting.

The second shift is in the setting itself. Time also influences the setting itself. The ecosystem I may have chosen for its torrent of Customers may suddenly dry up to a tiny trickle, necessitating a search for another source. This one can feel a bit more challenging, because it has an appearance of kind of happening to me, rather than me making the choices.

Both of these shifts illustrate that settings change, whether through our actions or by themselves. To accommodate these changes and persist, every customer-vendor loop needs a bit of slack built into its stocks. Put differently, for a customer-vendor loop to be sustainable, it needs a capacity to grow. Applying a bit more nuance on it, the loop does not need to always grow. It just needs a capacity to do so. A customer-vendor loop that’s deep into its asymptotes is a dead loop. Dead loops are structurally unsound, because they no longer have room to change. Some dead loops can survive for a while, because they still produce value even after they can no longer fit the setting. However, they are a “dead loop walking” – their demise is predetermined.

This may sound a bit abstract, so let me reach for a more concrete scenario. Imagine a sub-team that was organized around a particular feature of some larger app. Maybe it’s a button that does something interesting when you click it. If we draw a customer-vendor loop for this team, we will notice that its Customers stock has a strong asymptote. It’s bound to some percentage of Customers that use the app – which makes sense: to click the button, the users will first have to get into the app. Similarly, the value of the Interaction of this loop is strongly tied to its expected usefulness within the app. The feature is boxed in by asymptotes. 

In this scenario, the sub-team will happily climb the developmental stages of the loop, and run straight into the walls of the box. Once the feature reaches some plausible number of app Customers who click the button, the sub-team will quickly turn into a dead loop: the feature is still popular, and still needed by the app, but there’s little reason to improve it. A common side effect here is that the feature’s active development stops and the loop is abandoned. One by one, the members of the team move on to more interesting projects, with one burned out, yet still duty-bound maintainer left fixing bugs, grimly holding the dead loop of the original team in their grip.

An alternative ending to this story is the dead loop avoidance tactic, where the product lead of the team keenly avoids the deadness by steering toward new fronteers, defying the confines of the asymptote. What if instead of just users clicking on this button, we could also play a small video? What if we opened a tiny window that allowed the user to customize their preferences for how to use the feature? What if we made the button larger, or perhaps more colorful?

This creativity may seem wonderful, but because it plays out within the larger setting of an app, it may suddenly stop being an integral part of the overall app experience and instead start jostling with other features for user’s attention. If you’ve ever participated in an app experience that comes across as an incoherent mess of features, each seemingly operating within its own bubble, you have observed the effect of dead loop avoidance. If you’ve ever wondered why a particular app feature hasn’t improved in years, you’ve observed the effect of the dead loop abandonment.

At the core of these sad stories is a rule of thumb that’s worth repeating: to be sustainable, a customer-vendor loop must have room to grow. A team that’s organized to ride such a loop must have – and will keep seeking – flexibility to choose and change its setting. 

Builder and Gardener Mindsets

My dear friend Alex Komoroske did a podcast episode recently on all of my favorite topics. I highly recommend watching it and studying the excellent deck that the majority of the discussion rotated around. I also wanted to riff on the builder and gardener archetypes that were featured in the title of the article.

Briefly, the distinction emphasizes the difference in mindsets with which we approach unsolvable problems. As builders, we view them as ultimately solvable, and so our actions usually yield building something that solves the problem. Unfortunately, as the problem is unsolvable, the thing that we end up building is solving a problem that is different from the one in front of us. In rare cases we are lucky: the difference is small enough and we get to reap some benefits from the solutions. More often, we now have a solution that still needs to find a problem that fits it.

In my experience, the latter outcome is pervasive around ecosystem work, aka “platforms”. Since ecosystems adapt to our actions, changing them to behave in accordance with our intentions is indeed an unsolvable problem. So when a team charges forth with the idea of building a platform from scratch, my response is usually a skeptical eye roll or a wince: I detect the “builder” mindset and all that falls out of it.

The mindset Alex suggests as an alternative is that of a gardener. Just like builders, gardeners have blueprints. They have an idea of some state that they want the garden to eventually reach. The key difference is that they accept that they are working with a living matter. Living matter has a mind of its own and is likely to surprise us. The blueprints will need to be redrawn and mental models adjusted frequently. In many cases, gardeners never reach what they’ve drawn in the initial sketch. They know it and hold them lightly, and it’s the only feasible approach. Holding firmly to the original blueprints is a path to eventual madness.

For technologists, the shift from “building” to “growing” is a bit hard to perform. There are two common traps that I am familiar with. The first one is what I call “garden-builders”. Here, even after armed with the gardening metaphors and ideas,  we still imagine how we’ll grow perfectly cylindrical carrots and spherical potatoes. We may talk the talk, but underneath, the builder mindset is still present. Projects run this way will have words like “ecosystems” and “platforms” and maybe even “emergent” and “complexity” plastered all over them, but the manifested outcomes reveal the story of rigid construction.

The second trap is “garden-workers”. This one plagues teams that swung way too hard into the idea of working with the living matter and abandoned the intention behind it. Garden-working is still an engineer’s escape. Assuming that gardening is just about waking up very early, weeding, watering, and tilling the dirt is comfortingly similar to the common activity of continuous refactoring that many teams in mature stages undertake. The blueprints are mostly forgotten in the soothing practices of daily work. Projects run this way will ship incoherent bags of features that even they themselves can’t cogently describe. If you hear a presenter say “we can’t wait to find out what you’ll build with these APIs” to the audience of developers, chances are the team shipping this API is stuck in the “garden-worker” trap.

If I am being brutally honest, I don’t actually know if it is possible to achieve the full zen of the gardener mindset. Based on what I’ve seen, a platform team is usually either completely unaware of this mindset or is caught undulating between the two traps. Last release: “OMG, we shipped was a bunch of random stuff, let’s organize this better!” … next release: “Crap! We shipped things that nobody needs again, let’s get back to gardening, folks!” And that might be okay. Here’s my hope. By making these traps legible, I can help you, my reader, to learn how to work with them and countervail their effects.

Becoming a setting

I’ve been geeking out about this fascinating phenomenon when parts of one customer-vendor loop become a setting for others. By virtue of connecting the dots to find a functioning setting, we necessarily make this setting more accessible and legible to others. As one outcome, others can now copy our setting and create its clone. The discipline of business strategy covers this situation well, so I want to direct your attention to its alternative. When others can observe our setting, they may – and more than likely will – reuse its conveniences for their own purposes.

Take the ice cream shop example (boy, did I wear it out or what). When my shop becomes a destination for teens to hang out, it’s no longer about the ice cream. For them, it is a setting for satisfying their need to connect and belong. Teens take all of my hard work of establishing a setting and, just like that, make it their own. This might be good for me at first – more ice cream being sold! – but quickly, it turns into a nuisance. The teens loiter at my store after buying just a couple of cones and their youthful exuberance turns other patrons away.

In my experience, this “becoming a setting” is so common that it ought to be a law or something: as the Customers stock of my customer-vendor loop grows, the probability of this loop becoming a setting for others approachers 100%.

If we accept this “law”, our hypotheses for how our customers will behave must include scenarios of them setting up camp within our customer-vendor loop and appropriating parts of it in unpredictable ways. The more I embrace such scenarios and prepare for them, the more likely I will engage with them in a mutually beneficial relationship.

For a less made-up example, let’s look at Midjourney. If asked to define their product, my first response might be, “well, the AI-generated art, of course!” But that is only part of the story. As I mentioned before, their embrace of community-based creation, and the way they made the process of creation tweakable and shareable (thanks for pointing that out, Ade!) all hint at something different. 

Midjourney might look like a simple AI-generated art service, but as it grew, it became a setting for artists – a place where they can co-create, remix, riff off each other, and have that sense of belonging. The prompt and variation mechanism design seems to be begging: “please take this prompt and mess some more with it!”  Even if intuitively and completely by chance, Midjourney’s decision to lean into Discord had a big role in ensuring that the explosive power of creativity continued to play to their strengths – unlike the annoying high-schoolers in my ice cream example. 

Similarly, Midjourney’s eagerness to hallucinate compared to similar products becomes a feature: if I am an artist looking for inspiration, I don’t want the tool to give me exactly what I am asking for. I want it to surprise me, to stir my imagination. From the perspective of technical excellence, it might be tempting for Midjourney engineers to look around and worry about “more accurate and lifelike” representation, but that is not what technical excellence means for the audience that gathered around them anymore. It turns out, “weird and unexpected” is more valuable when it is part of a creative setting.

This is the most delightful and terrifying part of becoming a setting: it is impossible to know how it works out. Even if we have our eyes open to the possibility, we must be prepared to be surprised by what happens next. In human systems, exaptation is not a rare occurrence. It’s a continuous process. And most certainly, we must not start with an idea that we somehow can control it.

One of the greatest follies of high modernism – from architects to dictators – is the belief that becoming a setting can be constructed through a mechanical waterfall process. According to this belief, if we know enough things and think hard enough, we can draw the blueprints, plan, organize, and manage resources, and given enough time, bring forth the ideal setting of our design, be that a building, or a country. It is the belief that becoming a setting is solvable problem, that people will just come and dwell in the thing we create in just the way we planned for them. And when people refuse to and the conclusion of the waterfall process is revealed to be just a first step of an ongoing dance of exaptation, a high modernist is left with the choices of having a painful, but transformative learning experience or blaming the pesky people for screwing up their plans. You can guess which one happens more often.

A thing that might be helpful is recognizing that there’s a bit of a high modernist in all of us, and knowing how it shows up in our thinking. For instance, the irritation over “pesky users screwing up our plans” is a really good marker. Not expecting exaptation is a sure sign that we’ve fallen back into the waterfall model of becoming a setting.

Finding the setting

In the previous story, I talked at length about finding the setting, and I thought it might be useful to try and write down a pattern I’ve seen when looking to complete that puzzle of a functional setting for a customer-vendor loop.

The approach that seems effective is by studying the stocks of adjacent loops. As you may remember, there are four of them: Customers, Interactions, Vendors, Products. Each stock has value. There’s something here about abundance and lacking that I haven’t quite figured out yet. For the sake of this narrative, let’s assume that we can tell if the stock is abundant or lacking. When the stock is abundant, there’s excess value that presents us with an opportunity to create our own stock. When the stock is lacking, our opportunities in relation to this stock are rare and unimpressive. It’s not always so clearcut. Sometimes lacking stocks present opportunities that were previously unavailable, and stocks gaining in abundance seep energy away from the opportunities that were there before. But to keep things simple, let’s go with the simple rule of thumb: adjacent abundance leads to more opportunities, and adjacent lack to fewer.

I’ll start with the Customers. As their numbers grow, we start recognizing that the customers themselves create value. Think of a lively market, a bazaar. People flock to a bazaar because there’s something they may need to purchase, but also because they might be surprised to find new things they haven’t seen before. Half the fun of going to a farmer’s market is in discovering a new kind of honey that I didn’t realize I definitely needed to buy. Customer growth spurs the engagement flow, and is often a common phenomenon that strategists spot. If I am near a bazaar, I will have opportunities for engagement, and many business venture ideas start here.

Moving clockwise, let’s look at the Interactions. Sometimes, there might not be a clearly distinguishable collection of Customers. Instead we notice a certain behavior that is hard to ignore as random. Cowpaths are a common buzzword, but they nicely describe the value in the Interaction stock. Being carefully observant of common behaviors alongside well-traveled paths and detecting unmet needs is another trick that strategists employ. Often, the cowpaths are opportunities that lie just outside established roads, and their value does not reside in having an  audience. People can come and go as they please. The entrepreneurs are attracted to some emergent common need that these people start having as they do.

Looking at the Vendor stock, its value is in the breadth and depth of capabilities. Whether they are the knowhow and expertise, funding, or just plain raw brawn – capabilities accumulate in this stock. Many teams get their start by putting a group of passionate, experienced, and skilled individuals. By doing so, they amass capabilities – or put differently, value in the Vendor stock – to create new opportunities by building things. Areas like Silicon Valley are traditionally brimming with the Vendor stock, though I am very excited about new spaces that normalizing remote work is opening up.

The final stock in the customer-vendor loop is Products. This one is very familiar to the engineering teams. Every time we examine dependencies,  which framework we will use or which platform we will pick, we are evaluating the abundance of the adjacent Products stock. I won’t spend much time here, since it’s fairly straightforward. However, there’s another set of opportunities hiding in the abundant Products stock. Sometimes we find new uses for things we already have. There’s a fancy term in biology: exaptation, or a shift in function of a trait during evolution. Products stock may hold value not only because they serve their intended purpose, but also because they may be repurposed to do something entirely different. Especially for well-established Products, there’s always some exaptation going on.

I am sure there are other ways to uncover a setting, but this seems like a decent starter kit. It probably won’t help you find the next big business idea, but it might produce an insight or two when considering your organization’s strategy.

Customer-vendor loops and their setting

The notion of a setting for a customer-vendor loop is fairly intuitive. A loop doesn’t exist in its own, insulated bubble. Taking that ice cream shop I use as my go-to example, where do its customers come from? They don’t just magically appear in the air. Instead, they walk up to the shop, traveling down a crowded street or perhaps a shopping center. This street is part of the store’s setting. Similarly, where does the milk to make ice cream come from? More than likely, the owner of the store buys it regularly from a vendor. That vendor is also part of the setting. For an ice cream store, the setting may also include chocolate and other flavor vendors, and of course all of the equipment that is necessary to make and serve delicious ice cream. Put simply, the setting of a customer-vendor loop is everything that’s necessary to make the loop go.

I would go a step further and claim that the process of constructing a customer-vendor loop is first and foremost a process of finding a setting that results in that special kind of feedback loop I’ve been going on about. The key shift for me here is away from the mental image of drawing a feedback loop from scratch, dot by dot, and toward the mental model of spotting a few unconnected dots that are really close together, and linking them together. It seems obvious that if I choose my ice cream shop’s setting as the middle of the Arctic tundra, I will first need to invest into first erecting a city that attracts people to live in it. I can’t remember any city being built for the purpose of setting up an ice cream shop.

It is probably not surprising that this kind of setting-spotting is largely about discerning existing customer-vendor loops that already exist. To drive this point more precisely, a setting of a customer-vendor loop is composed of other customer-vendor loops. As I write this, I imagine a densely connected network of loops, each reinforcing and weakening each other in various ways. The capacity to establish my own customer-vendor loops stems from my ability to understand the strengths, weaknesses, opportunities, and strengths within stocks and flows of customer-vendor loops of others that are adjacent to me.

The discipline of business strategy dwells in this area and I’ve benefited greatly from the wisdom of its purveyors. As one pointer, Hamilton Helmer’s 7 Powers is a rather beautiful capture of various setting configurations. There’s also a pretty comprehensive framework called “Business Model Canvas” that is described in the Business Model Generation book (thank you for introducing me to it, Ujval). If I tilt my head a little bit and squint, at the core is the process of defining a setting for a customer-vendor loop.  Finally, a thorough five-force analysis of a setting can do wonders for opening that strategic third eye. For instance, the setting defines how unique and differentiated our product can be. Borrowing Michael Porter’s example, to start an airline, you and I can just rent a plane and lease a gate at the airport – but so can everyone else.

More generally, when I hear the words “product market fit”, I hear “choosing a setting for our customer-vendor loop”. In software engineering, we usually use the word “dependencies” to talk about our team’s setting – though limiting our understanding of a setting to project dependencies can be fraught with peril. In my experience, one of the key challenges that software teams run into is not being deliberate about understanding their setting. I’ve been there myself, swept  off the ground by a fascination with some cool bit of technology. When we say “solution in search of a problem”, we usually talk about a customer-vendor loop that doesn’t actually close onto itself – and more often than not, it’s a result of plowing forth with developing a product without considering a setting to which it is born.

To emphasize the necessity of being intentional about the setting, I’ll close with this anecdote. I once had an enlightening conversation with a pastor of a small-town church in Central California. Their attendance was down year over year, and with the onset of the pandemic and ensuing isolation (remember 2020?), there was quite a bit of worry about whether the congregation is still, in fact, a functioning church. I immediately launched into the fixing mode and suggested reexamining the setting: embracing the momentum of moving the services online could possibly mean the expansion of the audience, opening up all kinds of new opportunities. Kindly, the pastor noted that the story of that particular church is deeply intertwined with and is inseparable from the story of its town. No matter how appealing the growth potential might be, the “small-town” bit was an immutable, foundational part of the setting. 

So yes, beliefs and principles are also part of the setting and they play a large role in defining what’s possible. It seems like a good idea for a leader to understand what those beliefs and principles are — both theirs and of their team, and how they influence the configuration of the setting.