Reevaluating the Role of Industry Expertise: Tradeoffs Between Specialization and Adaptation

Rob Collie (00:00): Hello, friends. I'm really excited about today's episode because I am going to be answering a question from one of you, from a listener, and it's actually not just one question because it ultimately spawned kind of a cluster of questions from listeners, and I have a cluster of answers, so buckle up. First, a quick plug for our LinkedIn group. This question came from the Raw Data by P3 Adaptive Steering Committee group on LinkedIn. If you'd like to join that, you can search for Raw Data by P3 on LinkedIn. You'll find the group asked to be added, and we'll add you, and then someday maybe we'll be answering one of your questions. So today's question originally comes from Zach, and the high-level question he asked is essentially, "What is the value of domain expertise in analytics and AI?" Now, he then went on to clarify that his question is mostly one about industry expertise, oil and gas exploration in his case.

(00:56): But I'm super glad that he originally formulated the question with the word domain expertise instead of industry, because I'm going to make a distinction between the two. Zach runs a consultancy that's focused on a specific industry, oil and gas, and our consultancy at P3 serves basically every industry. For example, should Zach's company switch to be like P3 and address every industry, or should P3 switch and become industry-specific? And the answers, in the end, are no and no. And, of course, I'm going to explain why both questions end in no. As a little preview, in the end, I conclude that industry experience is actually super important, but it's also not a large obstacle. In other words, it's actually really easy to acquire most of the industry experience that you need. You can acquire it very, very quickly, with a couple of important caveats that ultimately explain why these two business models make sense.

(01:56): Zach's industry-specific business model and P3's industry-agnostic business model. The reason why those two business models make sense in parallel is because of the caveats, not because of the core. I also reached some conclusions about domain expertise that I'll get to as well. But first, let's talk about industry expertise. What is industry expertise? If you know a particular industry, what does that really mean? What is it that you know? Now, it turns out... This is a question that I'd never explicitly asked myself. So, as simple as the question sounds, I actually found this exercise to be surprisingly valuable and interesting. So let's take an inventory of what it means to have industry expertise. So, if you're an industry expert, first of all, you know the jargon. For instance, if you work in the hedge fund industry that AUM means assets under management. And if you work in finance and accounting or mergers and acquisition, you know that EBITDA means earnings before interest, taxes, depreciation, and amortization.

(02:58): Now, of course, knowing what those two acronyms stand for and even their definitions really isn't the important thing. The important thing is knowing what those concepts mean as well as their implications. Going back to AUM, assets under management, it's the size of the fund. How much money have people in total put into that fund? And so a bigger number for AUM is kind of a measuring stick of clout, right? It's a bigger deal with more influence, and there's a certain prestige associated with large AUM figures, right? But at the same time, the larger a fund gets, especially when they become mainstream massive funds, there's a certain flexibility that is lost. They're not as maneuverable once they reach a certain size. And this is why sometimes you'll hear of funds closing themselves to new investment because they don't want to lose that flexibility that comes with being a little bit more nimble.

(03:55): So understanding implications like that is a lot more valuable than just knowing what AUM stands for or what its precise definition is. And the other example, EBITDA is a bit of a cleaner way to look at profitability of a company because those other things that it says its earnings before these other things, interest, taxes, depreciation, amortization, those four things can distort how profitable a company's operations really are. So, EBITDA is a way to look at profitability without those distortions, it's sometimes considered a more clean and honest view of a company's profitability than its actual profitability. Now, continuing with that example, there's a huge difference between knowing what the jargon and the concepts behind it, knowing what that means versus not knowing what that means. Imagine sitting in a business meeting where someone says, "Company X has great bottom-line profitability," but EBITDA doesn't look so good, and you don't know what EBITDA means.

(04:58): That meeting might move on in a heartbeat because everyone else in the room will hear that analysis of company X, and immediately they'll know a lot of unspoken information about company X, and they'll all likely be forming very similar opinions in their heads without there being any coordination, any verbal coordination of those opinions. They're going to be on the same page. And you are going to be hopelessly lost. Now, that will, of course, be a huge barrier to your success if you're trying to help that group achieve better business success with their data. Crucially, that barrier is not high. In business, I've yet to encounter any concept or jargon that can't be explained simply. Basically have a 100% batting average absorbing and understanding industry concepts as long as I can ask questions and the person I'm asking questions of is even like a halfway decent communicator.

(05:56): Now, by contrast, I have a bit of a hobby of occasionally reading articles about or watching videos about mathematical or physics-level concepts. And as interested as I am in those things, I have a very, very poor track record coming away from those things, understanding what was actually communicated. Just this morning, I was watching a video about Heisenberg uncertainty in physics and how that relates to wave frequencies and timeframes and all of that, and I mostly came away like scratching my head. It's not like that in the business world, in most cases, everything in the business world ultimately... And very quickly boils down to money in versus money out, and it's just different flavors and variations on that. And understanding what this concept means, EBITDA or AUM, or whatever, right? The decoder ring is not difficult to acquire, particularly if you have access to someone who knows the industry.

(06:59): So what else do you know if you happen to know an industry particularly well? The second thing I thought of here is really just kind of a follow-on extension to the idea of jargon and concepts, which is, if you know an industry, you also know the kinds of problems that that industry typically deals with and the kinds of activities that it's often involved with. So if you work in the oil and gas exploration industry, like Zach does, for instance, for example, that there's a lifespan, a life cycle to an oil well or a gas well, assuming that you're confident that you found oil or gas in a specific location, it still takes a certain amount of time and money to build and activate a well. You have to invest upfront. Now, once the well starts producing from the beginning is producing at its peak capacity, the reservoir you're tapping into is most full. It's under the most pressure at that moment, and so you're going to be getting the most out of it early in its productive lifetime.

(08:02): Over time, as you drink that milkshake in the... There will be blood metaphor, the well becomes less productive. There's a curve to it, like a decay curve, and eventually there's this breakeven point where the well isn't producing enough to sort of justify or offset its own operation costs. And eventually you shut it down, but you make your money between the time that the well starts and, then, the time that the well is shut down. So if you've got a portfolio of a bunch of existing wells and they've all got different ages and they're all tapped into different types of reservoirs, and then you also have in your portfolio a bunch of wells under construction that are at different points in their construction, they're going to come online at different times.

(08:45): Naturally, you're going to want to know what your company's overall cashflow is going to look like three months from now, nine months from now, 18 months from now. And so this is a very common modeling problem in that industry. And also, because what you're producing is a commodity, you're also going to probably be playing a lot of what-if analysis about different future oil prices. So if another pandemic hits, for instance, and demand absolutely craters, and the price plunges, and now you're literally having to pay people to store just to take the crude from you because you can't shut the wells down without making them difficult to restart. Well, that's a scenario that you're going to need to model for and plan for as best as you can, right? On the flip side, of course, if the Houthis managed to sink an oil tanker in the Red Sea and shut down the Red Sea, oh wait, this is kind of already happening, isn't it? What's that going to do to prices? It's going to send them the other way. Maybe you want to include that in your best and worst-case scenarios as well.

(09:50): So knowledge of problems and activities like that. Again, super important. That is no harder to acquire really than concepts like EBITDA. Some of you are listening and hearing some of these concepts explained for the very first time and going, "Oh, that's what that means." Now it's not like I've taught you everything about those industries or about even those particular concepts, but you see how quick it is to transmit information like that. It's not difficult. I'm going to stop here for a moment and say, "Hey Zach, are you impressed? My oil and gas industry knowledge?" Well, P3 definitely has active clients like in the oil and gas industry, like we do basically in every industry.

(10:32): But the only reason I know anything about the oil and gas industry is because of a client that I had in 2012 when the company was just me, and I had to absorb things like that in order to be useful to that client. It didn't take long to absorb it. It wasn't rocket science, and it was interesting. So, I've retained some reasonable percentage of it 12 years later. All right, so let's take stock these first two classes of industry knowledge. On the one hand, jargon and concepts, and on the other hand, common problems and workflows. Again, super important, both of them, but easy to acquire if you have the right kind of spongy brain. As I said, nothing like trying to learn quantum physics or general relativity. It's really mostly a matter of whether you enjoy learning such things, which, to be fair, not everyone does, but you definitely don't have to be Einstein.

(11:24): Now that's sponginess is a requirement for working at P3, which I'll get to you later. Let's stop and ask ourselves, "Should Zach be scared? Is P3 going to come, put him out of business?" Nope, because there are two other advantages to being focused on an industry. One straight up. It's just easier to sell to an industry if that's your focus. The fact that we're even having this question about how important is industry expertise tells you all you need to know, even if I sincerely and authentically believe that industry expertise is not a high bar for helping a client, and I do believe that the client doesn't know that until you work with them. So if Zach's company and P3 are competing like head-to-head for an engagement with an oil and gas industry client, Zach's company is going to have the inside track.

(12:15): And in fairness to Zach, maybe he should. But to put a finer point on it, imagine another company focused on the oil and gas industry that is actually mostly incompetent, and they're in a head-to-head sales engagement versus us with a prospective client that other companies still might have the inside track even when they shouldn't. Fair or unfair, this is a reality about the world. Now, of course, once a company starts working with us, it becomes clear to them very quickly that that industry expertise thing is kind of a trivial barrier. We get past that very quickly, but it's much harder for them to know that in advance. So there's a big difference in selling services to a particular industry when you've already identified as an industry expert, for sure, no doubt. The other advantage of industry focus is that you tend to be able to price much more aggressively.

(13:10): There's an old saying that people in companies will pay a lot more for a solution to a problem than they will for a technology implementation, even if they're exactly the same thing. For example, imagine consulting companies A and B each have clients in the oil and gas industry, and as part of their engagement with their clients, each consulting company A and B builds a set of Power BI data models and dashboards, which model the long-term cash flow implications at any point in time of each of their clients' portfolio of wells. And it just so happens that these implementations, these two deliveries of Power BI dashboard suites, they just happen to be identical, just amazing coincidence in the universe. They're exactly the same work, and they both have exactly the same impact on the client's long-term ability to operate.

(14:05): They're both equally amazing. They change the way that that company's able to operate because now they can, with confidence, see where they're going to be at financially at every point in time and also evaluate what-if scenarios about if they bring these other capacities online, what kind of impact it'll have, and what happens if oil prices go to X or Y.

(14:24): The CEO of both of these client companies sees this, uses it, loves it. It almost appears in their annual report in a way because it's so impactful. But company A sold the work ahead of time as a Power BI implementation, and company B, by contrast, sold the same work upfront as an oil and gas revenue forecasting and planning solution. Company B is almost certainly going to be able to charge a multiple for the same work that company A does. Now, folks, I've lived this. In 2013, it wasn't even Power BI at the time, it was Power Pivot. I built a Power Pivot solution for a client that dramatically corrected what they called a margin erosion problem in their ecosystem of sales reps. The company's overall revenues were going up over time, but their team of like 400 sales reps and thousands and thousands of customers, the sales reps were just offering discounts to their customers over and over and over again and constantly eroding the price that they were able to charge.

(15:36): So even as this company's revenues were going up, their profitability and even their EBITDA was going down, and this was affecting this company's stock price. And these Power Pivot scorecards that I implemented with this client back before we even had Power BI, back before we even had Power Query, did nothing less than reverse the declining stock price trend of this company and send their stock price back up, but it was a power pivot implementation, right? So the amount that I was able to bill for that project was such a tiny, tiny, tiny fraction of the value that was created that no matter how many decimal places you used, if you evaluated the fraction, I charged basically 0% of the value created. And that's absolutely a reality of our business at P3 today. And because we want to address the entire market and not just one specific industry, the only easy way to market ourselves is to sound like company A in that previous example.

(16:38): We do amazing things with your data. We do amazing things with data technology. As a result, we don't get to charge nearly enough. Now, of course, that's really good for our clients. In my company A and B example, imagine you're the clients, which firm would you rather hire if they both deliver the same results, but one of them charges a lot less, like Yahtzee. And that's where this "disadvantage" of being a generalist firm like P3 becomes an advantage. If you lean into that as we have, and you develop a reputation for delivering just fabulous ROI multiples, words going to get around, and you're going to grow, which is what we've been doing. We're probably a lot bigger than Zach's company. We're probably growing faster than Zach's company. I don't know for sure, but that'd be my guess. Does that mean that our business model is better than Zach's?

(17:36): No, it really is just different, and it has a lot more to do with, probably, where you come from. And the reason Zach and I have chosen different business models almost certainly has to do with where we came from. I don't know much about Zach, but I bet that he came up through the oil and gas industry, whereas where did I come from? I came from Microsoft, where we built software for all industries. So is it a surprise that Zach chose his path and I chose mine? Not at all. And there's so much opportunity in the world of business improvement powered by data that the chances of P3 and Zach's company ever competing head-to-head are basically no. Okay, so what have I concluded so far? That industry expertise is not a significant barrier to doing valuable work because it can be acquired quickly.

(18:26): And here I'm going to take a little bit of a detour and acknowledge something important, which is that the industry knowledge required to successfully execute on a data-powered business improvement project is easy and quick to acquire today, but it wasn't nearly as easy 10 or 15 years ago. So what's the difference between then and now? Why has industry expertise suddenly become easier to acquire today than it was before? The difference is actually, believe it or not, Power BI itself and also the Power BI family of tools, the citizen developer suite of tools that is now being rebranded as fabric, et cetera, blah, blah, blah, power platform. There are many ways to describe or explain why Power BI has been so successful, why it is so valuable. But I think the overwhelming number one reason for its success, the number one reason why it's so magical, is that it finally allowed us to bring technical expertise and industry expertise. Put an asterisk on that, I'm going to call it domain expertise in a little bit.

(19:35): We were able to finally bring those two things close together, bring them into the same room, sometimes even into the same brain. The old IT software before Power BI, like the original analysis services software that's the forerunner of Power BI, was so arcane that only career IT specialists could ever hope to get good at it. There was zero chance that you would be an expert in a business industry and also simultaneously an expert in analysis services. And then, crucially, unlike today, if you were an analysis services expert back then and you got a hold of a stakeholder, someone from the industry that you were trying to help, you're at a client, you're sitting down in a room with them, asking them what they need, you could not build anything in real time in collaboration with that stakeholder. Every time you went to load a little bit of data or every time you went to even write the simplest of formula, the way the software worked, every little action took tens of minutes, sometimes hours to process, or sometimes hours just to write the scripts.

(20:47): There was no way you could hijack the stakeholder's time while you built the thing, quite the opposite. In fact, you had to try to interview them about everything that they ever know about their industry, about their domain, about their problems, the things that they're trying to achieve, like try to capture the entire contents of their business brain, which, by the way, is impossible. And then take that knowledge away with you out into your dark cave, where you implemented these things over the course of weeks and sometimes months later, when you were first putting your first dots on a chart, only to discover that is not remotely addressing the problem that was originally specified. This is why the entire data, BI, analytics industry never really, actually, even worked before Power BI. Because Power BI moves so fast, it's such a low-friction technology. You can very often just get started with the stakeholder in the room.

(21:43): It's not at all unusual to load data from scratch and have your first visuals on the screen within the first hour or less. It's not always that fast, but it's also quite common that it is, and you can start getting real-time feedback on, "Is this what we wanted?" Even if you don't keep the stakeholder in the room while you're doing that, the speed at which you can operate still means that you don't have to attempt an all-at-once brain drain, but instead you and the stakeholder, the industry expert in that case, can collaborate on something tangible. Like, 20 pages of abstract documentation of requirements would fail to accurately convey principles and concepts ,and requirements that today flow accurately and quickly, sometimes in the matter of seconds or minutes at most, when the person with the technical skill and the person with the domain knowledge are able to collaborate on something very tangible that the stakeholder can understand and honestly that the implementer can understand as well.

(22:48): So you see that I've kind of already drifted into talking about this as domain expertise and not just about it as industry expertise. So I know I owe you an explanation of what I think the difference between those two is. But before I get to that, let me put a bow on what I mean by Power BI making industries easier to learn. I think I can best sum it up like this. Tangible eats abstract for breakfast In the old world before Power BI, both the stakeholder, the domain expert, and the tech expert, both of them were forced to communicate at an abstract level. The stakeholder would have to describe how the business is structured, how the data is defined, how the questions need to be asked, all in an abstract format, at best in a Word document completely devoid and divorced from the actual data.

(23:44): You're something in those requirements documents that does not exist yet. And at the same time, heaven help you if you're trying to listen to the technician in the old world explain to you the difference between a measure group and a dimension or a hierarchy or why this and that need to be related to each other. Again, it's all so abstract and distant. Now, contrast that with the world where the stakeholder and the consultant are both staring at a chart together or even just a table visual full of measures, metrics, numbers, and the stakeholders able to say, "You see that number there is close, but it's too high, and here's why." Even though it sounds like that same information could have been conveyed in advance in some sort of requirements document, it just turns out that human beings are not built for that kind of communication.

(24:37): We're built for that other kind of real-time collaboration communication where we're pointing at the same thing together. The stakeholder never needs to answer questions that they don't understand, and at the same time, the tangible, ever-evolving work product gives the consultant the lens through which to rapidly absorb what the stakeholders really after. Now, again, in theory, this all should have been possible years ago, but that's only if you don't understand humans because humans are pesky creatures and there's only certain ways that we work well. There's only certain ways that we communicate well and understand and comprehend well. And the Power BI tools let us work the good way, and the old tools made us work the bad way. Okay, so what do I mean by domain expertise versus industry expertise? Industry expertise is really only part of the story, isn't it? So if I'm working, for example, for two different clients in the exact same industry, are those engagements going to be the same? No, not even close.

(25:40): Let's say they're both manufacturing firms. Well, am I working with the same department at each of those firms? Am I working on a factory productivity thing? Am I working with the marketing department? Maybe supply chain? What about the sales reps? But even if I'm working for basically the same department, same division at each of those two companies, there's still going to be a tremendous difference in company-specific definitions and jargon. There's going to be tremendous differences in the chaotic realities of their business and the problems that they face at that particular point in time. Even the history of these companies and how they've grown over time is going to make a huge difference. So unless you're selling some sort of packaged product that takes the same exact data inputs and produces the same dashboards for everyone, the realities of working with different clients in the same industry, most of the differences between those engagements are going to be differences between the clients, between those particular companies, and the fact that they share an industry is going to be less than 1% of the domain expertise that's required.

(26:47): So the domain expertise changes everywhere, and this circles back to why the Power BI family of tools is so important. Everything changes all the time, and the high speed, low friction, rapid iteration, ever-evolving tangible work product that everyone understands is super important, super valuable for facilitating the communication that's required all the time. If we at P3 move from client to client within the same industry, assuming that when we walked in that knowing what we know about the industry is going to be super important, that would actually blind us to so many of the realities of what we have to deal with. And also, the cross training you get moving across industries turns out to be very valuable. Really, the cross-training you get moving from client to client over time. I mean, it's certainly helpful if you walk in and kind of already know the jargon, the concepts, the common problems, and workflows that might give you a little bit of a headstart.

(27:47): And I've mentioned this on the podcast before, but you'll see patterns emerge that span across industries in some weird ways. Like the model that I built one time that helped one of the big four accounting firms model FIFO and LIFO tax liabilities, that same pattern was useful years later to help someone who was modeling food spoilage in a warehouse. So to sum up, domain expertise is everything, and Power BI allows us to work at a distance from the domain expertise that actually produces value. That's the gift of Power BI. Industry expertise is part of domain expertise, but it's actually, in the end, a relatively tiny percentage of overall domain expertise, which varies from situation to situation, company to company, department to department. It's basically the sum total of the entire relevant business environment you're working in. And with all of that wealth of information that needs to be understood and transmitted, it's a miracle that we finally have a set of tools that allow us to do it.

(28:56): So there you have it, Power BI, Fabric. What do these things do? They tear down walls, let us do the things we need to do. It's about the highest praise we can give to a tool set, isn't it? All right, before I go, here's a bonus question that came from Amanda Manley. She asks, "If you're looking for someone to be your BI superstar, do you look for people who Rocket BI and teach them about your org, or do you look for that person internal who knows your business inside and out and then teach them about dimensional modeling and DAX?" I'll start by saying that you got a much higher chance of success teaching someone who's good at Power BI, for example, about the realities of your business, then you will taking someone who knows your business and teach them Power BI. But there's another layer of nuance here that's super, super, super important because either one can work and either one can fail.

(29:47): I said there's a higher percentage chance that the Power BI expert can learn your business than vice versa, and what circumstances can they not? It's if there are pure techie, it really bothers me that most Power BI jobs these days are described as Power BI developers. Yuck with a capital Y because developer sets a lot of unconscious expectations. Developers tend to follow specifications. Developers tend to go and build robotically exactly what they're told to build. Now, that doesn't describe every single person that currently has the title of Power BI developer, but the connotations of the word developer are very, very, very strong. And you will absolutely encounter people who are good at Power BI who have very little interest or capacity for absorbing the domain expertise required to be successful helping your business. If they want to sit in a room and be fed requirements through a straw, yeah, they're still going to move faster than the old analysis service developers, but they are going to move at a snail's pace relative to the person who is spongy, who enjoys and is curious to learn about what your business needs.

(31:09): On the flip side, listeners to this show have heard me talk about the data gene for a long time. It's really only about one in 15 people who have the data gene, and you can test for it by what's their reaction to Excel. When you mention Excel, do they cringe, or do they kind of get this weird, twitchy smile? There's an enthusiasm and an interest for working with data that can lay dormant for long periods of time and not be discovered. But when it gets activated, you know it when you see it. It can't be faked. So, if you have someone who knows your business and they have the data gene, then yeah, I think you can teach them Power BI, or at least there's a reasonably good chance that you can. Now, how good are they going to get at it? I don't know.

(31:56): There's a wide range of equilibrium states that people reach in terms of how good they become at the tool. At P3, we hire the upper 2% or 3% of that population, but again, no developers got to have the spongy business thinkers, which is why, most of our employees come from the business side of the house. They didn't grow up as IT specialists. So yeah, there you go, Amanda. If you find yourself a spongy data gener who already knows Power BI, that's the home run. They'll learn the realities of your business in an eye blink. A Power BI expert who sort of stubbornly defines himself as a developer, not pass, move on. And then, on the business user side, if they think Excel is Yucky, nope, no chance. They're not going to learn Power BI, give up. But if they're a data gener, you've got the raw material, you've got a real shot there. All right, I think that'll do it. I hope you find it valuable. Let me know what you think. Drop in, join the LinkedIn group, and we'll see you next week.