Get ready for a riveting episode of The Unlearn Podcast! Join us as we delve into the brilliant mind of Geoffrey Parker as he shares his insights on Creating Value Through Platforms and how this applies to B2B tech, scalable building and avoiding technical debt on the journey from product to platform.
00:00 - Intro
02:04 - Update on Geoff’s book “The Platform Revolution”
05:21 - The meaning of the term platform
11:32 - The VC Model to create network effects
19:47 - Bootstrapped companies remove technical debt faster than venture backed companies
21:11 - Ways to avoid technical debt
27:10 - Best of breed solutions as fixes to legacy tech interoperability vs investing in interoperability system wide
28:00 - Managing integrations inside the company vs outside it
29:46 - Competitive advantage for digital native companies designing their own systems to be interoperable from the get go
35:15 - Monetization models around revenue partnerships
45:03 - The Competitive-Cooperative line on platforms and the role communities play
"If you start offering a lower cost self-serve, low friction, sort of go to market, then you're gonna be potentially bleeding out P and L, you know, some revenue from the existing groups [on the platform]. So that's a tension that has to be managed."
00:17
Hey, everybody, welcome back. We're here with another episode of the Unlearn podcast. And today, the guest that we have is not somebody that you would normally meet. So, we're thrilled to have Geoff Parker with us, Geoff, do you wanna tell us a little bit about who you are and how you got to where you are?
00:49
Yeah, sure. so, my day job is at the engineering school at Dartmouth College and I used to be in the business school at Tulane. And so I ride this kind of borderline between business economics, strategy, and engineering. Really half my whole career.
I started actually as an engineer at General Electric and then moved into being a finance guy at General Electric and then moved to be a master's student in engineering at MIT and then a business school Ph.D. student at MIT, then a business school professor, then an engineering professor.
You should get the idea there that either I can't make up my mind or I have found the exact place where I should be, which is at that intersection of technology and business, which has been just super fun throughout my career.
01:45
That's super interesting. So when I came to this country, I came and I did the regular immigrant thing which is to go to school for computer science. And then when I got out of college, I only did coding for maybe like a week. And then it was way more interesting to go help the sales team because they had the same problem they were like, can somebody just take what this technology is and explain it to these other people that are business people?
And I realized that if you can do that, you're gonna have a job forever in tech or as I'm learning right now, you can go teach. So this is fantastic. You just gave me a brand new idea.
02:24
I will add because Geoff didn't mention it, but he's the author of The Platform Revolution, which is one of the key books on platform strategy. I had heard you on my friend Greg's podcast Unsiloed, and you mentioned that an updated version is coming out. Do we have an ETA on that or is that still being determined?
02:49
Well our publisher wish it were yesterday.
02:55
So do we.
02:57
So we're planning to ship it to the publisher. I'm not gonna give you a firm date, but it'll be in 2023, hopefully, earlier rather than later. I will say that the world is changing so fast around us that in many ways, the delay we've had is working in our favor. And in particular, in the regulatory space, there's an awful lot of action but also um in this B2B space that I think we're going to spend some time talking about today.
I'd say there's been a lot of change and that's one of the areas that we're going to add a lot of new content.
But yeah, I mean I'll just say a few words about The Platform Revolution because that book came out of probably 20 years of research that Marshall Van Alstyne and I had undertaken really from our graduate student days during the dot com boom and then kind of observing the dot com bust around two, you know, 2000.
And then observing the emergence of a real business model that had a chance of growing, which of course, we've seen in Google and Amazon and then later on the kind of Facebook and their derivative names of Meta and Alphabet. Now and then the resurgence of Microsoft, you know, which some had taken for, you know, an ancient, ancient history, but then they were able to make some, some pivots and become relevant again.
So the book was born out of our classes as professors. And, you know, we were frustrated because we're like, this is cool and this is important and uh we only teach 50 or 100 people a year that feels somehow limiting. So we were pleased that it hit 100,000 people in, in 10 languages and counting, and, I think we kind of hit a nerve if you will be able to explain changes that everybody could see around them.
And, more importantly, give some language, you know, give some frameworks, help people with some common terminology that helps them communicate more efficiently, understand, you know because they can see what's happening around them with their own eyes. So that was just sort of a few seconds on where, where we were coming from on that. And we were fortunate to meet up with Sangeet Choudary who was active in the space as well, but more from our practitioner side. And so that was a nice, nice partnership that continues to this day.
05:41
So for the new version, do you guys maintain the same definition of a platform? Because something interesting from the operational side and people working in the field, especially with B2B SaaS I think platform means something different for people in B2B SaaS than it would be in your book, how it was defined in your book. Which is fine as long as everyone understands what we're talking about, right? But I think, for example, Uber people will look at it as a two-sided marketplace is how they would think of it. And then they think of the Salesforces as a platform, AWS as a platform, and Amazon dot com as a platform. Have you guys made any changes on that front or do you maintain, maintain the definition and just explain what it is for the B2B context?
06:30
More the latter. So, and the word I insert when we're talking about some of the examples you just used Azure for example, or you know, Google Cloud or, or AWS is I'll talk about a technology platform, just insert the word technology because you're talking about the technology stack.
And then in terms of the types of platforms that we describe in the book and spend a lot of time thinking of those as a business platform because a lot of what's going on there is you're thinking about What are the sources of value and what are the business models? Um Because, we talk a lot about different types of users, the network effects they create for one another, whether those are the same side or cross side. And we'll dig into that.
I hope today in our conversation about how you might think about the value um kind of evolution, especially in B2B from kind of conception, launch growth, maturity because you'll end up letting up different buckets of value. And then that definition of a business platform will become incredibly important to kind of help with the mapping.
07:48
And, Geoff, have you been seeing changes in maybe the journeys of the people that are built, the leaders that are designing, or the building of these platforms?
08:04
Well, I'd say, you know, we were using the words accidental platforms a decade ago because I think people had not been intentional. But then woke up one day and went, wait a minute. I've got strong network effects. I can see that I'm getting pulled and some people use the word flywheel, but I'm getting some kind of a pull that's independent of the technology value that has as much to do with the user base as it does with the technology. And so some of those firms and so, for example, did they wake up one day and say, hey, we're going to build a network effect business, or did they wake up one day and say, hey, we're gonna solve the transaction cost problem with the distribution of content. And oh by the way, that ended up, you know, with a few digital rights, especially there at the early creation of a little bit of switching cost which then allowed for the building of some barriers to entry if you will, or some more.
09:12
More effects.
09:14
Also, exactly. and, you know, whether those economics were intentional or not, they became observable.
09:24
Yeah. no, this is, this is great. I'm always thinking like once people figure hindsight is genius and foresight is like completely like had to do it, right? I remember like when I first came to this country, right? And everything was all people, people were still devout followers of Microsoft and everything else. But like the iPhone, when it came out, some folks realized the reach and the stickiness of just the device and how it can change people's lives, and the early developers of even apps, you know, Like there were the two popular apps and everybody else, right? And uh and I think that those people got like 98 or 99% of the value out of the early, like, let's call it be one of the IT platforms, right?
Because they, they just understood what was happening. And uh and then they, they also had the patience to like go through all the kinks that the platform did and did not provide. And uh and, and it was incredible and I Remember for the very first time when I saw an iPhone, as it looked like the new mouse now, right? Like, and, and if you remember that and it had this like, like really four apps and we were like, well, this is a better Blackberry, right? And, but the people that understood, yeah, the value of just iMessage and they were like, wait, this can go across platforms and stuff and uh and that, that changed people's lives. And I clearly remember my friend Hussein telling me the way, way back in the day, like, hey, this is a trend to follow, you know, because this is how people develop code and reach other people. And if this becomes something, there's a huge business behind it. And again, just like you said, I was like, yeah, but my Blackberry Messenger is great. Yeah, like I'm not switching, right? And lo and behold today, everybody has an iPhone, right? Yeah.
11:22
Or, we can sort of go into the Android and iPhone kind of contest. But I do want to circle just quickly back to Kelly's question because going into those sorts of accidents, I think what's changed over say the last 15 years is that the understanding of the sources of value in these types of systems is a lot better. And so you, you see intentional efforts to create network effects, for example,
11:52
This is an interesting question because I think, you know, if you look especially in, in B2B SaaS, the model right often relies on VC funding to, to get going, right? And I think that when you look at that systemically, um what are some of the downsides? and what are some of the upsides? is there a better model for us that is the vehicle for which companies can move forward to a point where they can prove the value or not, right?
Tens of millions, if not more, are often invested in companies who spend that money to acquire users with the idea of creating network effects. And then, of course, some of them just fall flat and turn out not to work. Maybe hundreds of millions were spent. Now others work. Is this a good model from a systemic viewpoint? Is it the only model, uh sort of given our regulated capitalistic system?
12:51
I love this question and it gives me a chance to jump up on a soapbox. So observe me jumping up on a soapbox because I, you know, have the good fortune to work with a lot of different organizations. Many of them are incumbents so uh firms that have existing businesses and sort of more linear value chain, business models that are interested in becoming platforms.
And then what I'll often see is they're not ready for that. And the reason is that their technology can't support it. And so they have fragmented and siloed technologies stacks if you will um data in different divisions where you'd want to be able to pull that. And so there's this, this sort of first step of digital transformation and I promise you, I'll tie it back to answering your question about VCs.
Because uh and, and so where you end up starting with some of those organizations to say, hey, you know, rather than jumping immediately to a platform with network effects, how about just building a really good product or service, you know, like the old fashioned way that somebody wants and you'll start to amass a single type of user and offer them a value proposition.
But the caveat is with the understanding that in the long run, you're going to want to make it open, you're going to want to be able to connect crossed users so they could interact because you, you don't have every smart idea internally. And so you're not going to have the engineering capability to create every new bit of functionality internally. And then think about the social kind of interaction features, you know, and then How can you start to light those up over time? And what I just laid out to you is in effect like a 3-5 year journey that says, where are you going to invest to get going? What's the next source of value that you're going to start to light up in terms of potential network effects?
15:07
So when you say build, sorry when you say build a product, are you saying identify the user that you would like to exist if you have built out the network effects and then find a product that meets their needs? Because if you think of something like Fiverr, for example, right? What's the product that would have started the chain essentially like for freelancers, or are you talking more of a B2B SaaS? That makes sense.
15:37
You're a marketplace from the get-go, and you, have to mobilize both sides of the market and you have to have liquidity and you've got to think about managing those two sides simultaneously. I'm talking more of the kind of SaaS where you could deliver a service using your technology. But over time you could start to layer in different sources of value.
16:09
Do you have a comment on the VCs?
16:13
Yeah, I just said it's about who's going there.
16:17
But, the first part was a preamble because, you know, if you think about what I said, I'm talking about literally building a product or a service in a way that we would have thought of quite some time ago. And you say, well, what about the VCs that are gonna light you up in network effects, um which I'm, you know, an observer of, of a study or a student of.
But until you have nailed down a compelling product or service, it's almost what's the point because that's a good way to ramp you up and then explode um miserably and, and, you know, from the VCs point of view, look, if they get one great success out of 10, that's, that model works.
But for those other nine entrepreneur teams, they might have wanted to go a little more slowly and a little more deliberately and have a higher chance of individual success whether or not that would cap their long-run upside. And so you may have a, a kind of a mismatch if you will in those models of who wants what, and that's something I'd look out for. And, you know, if, if you're gonna talk to individual startups and say, hey, you know, think about who wants what in this equation and you know, ask some questions of the V CS that you're working with and you know, often super firms, tons of great information, connections advice. Um But you know, be thoughtful about who, who everybody's exit strategies in this.
18:03
Yeah, I have one question for you. but just for our listeners, like when you look at a VC and you look at their fund, the entire fund does not need a 10 X or better return. The majority of the fund is just looking for 2 to 3 X returns. There's a smaller major part of the fund that's looking for 3 to 5 X and then you have moonshots. And so I just want to say that I think it's, it's a, it's a pretty interesting time to be talking about VCs anyways, but the, the, the, the fund structure does not require 10 X and there will be many V CS out there. And other types of folks will lend you money for just a 2 to 3 X return and it brings the pressure of an exit down a lot. So you can do what Jeff is saying is just build an amazing product with an amazing sticky value proposition that is scalable because what happens, at least from what I see is people just build, build, build, build, build and now you have like 30 features and only two were required. So I don't know if you ever thought of this because I know you went to the product line, but I would even go further and say, just build two amazing features and serve them to a million people and just see what happens. Right. And you may find yourself exactly where uh uh uh what Jeff's recommending is. you'll just have a platform after that Or if you don't,
19:24
At least you've got an amazing product or service and have had success with that. but of course, my, you know, as a, as a platform guy, I'm always thinking ahead to, ok, but think about the architecture of that and sort of try to try to control the technical debt if you will because as you go down the, I'm going to iterate and build this amazing product or service and do it in, in this sort of rapid development cycle that, that kind of fights against the horizontally scalable architectures. And so kind of trying to keep those in balance is one of the challenges Jeff
20:08
Have you uh researched or just like, like I'm sure you have but ai gonna ask the question like I found that bootstrap companies remove technical debt much faster than venture back companies. And they're very intentional about it too. They will take some time and then, you know, because they don't have the same growth goals either. Right. They'll go and, and remove both technical debt and operational debt by the way also. Right. They'll look at the back office processes and stuff and say, look um these few things just don't make any sense or they're causing friction for our users. So let's just move, and remove them.
20:42
So I haven't studied that system but it certainly tracks. and I've talked to some leaders about their deliberate strategies um, for example, to build more of a horizontal system and then having to essentially tax their vertical P N L um leadership. And so this is sort of from the CEO S point of view, they're like, well, they don't love having to double pay running the kind of incumbent or the legacy infrastructure while they're retiring that tech debt. But everybody more or less understands it. And I told them they had to. So then you know, it became kind of part of the mandate. But of course, realizing that the CEO answers to a board and if it's a public company then too, you know, to some sort of larger investment community.
21:31
So what are some of the ways that you know, if you are starting on that journey you can avoid technical debt? because some of the things that, you know, I would add advice to companies is in B2B SaaS is one thing that's happened in the last few years is most people have come around to the REST API model, right? So in most um verticals and ecosystems, people are using that even if they're potentially also using others. But the number is just high.
The other thing is looking at the data models in your space. Asher and I did a study of 650 people last year in terms of um asking them about their partnerships and, to companies that were up to 2001 people, technology partners were the most important partners, and even for enterprises, it was the second most important partners.
I think um you know, part of the ways you can ensure that you're gonna be able to um open up if you want to and potentially even become a platform. But if not plug into other platforms by looking at your data models from day one and making sure they align with the models in the industry. Because otherwise when you go to integrate, you're putting a huge burden on your developers and you're also ensuring that third-party developers and partner developers are not going to want to integrate with you unless you give them even more money, right? You want to make it as easy as possible and remove the friction. But, any other advice like um beyond that, in terms of how companies can make sure they don't get three years down the road and have like an almost insurmountable amount of technical debt?
23:11
Um so first, I just want to emphasize how much I agree with what you just said. So you know, I love the way that you framed it. So, so where I see and, and we've done some work. I was fortunate to be on this World Economic Forum, Global Future Council on Advanced Manufacturing. And I can only say that once without garbling it. So Um,
23:35
I'm impressed you remembered it. It is a mouthful. yeah.
23:39
So, what we were looking at, uh we looked at some things, but one of the cool things was the way that um new technology got ingested into larger firms. Um, And the reason that I point this out is I think it'll partly answer your question. We saw multiple archetypes. And so at the beginning of these transformation stages, you saw a lot of point solutions, and point solutions are kind of end-to-end, they solve a specific problem. And so I'll give you an example. Um Let's see, Unilever um has some factories around the world.
And they have these drying towers, and the drying towers are for detergent products um at the end of the manufacturing process and it used to be that they kind of had a black art with the operators um which was from practice and skills and experience and what they were able to do was apply some artificial intelligence machine learning and optimize that process. And you'd say, you know, how much could this matter? Well, it mattered by tens of millions of dollars in terms of energy savings, in the overall system. And then they were able to roll that improvement out across, Say 10 factories. And so it had a massive impact, but it was still a point solution because that wasn't solving any kind of scalable architecture. They were taking one innovation and then moving it across. Um, but you should certainly do those. However, um that doesn't create the efficiencies of putting in a layer of infrastructure to your point Kelly about sort of uniform data models uniform A P AI S that people can integrate at low cost.
And so what, what you see firms do, especially the incumbents um is sort of pursue more of these point models like find me the best in a breed of insert X, you know, whether it's a chat feature, a natural language processing thing, literally a fax to P D, you know, too, to machine-readable text, which is an insane thing that still exists in a lot of company workflows.
And then go find the best of that, but every one of those best of them has to be integrated into the broader system. And so one of the questions you might ask is do you have to always go after the best of or is 80 or 90% that is scalable and plays nicely with all the rest of your stuff, the better way to think about it? Um and then. The next thing of course is to think about how you modernize, for example, your data models, lots of, lots of companies don't have that. So then they'll build a data lake and then they'll hydrate the data lake by ingesting a bunch of data sources from all across the organization. A massive, expensive, and time-consuming process. And then they sit at the end and go well. Hm. Did I prioritize that right? Or did I just go after grabbing everything I could and getting it in there? Um Because now people are starting to question the value proposition of having done all this in the first place. Um, which then gets you into. How do you stage some of these, these investments and transformations? Uh, I'm not sure that's an exact answer to your question, Kelly, but I think it, I think it kind of touches on some of the challenges especially the firms that have big legacy systems deal with.
27:30
So what's, what's your take on that is best of breed versus 80% that scalable is good enough?
27:37
I, so of course, I'll give you the economist's answer. it depends and it depends is, is that best to breed And that last five or 10% is so valuable because you can roll it across the system that it trumps if you will. Um, the kind of cost that you're still incurring because, you know, every one of these things bears an integration cost and then they all bear some sort of life cycle, you know, management cost over time. And so the more kind of one-offs you do, the more spaghetti you put into the system that, you know, eventually gets unwieldy.
28:20
Yeah. um, this may not be a question for you, but uh but do you have a viewpoint on managing integrations outside of the company versus managing integrations inside of the company?
28:33
Uh, I'll riff on integrations and then you can decide whether or not I had anything useful to say. so, I think the integration issue, especially with the kind of b-to-b SaaS or b-to-b platforms, is fascinating because it comes down to who pays. Um And why? So for example, if you're gonna onboard um a new partner, uh you know, everybody wants somebody else to cover the integration and that's not always possible. And then do you embed it in the recurring um kind of licensing fee? Do you just explicitly call it out and say, hey, you know, we have a third-party consulting company that we have an arrangement with, you know, talk to them and they'll be able to help us, or do you, and this often happens early on, do you mount your internal consulting effort? Because you're a relatively young company, nobody external will pay any attention to you.
And you haven't got enough routinized systems that, you know, it would make any sense. But then as you scale, you're gonna have to bring on some outside partners. The, so then, I think there's a huge amount around integration and then zeroing in on that to try to make that as, as sort of low a friction factor as possible.
30:05
Ok. To go back to the firms with all these legacy systems as someone who's working with a lot of different companies, do you see smaller companies who are designing their systems from day one? Um to be scalable?
And what sort of competitive advantage is this we've yet to see a company, as far as I know, fully sort of take that competitive advantage because it should be a competitive advantage, right? As you said, it's extremely costly to maintain and service these legacy systems and to build around them. Um, So one would think that you could have younger firms who, you know, cropped up in the last five years and were just so technologically savvy that they did best in terms of the architectural design of all their systems and that should propel them ahead. But um do you see how much of a competitive advantage is it not enough to overcome, sort of the advantage that the incumbent firms have and a lot of other ways of already existing out having the audience, the brand, the market?
31:17
A couple of answers. So one is, you know, one would hope that with the focus that comes from a young company, they're going to sort of be born if you will be horizontal and, and platform ready. Um, But you ask a great question, which is, you know, where does that show up? And how does it matter? And if they're primarily servicing in a B to B way in a way like other companies, you know, you're still having to integrate to those larger partners and deal with them. So that scalability that the startup has until they become a platform themselves and get large may not show up and the other. So that's kind of 0.1 and you're just getting me, I don't know, I, I don't wanna say spitballing, but you're getting me kind of reacting to, to the question part two is, and I think this is almost more relevant. It's amazing how fast rigidity sets in.
So, uh I've worked with some incumbent firms that you would have said, wow, that is about as digital cloud-native as I've ever seen and then you kind of scratch in and you go, oh my, they're locked into their original business model and if they want to enable different types of ecosystem partners and different business models, even they and insert name brand firm that everybody on planet Earth would recognize.
Even they have a big tech debt kind of refresh to be able to allow for this different business strategy as they try to pivot because the main core market started to stagnate on them um firms that are less than 20 years old. So I found it fascinating as an academic, but a little bit shocking.
33:16
Is it because of the way management bonuses are structured?
33:20
I don't think it has anything to do with that. I think it has to do with, they had a core business, they went after it, and they built scalability around that. But the business model itself was this more kind of um subscription based. And, and the reason I'm pointing this out is this is where a lot of companies get themselves into. Um whether they're B to C or B to B Um And then if you want to pivot to oh I want to be an open platform and maybe build some marketplaces or have some integrations and share in the revenue streams potentially of my integration partners or not. Um depending on, on sort of how you think about that value proposition. But all of those things require a whole new engineering road map and they require essentially a platform feature road map and a platform, product management function, and then an ecosystem management function, a bunch of stuff that even a firm just simply doesn't have, which I think super fascinating and, and lucky to get to kind of be on the inside of some of those conversations at the, at the management team level.
34:35
Yeah. and then they go look at the plumbing and they're like, wow, this is gonna be like four years and they're like, and some kids are like, well who had the tribal knowledge to do this? And, and that's why I made, I made a joke a little bit, but like, I've, I've been in a couple of conversations where like, wait, my bonus is actually like this type of thing. and do I really want to do this or should I just go over here and just go do this and I'll say I'll be ok? Well, that's, you know.
34:58
I love your point there because this is one of those channel conflict questions that you always get, which is once you open up, then you potentially start to conflict with the, in the sort of existing revenue stream. and in particular, if you start offering a lower cost self-serve, low friction, sort of go to market, then you're gonna be potentially bleeding out P and L, you know, some revenue from the existing groups. So that's a tension that has to be managed.
35:34
Um sorry, go ahead.
35:37
I was gonna say, do you have thoughts on the monetization models around technology partnerships? because that is something that um I think the market, in general, is evolving quickly.
and you know, I think some of the common ways that B to BS companies try to monetize it is by putting on higher tier plans, for example, and trying to prompt people to upgrade for either all integrations or key integrations. Um, Some people do have transactional marketplaces where integrations can be sold or the connected software can be sold. So you see Both.
I did a study a couple of years ago of the 100 largest SaaS companies, and 14% of them were transactional at marketplaces. And then it went down from there, I looked at series like D and C and seed companies, and, um, it got less and less. So um and there's a reason for that, right? Like it's a zero-sum game and nobody, if you want to buy all your e-commerce stuff through Shopify, then you're not also gonna go to Yap for the loyalty reward and try to buy everything there. So in these cases, not everyone can be, people can derive business value from them no matter which party they are, but they can't all be monetizing them. So um thoughts on where we are with that and sort of what considerations are and where the market's headed?
37:03
Um Yes. So uh the B to B one in particular I think is pretty interesting because if you've got a robust kind of monthly or annual recurring revenue stream, then one of the things, and honestly, I learned this from Scott Brinker.
37:25
I'll let him know.
37:28
He knows as it was in a public forum. He made a compelling argument that it was worth the investment in building out the partnership platform, which means a lot of technology, a lot of management function, a lot of capabilities um to make the integration sticky because once you had at an end customer, you've got, for example, this software layer um HubSpot in this case, and then you've got multiple integration partners. Once that's true, then customers are much less likely to churn. And so, you know, in terms of a lifetime value of a relationship or customer, it's a pretty straightforward metric if you change the churn rate, that has a huge impact on that LTV And so that's worth directly investing in.
So, my pushback would be as follows. So I get that um but that's almost a one-time bump on the revenue. And what you've seen some of the successful platform firms do is be able to layer in additional revenue streams.
That model is great, but it's an Upsell model to sort of Upsell you to the higher bandwidth throughput, and compute power and pick your industry in terms of what you're trying to Upsell on, on the monthly fee. Um, But you could get some nonlinear scaling. If you then start to build marketplaces on top of that, then start to add in new revenue streams and, you know, where do you land on that? Well, it certainly made a lot of sense to get some partners involved. Um And then help, help sort of grow the value proposition and make the core product stickier in the long run.
And I don't know. And you've seen some of what Brian had to say. This is a few years ago that, you know, they're, they're sort of holding the door open for potential percentage cuts depending upon the type of partner.
39:48
Yeah, it's interesting. I think it's a tradeoff right between getting more partners building to you and then taking the revenue, there's always gonna be, I'll say HubSpot is still currently not monetized. And I know from our partner's perspective because other ecosystems that we compete with are that um, it's a value-added that also calibrates their expectations, right? If you start paying somebody a significant amount of cut every year, then you're gonna want more back. And if you're not getting it, you're gonna be dissatisfied. So, um I don't think there's an easy answer and I, that's why I think that it is like a tough question and, and the models are gonna continue to kind of evolve and grow and how they're sort of taking out value.
40:35
Well and I mean I like the kind of gradual approach on that because what I've seen with some other organizations is they kind of get starry eyes on revenue streams and they try to monetize before they've generated enough value that they would have a claim on that. And one of the places you see that is around data, so firms will say, well, my data is worth, you know, a huge amount. And so if you want to be able to use it, aggregate it, potentially create products that you could sell from it, of course, you have to pay me and that's fine if it's true that a lot of value is getting created, but especially early on it isn't and you can put a lot of friction on those systems that prevent them from ever getting out of the starting blocks.
41:30
Yeah, go ahead.
41:32
I was just gonna pivot a little bit to the value the evolution of value realization that like, like Geoff just talked about because I'm like, I think I'm the stuff that we're talking about is cool, but I wanna hear what uh what Geoff has learned and uh and can share with us.
41:48
Well, so if you look at archetypes um and try to categorize them, they do kind of break out into, let me just pull a slide here. Um Because I've done a little bit of thinking around this um into things that you would say, OK, that's a, a software as a service type of thing. And it's going to have a standalone value proposition. Um And so that's kind of that build a great product or service from the get-go and build a set of users. Um And then over time, what you would expect to see is the firm intentionally finding a new source. Now, whether that's new features or whether that's going to come out of user-to-user interactions, that's a decision to make, you know, you're still a traditional firm if you simply build out new features. So think for example um Excel, so Excel is like the Swiss army knife, it's got a gazillion features in it.
I can derive a lot of value just sitting in my office and doing analysis or taxes. Um, On the other hand, it's still embedded remarkably after decades in the workflow of lots of companies, they email sheets around um they get populated, and they end up becoming kind of reporting. Um, So that creates a, a peer to peer network effect, you know, I am old enough to remember using Lotus 123, which is not a particularly popular spreadsheet program anymore. But we used it at uh at G E Actually, we replaced a proprietary in-house system with that over time. Um And it mattered hugely that you were on the same standard, you wouldn't want to have two people trying to collaborate. So that creates AAA kind of a network effect between the same types of users, not a lot of cross-side network effects. There aren't a lot of plugins. There are some of course optimization solvers, some data, and analytics stuff. But for the most part, you're looking at a value proposition that is a lot of standalone value and then a lot of same-side collaboration value. So then the question you ask is OK, in these sorts of SaaS B to B models, you've innovated to create the core product or service. All right. Now, what are you gonna jam a bunch more features at people? And that's your kind of engineering road map and that's fine. That's one way of increasing potentially the value proposition and maybe capturing some of that with price or at least capturing it with retention. So there's sort of a couple of ways of thinking about it: are you gonna create collaboration tools?
So that you create value propositions from users interacting with other users more effectively? Or are you gonna open it up to outside ecosystem partners and create value by extending functionality or some sort of cross-side or creating marketplaces? They're all reasonable alternatives and you just have to be thoughtful and intentional and lay it out and, you know, run the experiments where it makes sense to experiment, be intentional if you have enough conviction and knowledge about what's going to work. Yeah, I would,
45:23
Unfortunately, we're gonna run out of time today. but the social side of this thing and the role communities play in supporting these platforms, I'd love to share some data with you. Maybe we do a follow on this podcast because like, like because I'm in it and we're building it, we've been building this thing for four years, just the sheer amount of like value that gets unlocked in bringing prospects, customers, partners all together just in the guy. I focused on this connection and meaningful connections and those connections existing over time, right? And, then the content gets created, ideas get created and thus, you can actually uh start down this path of intentionality through a community while the rest of your business is, you know, kind of finding accidental value if you want to call it, right? And both can be in play. And there is a flaming source if you want to call it, right? That gets created, and you can get there
46:26
I think it's one of the critical columns if you will, I think of sort of stand-alone value, there's same side network effect value, which is this community and then there's cross-side network effect value which is these marketplaces or app stores or service integrations, you know, whatever label you want to put on it and the system over time accounts for, you know, comprises all of those in terms of the value proposition.
46:56
And, sometimes you just have to, again, we go back, we started this conversation with the whole v c thing, and given that I'm building a revenue back company, right? like, like you sometimes just let it happen, right? And just naturally it'll come to you, and all ideas have been thought of before, but they just slowly manifest through how customers utilize your products and services and they'll tell you right? and which I think is still the best way of building a company is just listening to your customers and staying close to the wholesale value, which not a lot of management teams spent a lot of time on at least in the early days because they're just trying to get to market.
47:29
They have a lot going on so sympathy I think, is there. Kelly, you look slightly, I'm detecting a skepticism.
47:39
Not at all. I'm just noticing we don't have much time left. and there's a question I want to ask that is tangentially related to this one which um I think it has more to do with the community trust angle which ties in which is this issue that people platforms struggle with which is the competitive cooperation line, right? and it's, it's not just a because if you look on amazon, for example, they've been criticized recently for pumping their brands um and for bombarding people with ads, but that's a separate issue um or maybe related but their brand is often heavily prioritizing the results and from the consumer side, despite some journalists writing articles about it, I'm not sure how much it's impacting that experience, but SAS companies have the same thing, right? Platforms end up building out features into their platforms that compete with integration partners.
Thoughts both from the side of the partner who has to often build their entire business heavily reliant on the ecosystem that could be made obsolete, whether it's because Amazon starts selling their batteries for $2 or because I'm salesforce, for example, builds out CPQ solution that it didn't have before. Um, best practice on both sides of how to think about that?
48:58
So an awesome point and this has been happening pretty much since the history of platforms. So if you go back, for example, to Windows as an operating system, it used to be that if you wanted a dictionary or a spell checker, um you bought that as, as a service or if you wanted to create a PDF, you had to have Adobe. Over time, those features and functionalities tend to get absorbed into the core stack of the platform. And so you know, why does that happen? Well, especially in the B to-B world, if you think about where a lot of those add-on-um developments come from, they come because they're helping a specific industry sector or specific partner. And so for example, it might be automotive manufacturing or banking or it could be, you know, mineral extraction and they'll have some unique needs in that industry and then you'll have people that will innovate and develop on top of the core platform. However, what ends up happening is you may end up discovering something that every vertical want.
And so then the question is, does it make sense anymore for that to be an ecosystem-provided capability that requires its external integrations and its external revenue stream? Or does it make sense for overtime to absorb those things that cut across multiple customer types over time? And of course, it's the second. And so then you end up because the end users are gonna want you to solve that integration problem. They're not gonna want to have it. If every end user wants the same thing, then it should be in the core.
And so because what you're using the ecosystem for is both discovery and also to serve an idiosyncratic set of demands, that's kind of the magic if you will of a long tail of needs and wants um that doesn't solve the problem of how do you, how do you keep the incentives aligned? And so you have to have a reputation as the platform for not wiping your e-ecosystem out. And just tomorrow saying, well, guess what? We copied it, we bought a clone, you know, we did this and now your revenue stream is torched. Um, that does not engender a lot of love for the ecosystem. And so that's part of that kind of governance and ecosystem strategy is being a good partner and part of being a partner is to say, well, you know, here's our road map and in about 15 to 20 months, you know, this is going to happen and we'd love to buy your technology or give you some sort of an exit on it. But, you know, in the long run for the good of the overall system, this is going to get absorbed um, and not kind of tomorrow surprise you. Um, and because, and are they gonna love it? No, but on the other hand Oh, um let's see, he was at Cisco at the time we did an interview. So this is quite some number of years ago, about 15, we're talking about exactly this issue. And he said, Well, often what will happen is the same solution will start to get provided by multiple end vendors. And so whatever high profits they were making are starting to get competed away anyway.
Whether that's a story you tell them to make them feel better at least um or there's truth to it, you know, that's an empirical question. But the broader point is not surprising, the ecosystem partners being, you know, having a road map being upfront that that can happen and why and sort of under what conditions would it make sense that we as the, the main platform would do such a thing?
53:09
Yeah, I think transparency goes a long way, and also the bigger picture of establishing that trust, which you can do through how you handle it. but also in other components of the partner experience that if you've built that reservoir up, it's gonna be less jarring.
53:23
It's interesting because over the last 67 months, if you just, let's say, go by what's been shared on social media, there's a lot of like, love the ecosystem, love the ecosystem, like talk. and just this week, I just started seeing threads around. well, my partners are competing with me, you know, and so what you just said, it could be more true and we're gonna see a little bit more of it.
Um OK, I feel like we could talk for hours, maybe we should do that one day and just do a marathon podcast, right? But Jeff like, thank you so much uh for spending some time with us. Are there two or three, let's call them platform designers that come to mind that you recommend we bring on the show?
54:08
Well, I would certainly hope you talk with one of my main, uh, really with all my coauthors, you know, Marshall Van Alstynen if you haven't already and, and Sangeet Choudary, um, I think in the marketplace area, um Peter Evans who's been working with McFadyen would be an interesting person to speak with. And so, yeah, I think that those are at least some of the main coauthor's ones. Super.
54:43
All right. I think that's great for today. Thanks so much for listening to another episode of Unlearned and uh we'll be Back.
55:12
Super awesome. Thank you so much.
Thank you for listening to Unlearn, subscribe wherever you listen and visit unlearnedpodcasts.com for the transcripts.
.png)
.png)