Open APIs are sets of rules that enable systems to freely communicate with each other. They allow companies to “tap into the wisdom of the crowd,” Marshall Van Alstyne explains, shifting the burden of value creation to external sources. “You want people you don’t know to bring you ideas you don’t have,” he adds.

In this episode of Product Momentum, Sean is joined by guest host Nathan Shapiro, Head of Platform Strategy and User Experience at Paychex. Together, they draw out Marshall’s expert insights on the correlation between a firm’s open APIs and the progressive growth of its financial performance over time. Marshall is a Professor of Information Economics at Boston University and co-author of the international bestseller, Platform Revolution.

Firms that open their architecture and APIs expand their ecosystem and ignite an interoperability within it, thereby creating a network effect – a phenomenon by which the value a user derives from a good or service depends on the number of users of compatible products.

The key, Marshall adds, is to position your firm to “command the center” of your ecosystem.

“Individuals tend to gain influence or power in proportion to the degree of centrality within their network,” he says. “We found exactly the same thing for firms. The more focal you are, the more central you are in your ecosystem, the greater your increase in market capitalization.”

But, he cautions, opening your data is not without risk. Bad actors exist everywhere. So your firm needs to open for a reason, all the while weighing the pros and cons of sharing your data externally. One of those reasons, Marshall adds, is to “invert the firm,” a mindset that leverages APIS and enables you to share the production of value beyond your own employees.

Marshall van Alstyne is one of the world’s foremost experts on network business models. Be sure to catch the entire podcast to capture all his insights.

Podcast: Play in new window | Download

Paul [00:00:19] Hello and welcome to Product Momentum, where we hope to entertain, educate, and celebrate the amazing product people who are helping to shape our community’s way ahead. My name is Paul Gebel and I’m the Director of Product Innovation at ITX. Along with my co-host, Sean Flaherty, and our amazing production team and occasional guest host, we record and release a conversation with a product thought leader, writer, speaker, or maker who has something to share with the community every two weeks.

Sean [00:00:43] Nathan Shapiro, good morning. How are you, sir?

Nathan [00:00:45] I’m doing great, Sean.

Sean [00:00:46] I’m so excited about the podcast that we just recorded with Marshall Van Alstyne. I can’t wait to share this episode with the audience.

Nathan [00:00:53] Same here. I’ve been a fanboy since I first heard him talk about APIs and network effects in my early product days and can’t wait for everyone to hear what he has to say about not just that, but networks in general.

Sean [00:01:05] Yeah, I think there’s some really key strategic lessons in this podcast. It’s really chock full of great advice for people that are thinking about opening up their data platforms or haven’t opened up their data platforms.

Nathan [00:01:17] Yeah, and I think, you know, the big thing with Marshall is he really understands how you can take a pure technical concept through a complete business strategy lens.

Sean [00:01:25] Yeah. Awesome episode. Let’s get after it.

Nathan [00:01:29] Let’s go.

Sean [00:01:32] Well, hello and welcome to the Product Momentum Podcast. We have a special episode today with two amazing guests. Our first guest was one of the first academics to quantify the dollar value of social networks. He’s been recognized as one of Thinker’s 50 Top Digital Thinkers on the planet. He wrote an international bestseller, The Platform Revolution, with his coauthor, Geoffrey G. Parker, and his theories and academic work on network businesses are taught in MBA programs worldwide. You may have heard him or seen him on an interview at Bloomberg, The Economist, The New York Times, Wall Street Journal, or NPR. Marshall Van Alstyne, welcome to the show.

Marshall [00:02:09] It’s a pleasure to join you. Thanks for having me.

Sean [00:02:11] And our second guest today comes from a very different perspective. He rounds the conversation out because he’s been heading up platform strategy and user experience for a Fortune 1000 company that you’ve probably heard of. He works for Paychex. He believes in innovation through courageous exploration, and he’s no stranger to building teams that innovate at scale. I’ve been working with Nathan for a number of years. He is a thinker and he asks incredible questions about the industry he’s in, the people he works with; he holds everybody to a higher standard. Nathan Shapiro, welcome to the show.

Nathan [00:02:43] Good to see you again, Sean. Thanks for having me.

Sean [00:02:45] Alright. So we’re going to kick this conversation off with a quick question for Marshall. You wrote a paper on the impact of APIs on firm performance. And by the way, your co-authors, make sure they get credit as well, Seth Benzell from Chapman University and Guillermo Lagarda from the Global Development Policy Center at Boston University. It’s been five years since you put that paper out. Have you seen any significant changes in the correlation between APIs and the financial performance of firms?

Marshall [00:03:14] Well, the beauty is in fact that since we did the original analysis, we were able to extend it by a couple of years and it seems as though the results even get stronger over time. One of the interesting points is that sometimes you’d think that a technology intervention would kind of change your productivity as a step function. This is really cool because the use of APIs doesn’t do it just as a step function, but as a progressive function, it changes over time. So we found the companies that opened APIs experienced a 12% boost in productivity, on average, there were changes up and down over two years, but as we extended the data set, it grows to a 38% gain in market cap over 16 years. It’s really quite remarkable that the gains continued to accrue over time. So it was continuous, not just a specific bump in time.

Sean [00:03:57] Well, that’s an unbelievable statistic. 38% growth in market cap in the firms that you studied that implemented sort of an open architecture for their data. So I’m going to flip to Nathan. Like, you guys have experimented with this as well. What’s been your experience for Paychex with APIs?

Nathan [00:04:15] Yeah, it’s been an interesting journey for us. We’re kind of in a conservative market, but also a broad human capital management company, so you naturally run into coopetition and competitors. And so, you know, we’ve definitely seen value, but there’s that conservatism in the market that we see. So I guess, Marshall, my question to you, you know, I first heard you speak back in 2014 when I was stepping into product management at the “I Love APIs” conference and you were talking about network effects, and it really inspired me, transitioning out of an engineering role into product. So I’m curious on how you envision firms leveraging APIs for those network effects and doing so in a somewhat cooperative environment.

Marshall [00:04:55] So it’s a great question. I’d like to kind of paraphrase it using a term that my co-author came up with. We suggest what you try to do is to ‘command the center.’ There’s something really interesting that happens with APIs. So our subsequent analysis kind of looked at, how many other firms are connecting to a particular firm, and what your position is within the network. In social networks, people tend to gain influence or power in proportion to their degree of centrality, that is, how focal they are within the network. What’s fascinating is we found exactly the same thing for firms. The more focal you are, the more central you are, the greater your increase in market capitalization, the greater your increase in product variety on that. So, you know, we like to summarize it as seeing if you can command the center.

Marshall [00:05:39] Another component of this, I’m sure, is something that you yourself would recognize. In some ways, you have to treat your developers like your best customers. You want to enable them to help you by giving them the tools and support and the rewards for doing the right thing. You want to make it easy for them to do that. So if there’s too much friction for their participation, they won’t be able to add value. You know, what we did is we actually tracked a number of followers on ProgramableWeb and we found that if there weren’t any followers, there weren’t any gains. So opening without getting developer participation didn’t get you any value. So you do have to take extraordinarily good care of your developers if you’re going to get that value.

Nathan [00:06:13] So I really like that. You know, when we started our journey, we focused less on breadth of API and more on developer experience, and we kind of saw that same synergy. You know, not necessarily a, ‘if you build it, they will come,’ but, ‘if you build it well, they will use it.’ And so I know in your paper you did talk about also the correlation not just of APIs, but also developer portals and developer centers. Could you talk a little bit more about that correlation and what that additive effect is with a strong developer portal?

Marshall [00:06:39] So we looked at the availability and the contact. We didn’t look at the portals specifically as to how much it happened. We really looked at is the levels of engagement. So a couple of other points on that just in terms of the data we did look at. So we tracked the numbers of followers. We tracked the numbers of folks that participated, the mash-ups if you will. We also, in a limited set, we couldn’t do it for all the firms, but in a limited set, we got private cloud data on the amount of data passing through the API membrane. And we did find correlations there as well. So the volume of participation mattered. So it was the numbers of developers, the volume of data, those kinds of things all did make a difference in terms of the market capitalization gains. And also on the R&D and the productivity gains, there’s really some quite some interesting changes in terms of the, shall you say, the R&D gains of the firms itself, even though they’re able to cut some of their own spending.

Sean [00:07:31] Interesting. You found a negative correlation with R&D spending inside firms that publish APIs too, as part of this. So like, there’s this cost-saving effect as well. My assumption after reading it, and I think this is in your summary in the article as well, is that the R&D is still being done, it’s just being done by outside developers who are substituting it. Did you actually see an increase in the total R&D spend in a given industry?

Marshall [00:07:54] You know, that’s a great question. So here’s what we actually found in there. So again, the market cap continued to rise. Then as the number of developers participating in the ecosystem rose, the internal R&D spend fell, but it didn’t seem to hurt the market cap in any way. Again, the market cap was rising throughout this time. So in some ways, external expenditures were substituting for the internal expenditures, or complementing the internal expenditures. This is a case where I do have to be honest. We didn’t have data on what the developers are spending, so we can only speculate. We do have the numbers of participation. We don’t know how much they’re actually spending.

Marshall [00:08:30] So my suspicion is that the aggregate R&D spend increased dramatically. The other thing that’s happening here that’s quite interesting is kind of the experimentation that’s happening. So you’re getting decentralized parallel experimentation, with lots of different people trying different things on top of your APIs, as opposed to just the firm itself. Not all of those experiments are going to succeed. You can think of those as extremely low-cost experiments that someone else is doing. You just want to make sure that you really help the ones that succeed when they pan out. So my suspicion is that the total R&D spend went up. We don’t have the exact data on it. The internal R&D spend went down and yet the market cap went up as their product variety and their other participation is rising over time.

Sean [00:09:16] Well, that seems like it’d be good for customers because it should reduce cost and provide more options, which helps the whole industry, like raises the sea level for everyone.

Nathan [00:09:25] Yeah and I liked what you said about the experimentation. You know, we’ve always kind of carried a mentality of, our API is a way to encourage and enable crowdsourcing innovation outside the company’s walls, which very much aligns with what you’re saying there. Are there any great, you know, case studies that you’ve seen that really show how that can work through APIs in a business growing with really innovative ideas by being at the center of that ecosystem?

Marshall [00:09:50] There are a couple of simple examples that we came across in a few cases. So, you know, one that was kind of fun was that Walgreens opened up API access to its high gloss printers, so you could do that from any of your photo apps or your social networks. And of course, folks go then to print and while they’re there, they buy a candy bar or a soda or something else. So it drove traffic and the consumption of the stores, which is really nice.

Marshall [00:10:14] Another one that I like is out of Brazil, where some customer loyalty programs actually connected small mom-and-pop shops together to give them the power of the larger stores. So they were able to actually create customer loyalty programs that spanned small stores. And I thought that was a really interesting application of that. So those are a couple of the examples.

Marshall [00:10:35] And then, of course, I mean, you’re probably familiar just with the wonderful story of the rise of Google Maps, which was accidental but a hell of a success story. I love this particular story; I don’t know if you know it. Paul Rademacher is an engineer looking for an apartment on Craigslist. And this was pre-APIs for Google Maps. So he hacked into the system to put pushpins where the Craigslistings were for his favorite restaurants, for nearness to transportation for, you know, high crime versus low crime areas. And it’s kind of funny because the lawyers thought this was digital trespass and wanted to sue him, and the engineers said, “that’s brilliant, we got to hire this guy.” Which they did, and of course, we now then got the APIs for Google Maps and the single most successful API system out there. So that’s probably my favorite story of an API success because everyone’s now attaching to the Google API. So that’s three that are fun.

Sean [00:11:28] I think there’s something to that in that sort of accidental or wisdom of the crowd piece with opening up data access, right? You don’t always know exactly what you’re going to get and, you know, the real goal here is to tap into the creativity of the ecosystem. You know, more minds are always better than one, right?

Marshall [00:11:46] Oh, absolutely. You get lots more variety. Was it Bill Joy that said, you know, “the smartest people always work for someone else?” So how are you going to get their help?

Sean [00:11:55] Yeah. I wonder if, though, there’s a bell curve. Like, you know, a lot of how companies compete today is on the proprietary nature of their data and how much data they have. And, you know, this is a challenge. This is why I think a lot of conservative companies stay conservative because there’s a fear aspect of like, “how much should we or can we give away?” And there’s got to be some kind of law of diminishing return. How do you determine, like, what that looks like for your given ecosystem? Is that something you’ve thought about?

Marshall [00:12:24] So that’s a great question. And you’ve actually highlighted what might be one of the CIO, CTO great challenges here, because, you know, when it’s a success, it kind of accrues to the entire firm. But when there is a problem, it’s their neck on the line. So it happens a lot. There were plenty of cases of opening APIs and then it’s not the case that everyone that then gains access is benevolent. Some of them are malevolent and try to go in and steal your data, hack your systems, do other things. You know, in some of the credit reporting agencies, they had horrible hacks, had a huge data breach; the CTO and the CEO both hit the chopping block on that one.

Marshall [00:13:03] So if it’s your neck on the line for some of these security breaches, you may not be willing to open those things. We did find, on average, we matched it against the security breach dataset, that there is about a 1.2% increased risk of data breach when you open APIs.

Marshall [00:13:19] We also found, however, that firms were really different in their response capacity. So this is again, it’s from the minimal subset within the data. We had the data for the amount of information passing through the APIs, and we find that some companies weren’t paying attention and when, you know, there was a data breach, they just got robbed of tons of data. Others were paying attention and immediately clamped down and we could see it in the data for the smart firms. We even call the cliff of cluelessness, in some ways, because there were some firms that when they got a data breach, clamped everything down and made sure that it didn’t move out, where others weren’t paying attention, they just lost all kinds of data. So you have to really pay attention.

Marshall [00:13:55] Something else that was quite interesting, we found that the breaches were more common among nonstandard APIs, and we think that what had happened was that the more standardized APIs had better security and had better testing, whereas the more kind of esoteric ones, you know, that had been hand-coded had maybe not been thought through and they had more problems there. So we did find a correlation between lower data breach and more standardized APIs and higher data breach and less standardized APIs as ways of handling that. So that’s one set of thoughts. You’ve highlighted a really interesting challenge.

Sean [00:14:30] Interesting. You found that one to 2% of firms that expose their data get, you know, there’s like, there’s bad actors out there. We can’t ignore that fact. And you think about companies like Paychex and Nathan here, he wants to open up to the world to grow, but he can’t risk being on the front page of The New York Times. You know, I mean, I love the advice of, and the statistical correlation that you made, between using standardized API platforms as opposed to just trying to write your own and ed hoc-ing it. That’s good advice. Nathan, what are your thoughts on that?

Nathan [00:14:59] I think, you know, there tends to be a mindset in some of the most conservative channels that opening APIs is you’ve just opened up to the world, right? Marshall, you say “command the center.” And I think it’s more than just security. It’s, you can still maintain control while enabling that, you know, integration, that coopetition and otherwise. And that’s something that was always important to us was, “how do we make sure we have control over what data is moving in and out of our application, our data centers, but it doesn’t mean we have to control the entire ecosystem.” And I think that’s a big part when you talk about, you know, networks and social networks and everything is you can still be the hub and maintain control, but not have to have ultimate control over the ecosystem. And that’s where I really see the value and the growth coming from, is understanding that and executing very intentionally towards it.

Marshall [00:15:48] I think that’s very good advice. You really don’t want that system of just, you know, “build it and they will come,” and just throw it open and hope that folks will be there. You open for a reason. You know, are there particular areas of growth that you want? You want the particular areas of experimentation. Another way to think about this that I think is helpful, I often talk to my students, you really need to think big in the sense of what we call ‘invert the firm,’ which is, you don’t want the production of value just by your own employees. You want it by an entire ecosystem. A lot of the value creation will happen outside if you help it and you enable it.

Marshall [00:16:19] But that comes with some other important challenges. If experimentation is safe, then you really want to open up a lot. But if experimentation is risky, then you’re really careful about that. You don’t want to necessarily open up APIs on pacemakers. You’ll kill people by accident. That’s a bad thing to do. You have to internalize that risk and keep that much more locked down. So think of, is experimentation low risk? In which case, open it up and encourage lots of third-party participation. Think big, go for invert the firm, get third-party production of value in this. But if experimentation is risky, then you need to be careful about that, you need to figure out which data you’re exposing, which products you’re exposing, and how you should consider opening for strategic value, not just opening for being open, but opening for strategic value.

Nathan [00:17:05] So as a follow up to that, you know, one of the things I obviously, I have a UX organization that reports to me too, and you know, one of my beliefs is that the technology landscapes have evolved enough that a traditional mindset of APIs and data integration isn’t just enough, you really have to go beyond and envision this integrated experience across that ecosystem. Have you thought about or really looked into some of the correlations of additional things like single sign-on capabilities or otherwise, and how that might impact a firm’s performance beyond just APIs in the modern day?

Marshall [00:17:36] So we tried to get down to the level of classifying individual APIs. I got to say, over the thousands we looked at, we had students try to classify a lot of them using just kind of machine algorithms. A couple of quick thoughts on that. One, again, if you think of API as permissionless contracts, we’re not having actually negotiations taking place, you want to help people help you, but you also want it in ways where you can revoke that permission if you need to. So single sign-on is important. Again, I also thought, full back on that the more standardized systems are better than the less standardized systems as ways to help with that. So I do think those standardized processes are valuable.

Paul [00:18:17] Hey, folks, please excuse the quick break in our conversation, but I have some exciting news to share with everyone. Save the date, it is the ITX Product and Design Conference. We’re back, so mark your calendars. It’s going to be June 22nd and 23rd, 2023, right here in Rochester, New York. Also back for this year’s conference to emcee is the one and only Mike Bellsito of Product Collective. We’re going to have workshops, keynotes with industry thought leaders, opportunities to network with fellow product and design professionals. It’s just going to be a great environment and we’ll be right in the heart of all the action during the opening weekend of the Rochester International Jazz Fest.

Paul [00:18:51] We’re still working to finalize the speakers for this year’s lineup. But to give you a taste, last year we had Adam Lawrence and Mark Stickdorn, who were also guests on Episode 87 here of the pod. They talked to us about service design. We had Cindy Alvarez, the director of UX at PowerPoint and the author of Lean Customer Development, and she gave a workshop on conducting better customer interviews. And Holly Hester-Reilly was also there, who joined us on Episode 33 of the pod. She shared a day two keynote on ways to leverage continuous discovery to become a high-growth product leader. So whether you choose the product track or the design track, there’s something for everyone. If you want to learn more, head over to ITX.com and there’s a link right at the top of the page. You can register to stay in touch and also check out the archives from 2022. All right, back to the conversation.

Sean [00:19:42] One last question for you, Marshall. You found parallels between a firm’s API networks and actual human social networks in the paper. What did you mean by that?

Marshall [00:19:52] Well, this is the one where I think you really want to command the center. There’s wonderful research in terms of people’s ability to find jobs, people’s ability to generate income, to have power and influence among others, is based in some sense on their index of centrality. You know, how focal are you in a particular network? And we’re seeing exactly that same thing among firms. To the extent that you are in the center, that others build on yours, others connect on you.

Marshall [00:20:17] We even had statistical instruments where if there was API deprecation and your centrality changed, your market cap changed and it fell. So we see statistically that it’s quite interesting that the degree of your centrality is absolutely a predictor of your, you know, market cap, and in some sense, your market power in the system. So the idea that your social network at the individual level ports up to the institutional level is probably what you should build on. So again, do try to command the center and think of your position within the network and use the tools to become more central, to get folks to build on you and to offer value that will pull transactions through your systems that will help you gain that influence.

Sean [00:21:03] Outstanding. All right. Well, I’ve captured a couple of key insights for our audience. I’m going to go through them real quick and collect your feedback and reflection, alright? So the first one is, opening up your data, there’s no doubt about it, it improves your ability to grow. And you should be looking for, like, what can be opened up, you should be opening up. That’s lesson number one.

Sean [00:21:25] Number two, I love the statement that you threw out at the very beginning of the conversation about treating your developer ecosystem like your best customers. That’s a mindset shift for a lot of organizational leaders, like your developers are your customers and you need to think about them as advocates as well. Number three, remove the friction from your developer ecosystem wherever possible. Because we don’t treat them like our customers, I think we tend to ignore them a lot, which leads to number four, which is the wisdom of crowds, right? Which we know, more mines are better than one. It should be common sense. It’s not always common sense. Those are the first four. Any reflections on those?

Marshall [00:22:00] That’s a very good list. Let me just supplement with a couple of different thoughts. On the wisdom of crowds, one of the things you want is you want people you don’t know to bring you ideas you don’t have.

Sean [00:22:10] Oh!

Marshall [00:22:11] And again, you need to open in order that that’s possible. And you need to reward them to make them want to bring you those ideas. So I think that’s a good piece of it. And again, I do think it helps to think broadly, to think of this concept of inverting the firm of, where is it you can benefit by having third parties produce value and not have to do it all yourself? If you can have a better business model, you can be more successful. You don’t have to do everything yourself. You need the better business model. And if you can modularize your systems where others can repackage, remake, and reinvent, you will help that happen. APIs are one of the critical enabling technologies that make that possible.

Sean [00:22:48] They are, but I think they represent a philosophy that’s really well stated in your book, The Platform Revolution, about openness in general and all of the things that you just said. That’s the theme of the podcast for sure.

Marshall [00:23:00] So I was just going to say, if everyone’s interested, the paper is freely available. It’s on Social Science Research Network. It has been peer-reviewed and it’s forthcoming in the journals and it’s on how APIs invert the firm. So you can find that on SSRN and you can get the details of what’s actually been proven.

Sean [00:23:15] Fantastic. We’ll put a link to it in the podcast notes, for sure. The fifth thing I captured was to avoid the cliff of cluelessness. And there’s two kind of ways that I captured for doing that. One is use standards. Don’t try to reinvent the wheel here. You know, you find a statistical correlation between using standards and being hacked. And the second part of that is there’s bad actors. Can’t ignore them. They’ll bite you in the butt.

Marshall [00:23:35] Absolutely correct.

Sean [00:23:37] The last one is, well the last two, one is to think of APIs as permissionless contracts. I thought that was pretty profound, like that’s what it is. It’s like the ability to actually go do the thing with our information, but you can always revoke it. So just keep an eye on it because you know the bad actors are out there. And then I think the key to the whole talk is about this index of centrality. Like, if you’re playing a big enough game, you recognize the network effects in your industry, you want to be the center of that ecosystem. And the way to do that is to be the source of the sharing, to be the place people go when they’re looking for information or things to plug into.

Marshall [00:24:16] That’s a really nice recapitulation. I’ll even strengthen that last point. The vice president of strategy at Alibaba, obviously, you know, one of the biggest platform companies, likes to define platform as the nexus of lowest transaction costs. That is, it’s the easiest place to get things done. And APIs can help you do that. So you can think of this as taking the friction out of getting really useful things done.

Nathan [00:24:41] Yeah. I love that, “command to center to control the ecosystem.” And that idea, you know, we look a lot at data, and every degree of separation from the source of record creates a lot of complexities and inconsistencies. And so the more you can control that center and reduce the number of degrees of separation from a key piece of data for your business, I think is really powerful. And I really like that parallel to social networks and how that works as well. And that’s just a really valuable insight that you don’t have to own the whole ecosystem. If you can set yourself at the center of it, you can have a lot of control over it.

Marshall [00:25:17] Yeah. It’s interesting you can borrow the parallels from the individual granularity to the institutional granularity and import a lot of the same insights, just to a higher playing field.

Nathan [00:25:26] So, Marshall, one last thing, could you give us your definition of innovation?

Marshall [00:25:30] My definition of innovation? I hadn’t thought about that one. Well, we could fall back on the patent notion of novel, non-obvious, and useful. I think those are probably a good way to think about it. So that would be a measure of whether or not it had achieved innovation. But you also want to ask an interesting question as to how you get it. And again, one other element of that is the point that I tried to make earlier is you want people you don’t know to bring new ideas you don’t have.

Marshall [00:25:57] You can be crushed by innovation if it’s somebody else’s or you can be crushed by innovation that you did and you didn’t use. Kodak is a fabulous example of that. They invented digital photography, didn’t use it, and got wiped out by it. So it’s a wonderful, interesting question. That was certainly useful, non-obvious, and novel, but they didn’t use it. So also think of how you’re folding innovation into your business model, wherever it’s arising, how are you going to attach it?

Marshall [00:26:23] To continue the thought slightly further, the guys that focus on open innovation like to conceive of it in two ways. One is outside in innovation where you’re pulling ideas from outside into your organization, the other is inside-out innovation, where ideas that you yourself aren’t necessarily using you make available to others in order to help them be successful, and you tap a part of that success. So again, it’s a whole business model and way of thinking as opposed to a single idea that you yourself own or capture all by yourself.

Sean [00:26:56] I love it. There’s a lot to unpack inside of that definition for innovation. So thank you for sharing that. What are you reading these days, Marshall?

Marshall [00:27:03] Oh, well, it’s a totally separate topic here. It’s free speech and fake news. Personally, I think these are one of the biggest platform challenges we have today. I mean, our society can’t function if we can’t agree whether the planet’s warming or not, you know, whether we’re in a pandemic or not, whether the president’s legitimate or not. So I’ve been reading up on free speech, case law, fake news, Section 230, and what can we do about it? Candidly, I think the research approaches we have to date haven’t really solved the problem, but that’s what I’ve been reading.

Sean [00:27:31] That’s a fantastic way to close the podcast. I think that’s something we should all be thinking about, especially when we’re building large software applications that interact with a lot of people. So Marshall, Nathan, really thank you for an amazing conversation. I can’t wait to share this with our guests and you guys are both welcome back anytime.

Marshall [00:27:49] It’s a real pleasure. Thanks for having us.

Nathan [00:27:51] Appreciate you having us, Sean.

Paul [00:27:55] Well, that’s it for today. In line with our goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get, so please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.