Adding Software to Your Consulting Firm's Offerings

Speaker A: Hi, and welcome to the crackerjack Consulting Podcast. I'm David A. Fields, and today we're going to be talking about an approach or strategy that I've seen more and more consulting firms playing with, and that is incorporating some sort of technology or software solution into their offering. And the guest I have today to explore that topic is Pete Hemsheld, who's CEO of Dialys. Dialys offers advice and competitive intelligence to pharmaceutical and biotech companies. Pete, I'm really looking forward to diving into the topic at hand, so thanks for joining me on the show.

Speaker B: David, it's great to speak to you today.

Speaker A: Excellent. You and I have talked before, so. And I'm obviously very familiar with dialysis. But before we dive deep into the topic at hand, maybe it would be helpful for listeners and if you just described a little bit about dialysis, how long the firm has been around, roughly how large the firm is, that sort of thing.

Speaker B: Sure, absolutely. So dialysis has been around for about 15 years. We set up in the UK in London, and now we have offices in the US in Los Angeles, in New York, in Tokyo and Shanghai. We've got just under, uh, 100 people. We specialize in life sciences. With a heritage in competitive intelligence.

Speaker A: Exactly. So that's excellent. Thank you for that background. I'm very familiar with dialysis since we've had opportunities to work together over the years. And one of the really interesting, I think, steps you've made or decisions you'd made was to go down this route of bringing in some sort of software platform or perhaps creating some sort of software platform that you could then offer as a complement to your consulting services. And, um, like I said, so many consulting firms are doing this now for almost every single day. I'm talking with a client about this idea and about this strategy. And so it'd be great to get your perspective. Pete, maybe we can even back up and just in this topic to the beginning, why did you decide to pursue this approach? I mean, what was the impetus? And then maybe we can jump into what you've developed. But I mean, why did you even go down this route of creating software or some sort of technology solution?

Speaker B: You can't start with we have to create software, or I think it's a good idea to try and jump on the digital bandwagon. You really have to always start with the clients. What are you trying to do for the client? I always talk about client centricity rather than client focus. So there's no point pushing your clients to buy from you, buy your products or services, you have to listen to the client and solve their particular challenges. So for us, and this is, I mean I've sort of created or introduced technology, uh, as a solution in my consultancies for uh, the last decade or so. And it's really using technology, having software really should be just seen as another skill set that can be either you have in house or you acquire. But I mean, to answer your particular question, in our line of business we and our clients deal with a lot of information, a lot of data. And our clients look to us to acquire and to analyze this information in order to answer a strategic question or hypothesis. And it's not news to say that the pharma industry has been behind other sectors when it comes to the digital evolution. The sector still runs predominantly in analog. Information sharing is still mainly via meetings, emails and phone calls. And what we realized was that our clients were overwhelmed with information. And this intelligence was housed in multiple places, emails, meeting minutes, various folders and things. And even to a point where if one client's left or moved positions, there was often a significant information gap for the new client due to the various places data was kept and relevant information intelligence sharing across teams was often limited. So that was really the need. We saw the challenge that our clients had and we started off to be honest, with thinking internally how do we best serve our clients by creating something almost in parallel to our consultancy projects that would help us and our clients really synthesize and um, collate the data in the most effective way. And we've done this over the course of a few months, I guess a year or so. We've created a platform using our clients knowledge and um, understanding to really help them with this.

Speaker A: So got it. So uh, and of course being right side up, being client focused is central uh, to everything that we do with our clients. And so you started with this need, you saw that there was all this information and it was hard to access. As you decided, you know what, maybe we need to solve that problem. Was there any concern that developing a, uh, software platform. It sounds like that's what you did. You developed a software solution to make it easier to access all of this information, is that right? So first let me check in on that.

Speaker B: Yeah, I mean if I quickly give the sort of the spiel, we created a platform where information is curated in one place, easily searchable and accessible deliverables. So presentations, etc. Tagged to enable filtering by topic communications are streamlined through the system, linked to key topics and curated to our clients needs. Information and intelligence is Integrated more closely into student decision making and nearer, uh, real time access to, uh, insights allows our clients regular updates and helps to accelerate the feedback cycle.

Speaker A: Okay, so got it. So if you're giving your clients faster access to information, they can get the insights they need, they can pull what they need, they can automatically grab presentations. I've seen folks, you know, some of these platforms that will actually create draft presentations from insights. Did you have any concern and, um, you know, did you have any concern and do you have any concern that the software could squeeze out the need for consulting? Could it actually somehow suppress the consulting side, the advisory side of the business? Is that a concern? If so, why? If not, why? I mean, sort of how did those two pieces mesh?

Speaker B: Yeah, no, it's a really good point. I think you always have to think, uh, about what are you, are you cannibalizing your own market and what's best for your client? And we certainly don't want to turn into a tech company. You know, we are a consultancy providing our clients with solutions in some of those tech solutions. And so the key for us was to, again, to look at how our clients, what our clients need, what our clients sort of challenges are, and how do we resolve this, both using our consulting, but also our, uh, capabilities in tech. So it really goes hand in hand. We leverage. I like to think of tech as leveraging what we do. So we're giving our clients a better quality service, but we're not cannibalizing our own business. We might be able to do it with a higher degree of quality, less risk of errors, but we're able to then focus our clients on giving that consulting support, which is sometimes restricted if a lot of the other elements that the tech side is now able to do would otherwise not cover. So to me, it's given a higher quality, deliverable and engagement to our clients.

Speaker A: Okay, so it's enabled you to do more. Let me just push again, just sort of push slightly because you said there's always this risk, this concern. So did you have a concern that this might squeeze out or crowd out some of the need for your advisory services? And has that come to pass? Or have you actually found that it's increased the demand for your advisory services? Or maybe neither, it's just kept it the same. But, uh, you've been able to increase the quality, as you say, it certainly increased the quality.

Speaker B: One great thing about having our clients use our platform, it's actually opened us up to more client stakeholders, which is the great thing. So having our own product, our own platform within the client business has allowed other stakeholders to see our platform and see what we do. So we've actually brought in, introduced dialys to other stakeholders within client businesses. So I actually think it gives you better penetration to clients and they can see that. I think the key is you go in again. We talked about client centricity versus client focus. You don't go in with a product. You go in and talk to the clients about their challenge and their solution. And part of that is solved by inputting or uh, creating the tech side. The key for me, and one of my concerns, when I started this again a decade or so ago, trying to think about could we create a tech solution, My big worry was how would we fare against large tech companies. And what I realized was the clients are going for us because of our domain expertise. So that is key. So it really is. Our, uh, solutions are driven by our domain expertise. And if anything we're creating something that our consulting, it can help leverage our consulting.

Speaker A: Okay, so that makes a lot of sense and it's certainly absolutely consistent with everything that we've seen and I think you and I have probably both seen across our consulting lives, which is that clients look for domain expertise, right? That's why they tend to look for experts in their industry, experts in their particular kind of business. So that makes sense at the same time. So you brought up something, you wondered how you were going to fare against technology firms, against software firms and consulting firms. And software firms are fundamentally different in their structure, in how they sell, in the financial underpinnings of them. So what was it like to create this inside a consulting firm? I mean, since they're really fundamentally different businesses, what kind of strain has it put on the consulting business to build software inside of it?

Speaker B: It's a really good point actually. And you have to be very careful this doesn't become a distraction. And there's actually lots of elements to that. So there is the fundamental principle that some consultant individuals, some consultants don't see themselves as pushing products onto, um, clients. They see themselves as solution orientated. So actually having consultants sell or talk to our clients around tech solutions has been a sort of change management situation. We've had to explain to our consultants how this is part of the solution. So it's not just the financials, it's actually change management that you have to think about. In terms of the financials. It really depends on how you're setting up the tech side of the business because you can do this in many different ways. In my past, we've subcontracted with tech experts to provide the tech side. In other businesses we've had that organically, it depends on the tech as well. So, uh, I'll give you some do's and don'ts. Very briefly on this. Irrespective of whether you bring in the tech expertise in house or you partner, the key is the software engineers. The tech team have to have a seat at the table with the client. If you are, uh, too hands off, if they're your back office staff, then something will go wrong. And I've learned from mistake in a very early part of my career where I effectively felt that I needed to be the face to the client, the project manager and coordinating things behind the scenes. So you have to really, you have to make sure that irrespective of whether they're part of your business or subcontracting, they are still the face will uh, have face time with the clients. So obviously you have that sort of domain where you're working with a partner and then from a financials perspective it's fairly straightforward. The second piece, if you're providing bespoke solutions, tech solutions, and again I've got some examples in my past where you're creating a tech solution for a particular client, then the financials are quite similar to the financials, uh, in a consultancy. The third one is where you have more subscription style. So it's a build one sell many model. And that's where you do have to be very careful. And that's where a split P and L effectively is something very much to consider. Effectively you treat them as almost separate businesses because to your point, a leverage in consultancy actually might be the exact opposite in a tech firm. And so you do have to have a fairly clear distinction there. And so again, taking examples from my past, I've certainly had split P and ls where you can therefore use the consulting versus the tech dynamics. But it really depends on the structure of your business and the relationship and the actual product and the relationship you have with the tech teams.

Speaker A: All right, interesting. Okay, so that's super interesting, the idea of a split PL and separating the consulting P and L, which can look quite different as you said, especially if you're trying to create a platform that's not a bespoke solution, which is kind of interesting because if you're constantly creating bespoke solutions, then you're becoming a bit of a hybrid between a consulting firm and like an app development or software development firm, which is, which is again, uh, a different beast entirely. And most of the consulting firms that I interact with, they're not trying to do that. What they're trying to do, I think is closer to what you've done, which is come up with some sort of platform or software which could either be subscription or it could be a tool that's part of their delivery, but it stays relatively constant. You're not creating something new every time. So I think that's probably a little bit closer. And you touched on development a little bit. Uh, my experience with clients has been developing these types of platforms. Developing this sort of software is very hard and can cost hundreds of thousands of dollars or millions of dollars. So what's been your experience with that? And how do you make sure that this investment, which could be quite substantial, is likely to succeed?

Speaker B: So I've probably learned from mistake here in my decade of working with tech, with consulting. And I've seen this, um, happen in other companies as well. So the first thing, I mean, it's probably a catchphrase. I mean, you actually, I'm going to steal one of your, um, phrases you mentioned to me. Clients, shoes.

Speaker A: Right, right. It's not about your shoes, it's about their feet. That one.

Speaker B: I'm so glad that you remembered your, uh, quote. Not even paraphrasing, but messing up. But I think that is so true here. I've seen consultancies with great ideas thinking, this is going to sell, this is perfect. I think this is a great idea. And they spend a lot of time, a lot of effort, a lot of money into developing something that then they try and sell. And again, this is really going to push them out. They think that they've come up with a solution from the clients and they may have had some light conversations with clients to get their interest, and then they create a fully fledged solution and then they can't sell it either it's a great idea, but there's just no interest in paying for it, or the price is just not where it needs to be. So you have to partner with clients when you're developing those, in my experience. So test, test and test again. And the great thing about working in a consultancy versus a tech company is you're working with your clients daily, you're innovating with your clients daily. And so the interaction will allow you to create something that you really know is going to benefit the client and you have to do beta testing. So you very much have to create a minimum viable product and work with your very close clients to expand on that and create it. If you don't do that, you absolutely can throw money at, uh, these things overly invest. Hope, I don't choose that word lightly. A lot of this is hopefully that there is a market and then you suddenly realize there really isn't. The other risk or pitfall is actually focusing too much on what an individual client wants and accidentally creating something very bespoke. You didn't know this at the time, but very bespoke for a particular client need. And then if you try and sell it to another client, you realize you have to tweak it to meet their needs. And then you're ending up continuously tweaking something so that it serves every client perfectly. And again, that in terms of the investment cost, in terms of the build cost just runs away with itself. So you really have to test and really feel like the clients, your vested clients, are partners with you and part of the journey of development. So that when you do have something that is, um, sellable, you've got confidence that there is a market and then you have to continuously evolve the service or the offering.

Speaker A: Okay, so now you've just triggered a whole bunch of questions in here. You're developing this with your clients, so. Right. And it sounds like the idea is you want to co develop with multiple clients. So a few questions on that one. How many, how many becomes too many? One, uh, is too few because you could end up being too focused. What I'm hearing from you is you could become too focused on one client and then you, what you have is a, is a perfectly tailored product to that one client, which may not be a, uh, good fit for anyone else. So how many clients do they pay you to develop this software? So are you making this sort of paid development, which is a nice place to be, or do you give some sort of discount versus what you would eventually charge for this platform? And how do you engage clients in this idea that you're going to eat up a lot of their time and energy building something, going through beta versions that are not quite right. So I just dropped a whole lot of questions on you and take them in any order and I'm happy to repeat them.

Speaker B: Yeah, I think in terms of sort of partnering with your clients there, the number, I mean it varies to be honest. You certainly want to have, you know, sort of two or three. So you've got a fairly, you know, you're getting a spectrum of thoughts and perception so that you're not, again, you're not biasing yourself to one particular client. The other thing is if they've come to you with this need and you say you've been very transparent with them and say, yes, we want to partner with you, we want to create this for you. If it very much looks like it's going to be one that you can sell on, then obviously you can't ask for the full price. But often you can still charge the client because they will be getting something back, but you very much have a discount. It depends how close you are with the client. I mean, sometimes you get clients who have a personal interest in what you're doing because you're creating something that will improve the sector or the field that they're in and so they have a vested interest and a genuine interest in helping you develop it. So it depends. I mean, it really depends on the product. The client, um, well, yeah, the product and the client really, you certainly can't charge full price if they're helping to develop it. And one thing is, if you are creating a minimum viable product and you're speaking to multiple clients about what this will be and what this will look like, and then when you introduce the minimum viable product, you get their feedback and they say, this is great, but I'd like it to be slightly different. This is great, but the user face doesn't quite work for me. This is great, but can you include this particular additional design piece? Then you start to, um, create different versions. And this is where even though they are truly your clients and they feel like they're paying for a service, you listen to them, you change it because of what they say and then you go back and say, hey, we've made the changes because of your needs or the challenges you had with it and we've created something slightly different. And um, if you then charge new clients more a premium because it's a better product, you can still keep the original price with the co developer effectively. And sometimes it's not necessarily a co developer, it's a client who's giving you honest and transparent feedback and understands that they're part of the development journey.

Speaker A: Uh, just again, so I'm clear, are you suggesting. So if you do this with two or three different clients and client A says, you know what, what we need more than anything is A, we need a home screen with, you know, with a dashboard on it. And client B says, you know what? More than anything, I wish there was not this home screen with a dashboard. It's in the way. First, uh, of all, do you encounter that kind of diametrically opposed feedback sometimes. And then are you trying to create slightly customized versions for each client or are you trying still to get to a common offering that will please not, you know, maybe not overjoy, delight, it's perfect. But please most of your clients, that's

Speaker B: a really great example. So when that does happen, and it does happen, that's when you know you need to do some more market research. So you've got two very, very conflicting requests and say, what does the market look like? Who is the anomaly? Uh, where's the market looking? If you do have that and you want to go one way, but one of the clients is very strongly suggesting that you should go the other way, you can talk to them about a bespoke solution for them in particular and how much that would cost. And often to your point, it will cost them a lot to have a bespoke solution that otherwise would be a subscription, um, for everyone. So you can have that open conversation with the client and say, how willing are you to pay for this? Because this is what we have, this is what we sell. If you want something particularly different, almost not completely different, but with a different user face, it will cost you this. Would you be willing to pay for this change? And depending on the client, typically they'll say, well, actually it was kind of nice to have. Um, I didn't understand that it would cost that much. Completely understand. And they usually go with it. If they then walk away and you can't afford to make the change and they're not willing to pay for that because it's a bespoke thing, then the client walks away and you have to be comfortable with that. But any feedback against what you've done should trigger some more market research to see is this an anomaly or is this actually. Have we missed something in what our clients are looking for? So it's a really good thing. And I think, to be honest, I've got an example in my head where company, um, quite close to me in the past did exactly that. Would speak to one client, would make a change because of them, would speak to another client, would make a change because of, and ended up having this pretty amazing product. But it was not commercially viable because of the cost to continuously maintain the changes. And so you have to be very careful. You always have to have a commercial hat on. You can't do the. If we build it, they will come. I think the problem with the company I've got in my head was that they honestly thought they created this amazing product because they got so many inputs from so many clients and everyone seemed very pleased with it and then they tried to sell it on and People just weren't willing to pay for what it would cost to maintain it. So you have to have that hat on and be comfortable to say, you know, no, if you want this change, it's going to cost you to effectively have it as a bespoke solution.

Speaker A: Okay, got it, got it. So that's super helpful. A couple of things I'm taking away from that is one, this is really about co development. It's about collaborative development with your clients. Never you alone as a consulting firm in your back room developing something. You have to do this with your clients and you have to, uh, whatever you're developing, make sure you're developing it with broad commercialization in mind. Not kind of one off, one off, one off, which is just incredibly expensive to develop and to maintain. This is going to, then point me to, I'm going to, uh, to close this out by asking you for kind of three sets of advice. The first set of advice is, let's say you were talking to another consulting firm leader. They're similar size to dialysis, perhaps, and they say, pete, you know, we're thinking about developing a software platform much like you have for our clients. What are the two or three or four things you would say? Make sure you consider this before you decide to go down the route of developing a technology offering in your consulting firm. What would those two or three considerations be?

Speaker B: So the first one would be, is this just a one off? Is this one client asking for something that really is exactly that one off? So you would absolutely pressure test the market to see if there, uh, is a market, there is an opportunity. And the second one is, are you willing to fundamentally change your business and have this as an, um, additional tool that will spark, um, different decisions around partnering with a tech company or bringing something in house? So you really have to truly answer those two questions.

Speaker A: Okay, got it. So those are two excellent questions. One is, does the market really want this? And two, are you willing to become a different kind of company? Okay, outstanding. So let's say we've made this decision and we're going to go down this route. So again, you're talking with the consulting firm leader. They've said, I've realized, I've done some market research. This is a big need and we're willing to change who we are. So Pete, I'll wrap the last two things actually into one. If there were one or two ideas that either keep us away from landmines or allow us to be successful with this, what would those one or two ideas be?

Speaker B: Yeah, I think that's fair. The other one, which isn't necessarily you must do or you must not, don't do this, but it's more almost the holy grail is if you create something that you can use internally, if you create something that is making you more efficient, allows you to give a better service to clients, then it's almost the holy grail because if clients aren't buying it for their own use, so you're effectively, your team can use it. And if that gives either an efficiency saving or creates a better quality service to your clients, it's a win, win.

Speaker A: Okay, got it. I have another question for you, and then I'll let you go. You've been incredibly generous. Here's my question, which is what you're talking about. Do you develop kind of a platform? Some folks are developing apps, they're developing, uh, online products or whatever. This can be a really significant investment. And if you're willing to share, not necessarily the absolute dollars, but what percentage of either revenue or ebitda, uh, were you willing to invest to achieve this? I think a lot of people just sort of want some idea of, well, should I be willing to give up all my EBITDA for two years or should I invest 25% of it? You know, is it 10% of revenue? Any guideline, at least from your experience, I think would be really helpful to a lot of listeners.

Speaker B: It's a good question. Because you're developing something, you have to remember it doesn't always hit the ebitda. Sometimes it drops below that, um, because it's a capital expense in terms of percentage, certainly we haven't spent more than 3% of revenues, and that's the top. You have to keep it, uh, reasonably sensible. But you have to invest, obviously, you have to invest for the return on investment. The key for us is, and this is really important, the key for us is create a business plan, have key milestones, and be comfortable and willing to sunset an idea, an investment, if it becomes unwielding. So cut your losses if it becomes unwielding.

Speaker A: And have you ever had to do that? Have you actually invested, spent some time, maybe it was months or years on a product and said, you know what? It's not hitting our metrics. This isn't working. We need to cut our losses.

Speaker B: Yes, yes. In a previous life, in a previous company. Well, it wasn't years. It was probably in a matter of months, but it was about a year's work that effectively we ended up sunsetting the idea. And you have to put business bets on. But the key is it's not your baby. It's a commercially viable product. And if you feel if the business case goes the wrong way, if it becomes unviable, then you have to let it go.

Speaker A: Excellent. That is good advice. In so many facets of consulting. Not just creating technology, but just building your firm in general. The idea of placing bets and also knowing when to walk away from those bets. I love that. We'll wrap it up there. You have been so incredibly generous, uh, and really interesting. So I appreciate your willingness to share today.

Speaker B: Always a pleasure to speak to you, David.

Speaker A: Pete, if people want to get in touch with you, if you're willing or learn more about dialysis or anything like that. Where should they go? I'll capture stuff in the show notes, but where should they reach out?

Speaker B: You can catch me directly via email or LinkedIn or you can, if you go to the website, you can have, uh, our contact details there.

Speaker A: That is perfect. Excellent. Again, thank you so much for joining me today. This was great learning for me and I look forward to our next conversation.

Speaker B: Take care, David.

Speaker A: Thank you. Take care.

Speaker C: The crackerjack Consulting podcast is produced by the David A. Fields Consulting Group, where you'll find everything you need to build a more successful consulting firm. We'd love to get your feedback and hear about any consulting firm leaders you think we should have on the show. If you'd like to appear on the show or know someone whose insights would be helpful to others in the consulting industry, please send us an email@infoavidafields.com that's infoavidafields.com. let a friend know about the show and don't forget to leave a review on itunes or Google Play. And if you subscribe, you'll be notified about every new episode. Tune in for our next podcast, which is very special. If you listen to it backwards, you'll hear a secret message about one of the beetles for those listeners. Born after 1980, the beetles were little insects manufactured by Volkswagen and played by Michael Keaton in the documentary movie Beetlejuice. I recommend just listening to the podcast the normal way. At any rate. I'm, um, Robin Epstein and our host is David A. Fields. Thanks for listening.