Platforms & Customer Centricity – The Platform Explanation

Platforms & Customer Centricity are hot topics, but how do you get there? Hamish Nuttall says that the “why” and the “how” can be explained by electrical plugs and spaghetti.

In 1997, Amazon’s stated objective was to be the “leading online retailer of information-based products and services, with an initial focus on books”.

Now its aim is simply to be “Earth’s most customer-centric company”.

Actually, according to Ben Thomson, Amazon’s goal is to take “a cut of all economic activity”.

Amazon already accounts for half of all ecommerce sales in the US and is still growing its market share.

Remember when Amazon was just an online bookstore? Now it is the Everything Store (I recommend this book by the way). It is also Amazon Web Services (AWS), Alexa, Kindle, Prime, Fresh, Go and now Wholefoods. But above all, Amazon is a platform. And that explains a lot of its success.

Why? You might ask.

Steve Yegge wrote a brilliant piece for his Google colleagues which he accidentally published to the world. In it he says that Jeff Bezos realised that the software that Amazon had built “for selling and shipping books” could become a computing platform that anyone could use. Now, 40% of the products sold on Amazon come from third parties, and more importantly the Amazon cloud (AWS) hosts businesses such as Airbnb and Netflix and many more.

But more importantly, according to Yegge, Amazon can’t always build the right thing. As I’ve said before, if you don’t know the “why”, the “how” doesn’t matter. But, as your business grows in capability – and complexity, your ability to figure out all the “whys” degrades. And if you are focusing and prioritising, as you should, there are many painpoints that you are not addressing.

Think about the success of Facebook compared to Myspace. Where Myspace tried to control everything on its network, Facebook opened up to third-party developers who could use the platform to offer different services that Facebook might not have thought of.

Both Amazon and Facebook built their infrastructure for themselves, and only when they had reached scale did they open themselves up as platforms. They both had “killer apps”. A killer app is an application that drives the demand for a system.

“Book selling” and “social network” are the killer apps for Amazon and Facebook respectively. Those killer apps have driven the demand for the platforms they run on and given Amazon and Facebook the resources and impetus to open them up to third parties.

So, let’s try and generalise that.

Both Amazon and Facebook have a core product or killer app that is hugely successful. And they have built a scalable infrastructure to deliver it. What they have both realised is that what will accelerate the growth, is allowing others to leverage your technology.

But opening up your platform is not enough  – and this is important – you need your own “killer app” or, as Thomson calls it, the “First and Best Customer” to support the growth of the platform.

This means that innovation is about solving customer problems first, and a focus on platforms only occurs as you start to scale. Don’t distract yourself too much with platform thinking when you are figuring out what the product should look like.

Let’s say you have innovated to a product that people want (validate), and you have figured out how to attract and convert customers, how do you build a platform?

This is where it gets a bit technical. But bear with me because I’ll unpack it with a couple of analogies immediately afterwards.

According to Yegge, Amazon enforced a rule that all data and features can only be accessed through Application Programming Interfaces (APIs). Moreover, teams only communicate with each other through these APIs, and, most importantly, all APIs must be designed to work externally so third parties can interface with them.

Now for the analogies.

Think of computer code as spaghetti. In the old days there would be one big pot of spaghetti. As the volume of spaghetti increases, it gets more tangled and more difficult to manage. But now, imagine the spaghetti (the code) is divided into small bowls – each “bowl” has a specific recipe, such as “spaghetti bolognese”: Each recipe corresponds to a specific function in the code, such as managing logins, “buying a ticket” and so on. In code terms putting the spaghetti into bowls is refactoring and modularisation.

Now think of the APIs as an electrical plug and socket. If you are making lamps, you don’t need to understand how electricity is made, you just need to know the “format” of the electricity at the socket.

Imagine that some bowls of spaghetti need to know the recipe of other bowls, so you need to link them together. You could have a wire from each ingredient in one bowl to each ingredient in other bowls – but that gets complicated very quickly. Instead, each bowl has a plug and socket and you only need one wire between each. And because the plug and socket understand the recipes, if the recipes change, you don’t need to rewire. That’s what APIs do in code. They make communication between bits of code simpler.

Some really cool things happen when you do this. You can change the spaghetti recipe in one of the bowls and it won’t affect the other recipes (in the coding sense it won’t break the whole system). Because each bowl communicates only through the plug and socket, other bowls don’t need to change.

When you have one big pot of spaghetti, the chefs lose track of what’s in it, so that you often get two spaghetti bolognese recipes or two sets of code doing essentially the same thing. That’s a waste of effort.

If you have a lot of spaghetti (code) you need a lot of chefs (developers). If there is one big pot it will be easy for the spaghetti to get mixed up.

Can you imagine the mess? But with the spaghetti in small bowls, each chef can look after their own spaghetti without tripping over the other chefs.

Finally, when the spaghetti is in one big pot, it is difficult for an outside chef to find the recipe they need. But if each spaghetti is in its own bowl with a plug and socket arrangement, the outside chef doesn’t even need to understand how the spaghetti is arranged. All they need to know is how to communicate with the plug. This makes it much easier for third-party developers to create external applications that work with your platform.

So, even if you don’t like spaghetti (and I love it) it’s a useful way of explaining how to make code scaleable and extensible.

What’s neat about this approach is that it’s consistent with the 80:20 rule – you identify the 20% of pain points that account for 80% of customer satisfaction, and solve for those. And, as you scale, you open up your business to allow third parties to solve the other painpoints.

Thus, by leveraging your technology, you can reach more customers, and solve more customer problems. And as your ecosystem grows, it becomes more central to your customers’ lives. And that’s a nice virtuous circle.

To recap, start off by identifying your product (your recipes). Finding a killer app will help you grow quickly. As you grow, you’ll end up with a lot of spaghetti and that becomes unmanageable. So you put your spaghetti in tidy bowls and use plugs and sockets for communication both internally and externally.

And voila, you have a platform, and other people can use your spaghetti and build their own recipes.

 

If you want to talk more about spaghetti (or pizza) and how you can apply it to your business, you are welcome to contact us on hello@digile.io

If you have better spaghetti jokes please also get in touch.

Tip to understand more about platform: Platform Revolution by Geoffrey G. Parker, Marshall W. Van Alstyne and Sangeet Paul Choudary

Another good read: Agile: if you’re not clear on “Why”, “How” doesn’t matter