Arguing Agile

AA204 - Domain Expertise vs. PM Skills: Product Management Showdown

• Brian Orlando • Season 1 • Episode 204

Share episode

Is it better to hire someone with deep domain expertise and teach them product management, or to bring in an experienced PM who can learn the domain? 

Today, we're debating the strengths and weaknesses of both approaches across critical areas like business impact, product discovery, stakeholder management, and leadership!Listen (or watch) as Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel discuss why domain experts excel at identifying immediate pain points but may struggle with deeper product methodologies... or listen/watch as we discuss how experienced PMs can bring fresh perspectives while also facing steeper learning curves in specialized industries. 

This podcast is all about exploring the real-world tradeoffs Product Leaders face when building product teams and providing insights for both hiring managers and product professionals!

#ProductManagement #CareerDevelopment #AgileLeadership

References:

  • Boiler Room (film), 2000
  • Marty Cagan - Inspired: How to Create Tech Products Customers Love, 2008
  • AA120 - Did AirBnB Fire Their Product Managers?
  • AA199 - W. Edwards Deming's Profound Knowledge for Transforming Organizations
  • AA201 - Mastering Stakeholder Communication & Management

= = = = = = = = = = = =

YouTube

Subscribe on YouTube:

https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1

Apple

https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596

Spotify

https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3

= = = = = = = = = = = =

Toronto Is My Beat (Music Sample)

By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)

CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

I threw out a zinger the other day to some product managers. In the arms race of domain expertise versus product management skill, when you're looking for the right mix. how long ago was your domain expertise, was it from 10 years ago and you haven't worked in that field for a decade? Was it five years ago in the AI ML field. And now everything is. Gone bananas since then or was it in one of these industries that, that the, the, the pace of change is much slower. So that kind of sparked an entire debate then they kicked me out and said, no more for you, Brian, oh my goodness. I've had a conversation similar to this some time ago with a domain that. There are a lot of people that have moved very slowly. We're talking about industrial equipment. The likes of you know, Caterpillar or Fujitsu make, right? Huge, Machines, but not a whole lot of innovation, Well, that was a few years ago. Micro, micro innovation. There's lots of micro innovations, but they're not visible to the eye. you could argue, do they add significantly to the bottom line? this is a great zinger. I think this is worth digging into. So we're going to do that today when I try and figure out if you should be focusing on. Domain expertise or core PM skills or some sort of a balance in between, obviously everyone's going to say , you need to balance. It depends. Hit the music. Like we're done podcast over. People would say that, but if you've started to look for those kinds of skill sets, you would know it's hard to find that it's very hard. it's especially if you're in one of these companies where the folks running the company think that you're. Very unique. And there's absolutely nobody in the world that does exactly what you do. I'm looking at you open AI. We're so unique. Nobody can copy our like and You're trying to hire somebody that knows what they're doing in product management and has worked in the field. To serve the customers that your business and software serve and you come from that field and you have product management expertise and also like you'll watch my car build my house and fix my drains. Cause you now have unique tools as well, right? I'd like to say something here about what can we acquire having been installed in a row. if you're a product manager who's been doing product management activities, you've been playing the role in some industry somewhere, And now you're in a different domain altogether. is that person more likely to be a product manager? Able to be trained and be successful versus the other way around right where you come deeply from the domain Yes, you haven't got a clue about product management. Can you teach? Product management skills to that person those are the choices we often end up having to make. I think a typical choice that most hiring managers and companies in this position will make is they will get the person with the industry expertise. They will opt for the person who has been working in the industry, pluck them out of the industry and say, you're a product manager. Now, pat him on the head and be like, get out there, kid. You got this. I think that's the most common. The other thing they might do is just say. What do you mean you don't know about product management? Go take a class and that's it. Ooh, that wasn't even on my list of things we wrote down of like, just go get a cert and you're you're in kid, you're in the game. And it's not just that field, but you know, we've seen that. We've seen that a lot. I don't think I've ever seen it the other way where People have come in and knew into a domain, right? But they've, they know what they're doing. Vis-a-vis product manager and they've been supported for the domain, like with sidekicks or whatever, however you do it. I haven't seen that much at all. I want to do , a little arguing agile return to form back and forth. Highlighting some of the considerations. If we're going to be fair and equal about this and not just say the company is going to try like lifting people in a field where they get paid very little money and then dropping them in a product management so you can pay at the lower end of the product management scale is a business tactic, it's the old boiler room? Is that the stock market movie? Before we get started, I have one question. Is anyone here past the series seven exam? I have a series seven license. Good for you. You can get up to it. Why? We don't hire brokers here. We train new ones. That's right. We don't hire product managers here. We train new ones. That's exactly what I was thinking. I like having Ben Affleck open the other tab to give me, inspirational yet questionable. Cause the whole point of that movie was, everyone was like cheating the system and went to jail or whatever. And yeah, we don't hire traders, we train them. This is the same thing. It's like, Hey, we're going to hire you kids. we don't want any professionals because, like in the movie, they wanted to have the spoiler for boiler room. They all went to jail because they were all like hey, just do what I say, that's the kind of people they wanted I don't want to focus on that in this podcast. Although that is a very regular thing in product management, people are just happy to break in this hot new field but yeah, I want to get back to the normal format of arguing agile to go through some of these categories. All right, let's keep going. All right. If we're talking about product management and we're talking about whether I should hire. A experienced product manager versus a domain expert and kind of train them up, I'm looking for , more of one category than the other category. I guess that's what I'm saying. It doesn't have to be like, they've never been a product manager before at all. It's just, they have more of one than the other, right? Yeah, but these are rare breed people, They're not that common out there. I guess I will tell you from my own experience, usually what you're looking at is. I guess even though I said it, I was like, Hey, it's not every case where you have somebody brand new to the domain or brand new to product. But hiring product managers, that is my experience they either have one or the other. Right. Okay. All right, let's talk about the first thing that I want to talk about when I talk product management, let's talk about business impact. Okay. So I'm a PM. I'm making a case to you, Om, the VP of product management, chief product officer at the company. You're the person responsible for hiring product managers. I want to make a case to you. We want to hire somebody with product management skills and they can learn the domain. My point is that a strong PM knows how to identify and drive business value regardless of whatever specific industry or KPIs that are specific to the industry. I'm trying to think of a KPI that would be specific to the industry, like niche topics that are specific to that industry a PM worth their salt will have the ability to figure out what makes an impact. Whereas someone from the industry, I started not agreeing with what I was saying as I was saying it, I know it's hard to do this. I still believe that domain knowledge trumps PM skills. Here's why PM skills are transferable. you could work in food and beverage have solid PM skills and apply those principles in another domain. But if you don't have domain depth, You don't know who your real competitors are you don't know, you know what your mo is why you're there What do you bring to the table your competitive advantages? That's hard so that's the other side of the argument can you learn pm skills? Absolutely. not just by attending a class I I'm always in the past podcast, I've always have a big believer in the journeyman model. Maybe that's what you do. You know you have, you have depth in the domain, but you don't have skills on the PM side. So work with a PM and learn those. Somebody from the industry is going to know where the big pain points are and where you can make impact immediately. They'll, they'll immediately know. It'll be part of their product sense right away. Over time, as you solve the low hanging fruit, I love saying low hanging fruit things get deeper and more complex in the industry. Restaurant management is a great example because I happen to know something about that as a PM. You can only sell so much with regard to managing the assets in the restaurant, and then there's the people, and then there's the back end finance, and then there's the chain management. The finance is multiple stores. So you very quickly could solve all of the pain points where those big swings of bringing in revenue slow to a halt. So you could solve all the low hanging problems, all the immediately painful problems, and then be left with deeper systemic problems. That you don't know how to solve. That a product manager, because they're used to basically going from A to B to C, like continually rooting for deeper and deeper problems, like this is just the normal reflex, this is the normal muscle they built up. That you would have to teach somebody who is an industry expert to continually be digging toward the problem. Because you come from the industry, you most likely already have opinions about what needs to be solved. So there may be less digging, which could be a benefit. It could be a benefit to say we need to get to work quickly. This domain expert knows how to get us running quickly. Just hire somebody, get them in here running quickly. However, again, how long you're going to do that for six months and then you run out of problems? Two years until you run, there's an airstrip and eventually you will run out of airstrip to launch your plane from. Yeah, I'm not disagreeing with that. you don't just pick up somebody who is entrenched in the domain and then push them through a class. That's too short term, that's not going to work. Because Now you're focusing on the mechanicals, right? The product management with an uppercase P. So I'm using the Agile analogy. But to your point, would a domain expert run out of things that they're digging into? Would they do that? Because they're domain experts, right? over time, they've built up this knowledge base. And if they're working with somebody who can help them On the tactical aspects of product management, that might be a formidable duo. I think that might actually work in certain domains. I agree with you. If we're running from the perspective of the Deming podcast, where we say the modern managers, the coach, they should be an expert in product management. They should be helping you continually coach continually get up to speed on product management practices and to get better at product management. However, most organizations it's hit or miss whether that person that is hiring product managers actually has deep expertise in product management, because my concern about people with expertise is they're going to solve the problems that are apparent or the problems that are in front of them, or they're going to assume that what they think are the worst problems are the worst problems. Again, as a product manager, if I were behind them coaching them, I would be pushing them to say, gather your evidence. break it up, present a business case show me where the growth is, that kind of stuff. I think they could have blind spots for sure, right? that's a real danger. They could have the blinkers on and run with what they know. That's true. How do you mitigate that? I have no idea. you mitigated with good product practices and also if you would hope that a person with deep domain expertise maintains Contacts in the network. this is the same thing that I brought up when, when we talked about this the, the, the, the, the opening of the podcast where I sparked that I was talking about this with other product managers, the example I used was, were you a domain expert five years ago, 10 years ago, because the industry might've moved on from that the problems that you were there that you had experienced when you were in the role might not be the problems of today. And they may not be the ones that the customers are willing to pay for.. I want to call this one a draw. I feel like I didn't make a really great argument. I'll take a draw. I don't know if there's any other outcome here on this specific one. Well, let's move into one that I think maybe I'll have an advantage in So product discovery. The skills that you use to discover business impact product discovery. So the product discovery, like the continual cycle of experimentation measuring, and then studying the impact of what you just did, the plan do study act cycle from the Deming podcast, a skilled product manager has these user research methodologies. coupled with an expert in design, right? Product design and Hopefully they have like an array of frameworks available to them to deploy to figure out the process of product discovery, as outlined in the Marty Cagan all, all the four Marty Cagan categories, how, how to actually verify well is this something that's viable to our business? Will customers use it? all the categories. Yeah, I think you're right here. I think this particular category is something that you probably will win out on. Because those core skills of journeying the customer's path and understanding the pain points, et cetera. I don't know if you have domain expertise, you necessarily bring those to the table. You possibly just bring. A lot of assumptions I know what they want because i've been in the industry for 15 years And that's a danger. That's a real danger to a person that comes in from within the domain, right? So if a person who has domain, expertise hasn't done a lot of Ux type of work, These are core skills. They don't learn those in a hurry they tend to gloss over them. They tend to have a lot of assumptions and there's a lot of danger in that. this specific topic about product discovery, who would excel here? It would be somebody who knows the practices, product management in this regard, as opposed to somebody who's really familiar and an expert on the domain, but doesn't know how to do this. they can be learned I would say that, I know I said I was gonna support the argument, but I feel like there's a lot unexplored in the typical pushback on this one, and the main one that I can think of is, why do I need to do product discovery? I've dealt with many managers over my career who just say, just build what I tell you to do. Discover why you need to talk to the customer. They almost take offense to the fact that you're like, I need to do some user discovery and do some journey maps They feel challenged with their authority. this category is like, why do you need to do that? I just told you this is what we need to do if you implement this the customer will buy it They told me that's what they told me on the internet. They told you that on the internet I'd like to just hear from the customer, right? Let's validate that. When did you hear this? It might not be recent, right? And which customers you may have multiple customers, different types, etcetera. Especially if you have multiple products, my fear in this category why I would prefer a product manager in this category is because or at least if you're gonna hire somebody who's new, some strong coaching because you're coming to the table with a lot of assumptions in this category. That's my concern. You're going to the dev team and saying to build this , I want to know it's going to transition us right into our next category, which is real data driven decision making. So, you're bringing me assumptions. I want evidence. I want hard evidence. the PM case here is strong analytical skills. the ability to dig for data to back up experiments before you make claims. Any claim you make, make a qualitative claim, that's fine. I'm not pushing against qualitative claims in the business. I would just like to see some quantitative data that backs up your qualitative claim. And if you truly can't have any, then like, that's what surveys are for and stuff like that there are ways. There are ways. if I were a director of product or VP of product I would inherently push back on anyone that says Well, I can't just give you data for this. I didn't, you know. But I know because I'm an expert. I know. I would say, that doesn't smell right. get out of my office. Again, this is another one that if you're coming in with very strong domain depth, you're more likely to be fooled by thinking that you know what the customer wants, or when someone tells you, and they're also a domain expert, or they've been around, they're an allied person to you you're going to believe them. Let's say you're dealing with a salesperson who's been there 20 years. this salesperson is successful. They've lasted this long. They command respect and they're telling you what the customer wants. somebody with just domain experience is more likely to go along with that as was somebody who is a strong PM would say, well, let's see the data. And to your point, I agree. There's always ways to get quantitative data. Qualitative data is not to be discounted. But it should be used in conjunction with qualitative data. I already know the Silicon Valley pushback on this one, on the Brian Chesky podcast I think even he says we don't need data for every single decision. I might be wrong about that. But I believe it was him that said, I don't need data. I mean, he's kind of like painting with a real broad brush to say some decisions are really simple and we should just make them. I was going to say the rebuttal in this category, the Silicon Valley rebuttal in this category is I'll tell you what metrics matter. Oh, I know the Brian Chesky in the Brian Chesky podcast. And then the Brian Chesky. Figma podcast that we did with Curtis Brian Chesky said you don't need to run an A B test for every little thing. That's what he was pushing back against, you don't need to run a test every time you want to make an informed decision just make the decision we need to move faster. that's the underlying thing. Don't waste time trying to gather data. maybe some decisions are very few possibly, right? Some decisions you could just say, let's make an educated guess. Because you still need to know why you're doing something as opposed to, I'm telling you. How do you know? That's the question I always ask somebody who says, I know what they want. Build this. You treat me like an order taker. how do you know, when was the last time you spoke to a customer? can we just validate that? Because maybe you spoke to one or five and we'd like to speak with others and see what the sentiment is across the board. So this one's, I don't think it's black and white, but it's kind of gray. It's certainly very opaque and murky because another problem with this one is very few people actually keep a decision log to tell them this is what we decided to do. And in that log of this is what we decided to do. You also would have another bullet point that says, these are the things we've talked about that we could do, but we decided not to do. And here's why. very few people keep that kind of information because at the end of the quarter, when you do your quarterly planning, you can say, remember when we decided not to do these things or not to AB test these ideas. here we are now. The market seems to have moved on. the problem with this category is, what do you do when you've documented a string of evidence that kind of proves, this one person makes bad decisions. that's easy to deal with, right? What if that person is Brian Chesky? everybody has their needs. So the bottom line on this is decision making should be. Based on evidence and the evidence should be sourced at the source rather than somebody telling you that I've spoken with customers. they were at our last symposium or conference Okay. But who did you speak with? Maybe you spoke with somebody at the company, but it wasn't the right people. It wasn't the end user. So can we validate that? That there's the only pushback against that. Usually I think you said that is let's get there faster. But the cost of getting it wrong is way higher. See I want to give this category to the product manager because I feel like both of the candidates in this position can make risky decisions. That's what we're talking about. We're talking about making a quick. Risky decision. Yeah. A decision based on risk and I want to give it to the product manager in this category because if I'm making a decision that I know is a risk, I'm trading off speed for knowing a thing, for being sure. That's okay. That's no problem. We did it when Alex was here. We did a whole podcast about intuition versus evidence. Sometimes when you're taking a leap, you need your intuition. But I feel the product manager can feel out all of the potential paths. Look at the evidence that they have, or they don't have look at the potential impact that they could have or can't have. And then make a leap based on experience. Now they get it wrong, like fine, like again, they're going to insulate that decision because they're a product manager, that's what you do. Whereas the domain expert might feel like they're putting all their eggs in their basket, or they might actually put all their eggs in their basket. I agree with giving this to the product manager because the domain. Expert may not have the skills to validate what they're doing ahead of time And because you're a domain expert, you're more likely to say I know what the customer wants, right? As opposed to i'll validate that so that that hard data to make decisions, the PM is more likely to succeed there, I think. All right, let's move on to stakeholder management because stakeholder management is like MVP. It's so watered down. I don't know what it is. Stakeholder communication. The act of managing relationships, building consensus, navigating organizational politics. These are all universal skills. These are all political skills. If you want to get ahead in your career, if you want to move to director of product management, these are, these are skills you need. These are not skills you need. If you want to move to chief product officer, you need to be a salesperson. That's right. So I think we've been here is also a little bit of that. You mentioned politics. Absolutely that is ingrained in there, but also change management. How is the change going to be communicated? And you know, how often, to whom and what medium. And that's even putting aside in product management, we don't talk about the project management piece of the job, which is very real. your whole communication plan, your plan to roll things out and what phases and how long when's it going to be done? Like there's ways to answer those questions. Those are very project management, type of things that you just do, you hold your nose, you do it, you get over it. It's baked into product management as a subset. Sometimes you do more of it, sometimes you do less of it. But if you're not good at stakeholder communication, you're never going to be a top tier product manager. when you're putting that next to. domain expert. That is a tough hill to climb. I think of the role, like the, job title of technical product manager. we're looking for someone who knows how to code I once talked to a PM who worked at a company where they developed software. Software testing software. Oh boy. That's tough. Software testing software where the testing software basically analyze the DOM layer and it's like extracted the elements and figured out how to test things based on the DOM layer. Very deep tech, like as a PM. deep technical expertise in understanding HTML CSS and the underlying actual code to be able to hang in a requirements discussion user stories or whatever you want to call it right. Or development directors, those kinds of people, tech leads. Yeah. But I think of businesses like that, they would be making the case to say, stakeholder management is important, I don't want just somebody who's political Cause then they won't understand our software. They won't understand our users all of our user developers. So, yeah, I think that's right. And also if you're a, if you're a diet in the world domain expert, you're going to basically not pay heed to this. You're not going to really worry about a racy, which a lot of times is used for figuring out who gets communicated to how and how often, et cetera. You're basically going to assume that you are running the show And whoever needs to know. they'll come to you right? And that's a big problem because It's not just showing progress in what you're doing, it's also communicating the bad news first when there is bad news and the tact in which that's done, Change management's all about that, in my opinion. It's all about the change and how you're communicating that, because not everybody's going to welcome the change. There's always going to be a few people that don't like it, before this comes out we will have posted the stakeholder management podcast where we actually give you a framework to Communicate with your stakeholders and we give you something. If we're going to back out of the arguing for a second check out the stakeholder management podcast. we did we give you a real tactical framework you might take that framework, use it for six months and then advance beyond it and throw it away. Fine, but at least you have some thing because this particular one, like how to better communicate, first of all, how to even segment out your stakeholders to understand that they are different types of stakeholders that have different communication needs. Yeah, that's the first breakthrough you have to make we covered that. So it's very practical, actionable. This is why this is such a difficult category. Experienced product manager or not. because you're fighting all the tools. You're also fighting this attention ecosystem that is trying to grab all your minutes of every single day to take your attention. You know, pop ups on your phone email slack everything that's trying to alert you You're fighting that. to get a real human connection to really get on the same page. Agreed, absolutely. So I think stakeholder communication is super critical, in my opinion. Because the one thing, one day, that you fail to communicate is the one that could come back and behead you. That's why I'm going to give the PM this category because I think you come into the ring. Day one knowing that this is a huge part you may already have that natural talent depending on what industry you come from Pound for pound like the PM you would expect to already have this skill. I agree with that if you're from the domain squarely like coming up through that side of it You could learn this yeah, this is not that hard, but you have to you have to have some coaching You have to be lucky enough to have somebody who can coach you on this not just yell at you and say you're not doing a good job like what do you mean? Well, you just gotta Talk to people more generally. Yeah. Stakeholder communication, we should have just done round two of the last stakeholder communication podcast, because that's what this is turning into. I think that's true. you have to be very lucky to get decent coaching, but I've seen the other side of it, The coaching goes you're from the domain. You don't know. You got to document everything. put it in an email, CYA. That's what I've seen a lot. there's a lot more terrible advice in this category than there is good advice Sadly. Experienced product managers. But again, this is why we did a whole podcast on it. there's solid advice in that podcast for people that want to go look at it. Alright, let's move on to product strategy. We did a couple podcasts on strategy. And the takeaways for both of those podcasts where everyone is terrible at strategy so if, if very few people in the business that includes executives and the people running the business have ever really like run a successful strategy, understand how to construct a strategy, understand how to keep a strategy moving forward. I will say if there is a chance that somebody in the business knows how to construct, build, drive a strategy, it's going to be the product management folks, the people with product management experience, strategic thinking, developing a roadmap. building consensus hardcore prioritization skills. Maybe some people use frameworks with like numbers and stuff like that. The principles of good product management. it's all baked in. you get this with good product management skills the difficulty of hiring someone. out of a domain who doesn't have product management in their background, or especially hiring somebody new is they're not really going to know how to do this. So they're going to go from feature to feature or what management tells them to build without regard for a strategy, which might be fine if you're like a quarter to quarter kind of business, in the long run, it's going to hurt you. Yeah, I agree with that. if you're from the domain, you're more likely to say. this is what we do. This is why we're questioning that. This is what we do. We've always done it that way. And we've been successful too. They may be right. Maybe you are successful, but that may not be the core reason why you're successful. Maybe there's some underlying strategy there that they haven't been a part of in the past part of creating it or implementing it. So there's a danger there. They could say that they could, the other thing they could say is. I've been in this domain for 15 years, I know about our competitive landscape, I know who the players are, I know their strengths and weaknesses. Do you? Really? Right. So yeah, I think that this one also probably will go to the product manager because those core skills of visualizing, creating a strategy and then executing on it. They don't come naturally to someone who's just coming up from the domain. Yeah. the other side of this discussion is. You can come up with the best strategy that you want, it's sort of a mix of what we said earlier on in favor of the person with domain expertises. Number one, you don't need as much spin up time. You don't need to do as much research. And number two there's the possibility that the pm, I mean, or business leader really, it, it's not, it's not just an accusation of the PM right now, but yep. There's a, possibility that your strategy may miss the most impactful business problems or opportunities, And also you may not be aware of some of the subtleties right in your industry, which if a domain person would have come across that over the 10 year they've had, so maybe that's, that's also a possibility there in favor of the domain expert. I'm not super clear on this one. I would give it to the PM just because so many. people running businesses Are comically bad at this? more people are bad at this. Than are good at this. I, this is one of the, and I don't mean like, not even like 50 50, no. I'm talking like overwhelming. Easily. 90% of people are bad. I agree with that. this isn't one of those where for some of the other categories we said the domain expert could learn these skills, but this isn't one of those, I don't think you can learn quickly how to craft strategy. If you're a domain expert that takes a certain set of skills that you have to have built up over time So slight edge on this one to the pm. All right. So let's throw out a category that the domain expert actually might have the advantage in, which is user empathy. Okay. So the PM side of this, I would say strong user empathy and interview skills, the ability to work across domains. this is a skill you should have regardless. Same thing with like, if you're going to be in the Marty Cagan sphere and, you're gonna have a UX person a designer on your team, the designer should have the best skills in the business for this kind of stuff, right? So, theoretically, the advantage should be in the PM's court good PMs know how to uncover details and kind of keep driving it until they get to the heart of the matter, regardless of discipline or user or feature or whatever you're talking about, right? Pain point, you should be able to dig to the underlying problem. I will point out that the PM should have the advantage here. I also realize that PMs are extremely busy. PMs are the first people that can wrap themselves around the axle of wanting to believe what they want to believe. Regardless. So this one if you're a domain expert, you already have the relationships. Hopefully you already know the people in your domain and that makes it easier, It also means that you've talked to them more over time, what their needs are. You may not have done the scientific analysis behind that gathering we talked about earlier about making decisions based on actual data. You may not have gathered that in the past, but if you've been there a long time, you've spoken to your customers, right? there's a danger there because you tend to believe. What you want to believe on the other side. So yeah, the PMs could craft surveys, et cetera, in the way that gives them what they want to hear. on the domain expert side, you don't have structured ways of gathering data. So you tend to fall mainly on beliefs and assumptions as well. I'd be willing to give this one pretty clearly to the domain expert because when you're proposing solutions and like the, when, when you say, Hey, if I solve this pain point by doing X, Y, Z, what would you think about that? Or would you sign up for that like if you're a product manager, you're throwing these things out, like a sales person would say would you sign up on a waiting list if we came out with a feature that. You know, wash your car for you while you were at work or something, whatever. And you see the light in the eyes of like, that would be amazing. I could go in to work and come out and my car is completely washed and polished. Yeah. Amazing. I don't even need to worry about scheduling because you guys would take care of scheduling there's a moment where you suggest something. Yeah, and a user's eyes light up and you know that you've hit on something special. the user empathy for the Domain expert can have that feeling well in advance of when the product manager you don't need to there, there, there's less information you need to gather, less interviews, you need to do, theoretically, again, all things being equal. To have this aha moment that we're really talking about. And , I'm pretty confident handing this one to the domain expert. I agree. And the domain expert can learn those scientific ways as well, right? those are learnable things., if you're willing to, keep going back to this. If your company is willing to spare the time of someone more senior in the role of product manager to coach a lot of companies get in, they think this trap of what's the ROI on having someone on staff that spends 50 percent of their time just coaching, that seems like a big waste of money. We can get these people in right out of the industry. And not have to pay top product management fees. that's the argument against upscaling in general. you could say we'll just get a product coach in for a little bit. Right. What's the ROI? It's hard to quantify immediately, but there's definitely one there. I mean, maybe that's a product coach centric podcast to say well, can we just pay for like an hour of coaching every other week and call it enough? You know, like how much coaching do I need and what's the ROI? Do I need a full time employee? Do I need to hire a full time Agile coach? Or can I have one Agile coach split across 19 teams and think they're going to be effective? This would be a good podcast, I feel, with Mike Miller, because he was a product coach just recently. So, yeah, this would be a good one. I'll reach out to him. Alright, let's move on to a category that I would hope will be to the PM's advantage, which is I would expect the experienced product manager brings fresh eyes that can spot opportunities that industry veterans might miss, they're unburdened by the way things have always been done. They can get these, these what do we call the intuition versus evidence? They can have these breakthrough moments where they can break through with intuition as their product sense kind of tells them things about the discoveries they make, or they interview many folks in the field. And start seeing similarities and patterns. This is typical PM training. And also like they, they are considered an outsider. To the normal business that's going on and usually when your business grows to a certain size, the system kind of eats any deviation from the mean. These people can kind of break through that. I agree with that, if you're a domain expert, you do have blind spots, you have assumptions, and somebody new, to your point, could see things with fresh pair of eyes, question you, right? Or question your practices, Definitely. This is where a domain expert might say, what you're suggesting doesn't work here because we're special. Or, we tried that. In the past and it didn't work What did you try really? it's similar argument to Agile Coaches is going into an organization being told agile doesn't work. Yeah, right. We tried it We did that we did that podcast it doesn't work podcast we didn't do that I really want to do I didn't write it down or tell you about it before now marty Cagan doesn't work here I think we can put on a pretty entertaining podcast of Marty Cagan doesn't work here. Yeah. I'm gonna invite him to it. we need to put together the skeleton agenda. Marty Cagan doesn't work here. This bare bones skeleton agenda for us, Marty, like this style of four against four and then I will send it to Marty Cagan. Anyway, the technical understanding I think will be another quick category because a strong PM who is a good partner with their technical leadership, especially if they don't have a technical background. quickly coming up to speed with technical fundamentals and being able to coordinate with engineers, architects folks that are more on the technical side of the house, goes into the category of. Having a better initial relationship with your technical team members, and then across, across other tech teams you partner with. I would hope that this again, may, it might not be because your, your, your domain expertise might actually be a technical domain I was going to go there. But in cases where it's not, I would hand this to the PM., if you're coming from a technical domain, I would then hand that back if you're a domain expert and you have a technical background and you grew up in that organization, you probably have the edge. otherwise the PM gets the edge here. All right. So let's move on to a couple I'm going to, skip market analysis for now. Cause nobody does market analysis. That category would be a draw that wouldn't be a draw. All right. Let's, let's talk about market. So market, market analysis, I would expect a PM to understand a basic competitive analysis, the basics of total addressable market. Just key market concepts. And then they can kind of spot market shifts, business blind spots, that kind of stuff. And halfway through saying it , I thought to myself, I don't think I've met hardly any. Product managers who actually have these skills. also I know this field you're misreading the landscape the markets moving this way not that way I don't know if any one person from their one domain expertise position in the market would have these skills either. I think, this is a tough skill that unless you have a marketing background, I don't know if you have this skill. I think this is a 50 50, honestly. I don't know who gets the edge here because the domain experts more likely to either assume, which we've said about other, categories here as well, or go behind the curtain and say, You're an outsider. I've been here a long time. There's a lot of subtleties and nuances here that you don't understand. So Nobody wins. You both lose. Sorry, I'm cutting Willy Wonka in here. You lose! You get nothing! The people that move into product management from being domain experts I think they make that move because they are aware that there is a bigger impact they could be making this whole, category is speed to learning Slash curiosity, like they have a curiosity and with that curiosity becomes this I want to learn new things. I want to scoop them up as fast as possible. And this, this curiosity that, that surprisingly it's like way down on our list, but I think this is like to be a strong PM. This should be near the top of your list you should be a naturally. Curious person you see trends in the market. You want to investigate them. You see new technologies You want to investigate them i'm doing this now with data models in my spare time I'm like seeing which data models actually are good for the applications that I need most of them are garbage and I wonder what all the hype is about but I wouldn't know that if I didn't Personally explore the models myself, a new pm can go from market to market Meaning business domain to business domain Generally speaking Because they're a curious person. They want to know all the ins and outs. They want to know if you talk about the Deming podcast. They want to explore the system, the bounds of the system. Why the system is like it is. They want to know everything about it. Whereas your pragmatist here, your domain expert in the market, might say you don't need to know all that. You don't need to explore all the bounds and know all that is knowable. just build It slows us down. build FinTech widgets.. What do you need to know all this for? they may come from the standpoint of all this stuff that you're trying to learn is gonna slow us down. I'll say that their business leaders probably will be on the same page as them. Why do you need to know why things are built this way?. The business leaders would be in that camp because they know that these people have been around a long time. And their trusted advisors. But if we're being honest about this from a curiosity standpoint, I think the PM gets the edge. I will bring you to another one that I'm not quite sure about this category. I don't know if anyone gets the edge in the process and methodology category, a lot of people from the business, meaning business leadership, will discount this and say, well, just do whatever works. And also, I think the, I think the, the, the the domain expert here, I think that also would be their default stance. Do whatever works. Why do I need scrum or these other frameworks? Like, I don't need to learn any of this. We're just gonna go from the most difficult problem to the next most difficult, impactful problem, and we're just gonna do a great job doing cool stuff. Product discovery methodologies, organizational design patterns, frameworks to lay on my team to kind of get us all on the same page to get us through the forming stages and then once we're You know, norming and performing when we're further on down the line, then we abandon our scrum framework. We don't need that anymore because now we're Kanban and we can just move on. or maybe we don't need a framework at all. Talk about the shu-ha-ri here. I agree. I think what's going to happen in this scenario is a solid PM. Can bring a set of concepts with them that they know leads to success, better ways of working, right? Empower the team to do what's best. They're the experts, let them figure it out, give them the tools they need and let them get on with it. Those kinds of things. Whereas if you're just coming in from a domain perspective, I think you're somewhat blinkered. Like you're going to say, well, here's how we do things here. And it works, right? Cause it's successful. so you close your eyes to other alternatives, which may or may not be as good, but you close your eyes to them. So from that standpoint, I think this one possibly goes to the PM. I don't think so. the PM sphere online right now. Pushes back hard against any kind of structure When you're a product manager, you are a leader. Your job is to change the system in addition to all the rest of the stuff you're doing. not realizing that you are the best positioned. person of leadership to change the system going forward. if I were a scrum master on a product manager's team, that would be the first person I would seek. To get buy in, to say, we should do process X instead of process Y. Or, what do you think about going to leadership and saying why don't we try for a sprint instead of assigning us all of our work items., why don't we try for a sprint telling leadership what we think we can get done, the first person I would try to get on board as a coach. Would be the product manager because they're the number one person to make an impact in this category. if you're coming from industry and you don't have product manager experience. And you have these systemic problems with your process , you're not armed with any Experience. Yes the product manager is armed with skill to deal with this and maybe they don't have experience Or maybe they have experience in what doesn't work. This is equally important. That's true. I think You're making my argument now. I don't think either one of these, I think everyone's a loser in this category. that's what I'm saying. Everyone's a loser., the product management sphere online is not making this better by saying the agile people have no, there's no product management in what the agile people are doing. I'm not convinced about that. I think there's a slight edge here to the product manager, because you can apply the learnings from a different domain or your past into whatever you're coming into. Whereas a domain, all they know is what they know and that's a problem. I can't believe we're at our last bullet point. Well, which is team leadership, my case for the PM here is leadership skill, team motivation, cross functional collaboration. They're all universal abilities that a product manager should have to be successful. So you're better off grabbing the typical product manager cause they should have these typical skills. Rather than the domain expert. And the main exit is more likely to basically say, whatever you're telling me here, process wise won't work here. Because again, this is the same point we made earlier. We're different as a company. We don't work that way as an industry. We're number two in the industry. if you're a leader, the argument is more diluted, but if you're number two, you say, well, we've already attained success. We're number two. Right. So I think this one possibly will also go to the PM in my view, Team leadership. We're not talking about domain knowledge led leadership or technical leadership in that specific industry. We're talking about processes. Fostering a way of working that is different than what has been hopefully recognizing that what has been doesn't work. So this one I would give to the PM. Probably not even a slight edge. I'd say at this stage, I don't know. I actually was on the fence with this one when we wrote it down. Because I said For the domain expert like taking a big step back away from any specific industry or profession. So sometimes leadership is a personal skill that someone has developed outside of. Any of this kind of stuff and some people have it, some people I've seen that with excellent product management skill that are not people that I would follow naturally, you know what I mean? And, and, and the opposite is true. Sure. So you find leadership in people and there are some just get it and teams naturally form around them, whether they're in a position or not, they're influencers, whether or not, I would hope the PM has developed these skills. If not, naturally has these skills, I certainly would hope, yes. I think it depends on the maturity of this PM. I mean, if they're a young PM with not too many years of experience under their belt, maybe they don't have it. But if they've been in the game a while, then they should have that the main person might be coming from a technical background and all they think about in terms of leadership is technical leadership. Yeah architecture type leadership as opposed to everything else. the advantage a domain expert would have here is they would constantly be leading you towards the why, they would never let that go unspoken. Whereas, I think of PMs a lot of the time, especially when they get busy, that why kind of gets obfuscated. And they say, well, we got to do this next, in order to do this next, we can get along to these other things. So, we got to do this, so we can get along to these other things. And you say, okay, well they gave me this, so what? Let's focus on the now, what, why, what is the impact of this one thing? And I think if both the PM and the domain expert have even a rudimentary leadership skill there may be an advantage that the domain expert can exploit in this situation. Because they're never doing something without Communicating out the why, but also a good product manager should be doing this as well. They should be making a point of this. I agree with that. I think also the domain expert might have already established themselves as a trusted leader. So they're more likely to get people to follow them. But also leadership is a rare skill. 2025, we're still saying this. I just want to point that out. Yeah. Yeah. Shocking, but true. Well the age old debate of domain expertise. Versus product management skill we've thrown out a lot of points for and against, I'll let you decide in Thunderdome, which one wins at the end of this, but I don't know if I've really adjusted my thinking on one side or another coming out of this podcast. This, this, this pros and cons on both sides. That's definitely true. This pros and cons. And listen, if you guys have, those of you watching and listening if you've have any thoughts or have decided change your stance in some way let us know we'd be interested and don't forget to like and subscribe