Buy vs. Build - A Product Manager's Decision w/ Ardeshir Ghanbarzadeh of Logi Analytics

Hey everybody, this is Mike Belcedo, co-founder of Product Collective, and we're back for another industry interview. Again, live from my basement, but I hope wherever you are, whether it's your home office or maybe your basement, you are safe and healthy and doing all right. Excited to have you with us though for this industry interview, and this is going to be a good session on the buy versus build topic, which is sometimes a hot topic, sometimes one that people, uh, you know, you're always Googling and trying to find resources on, at least for me personally anyways. But before we get to that, uh, just a few kind of housekeeping things. If this is your first industry interview, um, then welcome. You know, this is, uh, we've been doing this for the last few years. I think we've done this a few dozen times. I have to go up and add up all the interviews that we've done, probably getting close to 100. But welcome. This is a part of Product Collective. Product Collective, we're a community for product people. And we do a whole number of things. We have a weekly newsletter that goes out to 30,000 folks. We have a very active Slack group, 10,000 people in the Slack group. And we do these industry interviews twice every month on the first and third Wednesday of every month. And they're meant to be good conversations with product leaders, and we focus on a different topic every single time. So again, today's topic, the buy versus build, but plenty more coming up. So when I follow up with everybody after, later today, I'll include some of our upcoming sessions as well. But yeah, so first, just to kind of get out of the way, hopefully you can see and hear us okay. Maybe if you can in the chat, just mention where you're from and what product you're working on if you want to. That way we'll know that you can see and hear us. Plus, it's just fun to see where everybody is coming in from. So I'm in Cleveland, Ohio here. I know my guest is from Maryland, so we're really You know, we're excited to be here. Oh, I see some, some people here now shouting out from Phoenix, Arizona and Berlin, Germany. So, um, I know our attendees come from all over the world, so thank you for being here. Um, just a couple more things. If you see me cut in and out, you know, again, I'm at home, so I'm on a hardwire here, but you never know, so bear with us on that. Um, but yeah, with, with all that, um, I also want to thank the, the sponsor for today, and the sponsor is Logi Analytics. Logi is a company that we've been collaborating with for quite some time. They're not just a great company to work with, but also just to learn from. There's all sorts of resources that you can take advantage of. So I'm going to send some of those resources later on, later today, just once we have the session on video to share as well. So I just wanted to thank Logi though for being a sponsor. But with all that, you know, I want to, want to get right to our guest. Artashere, thank you very much for joining me. Artashere Ganbarzadeh, he's a Actually, at Logi Analytics. So it works out. We wanted to have a guest from Logi, and Logi was gracious enough to also become a sponsor of these industry interviews. And so, Ardashir, just thanks a lot for joining me. I really appreciate it.

Good afternoon, Mike. Thank you, and it's great to be here.

Yeah, so, you know, I know the whole topic again, we're focusing on buy versus build, and, you know, that can come in a lot of different flavors. That can mean a lot of different things. I guess maybe just to start off with, Why is that buy versus build decision so important for product people?

Sure, sure. That's a great question. So chances are that if you are having the buy versus build discussion, that you've already identified a market need or have a project or have a customer or an install base that's presented you with a problem that you need to solve. And if in the world of software, you know, usually the approach is, okay, you know, what do we build the software? Do we buy the software? Those are the typical two paths that that organizations seem to take. The reason that it's important, because at its core, the buy versus build decision is also very much a business decision in that both approaches carry a certain amount of risk and a certain amount of cost. And this is different for every organization depending on where they are, you know, in their business. The reason that it is essential for product people to understand all the cost drivers and on all the potential risks involved is that they need to be able to appropriately balance those costs and mitigate the risks when it comes to making the build versus buy decision because there are long-term implications, especially with software which could have a 5, 7, 10-year lifecycle that they need to be aware of and consider into their decision before they actually decide which path to take. Got it.

And so I know you mentioned before there's sort of different levels of risk and there's different types of buy versus build decisions. I imagine there's some where there's sort of smaller decisions. You know, I could just think of an example. If I'm subscribing to some piece of SaaS software, technically I've made a buy versus build decision. If I'm acquiring a company just for their software, that's a much bigger decision to make. Can you just kind of speak to the different levels at play play here and kind of like what's associated with those?

Sure. So there's a few different levels. I mean, there's several different ones, but I'll cover a few of them. I suppose at the top would be what you suggested, an acquisition or merger and acquisition of another company. This is where you buy the entire company, their IP, their capabilities, all their resources, and you roll that up into your business and into your offering. And that's how you get growth or value. Probably one level below that, I would say, would be the rights to distribute somebody else's product and brand. And we see this model often appear with system integrators and value-added resellers and distributors who will take products from Microsoft and, you know, from other OEMs. But what they'll do is they'll actually wrap their own unique services and tools around them to create a value-added offering and bring that to market. The one below that, and this is the majority of time, you know, The majority of time companies are looking mostly for a tool that's going to help them with a specific function. And it may have absolutely nothing to do with their core product or the service that they offer to their customers. But they need this particular capability to be able to run their business. And I'll give you a simple example here. Imagine there's an auto dealership that may want to reach out to their customers by email to promote the vehicles they have in inventory, the kind of services that they offer. Or the kind of promotions that they're running. Now, to do this, they can subscribe to a service like an email marketing service such as MailChimp or Constant Contact or one of the dozens of email marketing tools that are out there. And through that subscription service, they get to actually do blasts, email blasts to their customers. They can track open rates and all of that good stuff. But what probably does not make sense for the auto dealership is to go out there and build their own email marketing tool. This has nothing to do with their business. They just need this to be able to market, market their business. We see the same kind of similarity in the software world. When you need a database or a security framework, it is very rare to see a company today go out there and say, I'm going to build my own database, when there's, you know, what, 100 database vendors out there, all with unique capabilities that can add actually address database needs. So we are seeing more and more that there are these specialized tools out there, and that's probably the mid-tier level of buy when you look at it. And at the very bottom, I suppose, would be something highly customized. You want a very, very specific feature. It is not available in the marketplace. You have to get this bespoke made, and that will be Probably another way to look at what types of buy there may be out there.

Yeah, awesome. By the way, everybody, I saw one question come in. There is a Q&A section at the bottom, and I think we're going to be able to get to at least a couple audience questions towards the end. I'm going to kind of save it towards the end this time, but fill those questions up as we're talking. If Arshir says something that you're curious about or you have another question, load it up in the Q&A section. I'll definitely get to some questions at the end. But I have a few for you myself, Artashere. So, one would be, you know, you mentioned those different levels. What are, like, how do we kind of judge, like, what factors, I guess, should we be considering when we sort of make those buy versus build decisions? I imagine probably depends on the type that we're making, but I imagine there's probably a lot of different factors. Maybe you could talk to that.

Sure, sure. Yeah. So, at this point, you know, when you're at this stage, you probably figured out what's the problem you're trying to solve. You already answered that basic question. Beyond that, you need to start asking yourself some other pretty critical questions. One is that, is what you're considering building part of your core IP? Is it going to uniquely differentiate your product and advance the value of your product? Or if it's not, if it's something that is, you know, very easy for somebody else to pick up and integrate your competition, for example, and replicate what you're doing, Then, you know, you have to start thinking about whether you want to spend time building it or maybe just grabbing it and integrating it in. The second problem, and this is pretty important, is that do you— do we understand the problem domain to actually be able to pursue the build strategy? Or is this completely out of our wheelhouse? We don't have the expertise for this particular capability and we should maybe consider partnering with an expert vendor to get some help. The third, and this is sometimes a critical event, is what's your timeline? You know, how quickly do you need to have this capability? Is this something that you have enough time to go and invest in research and development and go through the entire learning curve to build it on your own? Or is your need much more immediate and it makes much more sense to buy something and have access almost immediately for faster implementation? This is really important and it's a big driver in the decision-making process.

Yeah, that's awesome. So let's just say the buy is the decision that we make as product people. Like when is that the right one? And it might be, I mean, I heard what you said before, like, is this in our sweet spot? Maybe that's part of the answer, but can you expand on that a little bit?

Yeah, sure, absolutely. Let me give you a couple of more of the critical factors and then I'll get into, you know, when is the right time to buy, because these also go into go to the decision of whether to build or if not, or to buy. So on top of the fact that, you know, you may have a timeline to deal with, you may also have to really decide whether you have access to experts that are going to be able to not only build this but to be able to support and maintain your capability or your solution long-term. This is also very important for the viability of your product, you know, going forward. And then another key factor, which was kind of what I was referring to in the auto dealership example, was, you know, is this something that's already widely available? You know, is this something that I can go and grab off the shelf? Can we just simply buy this and plug it into our products? You know, that's a big driver if that's the case, and again, if it's not a differentiator. And also, how much more investment do I have to make outside of just building or buying this product with the infrastructure and the tech stack stack that I have in my business? Is there more that I need to invest there to be able to actually, you know, get this solution delivered? So those are some of the factors. One thing that I do want to point out is that the reality is that probably most of your customers are not so much concerned whether you built everything from scratch up or you cleverly integrated some purchase solution into your product to be able to deliver on their requirements. They far more care about the fact that the product works, it delivers exceptional value. And that's the kind of, you know, debate you have to have internally of where are you considering the risk and mitigating them and what kind of costs are going to be involved with the complexity of your products as you go through managing it through its lifecycle. So that was basically still talking about the considerations. But I think you asked me when was the right time to build.

Yeah, yeah, well, in both. I mean, really, like, my next question after— so maybe you could talk about both in that case, like, when's the right time to buy, when's the right time to build, basically.

Sure, sure. Okay, so I'll talk a little bit about, you know, when is the right time to buy. So once you've gone through that list of considerations we just spoke about, you now have a good understanding of the complexity involved in actually providing the solution that you're, you know, you want to take to market. So More often than not, the requirements that you've been handed or you're assuming are out there to deliver the solution are going to be a large set of non-trivial and demanding challenges. What I mean by this is you could have small difficult problems to solve with database, with security, with third-party integration, with workflows, with business logic, and a bunch of other things that will play a role in defining how multifaceted your solution has to be at the end. This is when you start to take some inventory of your development resources available to you, of the level of effort involved, of the long-term support and maintenance needs, your time to market, the opportunity cost, the risks involved with future-proofing the solution. And that's when the proposition to buy the solution starts to look a little bit more attractive and a little bit more practical. And there's some valid arguments behind that. When you buy, for example, you transfer, along with your requirements for the products, much of the responsibility of support and maintenance, roadmap development, and staffing of expert resources over to the vendor. They now have to maintain the software for you. They have to do the bug fixes. They have to give you a roadmap. They have to keep experts on staff to be able to serve you. What you also get in return is— and this is especially true if you're trying to build something that is not within your core competence, is that you're keeping your development team focused on your core application. This is a huge plus because that's where your IP is and that's where you want to create more value. You also would get access to the vendor support team, and oftentimes those support teams have service level agreements. So, you know, they have to adhere to those agreements. They have to have reasonable response times and reasonable time to resolution. So you need help, you pick up the phone and call for help and say, "Hey, I have a problem with my software. What can you do to help me?" And also, those vendors typically have resources to support you who are experts in that particular area. So you are getting people who specialize in the very capability that you're trying to deliver in your product. There's some valid arguments around the fact that you will see faster times to implementation because, you know, software frankly takes a long time to build. And the more complex it is, you know, the longer it takes. So being able to take a framework or a platform or a tool that somebody else has already went through the process of developing and testing and securing makes a lot of sense in terms of, you know, getting your roadmap to market faster. And I think one of the things that I touched upon, one of the key areas that you need to consider because this is ultimately a business decision, is the cost drivers. Typically the buy argument favors the predictability that comes with, with the costs going forward. If you subscribe to a service, if you buy a platform, you know how much you're going to pay this month, you know how much you're going to pay next month, you know your cost this year, you know your cost next year. So that predictability helps quite a bit in understanding what your costs are going to be, which is one of the key driving factors and why it's so important to to take that into consideration. So to sum that up, what I was trying to get across with the buy situation was that if your solution— if the solution you're looking to deliver is not basic, once you've gone through assessing all the requirements and now it's taking the shape of a more complex deliverable that may not be your core competence or you're not properly resourced for it, a buy strategy may be a good fit.

Yeah, great. I have a couple more questions and then we've got some other questions coming in from the audience, so keep those coming, everybody. But I, you know, thinking back to the time where my product wasn't a product community and a conference, you know, when I was back up as a product manager at a software company, I know sometimes technical debt also played a role in terms of some of the, some of the decision-making we'd make on buy versus build and I want to know if that's common for other people, and maybe you could talk about that in particular.

Yeah, sure, no problem. Um, yeah, so before getting into technical, that I did want to touch up a little bit on the build because I don't think I covered it in the last section. Oh yeah, yeah. So, uh, so we talked about, you know, what are the, what are the merits for taking a, a strategy with buy. Um, but let's talk a little bit about where sometimes even build makes some sense. So the ideal use case for building is if the requirements are very simple and they're not going to change over time. So I'll give you an example. You know, we at Logi Analytics, we, we work with, you know, embedded analytics. So if one of our customers is looking to, you know, embed analytics that are simple, it's just a simple chart or it's a simple table, those are very simple requirements and And if they don't expect this to change over the foreseeable future, then— and there's no additional complexity involved such as like security needs to be applied, then it probably makes sense to build something internally and keep it homegrown and do that relatively quickly. However, you know, in that same type of scenario, if— and this is true with the majority of analytics cases, by the way, use cases, by the way. The requirements are never simple. And in fact, they will change over time. And the primary reason for that is that when you offer analytics to your customers, they immediately turn around and ask for more because it's business intelligence and it's data and it can be actionable. And they want to be able to do more with it. So that simple chart or that simple table or dashboard now needs to be an interactive chart, an interactive dashboard. They want to be able to share that. They want to be able to, you know, to have multi-tenancy. They want to be able to ensure that they have good security and they can do this at scale. So those requirements now start to actually snowball into a big challenge. And that challenge, when you're building on your own, can suddenly become a significant lift, especially for the development teams, which means a large development backlog and technical debt, which I'll get into when I get into in a minute. So as far as the As far as the build, it really comes down to whether you have simple static requirements or more sophisticated and dynamic requirements that are going to change over time. Now, to answer your question about technical debt. So technical debt is one of probably the most underestimated costs that go into the whole decision to build or buy. Now, let me start by saying that technical debt is inevitable. With every single product out there. Every product you know of, you can think of, and you don't know of has some level of technical debt. And what technical debt is, you know, there's a couple of ways to raise it. Sometimes it is raised deliberately. You know, you may have a customer with a hot new requirement. You want this— you want to be able to get a proof of concept out to this customer as quickly as possible to see if you can get some product-market fit. So, you know, you build something and you maybe not fully test it. You may not go through the, you know, complete regression on it. You may even cut some corners, but you put it out there to see how the market feels. You know, you have to do those things at some point, but you just don't do them now. The pieces that you didn't do and the rework that has to go into that product if the market accepts it is what is going to go into your technical debt balance sheet. That's a deliberate way to raise technical debt. There's also ways where you can inadvertently raise technical debt, and this can be because perhaps the underlying software is either under-architected or over-architected, or potentially the application team was working on a functionality that was not within their core competence, so therefore they were not applying some of the best practices that would come along for that particular capability. And then that's going to create some rework that has to actually go into the product. And that's another way to raise technical debt. But to come back to it, like I said, all products have some level of technical debt. What's important about that and what should be a consideration for the product people is that this is something that would need to be managed and it is a risk and a cost driver both for their product.

Thank you. I appreciate that. I have one more question. I know there's a few other questions from the audience. Like, my last question for you is just like, what are the most common mistakes that you see made? Because I imagine you've seen a few and we should try to avoid those. I always like asking that question.

Sure, sure. Yeah. So, I mean, I'll keep it in the context of, you know, Logi, but when it comes to build, oftentimes what we see go wrong and where pain starts to get felt is the very considerations that we talked about in terms of the long-term risks and the hidden costs and what's going to be around the corner were not taken in when the decision was made to go with a homegrown approach. And for example, one of these costs is that when you are building in-house, conversely to when you're buying, when you're building in-house, all the support, maintenance, enhancement, scale, you know, upgrade responsibility falls on the application application team and all internal teams. And that becomes a real big problem if the application actually becomes successful and it starts to scale up. And that will lead to more demands for features and capabilities that now the app team has to, has to deal with. And this could cause them to very quickly become overwhelmed and create that development backlog and technical debt that we spoke about. Now, the interesting thing is that the dynamic happens to be that application teams are builders, you know, and they're always looking, you know, on building the next great thing, which is wonderful. And so there's this desire and inclination to build that comes very naturally to them. However, one of the most overlooked consequences and another hidden cost that is tying up— that comes along— is tying up the application team into building something homegrown where it is also very easily available out on the marketplace and not letting the application team actually invest their cycles into creating more value into the core IP of the company. So those are a couple of key elements to consider. We've seen this happen several times in the past. When it comes to buying, the biggest problem that companies typically find themselves in a difficult question— difficult situation is when they have not adequately mapped or vetted their requirements to the vendor's capabilities. So they have a set of requirements. They want to go and buy something out there to satisfy the requirements, but they don't go through a proper vetting evaluation process, checking to make sure that they can deliver all the requirements they have with that particular platform or with that particular tool. And when this happens, you know, at Logi at least, we've seen, you know, some customers that ultimately realized later, further down the lifecycle of a product, that, hey, you know what, I have a need for this embedded analytics to have the look and feel of my native application, but I've selected a vendor that doesn't allow any theming or customization. So now I my application has a poor UI experience, or there are serious shortcomings or lots of overhead in how security is managed and applied, or there's very, very complex and expensive licensing structures that don't scale because I'm trying to grow my product. So all of these are things that can, one, slow down the adoption or increase the cost, which we talked about as one of the key considerations when it comes to making the build versus buy decision. I would wrap it up by saying that overall, when it comes to simple requirements, it is probably more efficient and more cost-effective to build. But if the requirements are much more sophisticated and you can foresee that as the business grows and as the product matures, you'll be faced with having to deliver even more complex— deliver more even complex requirements, then then there's some consideration to be given, especially if there is a solution available in the marketplace. There's some consideration to be given that a buy strategy might make more sense here.

Yeah, got it. I know that's a pretty thorough answer, so I appreciate that. I do— I know we're coming towards the end of our time, but just to take a couple audience questions. One of them was just how important the investment conundrum should be with all of this. You know, money will be a factor, I'm sure. How important of a factor should it be in sort of the grand scheme as we make our buy versus build decision?

Yeah, I mean, I guess a lot of that has to do with, you know, the financial health of the organization and whether they have the ability to make the investment. So one way or the other, you're making the financial investment. You're either making it through a purchase and/or you're making it through, you know, the resources that you have to acquire in order to do that internally or build it yourself. You have to— the modeling here is to be able to look down the road about 12, 18, 24 months and see what is going to be the total cost to me if I do this internally or if I do it externally. Externally, if you're buying it, it's a little bit easier to understand. You get a quote, you know how much it's going to be. You maybe put a little bit on top of that and say this is going to be my total cost. It's a lot more difficult to predict cost when you're doing it internally because of the unforeseen or hidden costs that you will encounter. And I think that's where the investment decision needs to be made.

Yeah. Got it. And then, you know, one final question since we're really at the end here. I'll take this. This is an audience question. This attendee believed that sometimes buy versus build can be synonymous with deliver right now or long versus long-term benefit. Do you see it that way? Do you see sort of like the time to get product is one factor as to whether we might make that buy versus build decision?

I'm sorry, you got out just a tiny bit. What was that last part?

Yeah, just, um, sort of comparing buy versus build as deliver right now versus long-term benefit. So do you see that as sort of like time to, time to market, I guess, um, as a factor?

Uh, yeah, time to market is definitely a factor. It depends on, you know, if you have something critical that has a timeline attached to it and that could could be a big driver and a big part of the decision for sure. You know, whether it correlates directly to get it out there now, get it out there later, it all really depends on this problem you're trying to solve and what do you really mean by now. Is now 3 months from now? For some businesses it could be next week, for some businesses it could be 6 months from now. And that's their version of now when it comes to delivering it, depending on the complexity of the problem.

Yeah, no, that's fair enough. That's fair enough. Um, well, hey, I appreciate the time that you took with us. I know we didn't get to every single question, but I think what I'd love to do is I'm going to share again, um, a link to some of the resources that, um, that Logi has, because I think a lot of these questions might be covered in some of those resources too. So for everybody that I didn't get to your question this time, hopefully I can get it to next time. But look for an email from me later today, and hopefully you have some info there. And, and Artishia, I just really appreciate you joining.

Oh, thank you for having me, Mike. This was great. Appreciate it.

Yeah, and thanks everybody. Um, we have a few more sessions that are already scheduled, a couple that are about to be scheduled, so look out for those, and I will see you next time. Thanks everybody.