Building Platforms Developers Love: Lessons from Stripe, GitHub, and Netflix

[00:00:00] Welcome to the Convergence Podcast. I'm your host, Ashok Sivanand. Some software platforms thrive and others fade into indifference. And I think there's three simple principles that make the difference for really successful platforms. Let's dig into it. On this show, we'll deconstruct the best practices, principles, and the underlying philosophies behind the most engaged product teams who ship the most successful products.

[00:00:36] This is what teams are made of. Hey folks, welcome back to another episode of Convergence.fm. As technology and product leaders, one of our greatest challenges and also our greatest opportunities is building platforms that act as building blocks for great products. That software developers don't just use to build those products, but they genuinely love using and love telling their friends about.

[00:01:01] Some of the greatest companies and greatest value in the tech space that's been built in the last few years, companies like Amazon Web Services, Stripe, Twilio, and also more traditional companies that have adopted modern methods like Microsoft, have been largely successful because they provided a set of capabilities to software teams out of the box that enable those software teams to build products that are better,

[00:01:31] build them faster and for cheaper, build them faster and for cheaper and bring the most value to their customers. A platform with high adoption drives innovation and efficiency, whereas neglected platforms aren't used and are forgotten.

[00:01:46] And in the case of internal platforms, if you're a large company where the engineers of that company are forced to use this platform, a neglected platform will tend to drain resources, curb your employee morale, and slow down innovation and stifle it versus enabling it. On today's episode, we're going to explore some of the things that differentiate the platforms that developers embrace from the ones that developers avoid.

[00:02:14] And I've got a number of stories from the field, both from my time working with platform teams through our work at Integral, as well as stories from leading platform companies that have been really impactful sources of inspiration for our industry. Subscribe to the podcast to get future episodes as soon as they're published. If you find this helpful, give the podcast a five-star rating on your podcast app or hit that like button on YouTube.

[00:02:43] As I listened to and thought about the last episode about platform architecture and team topologies on Convergence.fm, where our guest Henri Vandenbalck, the VP of Global Software Systems at GM Financial joined us, I recall some of the really impactful stories and some of the trends that emerged amongst those stories where there was a lot of success on the platform.

[00:03:13] The trends, the first is that platform teams tended to have a deep customer empathy and more importantly took intentional steps that were repeatable and teachable around developing that empathy through approaches like human-centered design. The second trend was one around an iterative and disciplined approach to product management.

[00:03:37] And the third was that the companies or teams had a strong culture of empowerment that was fostered by their leadership teams. So let's get into some of those stories and how I think those approaches played a part in building really delightful experiences.

[00:03:55] The first couple of case studies that I'm going to talk about are around how to systematize that deep customer empathy amongst the customer developers that are consuming your platform. The first one is from our time at Integral and we worked with a large automotive company that was building a much more flexible payments platform for their internal developers.

[00:04:22] For context, this was at a time when the automotive industry was moving away from a payment standpoint from just collecting a lease or a finance payment once a month or twice a month to a lot more diversity in their payment models. They were getting into things like subscriptions for various features like maybe full self-driving for flexible billing periods instead of just once a month for usage-based charges versus time-based charges.

[00:04:50] And maybe billing charging for their electric vehicle customers. And we had to serve numerous internal app development teams that came from various departments and lines of businesses from commercial vehicles to autonomous vehicles, electric vehicle charging, vehicle sales, vehicle service, and a lot more. And initially when we set out to develop the platform capabilities, and in this case we wrapped around a leading payment services provider.

[00:05:18] When we got into it, we saw that the internal teams that we were supporting from the various departments and lines of businesses had competing priorities. This shouldn't have been surprising given that the lines of businesses that they represented had competing priorities.

[00:05:31] And catering to these diverse goals raised a bunch of risks like platform fragmentation, low adoption of the platform, frustrating not just the product teams and software engineers, but also the executive stakeholders that they reported to that were responsible for new business through these new flexible payments. And without mitigating these risks, I think the company also risked duplicating development efforts across their organization.

[00:06:00] They risked delaying new products and new features that they could bring to market and the revenue associated with that. They risked frustrating their internal developers who are generally a challenge to retain already. And ultimately and most importantly, I think they risked having unhappy or end user customers that found it subpar.

[00:06:20] So to mitigate this, we spent time sitting directly with the customer teams internally, and also in some cases external end consumers for some of their newer offerings. And we facilitated workshops, did detailed depth interviews or contextual interviews, and we uncovered some of the detailed, more deeper constraints and nuances about these teams' workflows, timelines, various challenges, expectations from payments.

[00:06:47] And I think this very customer-centric approach helped us uncover some super critical insights. Like for example, some teams simply needed clear documentation early through a tool like maybe SwaggerDocs so that they could plan their own architecture and development. They just wanted to know what the APIs were likely going to look like. They didn't need the actual production APIs until much later when they had payments prioritized.

[00:07:11] Others super urgently required very specific in-production capabilities that unlocked significant revenue that was being blocked and also created subpar customer experiences. And so we tailored our roadmap by incorporating the synthesis from this research. And we created a pathway that addressed the highest value and the most urgent use cases first. And we didn't have to do anything like compromise quality of service or reliability of the platform.

[00:07:36] This is something that teams can get pushed into inadvertently sneaking into how they pull levers. And quality is the lowest one on the priority that we'd want to have any sort of compromise around. And I'm glad we didn't have to in this case. And ultimately, as we rolled out the early releases of the platform and then added to more features later, we got to collaborate with some of those early adopter internal customer teams.

[00:08:05] And in order to ensure the highest adoption amongst those customers or any wasted development by those teams in order to maximize the value they could bring, we sat with them and helped them integrate it ourselves. And spending so much time with our customer developers not only allowed them to go to market faster and delighted them, it also helped our team's engineering teams develop deeper trust amongst the product teams who are our customers.

[00:08:34] And we were able to develop this trust really early. I think taking the time to understand their needs and goals and constraints, and then also communicating our updates in language that was most relevant to them and highlighted things specific to teams that they were relevant to, made it a lot easier later on when we had to negotiate with them on occasion. And this avoided a lot of the political strifes that can tend to show up in large companies and really just allowed the builders to focus on building.

[00:09:03] An industry story that we were inspired by certainly that sounded similar around a very customer-centric approach was from GitHub, which is now part of Microsoft. But way back in the day when GitHub was founded in 2008, some of the things that we take for granted like source control were a lot more cumbersome for development teams. If you're like me and you wrote code before GitHub, you'd recall that we use version control systems like subversion or CVS

[00:09:32] and how much coordination that required across all the development teams just to check in code and how error-prone that was and all of the frustration that came with that. Now at the time, in 2008, GitHub did face a pretty uphill task. They needed to make this complex and sophisticated concept of version control a lot simpler, seamless, and more accessible. If we didn't adopt this as an industry, it would mean we generally, as developers, fall back to the default of familiar but inefficient workflows

[00:10:02] that hurt our productivity and cause a lot of frustration. And what did GitHub do? They tackled this by immersing themselves amongst the developer communities. They attended meetups. They closely engaged with open source contributors. They actively participated in forums and mailing lists. They reviewed analytics and directly observed the daily coding practices amongst their target audience.

[00:10:29] Through these interactions, they obsessively studied their customer developers' pain points, frustrations, their existing workflows, and they were able to identify precisely which points of the collaboration broke down or became overly complex and frustrating and inefficient. And this allowed them to design a solution that was intuitive,

[00:10:54] developer-friendly, clean, simple, and really in response to real-world research and feedback. Features like pull requests that we take for granted today emerged from observing how developers collaborated organically. GitHub had a super empathetic UX and it made it frictionless to adopt, helping the company become the most beloved developer platform, I'd say.

[00:11:19] And then also, just 10 years later, they got acquired by Microsoft for $7.5 billion. Fostering an engaged product organization and aligning them with the principles around lean, human-centered design, and agile will more than likely lead to successful business. And then, just 10 years later, they'll be able to help them with the business outcomes for your organization. But getting started or getting unblocked can be hard. This podcast is brought to you by the player coaches over at Integral.

[00:11:49] They help ambitious companies like you build amazing product teams and ship products in artificial intelligence, cloud, web, and mobile. Listeners to the podcast can head on over to integral.io slash convergence and get a free product success lab. During this session, the Integral team will facilitate a problem-solving exercise

[00:12:14] that gives you clarity and confidence to solve a product design or engineering problem. That's integral.io slash convergence. Now, back to the show. The second trend of the three we're talking about today is having an iterative and disciplined approach to prioritizing your product roadmap and your development backlogs

[00:12:42] and being intentional around your product management. The first story that comes to mind is when our team was building an identity and access management or IAM platform for a commercial vehicle client that we have. There were a lot of applications that helped those commercial vehicle customers that sat on the commercial vehicle platform. Things that helped the customers with choosing which vehicle was best for their business and use case, buying them, servicing them, charging them.

[00:13:10] And all of those different products and applications relied on our IAM system for security to get authenticated and authorized. And this required extreme reliability of the platform since almost every API in the system depended on us. And similar to the last story, we identified early that we faced some major risks of failed integrations, delayed products, lost revenue, and a subpar experience for highly valuable commercial vehicle customers and dealerships.

[00:13:39] And in order to mitigate this, we prioritized our efforts carefully. We identified the initial customer teams that were going to be consuming the platform. We aligned closely with everyone's product release schedules that sometimes matched up to vehicle releases and intentionally started with minimal viable solutions for them. In this case, minimal viable solution wasn't one that compromised security or like we talked about quality by any means. What it meant was that our early customer teams

[00:14:07] had to do a bit more work to integrate our services into their products. But in return, they got access a lot earlier. And what we did with them, since they did have to do extra work and we were curious about how it was to use it, is what we had really high-touch onboarding with these early teams. And we captured detailed feedback and usage insights through pair programming. And this allowed us to iterate rapidly and continuously refining these services and documentation

[00:14:35] and also knowing what to automate and ultimately made a much more seamless and fast onboarding experience for all the other product teams that were going to onboard onto the system. And in this case, it resulted with the early teams getting what they needed, even if it required that they put in some more work that we helped reduce. And all the other teams having a much more seamless experience when it came to their turn to integrate our service. And this feeling that they had of, wow, these folks get it.

[00:15:04] This aha moment, right? And I think that this disciplined, iterative approach ensured that our service also became both robust and intuitive and it reduced the friction and drove really enthusiastic adoption amongst the customer developers internally. Something that I recall from the industry is a story that I loved hearing from our season one guest, Kenneth Alchenberg, from his time at Stripe.

[00:15:32] And as the story goes, it was in the early 2010s that the brothers Patrick and John Collison founded Stripe. And they did so because they personally experienced the complexity and frustration that it takes to set up online payments. And you may have done that too on products that you worked on. And despite this industry of payments being a super crowded space with a lot of established incumbents, they recognized that the existing solutions were very complicated.

[00:15:59] It took a long time to implement. And even if it catered to the leaders of the customers, it alienated the developers who worked there and subsequently the startup customers. And believing that there was a substantial opportunity to simplify online payments dramatically, the brothers and their team set out to create an API-focused platform which abstracted away all the complexity of payments

[00:16:27] and ultimately helped their customers integrate online payments into their products with just two lines of code, as they used to say. And to ensure success, here's where it gets interesting. The Collisons personally supported a small group of initial developers. They provided hands-on, direct technical assistance. Patrick Collison actually famously has rumored to share his personal phone number quite publicly

[00:16:55] and answered urgent calls from developers at all hours. They would frequently debug developer code themselves. They offered personalized guidance through live chats, visited some of their early users on-site at their offices to help them integrate, but I think also observed precisely how Stripe was integrated into their applications. Now, no doubt, think about the level of super rich customer information that gives them. This level of customer engagement,

[00:17:25] no doubt allowed them to capture very nuanced insights that directly shaped Stripe's API design and also their onboarding process and documentation clarity and other things that Stripe is famously known for. Now, this might remind you of a product adage that you got to do the things that don't scale initially to learn and know what to scale through your product or in this case, your platform. Only after extensive real-world validation and research

[00:17:55] did Stripe scale up to automate their onboarding and documentation, and it was based on the proven successful patterns from the field. Their iterative discipline created one of the most admired API experiences in the industry, the gold standard, I'd say, in many cases for developer relations and developer experience, and it's led to widespread adoption and massive success. Today, Stripe is valued at over $90 billion. I think there's more than a million websites that process payment through Stripe,

[00:18:24] and they work in almost 50 countries, and that's pretty impressive given how complex payments can be alongside internationalization. The third trend for today that I think is really useful for building great platform teams comes around empowering your team as a function of your company's culture. Empowerment is a complex and overused term, I'll admit. It's a little jargoning. The author, Tom Foster, has helped me simplify this term empowerment

[00:18:53] into three more actionable things. The first one is authority. Clarify the boundaries in your organization in which the team can make decisions without needing permissions or approvals from anyone else. The second two are around accountability, which further is clarified by him around what is due and when is it due. And Netflix, although widely recognized, of course, as a consumer-facing website

[00:19:22] where we watch TV shows and movies, they also heavily depended on internal technology platforms to efficiently scale their streaming services and their content production. Internally, Netflix managed complex challenges around content streaming, personalization algorithms, global content delivery networks, data engineering, and infrastructure reliability. I think they've got above or around 2,000 developers that work on very specialized teams.

[00:19:52] And those teams face immense pressure to innovate really fast, scale globally at Netflix scale, and maintain exceptional reliability that Netflix has as the business and our awareness of Netflix grew exponentially. They quickly became a leader, not just in what they did as their day jobs as video streaming, but also on the back end around cloud architecture. And they pioneered tools and practices

[00:20:22] that have been adopted widely across the software engineering industry today. Some of the things I really love are Chaos Monkey for resilience testing, their Spinnaker for continuous deployment, and the Simeon Army Suite that's used for infrastructure stability. And I think in their case, they recognized early that a top-down, rigid decisions could really demotivate their internal teams, slow down their innovation and bottleneck it, and create technical bottlenecks as well.

[00:20:52] And they have a famous principle called freedom and responsibility. And it's something that our guest from season one, Jose Moreno, joined and talked to us about. And through this freedom and responsibility principle, what they did was they empowered their super diverse service teams, like we talked about, like streaming, infrastructure, recommendation engines, content delivery networks, data groups. And all these teams were autonomously allowed to choose

[00:21:20] to use or build tools that best fit their needs and their business objectives. And this ended up driving platform adoption and very high internal satisfaction amongst their colleagues for the services that they built. They gave their engineering teams significant autonomy, supported by really clear accountability expectations, and very transparent communication. The leaders at Netflix trusted their developers to make technical decisions

[00:21:49] that aligned to the company objectives that they clearly stated. And this fostered deep ownership and motivation amongst their talent. This empowerment culture has created extremely high internal employee satisfaction, rapid platform adoption, and I believe it's an important reason for Netflix's innovation and impressive growth. You can find more through the Netflix culture deck that we'll make sure to have a link to in the show notes. To wrap these case studies and the trends up, let's recap the three trends

[00:22:18] that you can implement to ensure that your developer platforms are widely adopted and loved by your customer developers. First one is deep empathy. Spend time understanding your customer team's real-world challenges and build solutions and your roadmap and your backlog directly from those insights. My advice on this additionally is to also have a few folks who do this research, not just one, and include engineering folks to join these conversations. In my past, I've seen friction

[00:22:48] between project managers maybe on the platform team trying to negotiate schedules and stuff with engineering leaders and the customer product teams. And those engineering leaders needed to architect solutions within their constraints and it led to sort of communication friction. And when we started adding engineers to those calls, a lot of that friction went away and the engineers were able to listen better and understand each other better. And I think this helps a lot in terms of driving that adoption and delight. The second trend is around iterative discipline in your product management. Start small,

[00:23:18] validate early, refine rapidly, and automate based on what's actually working well and try to limit the assumptions you have in there. The third is around cultivating a culture of autonomy, transparency, and accountability to motivate your teams and drive enthusiastic adoption in your culture. Clarify the authority, the accountability through transparency like we went into a little bit more detail about. That all being said, thank you so much for joining today's episode

[00:23:46] of Convergence.fm. Building platforms that developers love is super achievable by putting your users at the center, iterating methodically, and empowering your own platform teams so they can bring delight to the product teams that they enable. We will see you next week with another episode of Convergence.fm. Until then, I hope you have a great week.

[00:24:16] Thank you for joining me on the Convergence podcast today. Subscribe to the Convergence podcast on Apple Podcasts, Spotify, YouTube, or wherever you get your content. If you're listening and found this helpful, please give us a five-star review. And if you're watching on YouTube, hit that like button and tell me what you think about what you heard today.