The “Coke Paradigm”

Are your customers coming to you, or are you coming to your customers?

I’ve been trying to figure out how to articulate a vision that I have for something at work in simple terms, and I finally found (what I think is) a fun way to describe it, in plain English. And I’m also childishly excited because I came up with a catchy name: The “Coke Paradigm.”

Imagine two scenarios.

The context for both is the same. You are lazily sitting on your sofa, it’s hot out there, and you’re parched. You could use a nice cold drink. And then you think, “I’d like a Coke.”

In Scenario # 1, you have to get up, put on proper pants to go out in public, drive to the store, buy a Coke, drive home, grab a glass and some ice, and pour the Coke.

In Scenario # 2, somebody just brings you a cold, refreshing glass with Coke. You didn’t have to get up. It just magically came to you, where you were.

In which scenario are you most likely to end up drinking Coke?

Why, of course, scenario#2!

So, what’s the difference?

In Scenario#1, you had to come to the Coke.

In Scenario#2, the Coke came to you.

It boils down to basic human nature. When things come to you, it’s simply less effort and more natural than when you have to come to things.

How does this relate to my career at Google, Amazon or Microsoft?

Say you created an engineering productivity tool that will make the lives of thousands of your peers better. Now you have to figure out how to get these engineers to actually adopt your thing. You need to get to critical mass. The paradigm of “me coming to you” instead of “you coming to me” is simple yet transformative.

Back in 2014, while working at Amazon, I created what would eventually become the internal company-wide Load and Performance Testing Platform, called TPSGenerator (which Amazon uses to answer questions like “is amazon.com ready for the sudden surge of millions of humans hitting the site all at the same time on Cybermonday”). Today, thousands of services use TPSGenerator. But back then, it wasn’t widely used, it was just a handful of people. I had had fairly lukewarm success. But I was proud of what I had built and I wanted everyone to use it.

One of the problems was that I had followed the pattern from Scenario # 1. Customers had to come to TPSGenerator. I was vending the software as a command line tool that customers had to install. That was a bit cumbersome, but even worse, before installing, customers had to know that TPSGenerator even existed. So I spent countless hours advertising and socializing the existence of my thing. I spoke at every single internal developer event at Amazon that year. I created classes to teach engineers how to use it. In Scenario # 1, the only reason that you even know that you want a Coke is because Coca Cola has spent literally billions of dollars over the course of a century advertising that it exists and it’s delicious and you should drink it. Scenario # 1 is exhausting. It requires relentless advertising and socializing.

I thought: I should flip this. I don’t want Customers to have to come to TPSGenerator. TPSGenerator must come to Customers. It must show up where they are, where they naturally do their work, in a way that is ubiquitous. I had not articulated it at the time, but now I know that’s Scenario # 2. Somebody just brings you the Coke, already chilled, right where you’re sitting. Of course you’re more likely to drink it.

The most natural place for me to inject my little invention in developer’s workflow was CI/CD (Continuous Integration and Continuous Deployment). Luckily for me, Amazon has an amazing internal CI/CD orchestrator called Pipelines. You check in a piece of code, and among other things, Pipelines builds it, runs unit tests, deploys it to test environments, runs integration tests against them, deploys it to bigger test environments, runs larger system tests against those, and deploys it to production. Pretty much all Amazon developers use Pipelines. Pipelines lovingly and faithfully shepherds tens of thousands of checkins along this workflow, every single day, and it has a pretty cool UI to add Approval Steps, things that can gate code progressing from one step of the workflow to the next. A lightbulb went off in my head: my tool shouldn’t just be a stand-alone command line tool that you had to install manually, it needed to be a built-in approval step in Pipelines. When you went to add a new approval step in Pipelines, voila! There was this intriguing option that said, “Add a Load Test”. Amazon engineers would think, “What the heck is this? Do I event want load testing? Well if it’s here then maybe all the cool kids are doing it. Perhaps I should too then!” The socializing and advertising came for free, simply because I was where they were.

This opened my eyes. The paradigm of “me coming to you” instead of “you coming to me” was so powerful! What other places could I leverage? Amazon developers use an internal Server Platform called Coral, which simplifies the process of standing up a service within the amazon ecosystem, logging, monitoring, client/server communication, throttling, security, etc. I collaborated with the Coral team to add a bunch of Coral syntactic sugar to TPSGenerator, and so TPSGenerator became the natural way to do load testing on Coral services.

I had naturally embedded myself in not one, but two places where a vast majority of Amazon developers spent significant chunks of their day already. I didn’t know it at the time, but I had switched my software vending paradigm and onboarding story from Scenario # 1 to Scenario # 2. A year later, I could clearly see that the customer adoption curve had a slope before this change (mostly linear), and an entirely different slope after this change (exponential).

So, as you’re thinking about how to get customers to adopt your amazing invention, ask yourself: Are you expecting them to come to you, or are you coming to them?