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.