Do you want to be a Product Manager and have been doing the role of Product Owner on a Scrum Team?
On this episode, Product Manager and Registered Nurse Stormy Dickson joins Product Manager Brian Orlando to talk about her transition from being a Product Owner (as a job title and role) to being a Product Manager and the difference she has noticed.
0:00 Topic Intro
0:25 Starting with Teams
2:16 Stormy's Experiences with Self Managing Teams
5:26 Brian's Questions...
6:48 Change Triggered by Crisis
9:20 Brian's Take: PO vs PM Job Roles
10:29 Strategy
11:42 Learning New Skills
13:54 Stunted Growth
18:30 Coordinating Strategy
21:17 Communicate Like a Doctor
22:10 View on Career Paths in Product
23:29 Product Responsibilities (with Graphics)
25:28 Continuous Discovery, Customer Empathy
26:51 Validate the Most Important Problems
29:06 A Typical Product Situation
30:53 Being Overextended
32:02 Lobbying for Change
34:06 Bob Galen's 4 Quadrants of Product Ownership
34:38 Good Business Metrics
36:08 Brian's Experiences
39:54 Suggestions for Transitioning from PO to PM
42:38 Taking a Leap
44:27 Mentorship and Sponsorship
= = = = = = = = = = = =
Watch it on Youtube
Please Subscribe to our YouTube Channel
= = = = = = = = = = = =
Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Google Podcasts:
https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5idXp6c3Byb3V0LmNvbS8xNzgxMzE5LnJzcw
Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
Stitcher:
https://www.stitcher.com/show/agile-podcast-2
= = = = = = = = = = = =
AA91 - Going from Product Owner to Product Manager
if you're moving from a role either internally or moving to a different job, and you're going from a position where you're a product owner to being a product manager. One of the first things I would expect that you're going to deal with is you're going from a place where you were assigned things. To a place where you either have to choose the best options or you have to make a case to get something new, whereas you didn't do that when you were a PO and I wanna start with it. I have two parts of this. I have teams, there's one part of this, and the other part of this is products and features. I wanna start with teams because I feel the majority of people that step into product owner positions it goes something like this hey Stormy welcome to our company and here's your team. They're the ones that are gonna be delivering your product., make it happen. Or the other case is like Stormy , thanks for being. Hardworking PO on our team. we're gonna give you this other team now, and you'll have two teams you are assigned things rather than they come to you and say, What would be the best case? And work with you to either scale or divide the business or segment things inside the business. You know what I mean? Yeah. I do do and I will say I, I know, I really do. And I, So what I would say is I I would agree with you that, that is the the most common scenario. I would also say in my experience and my product owner experience is, is, is far more than my product management experience. From a product owner per experience, that is the most common. Yeah. Right. So you're a product owner, you started a company and they say, Here's your team. Yeah. Right. Or here's your multiple teams. Uh, you're right, you're right. So those so no choices given. figure it out. You learn, learn what they know, where they're at, how they work, current state, and, and fix it. Mm-hmm. What I can say is to agree with you. Seems to be the most, I mean, the most common way in which, which those, that allocation of duties is done in regards to teams assigned to pos. However, the best case scenario and what I have seen most positively, and this does take some risk on the part of leadership at your organization but it is allowing your. Once we have developed a little bit of a relationship and we have a clear vision and strategy in place, so we need to know those things. Mm-hmm. and our product person also has a very clear vision of where we're going with this product. Yeah. Right. So those things have to be in place once that happens. I happened to be in an organization where we had six different product owners and we essentially pitched to the five development teams that at that point were assigned. And we're basically just kind of struggling along with what they, what they could do as much as they could do without a whole lot of guidance, without that, you know without that North star or really knowing exactly what they were working for towards mm-hmm.. So the product owners came in, they pitched their you know, explained their background, pitched their, their product vision. And there were also some leadership guidance given in regards to how teams needed to be evened out in regards to experience. We needed to make sure that we had someone front end, back end designs, qa, so on and so forth. After we gave our pitches as and this was this was after we had gone through a lot of pre-work, going, working with the leadership work, going through the roadmap and figuring out what needed to be done, in what order, what we were passionate about, what we wanted to do, and what we felt like we could bring the most value to. So then we, we came up with our pitch, and then we allowed every one of those developers in the room to pick, to go around to the tables, ask us questions clarify things, and then move on and decide, you know, what interests me. and there was, there was one, only one team that started as that team and stayed as that team. They never, they didn't move anybody. They'd been working together for several years. Yeah. Every other team had actually been hired on fairly new, new, within the year or so, prior. Most of them, less than that. And every other one of them actually jumped ship to some degree or another. And then what we found was they also realized that, hey, we don't have balance here in regards to experience, or we're not meeting the full stack needs that we need so that we can reduce the dependencies that we would have on these other teams. Yep. And if that were the case, then we said, All right, we're going to give you another half an hour, 45 minutes. Everybody walk around and see how we can balance this out. Mm-hmm., And they did with no there. So leadership reserve the right to say, if you can't get this done at the end we will, we will switch people out. Yep. They didn't have to, We had adults in the room. They knew what needed to be done. They were passionate about getting this done correctly, and some of them went and, and said, You know what, I'm, I'm more senior. I'm seeing a whole bunch of junior developers over there. Let me switch. Yeah. You know, they, there, they, they need me. and there was no intervention that needed to be had. Now, I would say that's the exception to the rule, but I cannot profess more profoundly how positive that was in so many ways that were even intangible in the sense that it was immediately empowering of our teams.. Mm-hmm., they were immediately bought in. It was theirs, it became their baby. Right. And we were all already feeling like part of the same team. Yeah. So what I'm, my point is when it comes to teams, there is, there are multiple ways of doing things. The simplest thing is just, just tie our PO and say, Here's your team. Fix it. Yeah. But there's other ways that can be approached and as a PO or even a pm, you can advocate for that. Don't know how far you'll get. It really depends on, you know, the culture of the organization. But, but there's other options there. I was gonna ask what triggered the shakeup, the, the, the Team Reformation event that you described? So remember this was greenfield, so they just basically hired a team in and then they just hired, the next group of six came in. They were the next team and the next group of six that came in that were next team. So they were immediately imbalanced and we didn't have all of the product owners already , hired. So we didn't have that alignment in regards to. business and overall vision and strategy. and then, and then that roadmap that was broken out from that over, you know, that long term roadmap. Once we were, once they had the product owners hired and we had created a solid vision that North Star, truly, that one that everybody could look through. Yes. Is our sprint and product goal moving towards that mm-hmm., right?, once we had those in place, then it made sense for us to rearrange and, and, and it made more sense. Or we made a bet to say, How about we, instead of doing this command and control and saying, Let's you go here, you go here, you go here. At this point, they'd had enough time to learn each other. To learn each other's personalities mm-hmm. to learn who was good at what, who was interested in what. and, and they allowed them to to choose and and truly self-organize their teams. Yeah. And and it worked so well. It sounds like there was some kind of leadership initiative to, to move their products from, whatever, the way they were before to some kind of future state. Yes. So they were moving from this and, and, and I will tell you, they were very driven for a very specific reason. And it, and usually it always comes down to money. And this time it absolutely did. Yeah. So they had internal servers. they had a big logo they signed. They did not realize the impact that we were working, They were working in insurance. So if you're not familiar, insurance has an open enrollment. Yeah. And generally have the most activity in your you know, in that very short period of time. Yeah. Every, every year it crashed their internal service for two weeks. Oh. Which was a devastating, a crisis. It literally crisis for this company. Okay. So, yeah. So we went. So, so it was that crisis that led to, all right, we need to invest in making this and in making sure this never, ever happens again. Yeah. There yeah. Never pass up a good crisis. never, never, never let a good crisis go to waste. There's a famous quote about that I like, oh, it was, it was Churchill. Churchill. Okay. Boy, never let a good crisis go to waste. And they didn't, and that, that, that really was the driving factor they lost. So, and, and a whole lot of lost revenue and lost face, so, you know, hey. but it could have been prevented. I mean, these were things that could have been mitigated ahead of time. And it was also a very old application that had been built on and built on and built on and built on and needed to be cleaned up. Right. So it was my job to go in there and understand those personas, the workflows and the problems, each individual work, you know, each individual persona was having with their workflows. Mm-hmm., and then prioritize those. And that led actually to our roadmap and how we were going to implement this incrementally across the year, but yes I was fortunately assigned one team. Each of us product owners were assigned one team, which is ideal. Yeah. There was no lack of work with just one team and my VP of product, who I adore but he was the, we did not have product managers and he was the one that acted in that role. Mm-hmm.. He was also the one that was the buffer and the protector to, to educate us where we needed to be educated, but to protect us from. Those business needs that would impact prioritization, potentially. He wanted us shielded from any of those outside. Yeah. You know, very, very what's in it for me? Type of requests. Yeah. So that we could look at it holistically and, and prioritize in that way. And it worked really, really well. We were very successful. Let's stick with the being assigned category of kind of the main, the main difference of what I see between POS and PMs as a job basically. Well, POS and PMs, I feel when you're new at your job, , you're gonna get assigned either way, but I feel when you're a PO you get assigned, like, this is your product, here's your product. Mm-hmm., or, or if you're, like, if you are lucky enough to work for a big company like Twitter or Facebook, Hey guys, you are the PM of this feature. Like you're the PM of, I don't know. What, what's a feature on Facebook? like you're, you're drunk and uncle posting racist things. Mm-hmm. like, what, what's the feature on Facebook? I don't even know what features are on Facebook. I know. I have no idea. It could be. Literally like the like button could be a feature., yeah. Right. Yeah. Timeline, I guess. Yeah, yeah, yeah. Something like that. so I think like, hey, here's your little feature, and then the, and then the difference now between a pm and a PO is we welcome all feedback but is it's not appreciated. That's the way I feel. So like in a PO role, it's like, Hey, I know you got great ideas about stuff that's outside of your wheelhouse, but so, and keep it to yourself like that. When there has been a job role called product owner that I have observed that has been the way it's treated. Stay in your lane. You know, You mean coming from the PM to the po? Yes. Yeah, yeah, yeah. Because in, in the PM for like, in my experience as a pm like your, this is going to our next category a little early, like like the next category is being involved in business strategy. Mm-hmm., right? So it's, it's difficult to ignore business strategy and ignore, I was gonna say viewership like I don't know, monthly active users, stuff like that. Like usage of my corner of the world. Mm-hmm. is down. Well, that's not your problem. Just analytics in general. Yeah, yeah, yeah. Like general analytics. Like, there's very little you can do unless you're like the PM of growth or something like that, and you just go, like, your whole job is going to other PMs and be like, You need to do this, you need to do this, whatever. I guess what I'm saying is your ability to affect the whole. Like the entire product. Again, assuming your product is just one little tiny product inside of a giant suite of products, or your product is one feature inside of a larger product. We use Facebook for example. I know they're called meta. I don't care. You probably recently have got fired from Meta, so stop complaining. For example, if, you are the PM of marketplace you probably have a whole bunch of concerns that the PM of Timelines doesn't really care about. Cause they're never gonna go to your area. Right. They don't see your roadmap, they're so busy with their own stuff and their own teams. They're never gonna look at your Probably not a whole lot of dependencies there. Probably not. Yeah. Yeah. Probably not. Your product or your segment of the product you have blinders on. You're very limited, where you don't really get to play in the entire suite, the entire area. That would be the big difference between product owners and product managers to me. I would agree. And, and so I have I just recently started a new role as a product manager. and fortunately I work for a fantastic vp of product who is very astute in regards to marketing in particular. He's trained in pragmatic, the Pragmatic Marketing Institute, which actually there's some real, real benefits too. I think it's a little beyond where I, as more than I wanna delve into at least currently. Yeah. but be considering where we are currently in our very infancy of moving towards that product led organization. I'm really jumping more into that product owner role because I need to, the teams who need me right now internally, that said, I'm leaning a lot on my VP of of product who I fortunately am able to learn a lot from. Yeah. Yeah. So, so I'm very fortunate in that respect. And this is what a, gave me agita coming in and going, I haven't really been trained as a product manager. And there is this huge gap between, you know, working with the teams and being, and, and being completely separated from the business. And very little, you know, other than if you have business coming down and saying, you know, metrics, metrics you know, capacity and velocity and blah, blah, blah. But there's such a, a different set of knowledge that needs to be, had learned, experienced from the product management perspective and how that ties into product overarching and impacts development. So understanding the the, the, the market understanding the product market fit mm-hmm. Understanding or potentially, completing win loss analysis. So, you know, kind of why are you winning these? Why are you losing these you know, what can we learn from this? so things that I haven't done before. I'm on my way, well, on my way to learning them., but I think that it's that separation between far more business, marketing, sales, analytics and making sure that we have a viable product that, will be viable in another five years. And then working with leadership, senior leadership. Executive leadership, and saying, , what is that vision? Yeah. Where are we actually going to be? Where do you want to be and what's that strategy? if people could only listen to a 60 second little snippet of the podcast, that would be the snippet I want them to listen to. It's like, hey, if you're going from a PO role, or like, a lot of times people are in the PO role. It's because they've, they've just gotten their. Mm. They'd just gotten their start. I got my start as a product owner. That was the title. Actually, my job title wasn't even product owner. I inherited a product owner job title in addition to my other job titles. Cuz hey, we wear lots of hats when we don't want to pay, you know, people. Right. Um, but uh that was my, I was product owner and to me the difference between product owner and product manager is everything you just said. It's all the, all the stuff that has to do with business strategy. Mm-hmm.. And I didn't realize it until years later from the experience. I was like, why did the people I worked for intentionally keep me out of talking about pricing, talking about go to market, talking about finding a user base, talking about, and, and I realize it was because they were, they were. Tiny, egotistical people with their own problems. Okay. That's like, that's not helpful to anyone cuz everyone's like, well that doesn't help me in my job. That I just had a bunch of people that couldn't. They, they just wanted control and they couldn't let go. There's no way I can edit this into a sixty second clip that like the, the people I'm working for, just that they needed to have control. They wanted to be in the business strategy. They didn't wanna feel like they were left out. They didn't wanna show, you know actually Let me wheel it back for a second. Go to a super large organization where everyone's trying to move up the ladder. Like a big four where everyone's trying to make that senior manager to director, jump, trying to make partner in seven years or whatever. Anything that, that doesn't look like their idea. Mm-hmm., that they can like their win, they can't chalk it into their column as their win. Mm-hmm., they're going to , push you out of, so, so throw you under the bus, ignore you. Make sure you're excluded. Yeah. Yeah. It's all about me. What I did. Make sure my name's on it so that, like, that's, I couldn't move up. I couldn't, And again, I didn't at the time, I was just, I'm, I'm really busy because I'm, I'm a product owner. I've got the team delivering stuff. I've got my own deliverables. I've got my pieces of the roadmap I'm trying to grab onto and help my team, I've got customers, I'm going in front of 'em a regular basis, and I'm trying to keep happy. I've got stakeholders. I'm trying to align and keep happy. I'm doing op, like, if you read the Melissa Perry Build Trap book, I'm doing operations. I'm operating like, like there is no tomorrow. Mm-hmm.. I'm trying to make everybody happy. I'm trying to keep, I got, I'm spinning all these plates, I'm juggling all these bowls in the air, all, all the euphemisms for everything I'm doing. But you know what, I'm not doing. Not doing strategy. Mm-hmm.. So when the executives say, Hey, we've decided we don't need this team, we're gonna cut that whole team over there. Mm-hmm.. And now, now you're blindsided. Your whole team's blindsided. Well, you shouldn't have been blindsided cuz you should have been looking at those metrics the whole time as a product manager. You, and, and, and the executives at that company should have been straight enough with you to say, Hey what this product line is bringing in. Mm-hmm., like, we see it being cannibalized over the next two, three years by the other, by the other products that we're promoting and the other things that we want to promote. So I don't see this, this product or this team sticking around for two years, so let's talk about an end of life strategy. No. Instead of that, instead of doing that, it's all a secret. I remember. After after going through a corporate merger one time I had a budget, and then after the corporate merger, HR was like, Well, you're not gonna have a budget anymore. It's gonna be managed by your manager because they're, they're the right people to do that. And I'm like, What does that mean? What does that mean? That means you want the department to go away. That's what that means. Mm-hmm., that's what that meant. Okay. But like, again, it's hr, so like, they're like, they're not, they're just carrying out the orders of the executive. They're just doing what they're told. Here we go. Going back to the basics, if it seems like people are not being transparent with you, there is a reason. And like you should flee that structure. You, you should take the experience you already have. And say, Hey, I know how to, I know how to operate. We're gonna go back to the build trap. I know how to operate, right? I can do this tactical stuff. I can do this operation stuff. And I'd like to be in the strategy realm a little bit more. I'd like to drive around the organization, talk to sales, talk to different departments, maybe talk to different customers that don't necessarily use, or maybe they use a competitive product or whatever when you're doing competitor analysis. Mm-hmm., talk to a couple people, maybe go to go to some networking events, fly out, go visit some customers, stuff like that. And I'd like to be involved in understanding the strategy level and , I feel like this is the, this is the big for me. If you are a product owner and you're assigned a team and you're assigned a feature or you're assigned a product, you know what I mean, or a sub product or of a larger product or whatever your interaction with the strategy the strategy setting, tier of the organization mm-hmm. They're probably gonna keep you out of it and it's going to stunt your career. Mm-hmm. by them keeping you out of it. Even if you just go to the meetings and listen to how things get discussed and kind of what they look at to make decisions that will help you. If they completely keep you out of that, you'll have no idea what data is used, no idea what, what, what, what exercises you use, or who they talk to or how they do it. You'll have no idea. So when you, when you go to bridge this gap of what we're talking about, when you go to bridge the Gap of, Hey, I'm in a PO role and now someone is hiring me to be a pm. And day one, they're gonna be like, Okay, cool. let me introduce you to the strategy layer and let me tell you how you're gonna plug into the strategy layer and you're gonna sit there and you're gonna go what? Huh? I don't what, what is like, I literally had to Google in loss analysis. That's like, see I'm not even kidding. There is not a clear delineation between product management and product owner. Mm-hmm.. There is an overlap there and should absolutely be a coordination. And even so far as having developer, or maybe it's a lead developer, enterprise AR architect or design or whomever, also be a part of that strategy. Yeah. So that we get an overarching understanding. Number one, the feasibility, right? If we're putting on our armed but roadmap, we need to know, can we freaking do it right? The usability. So from a design perspective, I mean, are our users gonna be able to use this? Right. and then from a product perspective, really understanding the, , can we do it? And if not, how could we potentially do it? But all of those things impact strategy. Just putting it a freaking roadmap doesn't mean it can be done. We need to include all of these other components to even figure out if it's possible. Yeah. Well this is what I was saying super early in the podcast when I was trying not to stick my foot in my mouth for some reason. I don't know why but The, the product owner will say, We'll hand it off to your development manager and they'll figure out whether they can do it or hand it off to whatever. That's not the PM strategy. The PM strategy is Hey, we wanna do something and we don't need to guess. We want to know that if we do it, it's gonna be a hit. Start ticking all the Marty Cagan boxes. Is it usable? Well, would the customers actually use it? Okay, well, maybe you can do some wire frames or maybe you can do some real low hanging stuff. That doesn't take a long time. I mean, if you, like, if you learn a Figma or another wire framing tool, once you're over the hump of learning it mm-hmm. it's pretty easy to work with to now. Now that's a tool in, in your toolbox to deploy. Mm-hmm., Hey, will the customers use it? is it priced within, their ability to pay? Is it priced correctly? You can do some experimentation with that. You can do some AB testing with that. You can do some surveys with that. You can sign up people to use a feature before the feature's available. You can add fake door in, in your application to Facebook. You should do that back in the day before they fired a bunch of people. Yes. I'm gonna keep harping on that. No, I won't quit. And feasibility like, hey we could redesign the entire app from the bottom up in whatever, you know what I mean, Different APIs, but like that would take us six months and we're just not willing to, you know what mean? So what can we do instead of that? Like, yes, we all know that's the right thing to do and that would be yield a much better result than we have now and keep our whatever servers from crashing, whatever, an open enrollment happens or whatever. Exactly. We know we could do that, but, we're not willing to basically not introduce any new features for six months while the whole team takes the whole application offline and rebuilds the whole back end. That's not gonna work for the business. the product manager would run around and, and then, and then at the same time run around inside to all the internal stakeholders to. What are support's biggest problems? What, you know, people calling up or emailing in or whatever, what are sales biggest problems? What's the biggest blockers? Keeping them from selling the application, keeping them from going to the next level? They probably have strong feelings. Different departments, you know, like you just said, like if, if architecture or some kind of like senior engineering leadership is a separate like team or department or something like that, Like, they probably have strong feelings. So the person who builds a strategy out of aligning everyone they could be the same skill set. But in my career, they are not the same skillset. I started saying this but I stopped saying it cuz nobody knows what I'm talking about. Where I, I say communicates, communicates like a doctor. The product manager communicates like a doctor, meaning when you go in for like an exam or whatever, the doctor always like narrates what they're doing before they do it. They're telling you what the Yeah, I'm gonna, I'm gonna touch you here. They overcommunicate they over communicate what they're about to do, right? The product manager I feel if you start with that skill, this whole business strategy layer, everything we're talking about is much easier. whereas the base PO skills that I think of, like when you were talking about before, like the division between the two, there is a lot of overlap. A lot of overlap for me is in that operations category of things that you do. The overlap is not in the strategy swim lane of things that you do. And I would argue a lot of people who, like, even if it's their first time in the role of PO, the strategy skills, there's very little opportunity for them to practice those skills Yeah. And to get better at those skills. I'm living it for, for different reasons. So I would say too in regards to product ownership and product management, there's this assumption, I think that it's a career path. And what I'm realizing is no, it's not. These are. Two very distinct separate careers with very separate and distinct skill sets, is that Yeah, I would, I would say skill sets. So there is some overlap And actually the personality types and the things in, in, in work that you are good at or that bring you joy may be completely , different from a product owner to a product manager. They're very, very different. And typically in my most recent experience is drawing a very different type of personality to the role. And I, and I'm not saying that you can, advance from product owner to a product manager, where sometimes that might be a natural progression. Mm-hmm.. But I don't think that should be assumed. And again, this is contextual has to do with, how many products are you supporting, how many product owners are you supporting? How do they work? There's a lot of variables here. But I think I assumed for a very long time that this was a natural progression in regards to career progression. And what I'm realizing now is I don't believe that that's the case. have you ever seen this from Melissa Perri's the Build Trap. Associate PM is like someone who's in the product manager role for the first time. So it's probably the nearest equivalent of product owner, although you could sub product manager out. For product owner in this as well. And I feel it'd be the same subset, but she's breaking things into at what level do you operate. Mm-hmm., strategic, which is everything we're talking about, working with leadership, that kind of stuff. Determining the future of your product. Operational meaning just trying to land dates to figure out what team's gonna work on what and when, when, what we're gonna prioritize and tactical is working with the development team. And this is the percentage of time spent by the, the higher in seniority you go. The, the division of your time is spent Gotcha. You see a big divide here. where at the director of product level, like she has the, a senior PM is spending 50% of their time straddling the tactical and the strategic almost, almost. Mm-hmm.. Cause they're still doing a bit of operations. I would argue that they're probably doing, the senior PM is probably doing less operations, but, at the lower level, you're working mostly, almost all with the development team. Okay. You know, that, that's basically what she's outlining here. Whereas if when you're at the VP of product level, you're basically doing, you're lining updates, go driving outta the organization, telling people when they're gonna get their stuff done, how much stuff's gonna cost and determining the future, that's like a 50 50 part of your job. Mm-hmm.. Whereas you're not working with any one specific team on low level features ever. Yeah. And that, that's her, that was her division out of Yeah. The build trap out of, out of the book, the build trap. And it does make, perfect sense. And then when you look for instance at the product owner I'll, I'll refer to Bob Galen and , his quadrants of product ownership, one of those quadrants being product management and needing to, you know, that's where that overlap is really needing to understand that and work with, if you have a product manager or if not, Owning that piece of it. Yeah. And that usually depends on the size of the company. Yeah. It depends on the culture of your company. Yeah. Be, because if your company is stuck in this command and control and they feel giving up any of this stuff is a, is, I don't know, a detriment. Some in some way, shape or form. Like, I can't answer why people are the way they are. Right? Like, I don't know what kind of damage they have in their life or whatever. this brings us in the last category, continuous discovery. The podcast we did not too long ago where we were talking about burnout uh, where we were reading a post from a pm who's, who we think probably was pretty burnt out. they probably don't do a They probably don't do a lot of, Oh, what, what's the business problem you're trying to solve? Mm-hmm., Well, let me do a couple little trials. Let me put some things out there into the ether and see what hits. And then depending on what comes back positively, we'll go down that road. You know, let me try a few. They probably don't do that. They probably just are, are completely like, what's, what's the next order? Okay, I cook a cheeseburger. Okay, I'll cook a cheeseburger. What's the next order? Oh, you want some fries? Okay, I'll cook some fries. That, that is probably what they do. And their company's a hundred percent happy with them doing that. Because the culture is, Hey, just do what I tell you to do. You don't, don't, don't question from who, No question. Yeah. Completely, completely get that. Yeah, so they're not empowered. I mean, there is no empowerment for them. And I, I have struggled with this at many companies where I feel like, From a product ownership perspective in particular, I need to understand my customers or users, right? So if I product, I have a product manager, they need to understand the customers. They need to be a SME in that application. They need to understand the problems, They need to be able to advocate for them and be able to translate that and answer any questions that might come up. Mm-hmm. for our development team, when they're trying to, solve for these problems, because I'm gonna give them, Here's the problem we're trying to solve. You need to figure out the how and they're gonna have questions and I need to be well versed into, in being able to answer those questions. Let's say for example, if I was a director of product or VP product and I were hiring product managers and somebody came through who, their career progression, they started as a product owner and now they were making the transition. I would definitely ask them, tell me about a situation where somebody brought you a feature to build. Somebody asked you to build a feature for them, and tell me, did you build a feature for them or did you challenge them on it? And if you challenge 'em on it, tell me what you did because I would expect, I'm gonna show all my cards for the purpose of this conversation. What I'm expecting is in the product owner PO job role, I would expect asking why, why am I gonna build that? Mm-hmm. I would expect that is not appreciated, number one. Let's put my own experience in this category aside for a second. Cuz someone will be like, Brian, you don't know what you're talking about. Companies would never ask that., well, surprise , I think we know who I'm talking about now. I was that when I was in the product owner position, Like, why are you asking why I'm telling you to do it? That's why cause your boss said that you should do it. That's why. And then they'll make it a big thing, right? The difference here is if you're a product owner, as a job role, your mind doesn't immediately switch to continuous discovery as a mindset. Mm-hmm. of what makes you think that is what we should build. Now, instead of getting straight to work, building it and designing architecture and doing whatever I need to get to work, validating that that is the top thing we should do. So I need to work backwards from the feature you, you told me, but Mr. Internal user, or Mr. Vp or Mr. You know, C level executive, whatever. I need to work backwards from what you told me to get to the business problem, to validate the business problem, to then work forward to a solution that will solve that. All while experimenting, getting data and stats and then making this decision with you based on the data available that negotiation, driving and all kind of stuff. I would expect someone with a job title of PO, who's in the PO role for a Scrum team. I would expect they don't have a lot of experience going through what I just talked about. Whereas someone who's in, someone who's moving over from a PM role in another company, I would, I'd ask 'em the same question, , to start, I asked 'em the same question, but I would expect that they already had this skill. At negotiation and the skill at, dealing with stakeholders and the, that the ability to operate a strategic level, that's what I'm trying to say. The ability to operate at a strategic level, which is where I need them to be in order to make continuous discovery stick and continue to be a part of the culture at the company, which I'm trying to encourage as a director of product, are you searching for answers right now? Cause there's gonna be no answers on the internet. No, I'm not, I'm not searching for answers. No, I agree with you. The situation that I walked into now with the company that I'm working with, with, by the way, I'm super excited about mm-hmm. we have a lot to work on. I, but we have great people. We have a great product, and I have leadership that I am feeling really confident that are on board to make this change, right? Mm-hmm., mm-hmm.. So but as it is right now, it is a list of requests, service enhancement. So service requests, enhancement requests, no questions asked, just sent in and put into a backlog that isn't prioritized by any one person. They haven't had anybody in product so I'm here to fix this. and then they just work top to bottom. Companies that I have seen that are like that, it's usually a technical person who is in charge of the list that you just specified. And usually when I have come into those companies, The technical person is relieved to be like, Oh, thank goodness I have a product person to answer all the when's that's gonna be done. Where's the priorities? What's gonna be done in what order? Cuz , I want to get back to architecture and development and building a better system and I have no interest in doing all this stuff Basically I, I find a developer sitting in a product position who the company has not worked to get them any of the skills that product people have. Yeah. That the individual person has not gone in. Like there's a certain part of this, somebody might be screaming at the video and be like, Well, just your personal responsibility to go get the skills that you need and to succeed in the job or whatever. I'm like, Ah, you're already buried working, so 70 hours', I'm saying your head about water, man. To a point, to a point, I understand the argument. But also that's the same way I feel as like the product manager slash product owner who has six teams. It's like, well, you should take it on your personal responsibility to do as best as possible to serve all the teams and, you can ask for all the help you want, but what's gonna happen when the company, mm-hmm.. Goes six months trying to hire another product, make the budget thing, and send it to the leadership team and get it voted on by the shareholders and blah, blah, blah. Get the position funded. Meanwhile, you got six teams for six months. Everything I'm talking about with like, Oh, well you should be doing continuous discovery. You should be vetting like ideas. You should be, Oh, what makes you think for six teams? What makes you think we should be doing that? Like the, those kind of good practices and everything I'm talking about, when you are, when you are overloaded those good practices are the first things to go by the wayside. Absolutely. Same thing with talking to customers and validating, like you know, the other thing that goes out that goes by the wayside is who, he's freaking me out. The other thing that goes by the wayside is like, What kinda shoes that guy wearing. The other thing that goes by the wayside is , when you release features, following up with customers to talk about, Hey, what did you like, What didn't you like? Let me run some surveys. Like, that's, that's the other thing that goes by the wayside. Optimization. Uh, yeah. Amazing. Just verifying with your customers, like, Hey, what we released, like, did it solve your problem? Like, gimme some metrics. Let's talk. You know what I mean? That's another thing cuz you're just like trying to throw features out as quickly as possible and just move on to the next fire. Yeah. You don't care, until they start complaining again. You're on, you're on to the next fire. If you're not giving the resources and you're not giving the trust to your team, PO included, they're part of the team and you are over extending them shortcuts will be made because that's the only way to move forward. Yeah. And you are going to put out a crappy product that will become exponentially more crappy. We're all the way back to being in a podcast now where we were talking about the difference between like a po you're gonna be assigned a team like, Hey, this is your team now, or your team's now. Like that's the difference between them and a product manager, product manager is probably gonna lobby to say, Hey my team is working on several different products now. it's time to split the team and to split the backlog to have two different product backlogs because these products are very different. They're, they're probably going to be the ones lobbying to say, Hey, we need to split the finances of these products. We need to, cuz the, maybe the market is not the same, same, hopefully maybe the customers are not the same anymore. Maybe hey, the customer customer B is in a different market and they've adopted this product cuz it kind of works for them, but it doesn't really work. Like we should split the team. We should split the finances. We should, I don't know, give 'em a white label app or whatever, whatever it is, and give them their own stream of development and features and whatever. The PM is more likely than the po in, in this, in my experience here, what we're talking about. I'll just clarify to lobby. I'll just clarify and that is a good PM . So here's the reason that I say that is because I, that worked with, I've worked with PMs who are just Yes. Men or women, and maybe they're trying to climb the ladder. Maybe they're, you know, padding their resume. Maybe they just don't know how to do their job. I mean, I don't know. But they end up being the enemy of the product because they're, they aren't being the ones that are recognizing and buffering and finding the opportunities to make our product better. they're just making the sales and the marketing and the leadership team, and they're feeding, you know, they're, they're just basically rolling all this stuff down to product or to devs to do, because they said so, Oh boy, you're cutting into a whole nother podcast that I want to have. I don't know if it'll actually be useful to anyone, but like, it sounds like all the people I work with who were marketing people who got hired into the PM role and didn't actually know how to do it, like they, the, or a diagram that I showed earlier with the tactical and the operations and the strategic, like, they're, they're in the strategic category. Mm-hmm., but now they have development teams. They don't know how to do the other. They, they never did it in their career. They never did the other, or I think of like MBA grads who become PMs outta school. They don't know how to do any of the categories, quite honestly. So, like, it's another podcast. I kinda wanna keep it out, this podcast just to not muddy the waters. and figure out what I wanna say on the topic rather than just harping on 'em all night. It's page six if you wanna see it, but this is Bob Galen's but I believe this is from his version one, but he's actually in version two, added a fifth quadrant, which I know, and it makes no sense, but it's self-care. So product manager, leader, project manager, business analyst, The, Yep. I'll show this on the screen when we, when we cut the podcast, but under his number one product manager category, and look, cause I say this to my leadership all the time. I can't invent a strategy for you. Like if your leadership has no strategy, I can try to kill, like I'll go out and die on the battlefield for you., if you have no strategy, it's going to show. Mm-hmm., the team's gonna know it, the customer's gonna know it, everyone's gonna know it. So in category one, you have to run a good business. So that, that's like where you, where I thought you were gonna go with the product owner thing , where you're looking out for the ROI of the product but , you need to know what good business metrics are. And I would say a lot of times pos are not exposed to what makes a good business metric. Hey, how easy is it for someone you know, whatever, off the street, whatever, to pick up, subscribe, start using, and start paying for our application. Like, basically. And, and what is the cost that we incur whenever we bring on a new user? Do we have to go, you know, like back in like 2000 in, in like the mid two thousands when you had to go run out and, you know, install servers in a rack and go send an engineer with whatever, you know what I mean? A hard drive in their pocket to go install the software. You know, like the, like the cost you acquire literally was thousands of dollars Yeah. To set up a new user. Is it that and, and, and, and the speed as well. You know what I mean? Like, it takes you two weeks, you gotta fly out there, they gotta schedule and they gotta do this and they gotta do that. So there are some business metrics, you know that the good product managers will keep an eye on. I really like, I want to go down the road that you've kind of opened the gate and shit. Hey, look, here's the road we can go down of what makes product managers bad? Burnt out. Product manager. Like, you're right. Like they, they could already come in not with the right skill. They could have come in , for bad reasons. management does this a lot with , the higher, the position in product management, the kind of hit or miss they do this with cuz, private equity firms will do that all the time. They'll, they'll hire a chief product officer who has no product management experience at all. Fortunate, I've never worked for private. Okay. Well, I just, I stay in healthcare. That's, if you're, if you're a product person is a sales per, if you go look at their background as all sales positions, you have a big problem. All right, well I don't know how much this in this last bit of the podcast I'm gonna leave in cuz uh, we got dark near the end. But moving from a product owner job role to a product manager job role. So I told you my thoughts in regards to the progression, if that was a natural or progression from product owner to product manager. Do you feel like that's the case? It, it could be. It could be like I got my start as a product owner. But again, like my, my experience was Hey, you got an idea for the product., well great job kid. The adults will take it from here. That, that was what it was handled at that company. Cuz , the product management aspects, they didn't want someone to do that job. Mm-hmm. because of the command control nature of the. Hierarchy of that organization. Yes. Where they actually use a product manager as a manager of people. Yes. Yeah. Which is completely different. Yes. That, that organization would've been that way. Right. Um, and uh, I did a product owner there and I became a product manager at the next company because that, that's, that it set me on a path mm-hmm. to say like, well this is kind of silly. Like I am the person who most interacts with customers and the features and the product, and I am taking the vision and direction and bringing it down. Like, why am I not involved in all this stuff that I know best cuz I live it every day. Mm-hmm. and I started looking at trainings and I started looking at literature. I started reading books and I started realizing like, Oh no, no, no, no, I'm not crazy. This is actually the way it's supposed to be. Mm-hmm.. So I went and got a, a proper job as a product manager. Mm-hmm. where I'm involved in both the advantage there. because I could do the tactical level very well, because again, my previous role, they, they specifically tried to keep me in the tactical and out of the strategy. I was very good at the tactical mm-hmm. so I could concentrate more on the operations and the strategy side of the job. Because I knew that is where I needed to learn and, and mature in those areas of my job. But I could see starting out as a PM and having to learn everything when you're not artificially being. Of any one of the categories for, for quite literally no reason, there's no reason to keep somebody outta the category. I sort of have the internal viewpoint, but I sort of don't because like internal meaning the division, meaning the PO is the one who's dealing with the development team on a day to day basis. That's the role to the development team. Right. But then the rest of the stuff that you do throughout the organization, out to customers, all that stuff, those are aspects of the PM job. Mm-hmm.. you. Whereas my, like, my opinion on this is whereas you can divide them. Like, I think, I think of scaling as a the perfect example of places that I've seen that have divided this role mm-hmm., where they have one person that is basically the conduit to customers. They have all the relationships already, probably cause they've worked there a long time. Mm-hmm., they're the business domain subject matter expert already. And they know the software pretty well. Mm-hmm., but they have so many development teams, they just can't be with the teams at all. So they hire product owners to help them. But those product owners end, end up, like their careers either come up through QA or their careers come up through development or career, or their career comes up through business analysis a lot of time. Or project management sometimes. Mm-hmm.. But basically they come on as product owners and they're told to extend the product manager they work for. Extend the product manager's capability with all the development teams that are working on the product. Cause there are many right at the same time. And that's how the business splits things. the better model would be for, instead of calling them product owners and then keeping them out of strategy and just having 'em talk to the one product manager to get the strategy, the better model would be to. Product managers or associate product managers to note that like they're just getting their start stuff like that. And to call the product manager in that example, either a senior product manager or a group product manager for the whole application. Okay. And then to, to not play games with titles. cuz usually the big difference, we, I'm amazed we haven't talked about this. The big difference usually that I've observed between product owner and product manager is about $20,000. That's the big difference. I've heard you say that before. Yeah. what I would expect in that where people are like, Oh I'm just gonna get a business analyst and re resettle 'em as product owner and have 'em work and basically do their full job as business analyst. Kind of keep 'em out of strategy, kind of keep them out of talking to customers except like, I don't know when they're doing their demo with the rest of the teams or whatever. But I'm gonna keep, the real thing is I'm gonna keep my budget real low cause they're not real product managers. I have recently tried to find research on transitioning from product owner to product manager. There is very little, almost nothing out there. There's no books. There's no, And so given the fact that you were a product owner and went to product manager. Do you have any suggestions, or any particular you know, books or anything that you can think off, off the top of your head that really helped you when you were kind of researching and trying to figure out how to be the best product manager you could be, given the lack of experience you had in that role? Coming from a product owner perspective I would start leaning into, First of all, I, I would be clear with people when you go through interviews of, of why they would be like, Hey, it looks like you don't have a, well, assuming that they are knowledgeable enough to even ask. Mm-hmm.. Cause a lot of companies are just not knowledgeable. I, I, I would, I would be straight with them to say you know, why are you looking? You know what I mean? Why, why are you looking to change? Or whatever. They'll ask you that question in the interview to be straightforward with them. They'd be like, Look, I, I know that in order for my career to progress, I've gotta get to the strategy layer. Mm-hmm., like, I'm being kept outta the strategy layer in my organization because of whatever organizational blockers, the culture, the leadership team, the fact that they're waterfall, I don't know a million reasons, right? To, to say, Look, I, I'm looking to expand my skill set. If you are in a PO role, anybody who is a PM or is, is like a group PM or a larger, you know what I mean? Has other PMs in the organization, they probably will understand that like you don't have a lot of opportunity to be involved in strategy You need to be in the right type of culture to gain that experience with strategy. That's what I'm trying to say. Mm-hmm. took me a while to get there and to, to be open about that. Like, what can you read to like, what I would say is what I was like, the, the I inspired by Marty Kagan is a book. I tell everybody, everybody. I'm like, You gotta read that. Empowered, Inspired and empowered. Yeah. Inspired. You should know the, you should know like the gold standard of the, you know, and people online and stuff will be like, it's not really reality. I was like, it doesn't have to be reality. It has to be a good goal that you're shooting for. And if you can do it where you can, your leadership probably be really happy with you to be doing a little bit of it. Yes. As opposed to just being like, Well, what do you wanna build next? Okay. What? You know, And then the metrics turn out, you know, Where you didn't really make an improvement. And then if you read that book and it does, you're like, Wow, I don't understand how to apply any of this. Like the, the, the escaping the build trap that we just were talking about, the Melissa Perri book that we were talking about. That would be the next one, because that, that one is more tactical than Inspired. Mm-hmm.. And that book gives you a good understanding of the divisions, of your roles. And she will walk you through like, well, you should be involved in these activities and this is how it should lend itself. And you, at that point, you should start realizing like, Oh, this person is in control of that at my company. And between those two books. Mm-hmm., you should know enough to say, we don't really experiment and try things. Mm-hmm., we just do what people tell us. Yep. And then if you're operating that way and you have that like moment of inspiration from reading those two books, you probably also realize that you're separated from talking to customers. Artificially separated from talking to customers or intentionally so Yeah. Intentionally so, Right? Mm-hmm. and, now we get into the, now we get into the question of like, well, can you overcome that at your current organization? Like, maybe you can, maybe you really like where you work? I don't think I've ever, like in the almost a hundred episodes in the podcast, I don't think I've ever had a story of like this, that at X and then it did Z and then I changed the culture in my organization. Mm-hmm. from top to bottom and they said, Yes, we are gonna completely, I don't think we've yet had a story like that. Yeah. So, you know, I would say like, open your mind, be open to learning, be open to see what's out there, and, and. When you're looking for that leap, cuz it's not, you're right, it's not, it's not a step, step, step, ladder progression, stair step progression. It's not, it is a leap to say, Hey, I need to get out of the tactical and jump into being involved in the strategic and operational across the organization. I'm glad you brought this up. Cause this is a super interesting topic that is, could be a whole nother podcast. When I say it's a leap, you're actively looking to leap out of the tactical. Mm-hmm. and leap up to where your VPs and your, maybe your directors, if you're a larger organization, your directors, you know, coming up with vision or, or pitching a new, a new product. Hey, look, the example I used before where, hey, we need to divide, these set of features, they're really, you know, I'm seeing from the metrics. They're different users, they're different use cases, you know, whatever. Maybe there are different databases on the back end. Maybe it's easy to draw a dividing line. you are making the case to say, we should offer a new product line. We should rebrand this and offer a new product line. These new features, we price it differently. That strategy should come from the people who know the product the best, and those people are the product managers for that product, I would hope or should be. Yeah. Or should be so. And there's no book to tell you how to learn that there's, And the only, no, the only way that you can learn that in regards to market strategy, pricing, all of that is really time on the job to do it right? Yeah. You've gotta do it and you've gotta be with people hopefully who know how to do it. Right? You have some mentor or you have somebody who's, Or just, or just trying and failing and, and, and hopefully you've got a company that's, But, but mentoring would be the, be the, be the better option. Yeah. You labeled it as mentoring. I'm labeling it as sponsorship. Sponsorship and mentoring could be the same thing, but they could be completely different. This is a lot of times they hear like, Well, we have somebody who's sponsoring. Agile in leadership. So one person in leadership, right? When that person goes away, Agile goes away. Right? The the point is the person who's sponsoring, like, Hey, we need to be product led. Like, we're getting killed, we're getting creamed in our market that we're dominating and we've, you know, we went from 90% market down to 50% market, and next year we're projecting going down to 30% market, whatever. And you've got somebody on your executive team going, We need product people. Mm-hmm., because all of our competitors are product led and it's easier to sign up or whatever. And I see the decline. I see where we're going. You have somebody in the. Who's sponsoring that change. Mm-hmm. So I think the difference in my mind between sponsorship and mentorship is accountability. So if they're sponsoring you, they hold some level of accountability, Mentorship, not so much. Yeah. Maybe, maybe. I'd have to think about that. Cuz that's a, that's a different podcast. I don't know how deep I want to go into that one. I mean, it's an interesting one. Um, I, I, I read a book on that recently. I'll tell you when. The podcast, I really haven't read that. That was, that was totally outta Stormy's brain. You know, I, I I'm a freaking genius. No, no, no. Should have wrote the book. Yes. Yeah

