Will: I agree with you about the example of AWS. Our friends at GCP will be sad to hear that they didn't come out as well in your scorecard, but the example is quite true. But I wonder, is it telling that the example you gave is from a technology company? Do you think incumbent banks or insurers or wealth managers get a fair assessment in terms of their willingness to engage in partnerships and collaboration?

Joel: In terms of external recognition financial institutions are definitely partner driven. Someone who's the biggest payments company or the biggest bank in their local market will be doing many B2B and infrastructural services on behalf of other banks. Or if you're international, you may be the primary correspondent bank, etc. So you're definitely sitting within a hub of relations, but it can break down. I used to work at JP Morgan, which has a huge correspondent network. But I didn’t see many examples of them saying, “Oh, customer number one, you should talk to customer number two because you guys could collaborate well together”. Instead, it was more, “Hey, work more with me and let's keep the customers away from each other”; or it never even came up.

The other view is to make our ecosystem larger because if our ecosystem wins, then we win by default. I don't think they approached it the same way that Zara would approach how their suppliers function. Tech firms are inherently interdependent on each other in many cases. Financial services firms start to exhibit more of these signs in elements of the market where APIs are available. APIs start to break down barriers because integration costs go down and the quality of what you're seeing can go up in a more measurable way.

Will: There’s a real challenge for companies to incentivise a change in behaviour.

Earlier you said how difficult it is for smaller companies to build a large platform and wait for years to monetise it. In today’s macroeconomic environment, there is a lot more investor discipline and insistence on ensuring the unit economics are profitable right now. If that pressure's there and smaller firms need to focus on monetisation, what's the right approach for a smaller firm to take advantage of collaboration and platforms?

Joel: From my perspective, every company needs to be thinking about themselves, both as a publisher and a consumer of platform services. It's very rare that you're going to ring fence software or operational IP behind your web portal, salesperson, or a narrower set of channels. Instead, the best collaborators say, “Oh, we've got some process knowledge. We're going to convert that process knowledge into technical knowledge. Maybe we have access to some resources based on wherever we're coming from - effectively, we will be a manufacturer”. The way you expose knowledge-based assets or technology-based assets that you manufacture is ultimately through APIs.

Which, generically, you could say is part of a platform: the API and then the rules and business model that governs the API. Even if you are a very small company, you should be thinking about saying, “How does my IP get out into the market and scale, and how do I deliver at least one thing that someone else wants to use consistently?” That then forces you to think about what aspects of your business are human-based, but can sit behind or in the middle of a technical process, what can be engineered out over time through software. Ultimately, you're bringing your hard won business knowledge to bear thinking about the high-value elements of a problem versus the highly repeatable elements of a problem. That's what starts to turn into platform thinking. To go back to the JP Morgan scenario, one of the most important ways to be successful in the bank is to consistently improve the efficiency ratio of your business unit.

High top line performance isn't valued, whereas high efficiency is valued and that’s why Jamie Dimon believes that over time, the top line fluctuates, whereas an efficient bottom line generates free cash flow. So if you've organised your business as a system of interlocking systems that generate free cash flow at an increasing rate, ultimately you will have built a cash machine. As opposed to a machine where your day traders come and go and ultimately will go somewhere else for half a percent more and you've been left with nothing. The idea of building systems is the core of what you do and then monetising systems, even if your own desk sitting in front of it is the primary consumer, it's important to have that systems knowledge and systems thinking regardless of what business you're in. Even very small businesses should start life with that as their framework and look to expand access to it. Everyone should be thinking about how their IP, over time, becomes leveraged at an increasing rate and improves quality and efficiency over time.

Will: That is very important to understand how that efficiency improves. One of the things that's quite hard is understanding some of those efficiency improvements will come from external sources, and are firms willing to open up to enable that improvement? Is it hard to structure a system or a platform in such a way that you're open to external input on efficiency?

Joel: It's hard in the sense of more hours in the day, more than anything else. If you think about the product management world, you have internal PMs who primarily have relatively limited exposure to the customer: maybe, 10% of their time. Most of their time is spent dealing with internal issues. Then you have people that spend time with the customer, but who may not have many windows to inject things into the product roadmap. You’re trying to marry those two tensions together. Much of the customer knowledge, insights, communications, etc. are held with the latter group.

But the latter group isn't necessarily able to turn 100% of that into actionable items for the first group. So there's a knowledge mismatch. If I'm in the product group and very internal facing, but I've got a window to say, “Oh, we're touching this particular widget. Tell me everything I need to know about how the customers want one to evolve, or help me interview a bunch of customers”. Then, in four hours, magically, this customer is going to tell me something that I'm really listening for when in reality, the customer’s got a billing issue, a content issue and 10 other issues, and they don't necessarily know what I care about. This communication impedance between the product and customer groups is a real problem. Ideally, you'd have these conversations often to find hooks that they marry up. Product teams need ways to receive direct customer feedback from the support process. Zendesk tickets should be turned into knowledge. At every turn you have to be focused on learning.

Will: We've been talking a lot about what makes for effective organisational rhythms around engaging in platforms and with partners, collaborating to develop efficiency, and deploying your company's knowledge. As you look out over the marketplace, what are some platforms that you like? Who's doing a good job?

Joel: I mentioned AWS earlier. I see it a little bit less now than when they first came out, but every six or eight weeks or so you get an email from them saying here's a whole bunch of new features we're launching. But they're very rarely what I would consider very broad-based features. They're very often weirdly narrow features around one particular industry that implies an extremely deep level of knowledge of that individual industry. I always find it's just so incredibly impressive to think about, who on earth is getting that close to one industry segment to say, look, let's ignore 10 other things we could do that might be more broad and really help serve this one segment. And then, eight months from now, we'll go serve a different segment and a different segment after that, etc.

I've always liked Stripe because the breadth of their vision is very wide. Aspects of what they do are not particularly wide, in terms of the number of payment methods or the number of countries they operate in, but their vision for building a nervous system for payments that goes all the way through the lifecycle. Relatively early on in their life they had services like Stripe Connect, which is really cool, but barely utilised because most people don't really understand it. They committed to them a long time ago and have built around it. They haven't quite figured out how to get it into the market really in a way that it becomes the thing that they think it can be, but they really committed to this idea of programmatic entities and programmatic payments a long time ago, which helps them stand out from my perspective. They had a product architecture vision and a vision for what the future might look like, and then committed the organisation around it. That's pretty cool.

When you think about IOT, the idea of saying here's a transactional service that appears to be non-network, non-intelligent and relaunch it without those constraints. Once I've networked it, what can I do differently that it wouldn't have been able to do before? The product will be so much better than the alternative because they decided networking will be a core part of it.

If you look at Airbnb as a system, they decided a long time ago that their asset wasn't the real estate, it was always the people who travel and the people who host. They've had a tough time during COVID, but they had already started three, four years ago moving towards the events model and really understanding what it takes to enjoy a destination. Their ability to pivot and add in these other services is because their product was the community. It was always the social network more so than a network of real estate. If your product was managing hotels and no one needs hotels, then obviously you're out of business. If your product is people who feel a certain way, who think a certain way, who want to communicate a certain way, then you can have some resilience.

Will: You mentioned the community in the very beginning and that's so important to understand. So much of the model that we used before was inherently transactional, product-focused.

Joel: Back to the first point, once you take out the constraint of time - a relationship with a time constraint is transactional - the relationship is about many touchpoints, over time. Part of the big difference is having a more elastic definition of time.

In my case, I've been here for a little while and adapted to make messaging a big part of my daily business process. I'm now in a position that I can ping people I haven't seen in a long time, ask them a question, get an answer, get a rate card, cut a contract, literally, in nine WhatsApp messages because we already have a relationship. They're equally happy to have something be very efficient because that trust is already there in some way. That's the asset over time.