 Hi, my name is Narayan Mandelika and I'm a Group Product Manager at Work. Today, we'll be discussing about the build versus buy analysis. A little bit of introduction about myself and some background about myself. I'm a Group Product Manager currently in the platform engineering team at Work. The platform engineering team is a centralized team that provides the tools and the products to be able to develop software at Uber and be able to deploy that software and manage it in production. We essentially provide the infrastructure and the platform to be able to run all our services on top of. Prior to Uber, I was a Product Manager at VMware managing the Kubernetes Management Platform. And before that, I was at HP managing the Cloud Management Platform. Prior to being a Product Manager, I was an engineer working in the payment gateway, infrastructure management software, and the cloud automation software. So now let's talk about the build versus buy analysis framework. It's essentially a decision making framework for software companies who have both the engineering prowess as well as the IT budget to be able to buy software. And it is these companies primarily who actually go through this kind of an analysis so that they are able to figure out how best can they use their engineering resources internally to solve their business problems. And whether a given business problem needs to be built in-house or should it be actually something that they need to look out and get a product and integrate that into their environment. And the outcome of such an exercise really varies, you know, company to company, you know, there are several both internal and external factors that could influence the outcome. Many things such as, you know, the culture of the company, the maturity of the company, you know, the confidence in the engineering talent would actually play a big role in the end outcome of such an analysis. Now let's talk about why this is important to organizations. One, it promotes a healthy debate before even trying to solve the problem. You have to consider various factors such as time to value, how critical this problem is to the organization, how it aligns with the goals of the overall organization. Before you attempt to kind of go about either building or buying software and all these, you know, decisions have to be made upfront. It's also a great opportunity for PMs and engineering teams to be able to look at various products and understand the, you know, the problems and the features that they're trying to solve. And also, you know, during this process, both the PMs and the engineering teams would probably uncover some interesting use cases, especially because, you know, the vendors would be interacting with many of the customers and they would be enriching the products based on their conversations. And some of these use cases would probably be applicable to the, it's our PR, our desktop. So that's something to consider. The other is that it could also result in some good partnerships, since you get to talk to various vendors, leaders in the same problem space, as you go through the evaluation process, and now you can also continue to build that working relationship and collaborate and partner with them, as you implement some of the solutions within your organization. It could also lead to some interesting options down the line. For example, if you're trying to solve a mission critical problem or a problem that is going to help you in differentiating significantly from your competition, your organization may be willing to invest in maybe acquiring maybe an each player or a small vendor, so that you're able to kind of acquire for building the talent, and maybe you may be able to quickly build this capability out or extend the vendors product that you have acquired, so that you're able to kind of bring in that time to value. At the same time, you're able to cater to specific internal needs that your organization might have. So now let's talk about the phases of analysis. You can think about this entire build versus buy analysis to be primarily of five main phases, at least that's how I perceive this to be. One is the build cost estimation, which is an internal estimation that you have to go through to be able to understand what does it take for your engineering team to be able to build this product out, operate on this product, and then also, you know, what does it take for your team to be able to maintain this product and the infrastructure product, infrastructure, the cost of running this product in the house. During this process, you go through an elaborate process of identifying the requirements and validating which funds are critical for your organizations, which funds could wait, et cetera, and we'll go through this, the factors that we use as part of the build cost estimation. The other is the vendor evaluation process. You identify the vendors of solving this problem, and you evaluate these vendors. Again, we'll review the factors there. The product evaluation phase is identifying the products, how best they meet your requirements, and then finally, shortlisting those products to be able to go through a POC phase, where you get much closer in terms of the details, right? I mean, you test the product, you experience the product so that you're able to evaluate this product in your environment or integrating it into part of your environment, and then, at the end, you use all the data that you've collected and frame an opinion and be able to do a build versus buy or even partner analysis. At the end of the day, you actually have to make a decision whether you want to build by it or you want to partner with one of the vendors of that. I've indicated in some of these phases where you would be better off by partnering closely with engineering so that the outcomes are going to be a lot more meaningful for your organization, and you definitely need the engineering partnership, especially when it comes to estimations, when it comes to actually integrations during POC, et cetera. So now let's also consider some of the factors before you go into doing the analysis. The factors that you have to consider is the level of maturity of the problem area. You can probably use the Gartner curve, Hype curve to be able to determine if this problem is something that many vendors have already addressed. There are mature vendors in the marketplace with mature products addressing this problem area, then why go reinventably? So you probably want to kind of lean towards more of a by decision unless there are factors, outliers that are very specific to your organization. The other is you have to look at the organization strategy and the goals. How critical or mission critical is this problem that needs to be solved? And then the pulse from the leadership is another aspect. You need to support from the leadership before you go through this analysis because it is going to take a substantial amount of time, both from the product management and the engineering team, as well as down the line the leadership. And the net outcome from this exercise need to be supported also by the leadership so that you are able to get to the implementation phase after the analysis is complete. The culture of the organization, again, look for whether there's a bias within the organization to be able to build or buy. And then the other aspects to look at is what is your confidence within your organization, whether your engineering team can actually pull off this by building something or would you encounter hiring challenges? Let's say if you don't have enough engineering resources to build this capability out, then you probably want to kind of lean towards more of a buy if you notice some of those challenges. Also look for what is the current and future IT budget based on your current and future projected scale? This is going to be very important both for the build as well as the buy. The current and future IT budgets will be required from an infrastructure point of view if you were to build, but you need to still host this product in your environment and maintain and manage that. So you have to think about the infrastructure cost of doing that. If you are to buy, then you are looking at the licensing cost and potentially other costs such as network, egress cost, etc., from your data center or from your cloud provider. So these are some of the things that you have to think about before going into doing the analysis. So now let's talk about the first phase of doing the analysis. The first phase is called the build cost estimation. The build cost estimation phase, this is the first phase where you first prioritize all the features so that you are able to identify the most important ones you need. This list is going to help you in assessing the vendor products as well down the line. The important features, as we call them as priority zero features, are going to be what defines your minimum viable product. Make sure that you work with engineering in the space. Identify what takes engineering to deliver these features in the shortest timeframe. Essentially, you look at how many people can work in this product in parallel. This is going to be your internal time to value if you were to kind of build this product internally. This factor is something that you use to be able to assess your vendors as well because the vendors may not have all the features that you ask for. So you have to look at, you know, what is the value of the product? You have to be able to assess your vendors as well because the vendors may not have all the features that you ask for. So you have to look at, you know, what is the meaningful timeframe by when you get these minimum capabilities that you're looking for from the vendors as well when you make this assessment. In addition to this factor, the time to value, you also have to assess the engineering man-mans to build these capabilities out. The engineering man-mans will give you a rough estimation of the cost of building the product, taking, you know, the average cost of engineering in your company and also where you desire to build this product. You can actually determine what's the average cost per engineer to be able to determine the overall cost of being able to build a minimum viable product. Add to this the infrastructure cost, the integration cost, the cost to be able to maintain this product. So this is going to give you like an estimate of what the build cost estimation is going to look like. Now let's look at the next phase of the evaluation, which is the vendor evaluation phase. In this phase you will identify the vendors who solve this problem with products. One way to look at this is you can go through the magic quadrant from Gartner, identify the leaders in this phase. Evaluate these vendors for financial stability, whether they fit the product, whether they consider the product to be a key part of their overall strategy. And if the product is clearly in alignment with the vision and the mission that they state. Also evaluate if they are a strategic vendor to your organization. This helps you in ensuring that you have leverage with the vendor. Also assess how responsive the vendor is. During the entire process of engagement with the vendor, make notes of how responsive the vendor is so that down the line if you were to go with this vendor, you want to make sure that the vendor is able to cater to your needs, address issues on a timely manner. And as a result, you would see better success if you were to go with this vendor, if you deploy this particular product in your organization. Look for vendor reference feedback. Ask the vendor to share references. This is going to be crucial for you so that you know that you are not an outlier, especially when it comes to scale, when it comes to certain use cases. You have other customers who are using the product. Similarly, as a result, you'll have better success in getting the vendor to prioritize and address some of the missing adjacent capabilities in the product down the line. So these are some of the things you consider as part of your vendor evaluation process. Now let's look at the product evaluation phase. Once you have identified the vendors and their products have been shortlisted, you can use the following factors to determine which of these products best suit your needs. At this phase, you get to evaluate these products through vendor demos, maybe testing the product out using test accounts. And once you do that preliminary evaluation, you know, you should be in a position to be able to at least identify two or three products that address this particular problem area. Obviously, you first start with, you know, in terms of the factors, you first start with looking into the features and capabilities that the product support, making sure that these products offer the minimum viable features that you are looking for at least to begin with. Check for scale, check for availability and throughput requirements ensure that those requirements have been met, you know, and also as you go through the POC phase, we talk about some of the other things that you could do to be able to evaluate the product in terms of scale availability and throughput. The licensing model is going to be a key aspect to look for. A good licensing model helps you in being able to predict the licensing cost based on your current and future projected growths. Right, the licensing model also needs to be modular so that you can pay for what you use from the product. And down the line, we will also talk about the options and you may decide to just use part of the product, not the whole. And as a result, the licensing model should ensure that you're only paying for what you're going to use. Use the licensing model to be able to estimate the licensing cost based on your current scale as well as future. Also assess the product for, you know, whether there's an open source availability. Because it does help you in de-risking the product, you know, implementation. For example, down the line for some reason, the vendor decides to not support the product anymore. You have the option and the viability to kind of go in and start bringing back the open source product and contributing to it and enriching the product. The other is having an open source model helps the vendor accelerate the features and capabilities because now you have the community also contributing into the open source product. Also, your engineering team can also contribute to certain key features that are very important to your organization. And as a result, the vendor can also accelerate that by pulling in that open source version into the commercial version. And as a result, you get the benefit from these features showing up much sooner in your environment. Look into also the feasibility to integrate into your current ecosystem. This is going to be really important because, you know, how does this product integrate into your user identity management? How does this product integrate into your monitoring subsystem, logging subsystem? These are all going to be very important to be able to manage the product and you don't end up with having, again, like a sprawl of other products that you have to bring in just to integrate this product with. So now let's talk about one of the most important phases, which is the POC phase, which is also one of the most lindiest phases, I would say. You know, once you have shortlisted the products, preference, as I mentioned, is to have at least two to three different products that you have shortlisted. You start using these products in your environment. You might have to deploy these products if these are only available on-prem or if these are SaaS based. Essentially, you have to integrate them into your current ecosystem so that you are able to test and validate your specific use cases. Using your test data with these products. You validate these products also for user experience, integrations, scale, performance, by sampling real data. Identify the internal customers within your organization who can partner with you with your engineering team and help try using the product and give you feedback. Grade the product based on the experience from these users. And as I mentioned, this is going to be one of the most lindiest phases in the build versus buy analysis. So you have to think about using checkpoints so that you're able to report the results to the leadership. Also, you're able to also at any given point in time, you know, call off the POC for a given product simply because let's say it does not meet one of the critical use cases that you need to support. Also, you're able to also share the results throughout during these checkpoints with the vendor. So the vendors are also able to resolve issues that you might encounter and not just do it towards the end. So now, you know, by this stage, we have pretty much completed the assessment. You know, we have probably framed an opinion, you know, we've collected a lot of feedback, a lot of data. Now you can use all the data distiller and then probably frame it into something like a simple matrix. Again, I put a matrix here. Clearly, this is not like, you know, something that you have to stick to, but I just put something here to be able to help you in saying like, you know, these are some of the factors you have to consider. And, you know, you take all the data and then put it together to be able to make a recommendation and use this matrix to communicate to the leadership and make the recommendation to the leadership. Such as, you know, on a scale of one to five, what do you think about the vendors that you've evaluated, you know, the products that you've evaluated? What do you think the time to value is going to be, especially when you build the product? And maybe what is the time to value from vendor one, two and three for being able to get some of the missing critical features that you need? You know, what is the licensing cost? You can use the net present value to be able to estimate the licensing costs for each of the vendors for the current day and also do the same thing for, you know, the build cost, the infra cost, the cost of being able to run the software on prem or in your cloud environment if you were to kind of build and manage this product. Even if you were to go with, you know, the products that are vendor based, you might have to probably install some components, maybe in your local environment. And that is something that you have to account for as part of your infrastructure cost as well. The maintenance cost, the availability SLA integration cost, these are some of the key attributes that you evaluate the products and your internal build product for as well. You can come back with, you know, a recommendation and you can use something like this to be able to have a discussion with your leadership with your recommendation. So, you know, we, you know, let's say we have made a recommendation. Now, you have to remember that the entire analysis doesn't necessarily have to be, you know, a binary decision, right? I mean, you have all this data and you have, you know, a recommendation to make. It doesn't necessarily have to be a build or a buy. It could be many other possible options. One is you may decide based on your analysis that you probably are better off partnering with an open source product that's out there, or you might want to kind of initiate an open source product project to be able to build these capabilities out. Maybe it's because you realize that there doesn't seem to be, you know, a viable option out there. And the internal build from scratch, maybe two time consuming or getting talent is going to be an issue. You may also notice that this is a widely accepted problem in the industry and there's no strong vendor in the market. So you may decide to hence partner with the open source community so that you're able to get the mind share and you're able to accelerate and get the capabilities out. The other is, you know, you may decide to actually use only a subset of features from a product that you think is the best fit. And you might decide to, you know, build the remaining features out internally simply because it could be that, you know, trying to build these features is probably, you know, far more easier and probably, you know, it's also probably going to be too expensive for you to license the entire product because maybe there are scale issues for the remaining areas that you might have to end up paying a huge licensing cost, right? So these are some of the things that you have to think about as options based on the data that you have collected and doesn't necessarily have to be a build versus buy. There are also other interesting options as I think I mentioned in the early part of the presentation. You could go back and explore, you know, one of the vendors who's small enough to do a talent acquisition. And as a result, you're able to build and own this internally. Typically, this is a case where you're trying to solve a problem which is mission critical. You want to differentiate yourselves from the competition as quickly as possible. And the problem can be addressed by, you know, identifying maybe a vendor is small enough and acquiring the vendor so that one, you're able to kind of leapfrog because you got some of these capabilities that have been already built and then you can extend on top of it. And as a result, you might reduce the time to value at the same time get some critical functionality in that is going to help your organization differentiate. There's definitely going to be a cost to it when you think about acquiring vendors, especially for talent. You do pay a potentially high price for acquiring a vendor, but maybe the cost is well worth it. And that's something that you have to explore as part of your analysis as a product manager. So now we pretty much come to like the end of this webinar. So let me recap what we discussed so far. One, the build versus buy is a decision making framework. It helps organizations to best determine how best to use their engineering resources. You know, if they want to actually dedicate their internal talent engineering resources to solve this given problem, or should they actually buy a product. It includes various spaces and some need strong engineering partnership as we discussed. The outcome or the recommendations that you can make don't have to be necessarily binary. And by the way, communicating this early that these are all possible options will also help you in getting the support and the buy-in from engineering as well, because they don't see it to be just a buy versus build, but there are many possibilities. Also, the open source option is going to be pretty attractive for internal engineering team. So the outcome will vary, as I mentioned, it varies. In fact, for the same business problem, if you give it to two different organizations, it will vary based on their internal culture, their bias towards build versus buy. It also varies based on, you know, the maturity of the company, where they are within the growth cycle, and could also vary based on the problem that you're trying to address. So there are factors, main factors to be considered as part of your analysis. One is the time to value, you know, what is the time it takes for you as an organization to build these capabilities internally. And then also look at it in terms of, you know, other aspects such as the operational cost, the infrastructure cost, the maintenance cost, in addition to the licensing cost and the cost to be able to build the solution. One other factor to consider as you go through this whole process is to look at how confident are you that the organization can build this capability out. So that is something you also look at, or how confident are you that you can actually hire, you know, engineering talent to be able to build this capability out, and that's another aspect to look at as well. So I want to end this webinar with a nice quote that I had read on Medium. You know, it's like the bill versus buy discussion is a sign of a healthy organization. It really indicates that the people are thinking about the best way to be able to advance their business, right? So because you're taking all these factors into consideration, and before you kind of dive in to be able to just go solve the problem, you're, you know, considering various factors and deciding what is best for your organization. That is something that is important. Essentially, you're looking at the opportunity cost here for your engineering team, whether they should be actually solving this particular problem or you're probably better off buying a product and integrating that into your environment. So that concludes this webinar. And thank you all for for joining and listening. And I'll be on a live chat on the 18th of April at 2.30pm Pacific Standard Time. Please bring in your questions and I'll be happy to answer them for you. And I'll be, you know, I'll be seeing you all there, you know, during the live chat session. Thank you for attending this webinar again. I hope this has been useful to you. Thanks.