 So today, he will talk about outsourcing IT and technology differentiation. All yours, Michael. 40 minutes. Great. Thank you so much. It's nice to be here. Nice to talk with everyone. I'm starting off the presentation with first the slide that introduces the topic I'm talking about and the second slide, which is trying to workshop a new title, because this is something that I've had a lot of trouble with the last several months. Thinking instead of outsourcing IT, it's going to be both sides of cloud, standardized tools, and diverse data analytics. And this really fits the topic. I'm going to talk about a bit more today than the prior title. Granted, it's really just a reframing and taking some feedback from the job market on how to reframe this more in the platform's literature and certainly open any feedback on things like that. So let me know if you're a whiz at titles. I'm in definite need. So this was my job market paper. And specifically, I came into the PhD interested in how things like using the same cloud platform or using the same platform could impact innovation, potentially making things more similar. So looking at products, do they become more similar? Is it harder to differentiate? Cloud is a great place to really examine this and think about this because cloud has become so prolific in the last decade. And then for startups, it's even more important. And so just starting this off with a gardener quote saying that firms not using cloud will be as rare as firms not using the internet. You know, this is something that this was three years ago. We already see this happening and unfolding and we really can't imagine life without the internet. I think that, you know, a few years from now, it's going to be very hard to imagine life without cloud. And so what does this mean? What is using a cloud platform really mean for a firm? It's a big business. We know that. So the big tech companies are making lots of money with software as a service, but also with app development and testing platforms and hardware and infrastructure that's available through the cloud. And so what this looks like for a customer or for a small business or any size business is moving from this picture in the middle, this in-house server room, where you have all sorts of IT set up to work together to create some sort of environment that you can develop a product to the picture on the right, which are these farms, you know, filled with different types of servers, different types of equipment. You have one on the right is in Wyoming, I believe. And so the middle of nowhere when powered, able to actually run all of the computing power, you would have in that server room, but you connect to it remotely and access it. I really like the picture below because you actually have an underwater server room. So this is something when you think about all the different regulations, you put it offshore and, you know, you can still access it. The water cools it many different ways to access cloud. But certainly what I'm most interested in is this app development and testing platform. And so this is also called platform as a service. So it's not the softwares of services you'd see with like, you know, Office Online, Adobe Online, and it's not necessarily the hardware infrastructure as a service. So just renting one of these, you know, large servers in the server farm and, you know, customizing it as you want. It's this middle offering. And so platform as a service is this ability to actually build up an app, create the environment where you can run that app, test that app, and then deploy that to customers. And so we've seen an increasing trend of startups outsourcing to the cloud. And I think this picture on the left really captures that. So this is from a recent paper by Daron Asamoglu. And so on the left, you can see the percent outsourcing. And on the bottom, you can see the size, the small to large, but then the shading is actually the age. And so you can see that the smallest and the youngest combined are more likely to be using cloud than other types of firms. And so this really gets you a sense of like, these are usually the startups we're most interested in. The higher growth, so they're small, they're young, they're, you know, resource strapped. They're trying to make their way into developing a product. You know, how do they actually access these initial resources that they would need to develop their product? So we know that IT is core to this, developing a digital product. It's core to actually building an app and making the app work effectively. So we know that startups benefit from the cloud. And you can see, you know, partly this by how quickly they're jumping to the cloud. But then just thinking through all the different things they could benefit from, the lower upfront cost of cloud, the speed to market, cheaper experiments, the ability to actually, you know, expand as they need, right? They don't have to go ahead and add another server room, you know, set up lots of different purchases that take months and months to complete. They can really go online and flip a switch and access the same type of resource they already have at a larger scale. The next thing that's really important is how hard it is to replicate these services now. So thinking back before about 2016, you should have a lot of startups that I talked with saying that they were able to replicate the environment on their own and, you know, they were afraid of Google stealing their data or Microsoft stealing their data and they wanted to do things internally. However, you see after that point, it becomes really difficult to replicate the security offerings. And so this is something that cloud services have really taken strides with. This entire environment has held together secure and, you know, a great way to quickly jump in and start to test out your ideas, test out your products, and startups have really taken advantage of this. And so this really drives the motivation of the paper, which is more startups are developing products with cloud IT. There's research that points to this. And so when you think about startups existing and entering, it's likely substantially more because this lowers the cost of entering into the industry. But are products less differentiated? Are, you know, the services, the apps that are being provided you know, somehow more similar because you end up using the same resources from these cloud providers? Or is it the fact that, you know, it's an enabling function. It's saving time. It's saving your bandwidth of your program or so you're actually able to focus on what's really important and differentiate even further. And so this is the flip side of the coin leading to my research question of how does adopting a cloud platform impact differentiation and growth? And so specifically thinking about these startups, high growth startups. So I want to preview my findings just so everyone can get on the same page. And so I'm using some really interesting data from built with but my approach is collecting this panel of data on all of the startups that actually have apps. They're listed in Crunchbase. So I have performance data or they're listed in pitch books. So I use both. And then I use built with to look at the web technologies. Excuse me. The web technologies, those firms adopt over time. So the panel from 2012 to 2021. And so I'm actually able to then begin to map the addition of cloud services, which cloud service they're adding and how this influences the web technologies they use. So use a different analysis here. I look at the change in the bundle of technologies. And so I'm using a cosine similarity measure and I'll talk a lot more about this. And so thinking about how a bundle of technologies they'd use in two different types. So development and analytics change when they add cloud. And so when they're actually partnering with this large technology firm and you have a clear instance of using cloud and so you can actually determine that from the web technologies they're using, which type of cloud they also use. I think a lot about identification. This is my job market paper. So this was a point of you must get this right. So said my advisor. And so these are my attempts at, you know, building out a causal argument and certainly open for more feedback on this. I think about an instrument. I think about double ML. You're looking for evidence to support that relationship. Next, my findings. And so these startups that adopt cloud are using more standardized tools. And so thinking about the development technologies or the tools they use to build the products, build the apps, but they're actually also developing more diverse data analytics capabilities. And so they have a tool set of data tools of data analytics technologies, processes that enable them to actually collect potentially more unique sets of data. This is really important for high tech startups. It's not really just the ability to make decisions. It's also the ability to train their algorithms. About 40% of these are AI startups. So this could be very important and could impact their trajectory as firms. And certainly we find, or I find more standardized tools and more diverse data analytics capabilities are linked to growth. And so this is kind of the pullback to the mainstream strategy literature. There is this connection with performance. And I'll talk through all of this as we kick going. So I want to pull from a few different points when I talk about the theory that I used to really frame this paper. And so broadly within the literature, there's lots of work on in-house and outsource. I'm kind of shifting away from that a bit. You can still see it underlined. This is an outsourcing decision. But I really want to think more about the technologies, the fit, the operating systems, and some of the literature that fits this technology development. And so one of the things that we can easily call out from the outsourcing literature from TCE is suppliers explored inefficiencies and seek to align customers with their interests. And so this really underlines the conversation here. When you're outsourcing, when you're using a cloud platform, you're on someone else's platform. You're working with Google. You're working with Amazon. There's control that they have over that platform. And so you as a startup actually need to fit with that platform in certain ways. And so the technologies you're using need to fit with the platform. However, they also need to fit with one another. And so thinking about the interdependencies between the technologies you would use. My example of this is always thinking about using R. And I'm sure most of you have used R. But when you download a package, it says, oh, you need this package and this package and this package. And then you download those three packages. And one of them has three other packages. So you end up building out where you just download a nine different packages to use one package. And so they're all interdependent. They work together. They're connected. And the same way some of these development tools are set up where to use one technology, one aspect of the tool, you actually need to have other types of technologies that support that. And so it's important to see how this could be a constraining factor where you actually need to develop certain sets of tools. And this could be different by cloud platform, right? So there may be certain tools that you use on AWS that are very similar to those used on Amazon that require different technologies to support them. They could actually have a similar purpose, but could be very different as tools. And so thinking about how this could play into the different types of technologies you choose and you adopt. And then certainly all of these investments are sunk. And so you're making investments into one platform. You can't really change it very easily. It's not like you have startups that are moving from platform to platform. They're really syncing their development into a single platform, creating an app. The pieces of it may be containerized, but it's very hard to move. It's very hard to shift from one platform to another. They're cost associated. It's even cost associated with paying to move data, right? So it's hard to do technically. It actually could be expensive. And then you're left with another platform where the coding is slightly different. So it requires different labor. All these aspects point to, you know, you're a bit sunk into one. And so all of these decisions you make, these fit decisions can play out into perpetuity. If you look at the picture here on the right, just to quickly show some of the differences in control, this would be a setup that we would normally see in a platform as a service environment. And so you see things like operating systems, virtualization, security, storage, networking. Some of these aspects you would have complete control over if you developed in-house. And so this is showing on the left, you really run the show here, right? You can pick and choose all these different aspects to make sure they fit with your technologies, to optimize to help the technologies fit with one another. On the right, however, when you're outsourcing, you have constraints. And so you may have a drop-down box here or there where it says, oh, for OS where I want, you know, Windows 95 or Windows 98, you know, this is obviously not a great example, but it could be a difference in operating system. You could be using Linux. You could be using Ubuntu. There are all sorts of different choices that you would have. However, it wouldn't be fully customizable and you'd have certain choices for some. It may be that you have three security protocols. They're all very new and you previously developed something five years ago into a different security protocol, right? And so you are making decisions, you know, based on these drop-down boxes in the rights and areas of outsourcing and using the cloud platform, which play into this. So it's not perfect customization. So next, thinking about the shared resources, and I'm sure some of you have, you know, experienced in the past working with big tech companies or even from the university side of how, you know, 10 years ago, you would actually develop, you know, or build out a server capability, build out the ability to use some type of sort of in-house process to, you know, let's say you can even run your data, you know, your data tools or anything like that. So it's not really just building an app. We can see how this in-house decision can play across different technological choices. You're using lots of suppliers. So if you look at the figure on the left, the in-house has OK, Dell, HP, Lenovo. You're like your big OEMs, right? So this is going to be who sells you the server. When you look, you have Ingram, CDW, Cisco, TechData. So these are going to be your distributors. And so thinking about the different advice you're getting from them on how all of this connects together, right? You're going to have some sort of sales person from, probably from Dell, from Microsoft, someone from Ingram, they're going to talk. They're going to be like, you need this. You're going to end up, you know, working with some consulting firm usually that offers IT consulting skills. So I add them at the bottom. But you're going to have a lot of people at the table, right? So lots of different opinions, and it depends on who your sales person is, who you're working with at these firms. There may be a best practice or a best path, but you're getting lots of feedback into what you need, how you need to connect it up, how it needs to work together. However, on the other hand, you see that you're using one cloud platform. It's really from one of three companies, right? So this is going to be, I would say, close to 90% of the firms that use a cloud service use cloud service from Amazon, Google, or Microsoft. And the majority, vast majority, use Amazon. And so it's really three strong voices. And so you also have three programs, and so a program from each of them that's set up to work with startups and share out resources directly to those startups. And so suppliers share resources with startups all the time. But in this case, they're very concentrated. They're sharing the same resources with everyone. They're sharing platform-specific resources. And they're also sharing resources, which is kind of the flip side of innovation. It would be very hard to develop on your own, right? So they have all these programmers that are actually building up how these things work together, creating compatibility guidance, creating lots of different materials that could be shifted and shared to different types of startups, depending on if they're in finance, if they're in, you know, healthcare. So there could be very specific nuances associated. There'll be a portal you log in, you can access resources from the portal. It could be that you go, you know, every few months to an accelerator event, you join into a program. All of these exist under the banner of these large technology firms, right? And so it's two-sided here, because you have these resources that are shared with everyone, and so it could impact innovation negatively. But on the other side, you could end up in a situation where you could create the resource on your own, right? So it's difficult to develop. It's something that could take you, you know, hiring programmers that you can't afford to build something out. Again, we see this lasting effect, and so it could impact future partnerships. These early shared resources could impact the trajectory of your technologies. You could be making investments in certain technologies based on these shared resources, also on the other side, based on the compatibility or fit issues that then last for you to come, right? So this isn't a very easy situation to make changes once the product is built and once you really decided on what you're doing. So I want to pull these two together and talk about two different types of technology startups commonly used. This kind of break is pretty common within the, like, IS departments. And so thinking about product development technologies, thinking about data analytics technologies. So first product development, these are really our tools. This is going to be, if you look here, this friendly program on the right has this coffee, he's coding, he's using tools to actually build out how the app works, right? So he's using common protocols, open SSL, jQuery, Django, Angular. So these are common frameworks that developers would use to actually make the app work. And so when you think about opening your phone, you go, you click on Uber, it's a little square, right? So this is one type of app you have other apps. Let's say you, you book a flight, you use something called concur. That's what NYU uses. It is terrible. Microsoft used it previously. It was also terrible. So this would be an application. That's a desktop app. And so this is really what I'm talking about. You have these tools to build out the app. So let's go back to the Uber example. What you're going to want is a tool that enables the programmer to connect up a map, payment, all of these different pieces that are different technologies. And ultimately you want it to work, right? You want to click the square and the touch interface work. It's going to open up. You're going to want to put a location in. So it's going to connect in with maps and tell you where you're going. You want your GPS to work. So it knows I am here at NYU Stern. And then ultimately you want that to run through, you know, your credit card, right? So all of these technologies fit together. The tools enable this. So these are frameworks that enable all of these technologies to really coalesce to come together to build out the application and to make it work effectively. And so there are many, many fit issues here, right? So just the kind of like boggles my mind thinking about how Uber is made, but all of these different apps and all the different types of things they do, how they connect together, very important. And so what you're beginning to see is the use of standardized tools based on the platform that you are actually developing on could be used to actually save time, save resources. You're not going to go and develop a tool develop a new framework. You're just going to use what's available and try to adapt that to your specific product to the app that you need to the industry that you're in. On the right hand side, these data analytics technologies on the other hand are really just turning messy data and the usable data. And so I call these data capabilities. And so it's very different from the first group of technologies that we hub spot. The second one is Google Analytics, right? So everyone's sort of Google Analytics. It's like a one stop shop from all different types of analysis, right? So this is something that enables you to sort data to connect data from your website. So there's so many different uses, right? It could be the fact that you have customers and you're going through customer databases and mining certain data that's important. You could actually have a technology that tracks web traffic on your website. You could have something competitive, right? So it's connected to your web domain, but it's focused on different competitors in your industry. A lot of times you can see where they're tracking different types of web technologies that other firms are using. So many different ways. The other thing that's important to note for this is that these are very modular. No matter which cloud service I'm using, you can kind of pick and choose which ones you want, right? So it's like, oh, I want to develop a data, a set of data resources that enables me to be competitive. And these are the constraints. These are the boundaries I want. You can pick and choose. You can trade them out very easily, right? So you're like, oh, well, HubSpot didn't work well. There's something very similar. I can use this. Let's try. It's point and click. It's not necessarily that you're locked in. Certainly there are fewer fit issues with that modularity. And also it leads to the ability to really customize the data sets that you're using. It requires programmers lots of time. They're sitting there trying to determine what's best. You know, how do we optimize on the data resources we need? What are the key pieces of technology here that are important? Certainly you're going to begin to see a connection between these two. And this is what I found most important and most interesting as the paper developed and certainly through the job market process is really the connection between programming tools. And if you save time with programming tools, how that could be reinvested into these data analytics technologies, which I think are really important for actually developing differentiated products and certainly preventing all the products from ultimately being more similar. Let's see. So I want to pull the two pieces together and really talk about the implications from this theory. So in the left-hand side. Can I just ask a question? So in the previous slide, you talked about the data analytics technologies and that they are modular. If a startup is choosing a particular cloud platform, a particular cloud provider, does it restrict the ability to use different technologies? So from talking with startups, I keep hearing that it's not a big issue, that it's not something that they're really feeling constrained by. It's not that they're locking in. They kind of pick and choose. So I do think it's a different setup. The other is that just relative to the product development, even if there is some of that, product development is substantially more. So it's you're much more constrained. There are many more fit issues. So it may just be this relative comparison that's probably most interesting in this context, but I think in an absolute sense, it is quite little. Okay. Thank you. Because I'm still trying to figure out why would choosing a particular cloud platform provider really restrict innovation? Like at which point would that happen? So it could happen at the product development technologies choice, but not at the data analytics choice. Yes. I think the next slide will help us with this and trying to pull it together, just all the implications from the theory. And so in the middle here, this is my claim to fame of middle of the night job market is my cloud-raining data. So I was very happy with this. So I have to call it out every time I present, but I have the cloud-raining data in the middle. And to the left of that, so cloud constraints, product development, technology adoption in these situations. And so when fit with platform is important, when technologies are more independent, so you need to fit together. And so you actually have where the impact of fit with one technology impacts the other technologies that are connected. And then situations where all the same resources are being shared with everyone, right? And so this is that the first discussion of the shared resources, when you're basically a startup and all the startups receive the same thing, all of the healthcare startups receive the same thing. And so this is the model that we discussed with the cloud platforms having these startup program. And in this situation, it's more difficult to search for and recombine technologies. And so you may just end up adopting what's available, what's more standard. And certainly this is something that you see by cloud provider, they're different kind of more available options, right? So since the fit with platform is important, you may actually adopt something that's being pushed by that platform. So there's compatibility guidance. And so you're left with something that may do a similar function, but is a different tool, a different set of tools or bundle of tools because some cloud provider is pushing that towards you. It's part of the resources you've received and it works really well in terms of fit. On the right-hand side, cloud enables data analytics technology adoption because they're quite different. And if they're more modular, fit with the platform is unimportant. Sort of on the left-hand side, if it doesn't fit well, the app doesn't work, right? Uber doesn't open, the map drops you off in the middle of the Hudson. There are lots of different ways that this could all fail. On the right-hand side, if the data is not great, you pick and choose for better data, it could be that your algorithm and your prediction models are less accurate. It's not that the app itself doesn't work. It could be that you're handicapped in certain ways. And so the other piece of this is when you're using hard-to-develop resources and so this is something that cloud is actually beneficial in the sense that hard-to-develop resources are probably on both sides of data analytics and also on product development. But this could be really important, right? Because you can't actually develop on your own. It could be something that's a key stepping stone. I mean, we think a little bit in this paper about TensorFlow, but a key stepping stone in developing the product that you need. In this case, more possibility for technological innovation and you adopt more diverse technologies. And so this could be the other situation. And so I'm going to jump into the data, just giving you a quick overview of what we're working with or what I'm working with, and then jumping to the findings next mechanisms and we'll see if we can get through all the mechanisms and conclude. So I've got about 12 minutes left. So hold on to your hats. If you look here, these startups are often quite small, right? So I'm looking for startups in Crunchbase, in Pitchbook that have raised funding. I have about 10 years worth of data. I exclude China. I make sure they have an active web domain and then I use data from Apptopia to ensure they have a product. So these are all product developing startups, right? So they have something either a web app or a mobile app. So about four years old, about 45 employees. However, this is the mean, the median is actually much, much less. I think it's like 11 or 12, right? So these are on average quite small. 10% are in health care, 10% are in finance. 38% call themselves AI startups, meaning they describe themselves as using AI. I think that the better number is the 9%, right? The firms that say they're using machine learning, I think those are actually the AI startups here. But thinking through how they describe themselves, the sample is very much developed markets. It is centered more so on Americas and Europe, right? So even in Asia, it's going to be Korea, Singapore, Hong Kong, these types of very developed cities. I also look at founder characteristics. I don't get into this much and I'll go through, but I pair this with founder data to do a pro-vit and tell you a little bit about selection. So looking at my findings now, and so I took out the slide just because I know we don't have too much time talking about cosine similarity and looking at the angular distance. And so these bundles of technologies I look at, just basically look at a set of technologies that I know are used for product development. I have about 200 and about 200 that are used for data analytics. I actually look over time at the changes and the angular distance between a startup that's using a bundle of technologies and another startup in a sample. I run this a lot of different ways. This is just the view of all the 3,400 startups. And so looking if you're using cloud as the event, but looking at the change in your distance from the average startup in this entire group, I can actually look by industry. I can look by cloud platform. The results remain very similar across this. So I'm just kind of zooming out to the broad picture view. And so if you look on the left, these are our development technologies, our tools. And so development technologies, and after the cloud event, adding cloud, you have less breadth. So they're becoming more standardized. This is set up in distance and so this is going to be dissimilarity if you want to think about it that way. So the bundles actually become less dissimilar. So they're becoming more similar. And so I'll have to possibly rethink how I put this in a paper because I've got a lot of dissimilars and similars. And so the data is actually built on distance. I can flip it around and make it similar. But I think you guys get the idea here. So tools are becoming more similar. And so their distance is becoming less. On the right hand side, you have the analytics technologies. You're seeing more breadth in those bundles. And so they're becoming more dissimilar. And so they're becoming tools are becoming more diverse. You're beginning to see data capabilities or bundles of technologies after using cloud really expand. And so you see them using more different sets and more unique sets. This is all the angular distance measure I built out is set up to actually normalize based on the number of technologies. So think about this, not impacted by the size of the technology, the size of the bundle. It's really just looking at the coordinates. And so the point kind of in space and the distance between the startups across these, I guess, 200 different zero, one, zero, one, zero, one technologies. I use a different diff specification. And so a lot of the robustness they do in the paper thinks about all the different great advancements made and different diff models over the past two years. It was really a great time to be writing a job market paper because I had to like keep looking to see if my different diff was still in style. But lots of different robustness around that as well. So first thing about these development technologies, these more standardized tools. And so this is the same picture from the left on the previous slide. The main finding here is they become more similar. So the technologies need to fit with the platform and the app to work effectively. The technologies need to fit well together. Certainly there's lots of shared supplier compatibility guidance startups co-advent using shared resources. And so this co-invention process could actually lead to you actually having more similar bundles of technologies that you're using because you're trying to adapt those, trying to change those. But in the end, you have the same base resources. On the other hand, the analytics technologies, you see more breadth. And so this breadth means you're using less similar data analytics technologies. The fit with the platform is less important for the apps to work effectively. The technologies are more modular. They're point and click, right? You, oh, this didn't work. I grab another one. It's not like you have to actually build out an entire framework. It's very much, it's a piece that sits on top of that framework, on top of the tools that you're using. Certainly there's less reliance on compatibility guidance. They work across everything. They're made for any startup that's using any cloud provider. Certainly much easier there. And so looking at the connection here with funding, and so I look at VC funding. On the left-hand side, you can see if you're using more standardized tools, you have increased VC funding. It slipped because we're looking at the similarity. And so just think about that the opposite direction. On the other hand, you see that more diverse analytics capabilities also lead to increased funding. So this pulls up a few of what, you know, the best performing startup would be one that's utilizing their tools. And then, you know, using that time, using the resources they save by kind of adopting the best bundle of their given vintage. And then investing that in data analytics capabilities. And so I begin to talk now about this connection between the two. And I'll get to that in the next few slides. But I think it's important to begin to think these are all the same startups, right? So this is one part of their tech stack and another part of their tech stack. And so they're combined. And so I think that would be standardized tools and more diverse data analytics. But before I get to that, I just want to quickly talk about some of the issues with this, right? So cloud adoption is, well, I'm going to talk about cloud adoption in Europe quickly, but selection issues galore, right? Cloud adoption is not exogenous. And so we need to, I need to think long and hard about this to make sure that I'm building up the correct argument. What I like to call out, especially because I'm going to France because this is a French-based crowd. Cloud adoption in Europe is really interesting. And so I do a probe at thinking about this outsourcing event. And so using cloud, and you can see that Europe is less quick to adopt cloud. It takes longer. And so this is one of the key points of interest, I think for future work, but this also points to the selection issue, right? And so if I'm looking at startups that have founders that have OEM experience or they developed the hardware previously, they're less likely to add cloud. They add cloud later. However, if you're a founder from a big tech company, you're more likely to add cloud. You added earlier. If you have funding from a big tech company, if you have this close relationship or bond, you're more likely to add cloud or more likely to add cloud of that particular company. It's also good to see that if you have an MBA, you're jumping straight ahead and adding cloud. I can imagine there's lots of different university accelerator programs pointing to, this is the path forward. Also if you're very technical. So if you have a technical degree you're more likely to jump directly into cloud. So there are two different mechanisms I'm going to talk about before I get into this connection between the two. The first one is looking at, if you use more technologies, I talked about this fit and interdependencies between the technologies. So let's say you're using a larger stack in these situations, you'd actually use more similar tools. And so this would actually really support what we're talking about, this interdependency between the technologies. When it becomes more complex, you use something more simple. What you just say, oh, I'll use the standardized one. I know it fits well. I have all this guidance from the technology firm on what this fits well with. And we're dealing with a big stack of technologies. It's hard to navigate this on our own. Next it's looking when you use two cloud services. So I look at infrastructure as a service as well. So this points to a tighter relationship with a single cloud provider. And this situation, you actually use more standardized tools as well. And so it could be two different pieces here. One is that you're getting more resources because you have this tighter relationship. The other is you have more fit issues, right? Because you have to fit with the platform in two different ways. You're using their infrastructure services and their platform services. And you see this impacts in a similar way where you have more similar tools. You're taking the easier path. Next I, and I'm going to do this in like one minute, but I'm glad to talk about this more. I use TensorFlow as an instrument. And so I think about the effect of TensorFlow, specifically on AI startups in the sample. And I use that as an instrument to then determine the development of similarity. So the tools piece and the data analytics. I come up with similar results for data analytics. It's really spot on for development dissimilarity. It's directional in the same way. It's a little bit larger. So beginning to think about what's omitted there. And certainly it still passes the sniff test. It's a powerful instrument. However, it's just part of the story. I use a double ML model as well. I'm not going to have time to get into that today, but I think that's another way of looking at omitted variables that we have information on. This would get to the unobservables, but really just pieces. You know, this is, it's hard to make a strong causal argument here. I'm trying to pull this together kind of piece by piece to convince the audience. So hopefully I do a decent job of that. And then before I close out, just talking real quickly about this connection between the development dissimilarity. So these standardized tools and also the analytics capabilities in situations where you have more labor and so more programmers, you actually see a significant tradeoff here. And so a tradeoff between the two different sets of technologies. I think this is important as a mechanism so that we understand the connection between the two, because what you have is a time savings associated with the development dissimilarity and using more standardized tools, which then could be traded off into this analytics dissimilarity and actually building out these capabilities, right? And so I was, you know, most excited when I found this out, I used LinkedIn data and look at the different job titles in each of the firms. And so I profile these firms based on the percent of the firm and the program versus other types of employees listed. And then lastly, just to conclude, so in my final minute, and so the research question, how does adopting a cloud platform impact startups differentiation and growth? And so adopting a cloud platform creates issues for tools that need to fit with the platform while to work, tools that are more interdependent, you end up adopting more standardized tools and aligned with prior literature, standardized tools can enable commercial success, they can save time. And in this situation, these high tech startups, the story goes that these startups differentiate by building analytics capabilities using these more modular technologies, which fits less of an issue, to provide more robust data. And this better data is really what drives the growth, right? So you can begin to see these connections between the types of technologies they're choosing and the growth and certainly the funding they're receiving. So all done. Perfect timing, Michael, thank you so much. Our discussion is Professor Shane Greenstein from Harvard. Okay, good morning. Good morning for me, not for anyone else. Can you hear me? Morning for me too. You can hear me fine then, that's great. You know, think about five minutes. Let me first start with just, you know, how much enjoyable it was to read the paper, a wonderful set of themes. You heard it just now, so I'm not going to repeat that. Let me first start off with a couple observations. I used to say about the young generation that to be digitally native meant you grew up using digital technologies and had an intuition for their economics from that experience. I'm going to redefine my definition of being digitally native for this paper as you grew up in the protocol stack and you have a sense of what it means to live in the protocol stack and so your sense of economics comes from that experience. I would also like to reiterate the theme in a slightly different way to then generate some comment. The theme here is a better one from economic history and that's a theme of there is a new input for production. It is cheaper, better, faster. It allows the user to accomplish their goals with fewer frictions and reach certain activities that were previously unreachable. And you might reasonably ask well then what happens to those firms, those users, because they're using that all using the same input and doesn't that reduce the differences between them? And if you were to ask that question historically say about automobile firms who went through such a process we know what the answer is. They all adopted the same essential input and they differentiated on output and that's how the industry developed and it is that intuition at a very broad level which is driving the core results of this paper I would say even more broadly that as someone who's grown up in the computer industry and watched it for many decades the process described here has never been described quite so cleanly and I love that and it's wonderful but I recognized it as something the mainframe industry went through and it's a it's a familiar broad process to anyone who's been paying attention for a long time so that's one way to rethink about the paper and to frame it and that's the way I read it and so my comments to the author and to the audience are going to come from that perspective I'm going to start with a couple small things just because I want to get them out of the way and then I'm going to put a couple big things on the table small things to our author who I love your paper but this paper is written for your thesis committee you now congratulations need to write for a journal editor for a journal editor you need to move more to the impendix and you need to add what I would call guide posts for the reader at the end of every section there needs to be two sentences that reminds the reader why what the point of the section was and the IV is just awesome don't get me wrong and the robustest checks are awesome don't get me wrong but most people will just want a couple paragraphs and you can put most of that in the impendix and your referees are going to read it don't get me wrong but for purposes of a journal the paper has to be written in a slightly more efficient way and more narrative requires more narrative and less detail so okay that's the small comments if I were going to tell you anything on your IV because you are good at that I would say the thing I would be curious about is if you would go back to the second IV because it is the second most popular framing today it's an interesting alternative to the one you use that's a small comment now let's go back to the bigger comment in the talk I'll make my one big comment it's bring the narrative forward I'll move some of the details into the background and the paper is extraordinarily strong in executing the Diff and Diff in a variety of ways it's very clear you paid attention to those comments it actually interferes with the narrative in a way that is not too difficult to fix but the narrative here plays out in an interesting variety of ways and for a reader like me I found that much more interesting and in the second half of the paper would love to see you turn what you seem to regard as a bug or comes across as a bug so to give an example an extreme example you have two kinds of startups here the really A plus startup and the muddled one it's you know who executes this better this trade off adopting a set of standardized bundled services and differentiating on the output side the A plus startup does it better that's the theme I'm getting from you but you could develop the theme there's another version of the same kind of theme local focus versus a national focus for the output so we would anticipate the firms who are building a service that's going to have a largely local focus to not be nearly as worried about differentiating as the firms who are going to have a national focus and then invite a much different competitive environment so again it's in your data you can kind of see it come out but you could pull that one out here's another one you touch on and I found very interesting the stage of the life cycle that you observe the firm at the entrepreneurial format again in some ways you treat it as oh no that's a control let's make sure the different diff works in spite of the life cycle I'd go no no no no that's okay I kind of believe you now let's turn it around at different moments in the life cycle where do we observe the difference in the input of the bundle and differentiation on the output side when do we see it play out most visibly early or late and so on and I get the feeling again that there's some endogeneity in the way we say that but that's fine let's just play it out the ones who adopt early seem to differentiate earlier as well that's what we get another version you have a wonderful discussion about the ecosystems in which these or the geographic conditions under which these firms incubate and if we could say it more less prosaically were they born in New York or were they born in the valley that anticipates that geographic birthplace imprints a different focus on them I would expect the ones from New York and LA to be much more entertainment focused in their output at the output side and so the point of differentiation is going to look quite different from a valley firm who is building a tool to be acquired in a different way and that is their principal goal and their point of differentiation is also going to be quite different due to their mission and so you have this again wonderful discussion about how the different diff survives the geographic location I want you to turn it around and say oh hey in these different locations and so I'm just giving a couple of these examples the last one I'm going with is the one you also alluded to it's the AI industry as I watch it today the AI industry is differentiated on output in a wide variety of ways large even national focus very little with you know local focus you have the other kinds of firms and again I want to see you blossom that a little bit more rather than use it just as a control on a different diff other than that so that's my big comment it's a wonderful paper it's a joy and I'll leave you with a reference I don't know if there's anyone in the audience who reads this anymore but it's about the automobile industry and they describe a process that is quite close to the one you describe and it's a classic of economic history and it's like the first thing that came to my mind when I read your paper it was just absolutely wonderful ok, that's my comment