Build vs Buy: Analytics Applications – Part 2

Connect with Dhruv:

Connect with Dino:

• 
• dino@turetskyconsulting.com

Connect with David:

• 
• 
• david@turetskyconsulting.com

Resources:

• Real Folk
• HR Data Labs Season 2 Episode 11
• HR Data Labs Season 2 Episode 9

• “We’re learning a lot as a community and we’re changing quite rapidly… People, when they choose to build or buy software, are speculating less.” – Dhruv Dang
• “Companies that build software that you buy are solving universal problems… Whereas with custom software, it’s completely different. It’s a lot more flexible and less rigid; you’re solving problems that are unique to you.” – Dhruv Dang

Announcer: 0:03

Here’s an experiment for you. Take passionate experts in human resource technology, invite cross industry experts from inside and outside HR. Mix in what’s happening in people analytics today. Give them the technology to connect, hit record, pour their discussions into a beaker, mix thoroughly. And voila, you get the HR data labs Podcast, where we explore the impact of data and analytics to your business. We may get passionate and even irreverent, but count on each episode challenging and enhancing your understanding of the way people data can be used to solve real world problems. Now, here’s your host, David Turetsky.

Dino Zincarini: 0:56

This podcast is the second half of my conversation with Dhruv Dang, if you didn’t hear the first half, it’s pretty good. Please go back to the HR data labs podcast page, and download that one as well. Thanks. So we just talked about the last 20 years of software technology industry, evolution and, and how that’s gotten us to where we are today where perhaps building software isn’t such a radical idea anymore, given all of those points. But I’m going to bring up something that I’ve always found to be a challenge, let’s assume that, yes, the building side of things is much more viable in terms of the technology context. But something that I’ve always noticed as a product manager, especially, is that knowing what you want, and perhaps even more importantly, why you need it. I’m a big believer in Simon Sinek, you know, know the why start with the Y philosophy. If you don’t know who he is, look him up sign and sign up. He’s brilliant, text me in the comments or on LinkedIn, I’ll give you more info. But I digress. knowing why you need something and what it should be, it’s actually hard, we tend to focus instead on the features, which are much more about how you use it. Because the features are easier to understand, I can look at a list and see this product does A, B, C and D. Therefore, that’s what I need, as opposed to taking a step back and saying, Wait a minute, what problem am I actually trying to solve? And why is that an important thing for me to solve? And what do I need specifically to solve that? So do we actually start from an honest assessment of our problem? Or do we actually start with a preconceived notion of what’s out there based on what the market is providing in the form of these pre packaged products? I think it’s mostly the latter. We start with looking to see what’s out there. And then we’re like, oh, well, I need that. Because it’s a lot easier than coming up with it yourself. Right? Especially if you’re buying software, not because you’re an expert in that area, your business is something else, right? Something else you’re trying to do. You just know that there’s a gap, you have a problem, you need a tool? How do I know what this tool should do? Well, let me see what other tools are out there to see what people have come up with, right. So knowing the what it should be and why I need it, it’s actually really hard to do. And that problem goes away when you have a bunch of vendors presenting solutions to you. So my question to you is, how do you get over that? If you’re building the software, it has to start with? Why do you need this and and what should it do? And what if your customer doesn’t really know?

Dhruv Dang: 3:34

That’s a really good question. You know, and I think this happens a lot more common. This is very common, and it happens a lot more than people think. And I always say that it’s good to think in questions, you know, ask yourself, what are the questions that you’re looking for answers for? And, you know, one example is, how can I reduce employee turnover in my organization, I want to solve that problem. The solution might not be software, there’s a chance that the chance, there’s a chance that you will have someone in your organization that can answer that question for you. Right, maybe there’s experienced within the organization already outside of software that can answer it. And that’s actually a wonderful thing about going through this process of thinking about what problems you need to solve. So it actually allows you to minimize your scope, which is very counterintuitive thinking. And the reason why you want to do that is that it gives you a shorter feedback loop. It allows you to say, Okay, I have this question. Let’s see if I can solve it. And maybe if suffer is the right tool to do that. What’s the fastest way I can get there to answer that question. Now, there may be off the shelf software or enterprise software you can buy that directly answers that question for you. But if you’re running a unique business, and you have a unique selling proposition to your customers, the chances are that your team is also unique that your employees are also unique. And they may not be software out there to answer that question. So you might need to go ahead and build it. So I, I really recommend thinking in terms of questions, what are the questions, you’re looking at this for looking for answers,

Dino Zincarini: 5:16

That’s amazing that, I love that because you’re right when when we go and buy something, we, we can jump past that pretty quickly, vendors are more than happy to come and tell you why you need their product. I mean, I wrote most of the marketing for that one of my previous roles, right? Like, it’s very easy, that’s part of the selling process is to help your customer understand why they need it, and what they can do with it. If a customer starts from that, then it is a healthy process. I like what you said there, right, it’s a healthy process, because you might reduce the scope, you don’t need as much if you are clearer on what you really are solving for, and you might even have the tools are the skill set internally. So you’re kind of saying things smaller in order to to get really focused on the problem you’re trying to solve? Exactly. And I think that once you have that question, you know, once you have something that you’re looking for an answer, but once you have something that you would like an answer for,

Dhruv Dang: 6:14

It’s always worthwhile thinking about who you need to work with, to make that happen. And it’s always worthwhile having an expert. So for example, if you’ve got a vague question, or a high level question, but you’re looking for more details, someone like Dino, an expert in the field has been doing it for a long time. He’s a great person, you know, to work with. And if you’re actually to tell that just software, having a software vendor that you trust, and has the right experience, make goes a long way. And I think that trust and experience are the two key words and picking the people you want to work with, whether they’re internal to your organization, employees, or if they’re external and vendors. They’re the ones that will try to understand what are the questions you’re trying to ask? And how you can get to their solutions?

Dino Zincarini: 6:58

That’s a really good point. I mean, all good points are really good. So I don’t know why I said that. But the idea that, you know, we have to really have those trusted conversations to get at to these ideas. And, and maybe it is a little difficult to think I need to do this before I start, you know, my formerly procurement process. Now my larger question of how should I approach this, but it’s not throwaway work. Because doing that due diligence of understanding, who is this for? And why do I need it, and reducing that scope, not expanding it, vendors will usually try to expand the scope, because their features are probably way bigger than what you originally went to shop for. So they want you to think, Oh, no, but here’s more uses for all these other things I could do. Instead of going the other direction, you go smaller, you get much more focused and targeted on what you need. That reduces your risk. It reduces a lot of things that ultimately it’ll probably reduce your cost, if you can match what’s out there to just what you need. And I think that’s the challenge with enterprise software is they’ve created things that are much larger, as we were saying before, due to those competitive pressures and the addressable market opportunity. They’re going to make large generic software, when what you need is probably narrow and specific. Do you think though, that that also creates a trap? If you’re creating something with a smaller scope and narrow and specific, does that mean that you’re kind of opening yourself up to risk in the future if your needs change?

Dhruv Dang: 8:26

I think that’s a good point, you know, and I think it can happen. And this is where the trust and experience really matters. You want to be working with software practitioners that are able to build a framework for what you’re actually trying to solve. So not just software that only solves that question, but leaves the door open to keep building on top of that. And that’s what I think is sustainable software. I think that’s how sustainable software works. It’s where it can adapt to that change.

Dino Zincarini: 8:56

Could you give us an example of that? Because that’s a pretty bad idea. I mean, I’m already digesting that, because that wasn’t one of the prepared questions, by the way. So I’m still reacting. Yeah. But that idea of a framework, what do you mean by framework?

Dhruv Dang: 9:09

Yeah, the question you’re trying to answer is, how can my company better employee, the skill set of its employees, you know, I have 1000 employees in my company, there are a bunch of skills across there and varying levels of expertise. And people may not be in the right jobs. You know, I want people to be in the jobs that bring them fulfillment, and also bring value to the company and customers. And I need to find an answer for that. So you might hire an expert like Dino, who’s going to be able to offer some valuable insight into that, even without software just by having experience. And you’re able to maybe elaborate on that question even further. Then it comes time to actually building software to run surveys, let’s say with all of the employees. And what Dino has done is that he’s come up with a bunch of questions to ask these employees. But you need a way to actually get the answers, analyze them, present that information and make decisions. And that’s where custom software comes in. So you hire a vendor to build the survey software for you. And they go ahead and build it, and it works fine. But what you find is, after you’ve gathered all these results is that, oh, wow, there, there’s this hugely diverse skill set in a particular team in my company. And they’re not really focused on a particular area of the business. But we found that the teams that are very focused in a particular skill set or goal, tend to outperform those very diverse skill set teams, the employees themselves are excellent, they’re really, really good. But the structural organization of that team isn’t working, for whatever reason. So we need to move things around. So what we’re going to do now is create a new survey, to ask leaders of different teams, how diverse the skill sets are of the teams. Now, the software that you’ve created for the first survey, should be able to create a second survey and gather that information, analyze it and present that data as well. It shouldn’t just be a one survey tool. The challenge with that the perspective of building the software is that the data is different, it’s ultimately going to be different. And the first survey might have you don’t know what to do, at the beginning, exactly. a scatterplot might be the right tool to present the results of the first survey, but a pie chart might be better for the second. And ultimately, when you hire someone that has experience, both on the problem domain, so HR analytics, or on the software side, you’re effectively asking someone to align with you. It’s all about alignment, and aligning incentives. If we are able to answer your question and get value from the question and make informed decisions, it reflects really well on the people that you’re working with. Right. But if you’ve hired a vendor that’s going to try and say blow up the feature scope, right? And not think about this in terms of a framework, right? Because I think that was your original question. Do you know, what does it mean, to build a framework? The framework itself has to serve the question that’s being asked, it can’t be something where it’s like, Here’s 10,000 extra features that you probably don’t need. It’s like, Okay, you’ve you’ve determined through research and with your knowledge experience, that running surveys across the organization, to better understand your workforces skill set is the right way to move forward. So we’re going to build software that enables you to do that in a very flexible way.

Dino Zincarini: 12:37

Excellent. So framework, it when you said earlier, you know, we’re building unique solutions through custom development, the actual functionality is quite unique or specific to the problem. But the framework, the framework is more flexible. And that’s where it gets into the skill set of the partner that you trust that you’re building with, that they’ve done this before. They know how to do this. And if you’re hearing this company needs a survey tool, as you said, you know that there’s never just one survey. And you’re going to build a framework for the software such that even though the capabilities perhaps are limited and what the customer wants, right now, the framework allows for extension later if the customer decides they see value in that. And so you’re not rebuilding things over and over again, you have a flexible framework, a platform that you can evolve. Because the tooling that you put into it all this stuff, we said at the beginning around the evolution of technology and the you know, the the open source, availability of tech, all of that goes into a really strong framework that is flexible enough to to evolve for you. But you only get that when you ask for it. And you don’t have to pay for it all before you need it. I think that’s a great point. Awesome.

Dhruv Dang: 13:56

The other thing I’ll mention is, you know, we’ve often seen in the field that when once we built a piece of software for someone, and they use it as intended, they’ll start doing things outside the software that it just required as part of their jobs. And I’ll give you an example. We built procurement software for the BC government. And we found that people were running the procurements through the software that we built, but they were generating and writing reports in Word documents to provide to senior leadership. And that’s something that a lot of people do in their day to day work in large companies is writing reports providing it to senior leadership. And using the example that we were talking about earlier, that might be a requirement that comes from using the software

Dino Zincarini: 14:36

And you know it right away. Only when you start using it that you realize, wait a minute, there’s a administrative burden here that we didn’t anticipate

Dhruv Dang: 14:44

Exactly like running additional surveys and asking different people different questions and getting different data. I would say that’s going deeper into the problem domain. Whereas starting to present reports upwards is going horizontal. It’s going it’s a lateral step and building a framework that able to address both is quite useful. I think when people sort of expand the scope before they even build anything, they’re just thinking laterally, like, what are the features, we need that a sidestep, so we’re not going deeper into the problem domain. But it’s usually better to go deeper first. And that’s why it’s good to minimize the scope is because you’re saying, I don’t want to have this huge surface area of what I’m going to build, I just want to stay really small. And I want to give myself the choice six months from now, one year from now, to go deeper into what I’ve built, or to go lateral then, and I’m going to save money in the process.

Dino Zincarini: 15:35

So we don’t have videos, you can’t see that I’m smiling, but I’m smiling. And the reason is, because having worked in software, this, this exact phenomenon you’re describing has come up over and over again, which is you decide you want to build a capability, you start to build it, and you get the product out there, there’s a lot of pressure to go and build something new, some new features, some new capability that we didn’t have before, over the depth, go and finish what you’ve got. And I bet you a lot of our listeners can relate to this. We’ve all used software where you start working with it, you’re going with it. And then you just wish you could do that extra thing you wish you could go further. And that’s a symptom, I think of exactly what you’re describing that there’s a lot of pressure when you’re building a commercial product, to widen the scope of it, to appeal to more use cases, rather than to complete an individual use case and go really deep. And as a product manager, I felt that. And I think you’ve described it right there that there’s the reality is the value probably comes more from the depth, not from the breath. Let’s complete one thing before we start building in another three or four things because that adds to that bloat, it adds to the adoption overhead, it adds to the complexity and the maintenance, without necessarily delivering the value you originally intended. So that’s an important thing to keep in mind. So this is great. The idea here is that when you’re building software, you need to have that trusted partner that can help you think through these questions which are are healthy, even if you’re going to buy off the shelf, you need to know why you’re building this and why you’re buying it and, and who’s it for and the use cases for this so that you don’t get swayed too much by your vendors into consuming things you don’t necessarily need. You need those use cases. And so spend the time even if you’re buying off the shelf. But if you were to build, then that becomes a fundamental piece of the picture when you start to partner with a trusted partner to develop that software. And those experienced developers will build frameworks that allow for flexibility in the future at your pace, and your desire to consume as opposed to getting it all at once. As is the case with with most most enterprise vendors. And the good news there too is you don’t have to pay for it until you actually want it, which is a plus. And getting that scope narrowed. So that it makes it easier for you to deploy it to use it is so important. So all great points to consider exactly

Announcer: 17:57

Like what you hear so far? Make sure you never miss a show by clicking the subscribe button. Now. This podcast is made possible by Turetsky Consulting and listeners like you. Thank you for your support. Now back to the show.

Dino Zincarini: 18:15

I’d like to move now to the final question I have for you, which is more around value. I think I mentioned briefly earlier that really this is all about value and in delivering value. And I think a lot of enterprise software, I’m not sure if we always understand value, we understand price, who we get that we know exactly what it costs. But value is a more difficult concept to quantify. And so when we’re thinking about building versus buying, let’s talk a little bit about value. And I think this is one where I also find building might be at a disadvantage. When I buy software, I know what the price is. I negotiate that with a vendor, it’s very clear, they give me a price list. And that’s what I’m gonna pay. Usually with, you know, cloud solutions, it’s, it’s a subscription for several years, so I can lock in a price. I know I have predictability, finance loves that they’d like to see predictability on these costs. So how does that work in the build world where, you know, what if we started out with a framework, and that’s great, but how do you address that?

Dhruv Dang: 19:17

Yeah, that’s, that’s a another really good question. You know, I think it’s something that has plagued the software world since its inception. You know, software estimation is, I think, perennially out of reach for humans. It’s always been really difficult. And it’s, it’s very rarely goes to plan. I think perfectly. We are getting better at figuring out how to solve this problem. Like how can we estimate software in a way that works with business. So when you when you buy software, there’s usually like a subscription fee per person or based on your team size of feature set, which is really nice. That is really great for an accounting department. But when you’re building custom software, it’s a bit of a challenge, because a lot is unknown upfront for everyone involved, not just the customer, but also for the vendor. And the reason why is sort of related to what we just talked about, which is knowing what you want, you might be able to formulate a question. But turning that into a product, and being able to elaborate on that question, is a time consuming process, you know, and there’s a lot of knowledge and work that goes into that. So what we try to do to address this problem is say that, you know, we have this expert exploratory phase, and there’s a fixed cost for that. And I think a lot of other vendors do this as well. And it basically gives you an exit after that period, where if you find out okay, we now understand the problem really well, we know what we need to build, and this is how much it’s going to cost. Oh, no, it’s too much. Let’s not do it. And, you know, you pay the fee for the exploratory phase. And you move forward.

Dino Zincarini: 21:00

And as you said before, that exploratory phase is actually valuable. That’s where you discover the what and the why that could inform your purchase of an enterprise product. So it’s not necessarily throw away work.

Dhruv Dang: 21:12

Exactly. It isn’t throwaway work. And it’s because I think, you know, this is, I think, varies from person to person and organization, organization, I think knowledge is a highly valuable off balance sheet asset in any company. And in that phase, what you’re essentially doing is figuring out what the problems are in the company, and what one possible solution might be going the custom software route is just one solution of many. And, you know, we’ve talked a lot about it during the discussion. But the reality is, it’s one way to solve a problem. And I think it’s conventional thought has said that, it’s maybe the most time consuming, expensive way, but that’s not true. So I think that going through that exploratory phase is really useful. Whether or not you build or buy software, I think that should be done. And having a technical person there, like an architect, or an engineer that you trust is worthwhile. But it’s really about figuring out what do I actually need, you know, and putting a dollar amount on that because it is something you need to invest into. Beyond that, different companies approach it in different ways. And I’m just talking about vendors here. If you’re hiring engineers, this probably in some costume model that you use. But for external companies, there’s a service fee model where you’ll pay a monthly fee per person. And you’ll assume, or you can estimate that it would take six to nine months, say to build something, and you can figure out the cost from there. Other companies do a fixed price, and they they take on the risk of the software not being completed by the time that’s done. The challenge with that is you need to have a very strict scope in your contract. And that’s difficult to do, because you want to have the flexibility to adapt after three months, because time is also a tool in product development. You will know things in three months that you don’t know now, and you want to have the flexibility to adapt to that. So I think that you’re right. In building custom software, it is much harder to estimate the cost and forget the price of these projects. But it is all meaningful work. And there’s value created in the entire process.

Dino Zincarini: 23:20

And I think it’s important to think back as well to something you mentioned earlier around the scope, right. And that there, when you enter into a custom build situation, you want to limit the scope, it’s the natural part of the process. That limiting of scope means that when it comes time to deploy that software, to train everyone on how to use it, it’s now much easier, you’re not training people on a whole bunch of features, they’re never going to need or worse, tell them to ignore all these other things. Somebody’s going to click on the thing if it’s there, right. And so when we buy software off the shelf, and we know we’re going to get far more features than we actually need. Hopefully, we’ve done that assessment phase that you advocated for. So we know what we need. And we know that what we’re buying is way more than what we need, that does not come free, you’re going to pay for it. Because you’re buying the full product, you’re going to pay for it every year, because you’ve got a subscription, and you’ve got to deploy it. You’ve got to develop a training program for that. You’ve got to make sure that there aren’t barriers to adoption. And a barrier to adoption is being overwhelmed is looking at something and saying I don’t know where to start. How many people have used software where it’s a bunch of menu items, a bunch of buttons, a bunch of things and you just don’t even know where to go and you have to keep referring back to some training program you had to attend in order to know what to do. That’s all cost as well. So when we’re adopting enterprise software, do not ignore the adoption costs. There is yes the price that’s the easiest cost to understand. But the cost of rolling out of training, of keeping up with all of the new features that are gonna get pushed to you, that is all cost as well. And we don’t typically quantify that cost upfront, we just assume it’s the same, because we’re all we’re going to buy from a vendor. Yes, it’s going to be the same for all vendors. So we’re going to factor it in. But if you’re building it, it’s absolutely important to factor that in, I’m going to get just what I need when I need it. I don’t have to spend time rolling out and maintaining something that I don’t necessarily have to use, that dramatically improves the adoption. And all the software packages I’ve seen that have been deployed and ultimately failed, did not fail because the software wasn’t any good. They usually fail because of adoption. People just don’t want to use it. That’s why software projects hit the rocks or it takes too long, even enterprise software can take years to roll out, especially if there’s some customization involved, which obviously wouldn’t be the case with a build, because that’s built into the software itself. So these are things we need to factor in. And we’re looking at the decision beyond just the price, the sticker price.

Dhruv Dang: 26:07

Yeah, definitely. And I think, you know, you’ve summarized the total cost of ownership for both build or buy really well, in the sense that there is an ongoing costs with buying software that usually isn’t thought about upfront. And there’s this concept of vendor lock. And that is often overlooked as well, because the person you’re speaking to about a piece of software is usually a salesperson for that company. And when you think about HR analytics, it’s all about data. And if you can’t get your data out of a particular platform, you’re essentially locked in for a few extra years until you figure out how to get the data out or migrate to a new system. And that’s the challenge of buying software, you’re stuck with this ongoing cost. The benefit of it is that it’s a lower upfront fee, there’s usually a very minimal or non existent upfront fee, whereas building software will have a higher upfront cost, but a much lower ongoing cost. And let me give you an example of that. When you think about a 10,000 person organization, you might pay a $5 a month per person fee for software that you buy from a vendor, and that could be a really low monthly fee, depending on what’s available. And that ends up being $50,000 a month. Right for that fee, so $600,000 a year. And if you build custom software, let’s say the upfront cost is a million dollars. That’s how much you have to spend to build what it is you’re looking for, that serves 10,000 people in your company. Now, the software marketing materials, the dialogue has really taken place around the top 1% of software out there, you know doing things at scale, things that can serve billions of users and do insane things that we really wouldn’t expect. But one thing that we like to say real folk is like we build software for the 99%, which is the other applications that are totally normal in size that never hit that level of scale. And when you think about a 10,000 person company, you think that’s a large company. But in the software world, that’s a bread and butter piece of software. Once you build that software, if you decide that you don’t want to add any features to it, and it’s done, and it serves your company really, really well. And it serves this 10,000 users, you pay that, let’s say million dollar fee, right, and you just pay maintenance and administration costs. So that’s something usually around 20 to $200 a month for a piece of software that had size. And that’s just to keep it running internally inside your company behind a VPN. And I think that’s a really good example, because in two years already building custom software using those numbers has paid off financially. One of the other things I think you touched on that was very valuable. Dino was the non financial cost. And I think an example of that is training and change management. When you buy software, another product development team in another company has thought about how people should use this software. So whenever they sell their software to someone, there’s usually someone that’s going to train or onboard people and teach the users in their clients companies how to use the software. So there’s this work or this distance that needs to be traveled from the person who’s actually using software to do what the software can do for them. They need to actually put in this extra effort. When you build custom software. A large part of the work that’s done is research. And what that is, is effectively interviewing your team and the people that are using these tools to figure out how they work on a day to day basis. What happens when you come into the office or signing on online at home? What are you actually doing? What emails are you sending periodically in a daily basis what can be automated, so when you’re building custom software, the distance to travel for training is much Smaller,

Dino Zincarini: 30:01

Right, your partner knows you as well, as you know, you probably,

Dhruv Dang: 30:05

Exactly as a software is going to fit your team much better than something you buy, because what you buy has to fit a huge variety of people, his entire spectrum of personalities and work styles. Whereas when you build custom software for one company, and let’s say it serves a 10,000 person company, but maybe the HR team has 10 people, and those 10, people are going to be using that software every single day. And it’s either going to be a really good experience or really bad experience. Right. And that research phase is what helps lower the the non financial cost of ownership of custom software, right,

Dino Zincarini: 30:40

I’m smiling and shaking my head because I’m thinking of a couple of things. And one is that most enterprise software, as you alluded to, is priced based on the size of the company, not how many people are using it. And so you’re going to pay more, the bigger you are you pay per employee, if they log in once a year, you’re paying the same price as if they logged in every day. And that may or may not work for you, right, you’re paying based essentially on the capability of your company to pay, that’s when, when you’re priced based on the size of the number of your employees, what’s really happening here is a vendor is pricing their product to scale with how much money your company has, which is the perfect pricing, right, everybody pays more if they have more money, what that’s great from the vendor side, right? That’s great from from the customer side, I’m also smiling because in a previous life, I used to work for an enterprise software company. And we had a lot of customers in Europe, and this was before the cloud. So in the ancient before times, but back when you had to actually install and run software yourself, you know, you had to keep getting these updates from the vendor, and you had to update all your software, and you paid maintenance every year. And we started to get a lot of customers, especially in Europe that didn’t want to pay maintenance anymore. And their argument was, I don’t want the innovation. I don’t want all the new stuff you’re pushing, I just want your software to do what I bought it to do. And it does that it does it great. I don’t need all the new stuff you’re building. And therefore I don’t shouldn’t have to pay 20 or 30% maintenance every year, if all you have to do is fix what I’ve got, I should be able to pay to just have somebody fix something, and, frankly, it’s your software, it shouldn’t be broken in the first place. So you know, why do I have to contain this money for you to build more features that I don’t. And now that we’re in the cloud world, that you don’t even have the option to opt out, right, you’re gonna get those new features, there is nothing installed, you can’t say I don’t need to have all of this stuff, I want to pay less, you’re going to get it whether you want it or not. And you’re going to pay the annual amount that you contracted for, whether you use those features or you don’t. And so I think this this pricing idea on this value idea is really important that when you build it yourself, you get what you need. And that’s it. And those nine, price costs, those, you know, the training, the adoption, all that stuff also has to be factored in. But it’s a whole philosophy change and a mentality change. When you look at this equation, to look beyond just the price on the invoice, you really have to think of all these other factors that maybe we don’t think about because it’s been so long, that we’ve just been buying software the same way we don’t really question these things. And I think that was the point of this podcast was to really have people question a little bit. It doesn’t mean that necessarily everybody’s going to build all their software, all of a sudden, sometimes you just need a hammer, and there’s one on the shelf, and I’m going to buy one. But it’s important to know the process of thinking that leads you to that choice, and why you’re making that choice. Because there are alternatives that might make sense. Yeah. All right. I think we’ve, we’ve used up quite a bit of time, this has been a great conversation and just like we determined the dog park every day true, we end up talking a lot or better. I better wrap this one up. But we we made some really great points here. We I love this discussion. You know, the whole idea of why is building software even a question. Now, when it hasn’t been for so long. The idea that the technology has changed, that the skill sets of our workers and our employees not only to build software, but also to to use it has increased dramatically. And that the sophistication and the tooling available to people like you who build the software is orders of magnitude better than what it was even just a couple of years ago. And that means you can build software faster and with more flexibility now than you ever could in the past and and that de-risks the proposition to our customers. And then we talked about the potential pitfalls, especially a customer not knowing exactly what they want. And how do they get around that, and the idea that investing in understanding exactly what you want and why you want it and for whom is a valuable exercise to do, regardless of whether you’re building or buying. And that that’s a key phase when you build, at least when you partner with a company like yours. And that that work to understand the reasoning is valuable, and carries you through the whole project, even if you end up buying something off the shelf. And that that’s how ultimately, you ensure that the software that’s built is what is needed by the customer. And then of course, the cost considerations that we’re just looking at that there’s so much more than just what’s on the invoice that you should consider, including all of the extra stuff you’re going to be paying for that you may not need, the complexity of adopting and maintaining that and whether you really get value for all that work, when you really get the value for all that innovation, or is it just extra stuff you’re going to have to manage later, the ability to choose how much innovation you want to consume, and pay only for what you want to consume is a powerful concept. So I think that sums up most of it. Was there anything I missed that you wanted to throw in? Before we wrap up?

Dhruv Dang: 36:09

No. Awesome. That was wonderful. Thank you for having me. It’s this.

Dino Zincarini: 36:15

This was a lot of a lot of fun. And obviously, with people want to find you, you’re on LinkedIn, I assume under Dhruv Dang, you can see obviously, the name is here on the podcast. Real folk is the name of the company. Obviously check that out as well. And I think drove it’s pretty safe to say you’d love to continue the conversation if anyone wants to reach out and talk more about some of these concepts.

Dhruv Dang: 36:41

Certainly, I would love to and I’ll share my email with Dino too, include if that’s easier for people,

Dino Zincarini: 36:47

Yeah, we’ll put it into the podcast information so people can easily find you and talk to you about other stories around how you acclimated to North America. Whether there’s there were more hiccups than just understanding what catch up what’s Yeah, but thanks again for joining. And thanks to all of you for listening. I hope you enjoyed this podcast and we’d love to hear your ideas for future ones. Thanks a lot everyone.

Announcer: 37:11

That was HR data labs, please visit Turetsky consulting.com forward slash podcast to review the show. add comments about this episode, or add new ideas about upcoming shows you’d like to hear. Feel free to be creative. But please be nice. Thank you for joining us this week on the HR data labs podcast and stay tuned for our next episode. Stay safe.