AA71 - Career Paths to Product Management

the ways that people break into being a product manager, ways that people break into product. There we go. Yeah. There's, there's plenty of different ways, right? You think about anybody who's in, the product space. How did they get in? Think about that maybe the company brought somebody fresh in from outside or they promoted from within somebody who's been within the organization in a given. Domain, so to speak, whether it's technology or, or business mm-hmm and it can range the whole spectrum, right. Or, or they've hired someone straight outta college that doesn't happen, right? No, it certainly happens. Those are the three ways. And here we are stormy that that is the reason I was like, ah, we gotta talk to stormy on the podcast. Because we have polar opposites of the way we got, we were both in product mm-hmm, both product managers and we have polar opposites. I came up through development teams. I started in QA. and I worked up through development teams and I came into a product ownership slash management mm-hmm . And you did not come through the technical teams. I did not, not even remotely. So I'm actually a registered nurse. And the first half of my career, I spent in an ICU at a bedside working with patients. I also was somebody who was not afraid to disassemble a laptop and put it back together, which was one of the things that ended up landing me a job in the it department at the hospital I was working at essentially they wanted someone who was comfortable enough to learn and not be intimidated by , software and it in general And someone that could walk walk the talk in regards to healthcare. Yeah , this was at the transition or the beginning of the affordable care act and really getting providers physicians involved, trained and bought into. Using an electronic medical record system. Mm-hmm . And so I became the face of it for a hospital, and that was my big break into it. Yeah, it was a few years later before I actually got into product. And that was a whole nother big accident. But that happened developing a care management application said, you know what? We've got multiple product owners. We are building this care management utilization manage application. Ground up we have multiple product owners and we really want someone in here who can, again, walk the talk in regards to the people that we are trying to serve. And that's how I ended up getting that, that role and breaking into product , so I came in with little more than just a little bit of knowledge of nomenclature in regards to agile mm-hmm and and otherwise no experience in product and worked and to date the most healthy and productive agile environment I have ever worked in. That's interesting. So your background as a nurse, you started off client facing, right. You were there in the ICU, right. With your client. So you kind of understood their their pain points literally in this case. But, that's important because you're bringing that knowledge. to the technology world when you become a product person, a product owner, product manager. Right. I feel like in that third instance that we quickly glossed over somebody coming in fresh from school mm-hmm they, they lack that, mm. They may have the theoretical knowledge of what product marketing or, or even just marketing is all about. Yeah. I don't think there's product ownership. That's being taught in schools. It's product marketing. Mm. And, and so when they come in, they're keen to practice the theory they learned. But they don't have the connection with the end user. Yeah. And without that, I feel like you're off to a Rocky start in product management, part of ownership, so let me see if I can people straight outta college. if we're going to go with the third, a third category the, the one that I know the least about, and I'm gonna support them as a, an argument on arguing agile. Here we go. Mm-hmm I would say the advantage of people who don't know anything about either the domain or how dev teams work is we can train them from scratch. Sure. We can train them from the ground up and they don't have any bad habits. I wanna teach.'em your own bad habits. I wanna say bad habits, but I wanna, I also want to go on a tangent about like you know like enterprise Azure coach, O like Hey, give me a Gantt chart about how long it's gonna take to apply this software and enterprise agile coach will will say I'm not giving you a G chart because that is not something that you do in agile development. There's no reason to do that. Like these people will do that because they don't really know any better to do that. So I can get people that won't really challenge my assumption way of doing bus. I, I don't know what to call it. Assumptions way. They don't have a way of doing business. This is I'm assuming here, but this might be their first job out of college maybe, or out of business school or something. So you're right. They don't have the baggage. But when they get into an organization, they learn those, the organization's quote, unquote bad practices as well. Right. Mm-hmm because they don't know any better and that's the bottom line. They don't have something to bring to the table when it comes to experience of having seen it a couple of different ways. Mm-hmm . Yeah. and that's where in either of the other two cases, whether one enters the, the field from a technical perspective you did. Yeah. Or from a SME angle that you did mm-hmm in both cases, you have something you can bring mm-hmm right. And both are valid approaches. I feel it's just that I think you have to be very open minded about what it is that you don't know. Where are your weak points, right? Yeah. And you need to be actively addressing those. cuz real, most organizations do not do a good job of redressing that deficiency in anybody mm-hmm and I mean that, that word in the best possible way. It's not that you're deficient. It's just that you're not well rounded just yet. No. If I'm gonna argue this point and try to try to try to actually argue it right. The interesting point about someone who doesn't have demand expertise nor. expertise on development teams maybe could be that they come with no preconceived notions. Right? So they they're gonna question everything that would, that would be the best case scenario. They're learning the best of everything because they don't know anything. Right. I I'm gonna assume that they're getting active mentorship from the organization. They're getting resources, they're being given a framework where they can take the best of everything they're seeing and run with that Hey, how do I decide what the best thing to do next would be? Well, I gather some evidence. I talk to customers and I decide, and, and they know that's a general framework, but they're being guided by principle rather than being guided by, I don't know, past experiences they don't have anything to anchor on that will anchor their judgment on. Whereas someone who has domain expertise might say like, well, I don't want to go down that road, or I don't wanna make that kind of feature. I don't wanna serve this kind of customer, cuz there's no money there. Or maybe that customer already has a great product for this and they'll never buy our stuff or whatever right. They, they won't anchor on anything they won't grasp on anything cuz they don't know anything which is good and bad. Right. It's good and bad. So your assumption that the organization gives all the support that's needed to this person that's coming in. You could challenge the assumption. There, there aren't many that do that because the organization immediately wants that person to be productive rather than nurture them for any length of time. Other than the initial induction. Oh, I was for onboarding. You're supposed to hit the ground running. Yes. Sorry. Sorry. I was, I was in, my ideal organization in the sky , they weren't like every week, they're like, you're not productive yet. Right. Like why you, why you not productive yet? That, that wasn't happening they realized that you were new. Yeah. They were giving you time to learn like the, the, the, the whole like two week four week, six week, 12 week, whatever plan of like what you should be doing, that, that doesn't really apply. Like they're looking at you in like quarter quarters or halfs. Of the year and that's the plan and there are, are some organizations like you're new, you're new, right? Yeah. You're new, you're new. And those organizations to your point,, they actually do give you the rope to play with and say, here's the problem. You figure out how to solve it. Mm-hmm thinking through this NASA Springs to mind, right? There's a program in NASA. College graduates are brought in and just given problems. Yeah. And not necessarily any direction of how to solve it because they wanna tap into some new creativity. Right , some innovation there, but that's very much the exception, unfortunately. Yeah. So I have a thought. So a couple of actually, so a little bit counter to what you're saying, and, and that is that. So as a new, for instance, college student coming out, you don't know what you don't know. Right. Mm-hmm so is your first job to your point. If you're being hopefully mentored, you are being led, you are being developed. Hopefully. Okay. Couple. Yeah. Hopefully, but there's a couple assumptions there being made. Number one, assuming that the organizations even are mentoring, but. are they mentoring? Are they teaching? What are the values and the concepts and the culture in that organization? Because, because this new person in, in the job force starting their career, what they're learning here is their first experience and is a baseline for their, their, their career and is what they are assuming is what we are speaking about in regards to product, whether it be product ownership, product management so, okay. Is this really an agile environment or is it something that is some quasi agile? So even so what they're taking on, what they're absorbing and what they're learning is going to be the baseline of what they assume, at least at this point is going to going follow through with them. So that's point number one. Yeah. The other thing I would just say is just to bring this up and that is that. in regards to kind of this the after times now. Right? So be, and this almost is kind of taught, made sense in the before times. So before COVID right. When we had mentorship and we had people who were in an office or co-located, and had the ability to see, be involved with absorbed through osmosis and really kind of see experiences right. Where now they're regulated to intentional half hour to hour long meetings and really have a lot of that opportunity to learn and develop taken away. Yeah. So that has to be really intentional. Yeah. So those are just my couple of points on that. to the first point, I don't know oh, my hope. I hope you have a good, hope you have a good point on this one. Cuz I certainly don't. I was like the, the first point I heard that loud and clear is like, is this really agile? Is this really what it's like to be a PM? You know what I mean? In my first role or whatever outta call it Hey, I went through, I went through school, I went some extra time. I got my MBA. This is what they taught me., I was lucky they didn't teach me about Gantt charts. We'll deal with that one in a separate episode. If you are lucky enough to be paired with people. truly get it, get it. I don't know how to describe that one where it comes through, do the people you're working for truly get it. Are they just trying to tick boxes? Cuz you're in some kind of organization where like agile, just another box of tick or whatever. I think an easy way to figure this out if you're in this role or you're straight outta college, you're not really sure you're in your first year, whatever. First 18 months I Don. Is the person that you're working for. Are they every week that you meet with them? Hopefully you meet with them every week, right? Mm-hmm , every week you meet with them, are they asking you how many customers have you talked to? What has the feedback that you've gotten from customers that you've talked to this week? Bin. And if they're asking you those questions, you're headed in the right direction. If they're asking you Gantt chart type questions, or like, when's this gonna be done? How's this gonna be done? That kind of stuff. Like ah, you're in a tough spot. I'm very worried about your future. You're right. You're absolutely right. Right. But as a person coming in, in their first job, they don't know any better. How do you know? They don't know. They're assuming they're getting what they're hearing those weekly meetings, which hopefully they are having whatever they're being asked for or whatever they're being asked to produce. This is their impression of what it is to do it. Right. And I don't know where you're gonna go home, but I I'm cutting in line. yeah. Go, go for it. You're trying to get in the park and you get your ticket in your hand and I see you. I'm like, oh, you should get in the park, but I wanna, I'm cutting right in front of you because I wanna say you think every other company is like this at this point in your career. Mm-hmm so you are likely interfacing with engineering managers and whatever. And you're like, how am I gonna get my thing built? I need to talk to these people to get my thing built. Like you don't have like a vision and direction and future of the product and a five year plan and all that, that kind of like running a good business , all the stuff that should be coming from you, what you are bringing to the table. This is why this blows my mind so much. Very early in my career. I was at all the QA people did business analysis. So I wrote all the requirements. I did user interviews. I did like all the different ways of interviewing and, and getting requirements back in the day. Right. Like use your interviews technical analysis, deep dives on product workshop, stuff like that. So this blows my mind that you're gonna take somebody outta college, shortcut, all that kind of stuff. All, all those learnings and say, oh, figure out what the right thing to build is chances are, they're not even gonna be offered that question like figure out, go build the right thing. They're probably gonna be to your point earlier are going to be. Driven by engineering managers or line managers in a matrix environment. These managers are focused largely, typically largely on utilization, efficiency, those kinds of measures, right? As opposed to effectiveness, what problems are we solving for our customers? That's unfortunately, very common. What I just described, what is very less common is to be given free reign, to say, come in and you know, here's our product line. Figure out who our customers are, or here are the customers figure out the products that we can fulfill these customers' needs with. Right. That's very, very rare, sadly, and a person coming outta college. I don't care. They come from the best business school. Mean they're done that. They're not in the best position to thrive in that scenario. Well, let's cut over to the supporting argument, cuz I feel like we've , not represented the supporting argument very well. Like let's cut over to the supporting argument. Like is this agile, let's say you're working for people that Ew, a traditional waterfall development cycle. they basically have no, they have no tolerance for traditional waterfall at all. They only have tolerance for talking customer, decide what to do, change your backlog, do that. Right? They, they they're hardcore just to the customer. If you are straight outta college and you work for those type of people, you will get a very customer centric attitude very quickly. And you'll never have a lot of the problems that we're talking about. The reason I bring this up is because somebody asked me what agile was and I stopped for a second cause I was like, I don't, I don't know how to answer. That's too basic of a question for me. I don't know how to answer that. I was like, cause this, get on like stop the training. I gotta get off. but what, what I ended up telling him is I'm gonna talk to the customer and ask 'em what they would like the most. And then I'm gonna take that away and work with my development team for two or three days and see what we can build that supports what they ask for. And then in two or three days, we'll call the customer back up and show them what we did in two or three days. And then based on if they like it or not, we'll change what we did and do something else. And then two or three days we'll meet with them again. I was like I forget a backlog and forget all that stuff. I was like, I'm gonna have one story. And every two or three days, I'm gonna meet with the customer and look at what they like about that story or not. And I was like, forget sprints and scaling and forget all.. I was like, if you can do that, if you can focus on that, just talk to the customer couple days, show them something else. Talk with 'em couple days more show 'em something else. I was like, if you can do that, you will be ahead of 95% of the agile organizations that are doing software development out there. If you can just do that. And that was my response to like, what is agile? What does that mean as a product person? What does that mean? Sounds a lot like some values and principles that happen to come along with I mean just saying, I mean, I heard you saying literally talking about putting the customer first mm-hmm and feedback loops and right. That's what I heard you saying. Yeah. So how you do that, but keeping those top of minds, that's that mindset. Yeah. I guess the only, yeah, I agree fully. Well, you said. Exception to that. And it's really a very exceptional exception. Is that a phrase? it is now. It is now. So if you are a super visionary, that super Villa like super villain, no super visionary Steve jobs, you don't ask the customer, you make something cuz you know, there's a need out there, right? Yeah, yeah. Right. You didn't ask anybody before he produced the, I. He knew there was a, there was a need for a portable music device. Yeah. And he came up with it. Well, he actually, wasn't the first one who came up with it. Sony came out with a Walkman first didn't I, I forget. But anyway, Sony. Right. So in this example, that's a rare example where you don't lead with the customer mm-hmm , but yeah. I mean, 99.9% of the time you do, because, or you should, cause you don't know what their needs are. You need to know what their needs are fundamental. I think, I mean, to that point, he did know what the customers needs are based on his personal, he knew, what he wanted and what his friends wanted and what, so, I mean, he really did know what was out. What was even though he wasn't necessarily engaging directly with the customers. Right. He knew what they needed. Yeah. I feel because stormy is here. I feel we should talk about the, the, the specific path of breaking into product with domain experience and not having technical experience you said you came into the product space from a domain knowledge background mm-hmm and what really kind of catalyzed that move was your your pension. Can I say that word? It's a French word. Oh, BA yeah. Yeah, yeah. We love French words. We love, we love French words for technology, right? So you said you weren't afraid of pull machines apart and together, . So that I think kind of leveraged your move into into this space. I suppose it's not necessarily critical, but certainly helpful. Mm-hmm , I mean, to be intimidated by technology software, I think would put you at a huge disadvantage. And I honestly don't think this is a job that you would probably be searching for if that were the case. Right. I mean, to be very honest, I don't, I don't feel like this is something you would be that you would be looking for mm-hmm so yes, that made this an option or, or created an option or an opening for me and, and the fact that there was also some luck and timing there. So I was in healthcare at a huge transitional point where they were needing someone to bridge that gap between the end user and technology and wanting desperately or seeing applications that were being developed a hundred percent by developers and how horrible they were to utilize in when you were actually starting to use them from a workflow perspective as a provider or user of the healthcare software was using it. Were you part of the company when they decided that or, or was that part of why they reached out to you? Like what, what was your role when they decided like, Hey, we really need someone to talk to figure out so when my actually breaking into information technology from actually bedside ICU nursing, right. So there was that stage. Yeah. And that really led that was that my break into healthcare information technology. Right? Sure. And I spent several years there specialized in a couple of things, became a subject matter expert in voice recognition, software loved that did a lot of implementation. and that led me into a couple of other kind of contracting roles and things like that. And implementations into. EMRs. and it was kind of this almost this domino effect of experience that led to a different experience. and the willingness of me to say, I'm willing to take this new opportunity. Right. So, so there was taking a chance. Yeah., it's scary when you're going into something new, but the op, so the opportunities would come up or I would seek for an opportunity and be willing to take the chance to take that new opportunity. So that's number one, number two, speaking specifically about product that one had to do with the me searching being out there and available on LinkedIn and saying Hey, looking for my next opportunity, my contract's getting ready to come up to an end. I'd worked two years. Loved it. And I, I had a company that said we really want someone who can empathize and speak to our developers and our other product owners who are coming from the technical space. We are coming from the dev space. Who can round out that product team. Right. So, so like I said, some some diligence on my part and really looking and exploring things outside of maybe my comfort zone willingness to take a chance and a little bit of luck there, just finding that opportunity to say, you know what, not only am I willing to take a chance, but somebody else is willing to take a chance on me. That was my break into product. Really. Did you change companies to make that jump? Yes, I did. Yeah. So I had, I had a two year long, long term contract, which was implementing that voice recognition software across the United States and Canada. so that was successful coming to an end, ending that on a really high note and was searching at this point for my next endeavor. And to be very honest, there was some, a headhunter that, that, I mean, I was out there on LinkedIn and, and definitely putting my name out there., but I guess I had the right key words and was, you know What they saw and what I was seeking ended up meeting what they thought were their needs. And I ended up in the final kind of running. I flew out, did the interview when you were still did those kind of things and and I think what was very honest in that interview and saying, this is not something I'm familiar with. Agile is something I'm, I'm actually quite unfamiliar with. Other than some terminology I have in, I I've worked with helping this voice recognition company and developers at the other EMR company I was working with to get together so they could do some integration. So by proxy, I've learned some things I've been in a standup here and there, but that's it. And but what I can bring to you is this knowledge of what needs to happen from an end user perspective. Yeah. And ultimately, they said, this is that, that's what we need here. We've got. The dev experience. We've got the, the other people coming from the, and, and I was that, that person that was able to round that out. Interesting. So coming into a technology company from that perspective, and working with other product folks that came from the other side what were some of the challenges, in working together with those folks? So I would say that initially I felt very much like a fish out of water. I mean, a lot of terminology and nomenclature things that I wasn't familiar with or comfortable with. that said I worked with a fantastic. Team that I was in. And I said, as I said in my interview, I was very transparent about where I was coming from. Mm-hmm willing to learn and absolutely ready to jump in and do everything I could to make this ha you know, to learn and develop my skills is something I was very interested in. So the fact that at had a team that was aware right, also my fellow product team, as well as the dev team that I was working with. And co-located with at that time, very transparent with them and I had a dev team that was super supportive of me. so it wasn't a, it wasn't so there wasn't this hu line in the sand, you're the product owner, you'll be the only one writing any story ever, all acceptance criteria will be on you. So I had a lot of support., but I also was highly engaged with the end users and was able to translate that not only for my team, but for the other product teams. So from a, from a long term perspective and looking at that roadmap and high and prioritizing that over the long term, my input was really valuable there. So where my shortcomings were initially, I was able to give a lot of value in other places. That's interesting because with my current team, I told them. where I would like them to get eventually is to a point where I connect them to the business and I bring the business need, and I don't really write any stories I'm bringing the, what the business needs. I'm bringing the business problems that need to be solved. And then the team is figuring out how to extrapolate those and break them down and size them correctly. And figur, acceptance criteria and all that kind stuff. I've told my team many times I eventually look to transition myself out of this role of, oh, Brian does all of the, uh he'll, he'll take a first pass at the acceptance criteria and we'll kind of beat it up and we'll change it but like, I was like, I wanna bring you nothing. I wanna bring you, I wanna bring you, I need this, and then they need to get good interviewing me and forcing me to get better at interviewing other people. Right? Cause like the, the ideal situation is I bring the other people directly to the team in one session mm-hmm and we all interview them together. In a future state , I will hopefully distribute all the skills that I have to the team members. And then I'll just bring the user to the refinements and we'll all talk together. And there's a bunch of ways that you elicit requirements that's they used to call it when you're all business analyst. Yes. elicit requirements , and we'll figure out what the user wants, but again, my background is coming figuring out the domain expertise that I need to build the proper software. Who are the users? What questions do I need to ask? How do I quickly come online to make the most impact in their world? Cause I know I live in the software. I will talk to customers, but only so far as I can get what I. To continue building the best product for them. And then I'll visit back with them once we built something to get their feedback on it. I wanna be the, not really the go-between cuz that's not, I'm not trying to cut the team off. What I'm trying to say is I don't know what I'm doing in my life. That's what I'm trying to say. You're just trying to catalyze this whole situation with your team and the clients. And it can be challenging if you don't have a product that is made for just one type of user. Then it can be challenging because persona the team persona. Yeah. The personas right started. So the team is with different ones. I started hammer. The personas, the persona with my team, because again, not to not to go all Mike Miller on everything, on everything all the time. But we have one user in mind for our one feature we're building. And one thing comes out of that. You could say, oh, well it's one user and they're doing one action, but they have like, they could take it three different ways. I was like, cool. Then we'll build three different stories. Mm-hmm to represent the three different ways they could extrapolate what this feature is doing. We are building things for one user. And the idea is if I'm building things for one user, I want to be able to profile that user. So when I go to invite people to my sprint reviews, The one user is tied directly to the one person at the business level. I can say, Hey this feature is for O who is a advocate representative or whatever. And I know that when we're demoing a feature for customer advocate, we know that O is our guy to invite to these sessions and we can invite him when we're doing a sprint reviews. Hey, O um, we've developed this feature for our customer advocates. We think this will help you. Why don't you give us some feedback? We're gonna demo some features for you, just 20, 30 minutes on a call. And that's it like it helps me because we've done this persona exercise. We know who we're developing each feature for. We can have we can take a little more care about who to invite to our sprint reviews. Mm-hmm and we use JIRA, well, I haven't done that in a while., and, you can add a custom field to jar that lets you select from a dropdown this story who is the persona associated with the story? And you can just select from the dropdown and pick the persona. So instead of writing as a customer advocate. I want this functionality or whatever like I can skip that line and I can code it as a dropdown to say like, oh, my little dropdown and my little dropdown says, oh, colon customer advocate As a customer advocate, I want this feature and then I can kind of skip to the feature. I always approach your ALM tool from the perspective of like, how can it just speed my processes along and make things easier as opposed to normal JIRA? Which just is yes. Yes. I, I don't know of anybody. Yeah. I wanted to just, just a quick add on to what you said and. You know, it is really, it's funny cuz you said the who and the, what is literally had just, just written that down. Right? So so my job from the product management perspective is the who and the what? Right. And coming from the healthcare domain, that's really easy for me cuz I know the who, and if I talk to the, who I can figure out the what, sometimes I have a general idea of the what anyway, right. What I actually don't have any idea about is the, how so I don't ever have to accidentally I don't roll over and start solving issues cuz I just don't know how to. Right. But the other thing I wanted to mention is. You mentioned on multiple, multiple times, there are different ways of involving your team and, and how to do that. So one of the things that I was able to do, and I didn't realize how foreign it was. So this is a first team I had ever worked with as this company I was talking to you about earlier first development team I say, co-located my work family. And so they're developing and I want feedback. So I invited them to we were doing some kind of an AB exercise or something mid sprint to try to get an idea of what their thoughts were invited. My entire dev team. I facilitated the meeting, introduced, welcomed, ask questions, right. As we went through. Yeah. They had never, ever, ever been a part of that type of a session where they had. First hand experience with the persona or the end user that was using the application that they were working with. Ever. Yeah. And so they saw them working through and maybe having a trouble finding something or going like this is confusing and they might be able to ask a simple question going I didn't think of that. That makes perfect sense. Yeah. It was so enlightening and it was something that we ended up now working into like to your point, as often as we could, when it made sense to make sure they were involved directly with that type of an interaction. I would think that's pretty typical. Regardless of the way you find yourself in product management whether you find yourself coming from demand expertise or coming with development team expertise, confronting your developers with, you're gonna actively shadow a user. and I think of this when I do journey maps. Right. I think of this when I do a journey map. and then the, experience to them would be, especially for, for people in organizations where they've never been exposed to that. Oh, it's probably really jarring for them in their first experience to be like, oh, I can't believe these people are having such a hard time. And this and this application that I work in all the time but that's good because they, they should gain that empathy for the people that are using the software. They should gain that empathy because they're not, they're not exposed to that. They're not exposed to anything in the organization that helps them build empathy with the user of the software. Agreed. So on that front, right. So we talked about on different podcasts, checkbox, agile. Yeah. This is another example of that, where. Teams would say, we're gonna consider personas in our ALM tool. Look, there's a little caricature of a person, right., that Fred or Mary or whoever. And, and that's the accountant. So we're gonna say as Fred, they do that, but the developers have never spoken with Fred mm-hmm , that's where I feel like we're just checking the box. You may as well not bother cuz you're not getting the benefit. Yeah. Very few organizations go to that level where they would say let's get together in a room and just talk, just talk about what the real issues are and not go down this path of, well, these are requirements. We're gonna write 'em down. That's the buff that we, we used to do in the old days, big requirements front mm-hmm right. And then get them all signed off. And every time somebody says, it's not quite what we want, go change request. Right. Mm-hmm just makes my blood boil. We need to do a better job collectively to make sure we involve. the customer with the development team. Yeah. You know, people say this word customer centric really put the customer in the center. Yes. Right. Surround yourself around the customer and yeah. We're not doing a good job of that, sadly. To your point. That empathy is exactly what all the sudden I, and, and my developers, after the meeting, the initial meeting were going. I had no idea that this is something they would struggle with. It made sense to me when I developed it this way. And so it did create that empathy and they were, and this was something a beating they actually looked forward to.. And they knew they would learn so much from, and it was something the other product owners and developers, or excuse me, managers ended up implementing. I don't know. I like, if I wanna argue about this one cuz I like argue about things. If I wanna argue about this one, I would say that the, the product manager coming with domain expertise over the product manager coming from a background of development expertise and learning the domain, I would think that the product manager coming from the domain and having to learn development expertise would have an advantage here. I would think that they would find an easier time. Empathizing with the users than the person coming from development teams. I don't know. I, I I'm willing to be challenged on that one cuz I also think that the person coming from purely coming from development teams, I would hope would have a certain level of awareness that they're lacking in that knowledge. So they would be open to empathizing. I come at this subject from working with development teams. So I come at the subject saying someone coming from development teams would likely anchor on technical solutions and go straight to solutioning. So maybe they're not the best person to propose solutions. I like I have is the person coming from the domain similar to that, where they would anchor on domain. but like, oh, this is the biggest problem in nursing or whatever. And like, maybe they're ignoring other things. I don't know. I see both sides. I'm not really sure which one would be better. I, I think one side is more likely than the other. So if you're coming from the dev side so you understand the technology, so you're centered along those lines. And, and before you hear and really understand the problem, to your point, you start forming a solution solution. Yeah. Yeah. I think the other way around is less likely you come from a domain, you understand the pain points. You're not necessarily going to do anything equivalent. Right, right. You're just simply gonna want a solution that is fit for purpose for the pain. So I think. coming from that side, as you did, you're not likely to say I need this client server arrangement. Right. Cause you don't care about the technology. You just want a solution. And the simplest solution. So MVP was definitely something that we we want the simplest solution that can give us working software, some benefit to the customer as quickly as possible. Right. So then, and, and iterate on that., but to your point, I think that there's bias. You're you're gonna come with bias from both sides bias. Yeah. Yeah. You're gonna have so, so, so I think that the most important piece to that is, and you mentioned this as well is just being self-aware of that. And being aware that you're gonna be coming with bias and being self-aware and open and honest with yourself as much as you possibly can. Right? Yeah. We're all biased. We're all human. And being open and willing to learn What is the difference between product manager and product owner to you Stormy? Like, let's, let's go down that road before we run out of time. So I'll start with product owners because that's where I started. That was my original title. So a product owner is a term coined in the scrum guide. Mm-hmm that's where this title came from, right. Product owner. And so there wasn't a product manager actually, at that point, the product owner was you're right. The product, right. The product owner, the product manager, all of the above. Right, right. So safe if I'm not mistaken and, and you could challenge me on this. I wouldn't put down a hundred bucks on this, but I believe it was safe that came up with the product manager and ended up separating these two pieces or these two rolls out. Right. I have really have no idea. I don't know. And actually at this point, the scrum guide in the 2020 scrum guide, aren't, they're not rolls anymore. Right. So accountability, exactly. Accountabilities. Is that what you call 'em accountabilities that's so they're not actually roles anymore. That sounds like something meant to sell something to someone. But my point is so, so once a product manager came in that was actually ended up being defined and separated out . So my best kind of cliff notes understanding of this is the product owner would be the SME for the application and or the feature or whatever it is they were responsible for. And they would be the translator between that persona or user or user group and the development team. Mm-hmm they would be working hand in hand with the development team, a development team., they're part of that team, along with the scrum master, they are the scrum team, right? The product manager on the other hand was more along the portfolio manager. So they may have multiple product owners. Working with them, not under them, although that has been misconstrued. In my opinion, but initially it was working with them potentially with different features, but under the, the same portfolio that product manager would be then responsible for understanding the market drivers of the customer, which would be driving the overall customer needs. Not necessarily the individual features. Yeah. Which those priorities might change, but that then would drive the. The long term roadmap and prioritization of that. So I think that's the differentiation I see is where the product manager typically is more involved with leadership, marketing sales. and overarching market trends where the product owner, now that there's a separation between the two is more involved with maybe specific product and, or feature and very involved with the, with the team teams regarding that. Yeah. Not to, again, reference Mike Miller twice in the same podcast, but the distinction, I have lines up with his distinction, which is the product owner is. Inwardly organizationally focused in, in, towards the development team, the product manager is focused externally from the organization externally out to the customers and whatnot. So one person talks outward about the features. One person talks inwardly about the features. Does that make sense? It does make sense. I feel like I'm missing a big, I don't think overlap. The two of you are saying anything radically different. I'm gonna try and use an example for this. So you think about products like Microsoft word, Microsoft Excel, Microsoft PowerPoint, right? Each of these products may have a product owner that's working with one or more development teams to produce that product, to deliver the product. Now all of these products, not all, but a lot of these products are bundle bundled under Microsoft office, where you may have a product manager who. Accountable for P and L of Microsoft office and they're trying to figure out how to position that in the market with the competition, et cetera, et cetera. So to your point, Brian, that might be the outward focus. Yeah. Rather than looking inward towards the dev team, because you've got the product owner handling that side of things. So I think that example kind of illustrates what you were saying and what you were saying both. Right. I think that's true. and Mike Miller's example, I have talked to Mike several times about this it's similar. He's thinking about it from a similar standpoint. It's not that. A product manager has no idea about how things are being developed, but it's not that a product owner has no idea about where the where this overall product is in the market. It's just that their accountability are different. Mm-hmm right. Yeah. Right. That's how I feel. I would say the granularity a bit different. So where I'm thinking about this is so from a product owner perspective that doesn't exclude you from working out externally outside of the company, right? As a matter of fact, I would be expecting that a product owner would be working with personas and end users relevant to the application that they are features so on and so forth that they're working on. Right. So they could be working and, and prioritizing appropriately for their development teams. That said they would be working maybe more so with those end users utilizing Excel, right , where a product manager might be working with the company leadership that would be purchasing the enterprise software portfolio of Microsoft office to be utilized. You know what I mean? Mm-hmm so I think there's some granularity there, but there is definitely a communication and collaboration that should be happening and overlap between the PO and the PM. We're kind of thinking about the external versus internal product cycle when we're dividing the role of this is this is way I don't know. I only bring up Mike's opinion because I like that's one opinion, right? When people ask me this, my opinion is you should keep the two together. You're like, you're just calling product manager and be done with it. keep the two roles together until you, until your organization gets big enough where it's just too too much context switching to keep the two roles together where there's, there's so much chatter happening external to the organization, and so much chatter happening internal to your organization. That it's just, it's not possible for one person to live in both those spaces. And then it makes sense to separate the role of the product manager versus product owner. I don't know. Even when I say it, I am only sensitively you know, behind what I'm saying, cuz I'm like, Mmm, I don't know. Like you can scale your organization to a point where your. Owners slash managers never get overwhelmed because you're scaling their little pieces of the business and their teams and their teams responsibilities and stuff. if you get to a point where without using any titles at all, a certain group of product, people are only dealing with external facing and a certain group of product. People are only dealing with internal facing. Yeah. They're hard delineations. Probably not. Yeah. Yeah. It's you gotta create silos at your point. That's what, that's where I'm going. I'm like, you're, you're probably very quickly coming to a point where you're recreating silos and that's, I don't think that's a good thing. If you are a product person, I don't know, owner manager doesn't matter. There's a certain point of tactics and strategy involved like every product owner who has one and only one team, two teams doesn't really matter. You have a point where you're plugging your team into the strategy, organizational Strat high level, five years, six months, anywhere in between. But as a product person, you're plugged into the next two sprints ahead of where you're at. So six, six weeks out, right. That's where you live. You live sprint N plus two mm-hmm That's where your backlog extends past that. Who knows? We can throw everything out. Doesn't really matter. That's a very tactical world to live in is sprint N plus two. I'm gonna do all my backlog sessions, all my interviews, all my team reviews and story building and epic breaking down epics and stuff like that in sprint N plus two. And, and certainly there is a need for that. There is certainly a need for that, but that product person who's living in that small tactical world should be able to extend themselves to connect with the strategy, to bring it into the world of sprint N plus. Yep. That's where their product backlog comes into place. Sure. They're looking at it from a kind of a micro lens of sprint N plus two. Yeah. But that chunk of work belongs on their product roadmap somewhere. It's not just completely random. Right, right. It's still contributing to the original vision. Well, that's my point that they have to lobby for what is coming up in the strategy. Yeah. to change it. And they have to have a say, cuz they live in the tactical world. So they should have a say, even if they don't make concrete changes, they should have a say to say, Hey if you do this, this is what's gonna happen at a technical team level. Yeah, so that the organization can knock down risks. Well, it's also, yes, I agree. And also it's that, they're the ones that can see the blind spots. Cause if you're really living up here at a higher level, strategic level, you're not really aware of the blind spots, an example might be there's there might be a regulatory change that the strategic folks aren't necessarily aware of. Yeah. But these guys will say, we can't do this because you know, or GDPR or something. So people can see that and say, yeah, we get what we have to do, but we have to pivot it now. Right. Those micro pivots they happen. Right. But they can't just say, oh, we're gonna work on something else altogether. That's currently not in the roadmap. They can't do that. That doesn't make sense. That's chaos at that point. Yeah. So I'd say that when I hear you saying these things, there should be some alignment here when we're talking tactical. I totally get this N plus two. That makes perfect sense. Right. But ultimately to your point should be leading, should be tied into strategy, which in my mind comes from, if we're moving bottom to top sprint, sprint goal into product, into product goal, which should be tied to our organization, mission values and all those. So, so ultimately, I mean, even tactically, we should be able to tie those to our overall mission of what we're trying to accomplish. Yeah, We all gotta be on the same pages. Like how do we knock down these problems? Well, in the, in the short term, in the next two sprints, if I'm doing two week sprints in the next month, the way I can deal with these problems is, well, I can deal with these things and they're very quick, but they're not a permanent fix. The permanent solution is usually much, much larger. Right. Yeah. And I like to get into the, how that's, that's one of my coming from a dev team , comeuppance. What's a, what's a good word is good coming from, from a dev team backwards. Comeuppance. Yeah. I mean, yeah, sure. I like to get into the, how if we're gonna do something, how are we gonna do it? Mm-hmm I like to get into that at at least a fair bit to make sure that the team understand. The, the goal of where we're going that, and that, that's probably my, that's probably the detriment to anyone who comes up to product management from the debt teams is number one, you need to abandon an analysis at some point, just be like, this is it. This is the cutoff of analysis I'm out. Like I've done enough analysis. And the other point is you need to get out of the business of how and technology solutions, the very specific solutioning of things, how UI are built that's something I definitely I'm like, I hate all UIs. I've designed webpages, I've designed a web application solutions. So like, I generally know what is quick changes and what is not So when I, when we're going through and doing like, I story pointing, for example, it's like, oh, this is like an eight I'm like, I know is it an eight? Like, you're just changing some colors why, why is this an eight? I guess I bring this up to say there are different things that I will challenge because I came up from being on development teams comeuppance... That's a terrible, terrible phrase that, that maybe if you came up through the business domain and you didn't have expertise in development, you would never think it to challenge. You would never think that. Say like, oh, why, why is it, why have you guys been working three days to make a change to this dropdown or whatever? Why does it take you three days? Add an option, give it an ID and you're done. It's good and bad. I mean, I understand coming from a business lineage, come up, you could say that. Yeah. It's coming from that background. It's very difficult to kind of extract yourself out of that mode of thinking. This should only take so many seconds or this is easy to do. Yeah. Right. that's one thing, the other thing is getting to the point where you let go, let go of that. You're not in that role anymore. Yeah. You're not developing software anymore. Right. That is so difficult. I found right. That is very hard. so the thing I wanted to talk about there just really briefly. Sometimes the developers will surprise you. So when you say to them, I want to change the color of this, and you say it's a three point story or five point story. It really should just be an hour at the most. Right. And they'll say, well, no, one of the things I wanna do as part of that is to make sure that it's, you know ADA compliant or whatever the term is w three a right. Yeah. And you go, oh, I didn't think of that. Mm-hmm but they did. So that's where yeah. You kind of just go so far and then just let them have it, trust them with it. Oh, we're gonna argue about this one. Like trust them with it. But also shouldn't. We negotiate that. and document what we agree on in the acceptance criteria. Absolutely. Cause because I might not care. I might be like, oh, listen, we'll, we'll deal with compliance and we'll deal with what, what is the term for accessibility. Accessibility? Yeah, that's the term. Yeah. Yeah. We'll deal with accessibility, two sprints from now when we deal with the whole site and we try to flatten the whole site for accessibility and I have a whole story for that. And I promise I will create a whole story for that. and deal with it in one go, but right now we're just trying to, demo the site for, to try to sell it or whatever that, that kind of stuff. Yeah, of course. So in that case, if there's a deliberate plan to address that specific thing. Yeah, sure. Yes, absolutely. My example was more about something that wasn't thought about and they actually came up with the idea ah, yeah. In, in that case you either say, yeah, that was a good idea, but not now. Right. We'll pull it later or whatever. Yeah. But yeah, just. The point I'm making is it's hard for people that came from a technology background to just walk away from that and let go. And relinquish controls in many ways I think the harder point in this is because I think the skill to challenge the team, to say, Hey, I agree with you. That is important, but it's not important to deal with now. I'm gonna take it and move it over here and we'll deal with it later, that skillset, I think, transcends anything we're talking about today. I think there's a future podcast on this specific topic about cause human nature. You don't want to stand in front of the tribe and, be like, oh, well like all y'all are wrong and I'm the only one that's right. You don't want to call out everyone and be like, and, and, and challenge a large number of people being the only person there probably are people that have no problem doing that. But you don't do it all the time. You certainly don't. I certainly don't do, I had no problem doing that, but I won't do it all the time. I will pick and choose those battles. But also when you are doing it, you are kind of fighting against your human nature. There's a thing about the only time in your human caveman nature that you like, you alone have to deal with a large group of people that are opposing your point of view is like when you are being judged by the tribe and your life might be in danger when you are being judged by the tribe. Hmm. So it's, it's very difficult. To deal with that situation when you're being judged by a large group of people, to be the only person to be , no, everyone's wrong and I'm right. but you might be right. You might be like, here's my evidence. And, and you actually might be the only person out of that group that has gathered evidence to prove or, or disprove right. Or whatever. Nobody else in the whole group might have any EV they might not know at all. They might have no opinion. They might have no opinion on that at all. But you, as a product person has to bring ring the evidence that supports an opinion mm-hmm and then people can pick apart that or not. But again we go back to I don't even want to challenge a group cuz they might vote me off the island or whatever yeah. Well you succumb to group think or you don't feel confident. It's super tough in yourself to be able to stand up to everybody and say you are wrong and I'm right. Kind of thing. Right? There's that too. So I think that has a lot to do with culture and, and, and trust and if you are comfortable with disagreement of your ideas, then you should also be comfortable with disagreeing with others. So it becomes this very, very in integrated, integrated into culture. So I will say from my perspective, coming from the domain perspective from the healthcare domain, that. I've never had the issue of delving into the how, because it wasn't, it wasn't, it wasn't something I ever stepped into. Yeah. Because I didn't know how to right. It, it literally, wasn't, it's something I wanted to learn about and I certainly would ask questions and, but we didn't when we were getting into micro services and all these databases and all these Kubernetes and Mongo and all these things. Yeah. So, I mean, they'll, they'll tell me what I need to know and tell me give me the Cliff's notes version so I can understand high level. Yeah , but I never got into the how, because I didn't know how to, and I think to my perspective, that was an advantage. That said there's some potentially disadvantage too, with coming in with domain expertise and thinking that what's best potentially oh, right. And leading and guiding. Right. Where maybe, maybe you aren't as open mind as, as you, as you thought you were. so just, I, I think the same trap could be had on both sides of that coin. And again, coming back to self awareness, being open, having that conversation and having the trust and confidence and safety within your team or organization to hear feedback contrary and to give contrary feedback and have the respect of the individuals to, to hear and receive that. And also one last thing, and that is. You said saying yes. Right. Or no , so for instance, you said, Hey, accessibility, mm-hmm yes, but mm-hmm, love that one or no, but right. No, not right now. Yeah. Right. So those are, those are really powerful, right? Yes. But yeah, well, that kind of stuff relies on you having and painting a vision What's more common is in reality, it could be your vision as a strong product person. Right. And they don't really have that same vision. Right. Mm-hmm so fortunately for you, it's gone up and then, and come back down and come back down. Yeah, that's right. In other cases, it. Doesn't go up. Yeah. And that's a recipe for disaster. That, that is a problem. Mm-hmm yeah. Well, everything we've just run through. Like nobody can help with that problem. Whether you've come in with demand expertise, whether you've come in through development, whether you've come through college or whatever doesn't really matter how you got into it you've just adopted a problem. Organizational problem. You, you now have to climb through the organization regardless of your background to figure out who you can climb to, to solve that problem and it's gonna be a problem for you until you resolve it and you, and it's your, and it's not a director development. It's not an individual team member. It's not individual product owner. It's not any of those people's responsibility. It's your responsibility now as a product person to climb up in the organization to make sure you've aligned on vision and then make sure that. Pours down, cascades down, waterfalls down. I don't know this. Oh, no waterfalls. Uh, yeah, trickles down. Yeah, trickles down. I would say too that, you know what, so this also comes with experience, so, and it's not going to be completely clear. as soon as you started an organization, this is gonna take some time to unfold and realize that this is even a problem. And then additional time potentially to go what opportunities do I have to potentially solve this? And who can I collaborate with?, and this could be a very fine line to walk in an organization. If you, you dependent on the type of organization and a hierarchy there. So I agree lot. Depends on some experience. There could be very well that resume updated. I do have a parting question. My question is what is the one piece of advice you give yourself to your younger self? Let's say five years ago, five years. well, or you pick a timeframe. Yeah, no, the, the one thing I would give a piece of advice I would give myself I would say from a career. Well I would say two things, so personally, so I would give myself two pieces of advice, one for personal and one for career, right? Mm-hmm I know this is very kumbaya kind of hippieish, but I can't, I'm realizing now I'm in my mid forties and have been really ambitious and, and now have an adult child and a, a 23 and 15 year old daughters. And I've spent a lot of time in my career and concentrating on that. And so. Self care and taking time with your family is so important. I realize how important it is to take care of our families financially and right, but taking care of ourselves, taking care of our families. So from that personal perspective, I would tell myself, five, 10 years ago, pay more attention, cuz it goes by quickly. And I know that sounds so cliche, but I, I really would say that to myself. That's very true. So I guess professionally, I would say that, gosh, I would say something very different to myself five years ago than I would say to myself a year or two years ago. So the before times versus the now times. Yeah. Yeah. Right. So, but I would. venture to develop strong lasting professional relationships with people that you look up to and respect. I only have a couple in my career, but they have been absolutely invaluable to me. And now someone who is a close and personal friend of mine, but someone I worked at a large organization who at that point was my leader and mentor mm-hmm, continues to be a mentor of mine now, eight, almost 10 years later. but Francesca big and she's just been. Absolutely fantastic. And what a fantastic leader and somebody I still will reach out to and go, Hey, am I, am I going in the right direction here? Yeah, I really so create those relationships when you can find them people that are true leaders and not just managers. Yeah. Awesome. Find them and develop those.