Customer-Vendor Loop

I’ve been sketching a bunch of compounding loops this week, and wondering if I am seeing a pattern. I am calling this figment of my imagination the Customer-Vendor Loop. I am not great at clever names. I briefly named it Maker-Taker loop, but after sleeping on it, decided to go with something more prosaic.

Before the pattern jumped out at me, I was playing with a convention for drawing a compounding loop. This convention insisted that when we document a loop, we draw it as a causal chain that contains the alternating sequence of nouns and verbs. I drew nouns as boxes and verbs as arrows. It’s that far from how we describe causal chains in English. “A confectioner makes ice cream, which attracts customers” follows the convention above quite nicely.  Some of these nouns are people and others are things that people produce. Following this convention, we can now string more causal chains like “customers pay money, which supports the confectioner”. 

Ka-blam! The money that the confectioner collects closes the feedback loop. However, whether or not this loop is compounding is not yet unknown. What would make this loop compound? Well, if the ice cream turns out exceptionally delicious, it attracts more customers, and perhaps the customers would be willing to pay more money, allowing the confectioner to make more ice cream. Every iteration of the loop begins to compound value and the cycle becomes virtuous.

Loops like this are always interesting, because each of their components tends to interact with another. If the ice cream is not that great, there will be fewer customers, attracting fewer customers, bringing less money to the confectioner, thus turning the cycle vicious. The causality remains the same, but the loop is no longer compounding. There’s still feedback, but it doesn’t accumulate value.

As I mentioned earlier, drawing a few of these revealed a general pattern. There are usually two parties: Customers and Vendors, who each produce two artifacts, each potentially interesting to the other party. In the case of our ice cream parlor, the two parties are 1) the confectioner and 2) the customers. The two artifacts are 1) ice cream and 2) the payment of money. Each artifact is produced by one party and is attractive to another party.

To turn it into a template, visualize a loop that consists of four boxes: Vendors, Products, Customers, Interactions. There are four arrows that connect them: Vendors make Products, Products attract Customers, Customers engage in Interactions, Interactions attract Vendors. This template basically asks four questions:

1. Who are the Vendors?
2. What are the Products they make?
3. Who are the Customers?
4. What are the Interactions that they engage in?

In different environments, the boxes and arrows will have different names. In a marketplace, it might be Sellers, Listings, and Buyers. When applied to services, it could be Provides, Services, and Consumers. For the software engineering team, I will use Developers, Products, Users, and Interactions, though the pattern remains the same. 

For a typical engineering product team setup, filling out this template should be fairly straightforward. Our team is the Developers. Our shipping product is the Product we make. Our product’s users are obviously Users, and the Interaction is the outcome of our users’ engagement with the product, which will depend on the nature of the product.

The customer-vendor loop contains a few useful insights. First, it asks us to separate nouns and verbs, because action is something that can be influenced, while the noun is the outcome of the action. In the language of System Dynamics, verbs are flows and nouns are stocks.

To understand the state of the loop, we look at stocks (nouns). To find ways to influence the loop, we look at flows (verbs). For example, DAU will tell us about the state of the Users stock. To improve the quality of the product we ship, we must change the way we build it. If you are familiar with the OKR system, you can view Os (objectives) as our tactics to influence flows (verbs) and KRs (key results) as our means to measure stocks (nouns).

Second, Developers have direct agency only over the verbs adjacent to them: “attract” and “build”.  There are two other verbs that can only be influenced indirectly. When a team commits to building great software, they assert that they will do their best to accelerate the flows they have agency over. This may or may not be enough to turn the customer-vendor loop into a compounding one.

Third, the two “attract” arrows are significant. The one that points at Users makes intuitive sense. After all, the whole notion of attracting users is fairly familiar to us. We promote our software, make it seem cool in commercials, we build reputation, and/or make onboarding as easy as possible  – these are all familiar methods by which we attract users.

The arrow that points at the Developers needs a bit more discussion. How do Interactions attract Developers? In the simplest scenario, an interaction is a purchase of some sort, which makes the attraction obvious: revenue from purchases supports developers and funds further development. 

However, there are many teams where the presence of this arrow is not as clear. What is the nature of the attraction for peeps who contribute to open source projects in their free time? If a team ships a free library, how does it close the loop? What is the source of energy that keeps them going? Answering these questions seems important, since if there is nothing that keeps developers coming back for the next iteration of the loop, there’s no feedback loop. Yet somehow, they continue to exist. What’s happening?

Puzzling over this often hard-to-see closure has been a really a really fun challenge, and I’ll keep you in the loop (ha!) on what I learn from the adventure.