AA86 - New Product Owners and Product Managers

Alright, Om, you're hired. you are my product manager and, I, I bless you. You're in charge of my new product. Go figure it out. Woohoo. I am hired. I'm so happy., would you gimme some money to, to do this with? No, Sorry. There's no money. No money. Okay. I feel good. I've just been promoted as a product person. Yay. The first thing I do before I come back, , celebrating is to sit there and scratch my head and say, How do I go about doing this? Yeah. Right. What does that mean? Yeah, Yeah. I feel good, but I'm also confused. I'm nervous. I don't know what to do. That's what this podcast is all about. So, a new product person, you, you've been given authority, you've been given the funds to do something with. I say the first thing I would do is to go figure., why are we doing this? Is whatever I'm being asked, does that align with the organizational strategy, the vision? Is it taking us down that path? It may or may not, You may not even have a sway in this, right? Because you've just been told to do this, you haven't been told, go figure out if this is viable. Yeah. So that's the next thing is what's being asked. Feasible, right? You have the money, but is it feasible? Because maybe you are asked to build something that is technologically difficult it's been done for the first time, et cetera. So kind of understand that and then look around you and look to the left and right and go, me and who's army, How are we gonna build this stuff? Yeah., so once you figured out the, what, the vision of it, try and break that down into, , What can I actually work on? Not me personally, but a team. Oh, I need a team now. Right, Right. Yeah. So I was gonna say, let's, let's slow down, let's slow down your pace here. Yeah, yeah, yeah, yeah. And go back to your first question, which I think was the right direction, which is to ask why, why why, why are we building a new product? Why am I the product owner slash manager? We we'll just use product manager what I'm trying to say is that you've been empowered as the product person, the individual in charge of product for this product. Right. Am I also gonna assume that we're not scaling, we don't have multiple product people. Right. Okay. Yeah. So, The businesses come to you and say, Okay, hey, great., we want to do this product and um, we think there's a market for it. go do it. Right?, and I've seen this happen with people that come from all around the business. I've seen this happen with people that come from qa. Uh, believe it or not, I've seen this happen when people come from support. I've seen it a lot of times with I can't think of what they're called um, project, like project managers. Kind of, kind of, I've seen it with that too. basically people have somehow otherwise represent the customer anyway. Mm-hmm. getting tapped to saying, Well, now you are the product manager. You know, Hey, we're gonna take this subset of customers that you are already familiar with or this business domain that you already have expertise in, and now you're gonna go learn the skillset of product management. And here you go. That, that's, that's kind of like, I, I kind of went all over the place, but I, I've seen people from many, many different domains, right? But what they all had in common is they knew the business domain Right. But they didn't know the role. Right. Right. They didn't know what am I supposed to do. Right. So yeah, I think that's an important point. Just because you've just been put in this role doesn't mean you have, what it takes to succeed , in terms of the training that's missing there. Right., so that's the other thing. I you're right. That's, that's one thing that's key here before you go ahead and do something is, do I know how to do this? Mm-hmm., And if you don't, what do you do? You have some choices here, you. Get training, you could buy some consulting expertise in, somebody comes in and, and shows you how to do this. Sure., or you could just muddle through. I've seen that too. Right. People just muddle through and say, Well try and see because there's no training money available. That's the worst of all the worlds. But , Oh boy. Uh, like you just stumble on a whole different podcast that we're probably not gonna go down the road of on this podcast but, To focus back on what we're talking about now. We're talking about you've been tapped as the, if you've read the Working Backwards Amazon book, like they, the concept that when they launch products, when they launch initiatives, well call 'em initiatives cause they might not even be products when they launch initiatives. They, they pick a leader and they say, Okay, you are now, Om,, you are now the person in charge of whatever doubling our. Revenue that comes from x, y, z area of the website or whatever, right? And like, you'll go off and you'll build a team and you'll figure out you'll do experiments and you'll basically build products and features that lend themselves to your product goal, which is the, the directive that you were given and basically weighs heavily into creating your product goal. Where, where you started it on two things. You started with I need to develop the why. Yep. I want to be able to clearly communicate why to my team members and everybody, everybody in the organization, everyone that follows me. If leadership has not articulated the why clearly, like I will work with them to continue articulating it until I can repeat the vision, right? And, and, and paint the vision for everyone. Because I will try to, to, to lay it out in every conversation. And everyone that I talk to about the, like the elevator pitch of my. I will try to spread news of, of the why. You know, I guess evangelizes the word, right? Yes. Yes. Being a missionary, not a mercenary, rather, that, that kind of thinking. Mm-hmm.. And the other part is, , the why should directly inform your, inform your product goal. So you wanna start with the product goal up here, which is basically the same as the why you wanna start with the product goal up here so that when you're building the initial backlog and deciding what your team is gonna try and not try or stay away from or delve into or whatever mm-hmm. take ownership of or, or push off. You should be weighing everything that you decide to work on against the product goal. So the company has a goal, right? The company has a vision and a goal. The company probably has many goals, one of which they hand off to you. You take that it becomes a product, uh aka a product goal and everything follows and it gets held up to the light of that product goal. Yeah, that's, that's, that's the, the two things that I came away. So, we're at a point now where like Scrum, guide, kanban,, whatever, like people normally would think, Oh, like none of that stuff's even entered a picture yet. No. Like, we might even have a full team. They might, they might have I wanted to start the discussion from the perspective of like, Oh, we're gonna hire a new team for you and you gotta, the first thing you're doing is interviewing candidates or whatever. Cause you're standing it up from the ground up. Yeah. But, but you might inherit a team who maybe just end of life another product, or they might split a team in half they've been slowly growing a team over time or whatever. Like, it doesn't really matter. The first set of activities that you're gonna engage. is all of this stuff that, that, that I like. I think of some organizations I've been in, they're like, That's not development work. That's a waste of time. Oh, that's just a bunch of meetings that, you know what I mean? Yeah. A lot of conversations like that is like, well, it's not because we're like, when we were building the, when we're at the ground floor of the product, nothing exists. No code, zero code is written. All this stuff's important to hammer out first, I'd say. Yeah. I, I couldn't agree more. I'd say it's, it's critical because this is where everybody is going to be. anchor to Right. This, this is why we're building the product. Yeah. Before we get into even the what, so understand why, to your point, understand how it aligns with the bigger picture, the organizational vision, and then we can look at the product. So now you're focusing in mm-hmm. to your product, Right? You've understood the, the periphery, the scope, bounding, et cetera of it, how it fits into the other, products that the organization has, or initiatives for that matter. So once we start thinking about the product, what should come out of there is how how are we going to do this? And you probably aren't the person to figure that out necessarily on a technical level, I'm saying. Right?, you're almost like the conductor of the orchestra. Right. You may not play an instrument. Mm-hmm.. , so you need players in your, in your orchestra. So you need. A team at this point. If you've been given a team, are they the right team? That's the first. Do you have the right players on there? Right? That's that's where, the focus should be at this stage. Do they understand? So that's the, the challenge you have is if you understand the why and then what you're building as the product backlog, do they understand that? So you've gotta now convey that vision to them, Right. And not lose anything in the process. Everyone must be united in, at least the vision where we're trying to get to. Mm-hmm. there's a bunch of roads we could go down, but like you, you nothing exists on., Right? Nothing exists yet. Yeah. Except conceptually. So the idea is like, there are some things we need to do. I'm pulling outta the air. Hey I'm just gonna assume we're using Scrum. We're a development team. I'm gonna assume we're using Scrum. I'm just gonna assume it, right? People might be like, Oh, let's, how can you assume that blah, blah, blah, whatever. Like honestly, I don't need to use Scrum. I don't, I'm not really interested in being part of that argument. I'm just short-cutting us to say like, I'm going to assume just for the purposes of our discussion we're using Scrum. I, I could go down the road, like if I was actually doing this myself as a product manager, I don't need a framework at all because I, I would say, the most important thing is I need to know who the initial users were doing this product we're creating this product for. I need to know who those users are. So I'm going to go out into the organization and I'm going to try to cast as wide a net as possible to say, Hey, does anybody in the organization have contacts, like deep contacts in whatever, x, xyz field, whatever we're doing. Right? I wanna know people who know people in the pool of users that we're like, I mean, I would hope that if a company is deciding that they wanna put money, a significant amount of money to, to the point where they're gonna hire a team of developers and a product manager, et cetera, cetera, ui, ux, designer, stuff like that. Like they already have a market in mind.. Yeah. But, but, , even if they do, movers and shakers around the organiz. Probably have contacts. Like I wanna leverage those contacts to get my initial group of users that I'm gonna be working with regardless. Even if they don't, then I have to go out onto the internet or whatever, to conferences, whatever I like. I have to go out and drum up business like a salesperson doing cold calls. Hey Brian, , this, this, this market, this segment of the market doesn't exist, go create it. That's basically, that's like the hard way to do this. It is. And that's, those are the, the trendsetters people that are breaking into the market with a new product, let's say. Yeah. Yeah. I think, yeah, I agree with that. I think it's also important to understand not only users, certainly. How they would use it, What, what start to formulate, what does that product lifecycle look like? Is, is it one years, two years, et cetera? Because you've now gotta start delivering stuff soon. Yeah, right. Maybe I'm fast forwarding a touch, but if you don't understand the bigger picture when, when does this product, it's in its infancy, but when does it mature and then what's the tail look like? If you don't understand that, then I think you could misappropriate the funds in terms of the life cycle at least. Yeah, well, the other thing too is, this is the, the Jeffrey Moore crossing the Chasm book like boiler plate. Like if you are, if you need to find the users, if you're building a product and nothing like it exists and you truly have to create an audience. I'm not gonna say it's easy because those people may or may not have money. Right. The most difficult situation that I've been in for what we're talking about now is when you get into the situation where your company, if we're gonna talk about Jeffrey Moore crossing a chasm, your company is over here dealing with the late adopters. Yep. And then they wanna launch. So, And then, and then they, they, but the people in your organization who are kind of future facing, looking forward, like they see what's happening at the edge of the market mm-hmm., and they want to catapult themselves to the edge of the market. So they will launch a product group who is at the edge of the market, but the majority of business is the late adopters. So basically you have this very small business unit that like, honestly, like this could be a clip all its own that appeals to some people. Like, there, there are probably some people watching this that like, they're like, This is my problem. Tell me about this. the company makes all their recurring revenue and whatever off of these late adopters, they want everything in the software package. They want it all to be working all the time. They're kind of a adverse at change. They don't like their UI changing, they don't like new things popping in and out. Right. But the company also says, Okay, well I want a group working on the product that's way ahead, on the edge of the market and the people that they're querying and the people they're working with, and the people that they're, running surveys with and the people, they're, they're running beta tests and stuff with their software. They're not this, this pool of people that are normal users of their applications. Right. They're wildly different in the market. And it might be the same market. It might the market might be a big, big, big like operating systems, for example, like operating systems is a giant market. A giant market like a, a, a wealth of people using Microsoft and, and, and iOS desktop on, on laptops and stuff like that, versus like, the people over here are using Linux. Right. You know, versus the people that are like truly power users. I think of like uh, the, all the people working in the field of like, in, in network security and um network uh, penetration testing and stuff like that. Those people mm-hmm. The suite of stuff they need from their operating system is just different. They're just different markets. You can say, Well, oh, it's just os it's just os market. It's just os. But no, that's, I mean, it's a giant, giant market. We just, we just came into this. This space where you have the money, you figured out the the what, and now you're starting to look at the how. Right? You need a team. It's, it's, it's a given. You need a team. If, if you've been given a team, are they the right team? Do they have the skills? Mm-hmm., do you yourself have the skills right for your work as a product person? Well, that that's I feel that's a whole discussion that, , I, I don't know if it's represented here, but like, I'm willing to entertain it for like five, 10 minutes. Training is a topic that we're talking about now. Yeah. Okay. Training. Stormy podcast. Actually, now I think about it. If you were like a registered nurse, for example, like Stormy, like for her case, I, I invoked her name. So now I gotta tag her in the, in the video., And you're a registered nurse, and the company says, Okay, I need a subject matter expert. Let me go find one, pull them in. Now let me teach you, I'm willing to teach someone who's already a domain expert, the business domain of product management. Maybe I have, and I've hired product managers in house. Right. And I'm willing to have my product managers spend whatever, 25% of their time, X percent of their time, right. To, to just shadow the other person and train them and get them up to speed. Maybe I have training budgets, maybe whatever. A lot of companies are not that well organized as you know, you know? Okay. In, in reality, in the experience, Yes. That it would be even harder to say, okay,, I am trying to hire for this product manager position, but I can't find. Maybe because of cuz a million things, right? Cuz of my, the type of business I'm in, the type of experience I'm looking for, the pay band could potentially be a thing. Like I, I'm willing to train people. I am not willing to purchase a, a product manager who's already experienced, they could be in that position. Uh, yeah, absolutely. But there's also some other alternatives here, right? So maybe you bring in expertise, teach you about specific aspects. For example, systems thinking. If you're not a sure, if you're not aware of that take a course on it. Bring somebody in. Bring somebody in that can talk the team about it., domain driven design is another example, right? Yeah., so people can come in with our experts and come in and do a, a, a seminar with your team. So, so that's, that's something that you should be open to because you don't know all these things. We're focusing on the product manager themselves. In my current role and also previous roles uh, we use Jira. Boy, it's been been a while since I did that. Um, we use j uh, and in just make a drinking game in J um, I added a component called Capability. Mm-hmm.. And any story that I take on as a product manager that I'm taking on that story for the express purpose of adding the skill, adding learning to my team, I labeled the component. As capability. So at the end of a sprint, I can say like, X percent of the sprint was spent learning these things. So if you have a training budget the buckets that your HR people. B play the little game where they pay for things or whatever., you definitely should have a training, like I, I call it capability, but you easily could call it training, you could call it enablement, whatever. Yeah, enablement up UPS skilling. Yeah. Maybe there's so many different syms for this, whatever you wanna call it. Like, you could directly tie that component in Jira to your training budget. So automatically when the sprint ends, you send a report out and it was like, here's all the work items. We did this sprint that are in done, here's their components , and whatever the components are, Mr. Finance person, Mrs. Finance person, whatever that does the budget. Yeah. Take the percentage of the sprint that this was based on the velocity... There, there are other formulas to do this with, but, take this percentage and apply it to the training budget so at the end of the year, again, we can add up all of the, all of the, , time per sprint that was spent on training activities, Right. Capabilities, enablement, whatever you wanna call it. You can add it all up and we can get a real dollar figure right. To all that stuff. So I agree. And you know what, that's just a measuring mechanism, Right? Good. But at the, at the end of the project project, Oh. If you haven't spent a, a, a certain amount of money, Upskilling people Right. Then how do you expect success to come out of that? Because people aren't getting the skills they need. Right? So I think that that should be baked in from the beginning, right? So when you get that money and somebody says, Hey, congrats on your promotion, here's the money. Go build something. Mm-hmm., when you're looking at that, the visioning of all the things that we talked about earlier in the podcast, try and figure out how much upskilling you'll need to do with the team you have and go forth and allocate a portion of your funding to that, because that is critical. That's the pillar on which you're trying to build this product, right? And if that's shaky, How can you expect a, a solid product? Right. And I, and I would say like you can do this in Sprint for your team members. Yeah. if you're the product manager, you, you have direct control over this because you can choose to take on things to train your team up. And, in doing that. You're being a good leader. That's right. That's right. If I saw a backlog item to this end, which was basically about training or upskilling people, Right. I would think, Right. We're on the we're onto something here because there's recognition that there's a gap. Right. And there willingness to basically bridge the gap. This is awesome. Yeah. Well also there's willing, like now that cuz a lot of times like the product manager falls into like the, the, the boss. Because especially on teams where the product manager has budget. Yeah. Like actually has budget, it's like Well the other word for that is sponsor. Cause you're paying for it. They think the teams right? Cause I don't know. Well, I, I think, I think of the places that I've been where, , the entire workforce has been contract. So the, the product owner slash manager is the permanent employee and they have budget and then they bring on an entire team of developers slash scrum, masters slash whoever, BA documentation what, whatever deal people, testers, right? Yeah., and all those people are on contract. So it, it basically is the product person spending their dollars on buying features by funding the development team. In those companies that have worked like that, they've been hesitant. To spend any money on any story that would say this story is just a capability story enablement story, a training story. They, they don't, they're like, Oh, I don't wanna spend any money on training, especially training contractors. Oh, right. Yeah. Because they're gonna be gone is the thinking. Right? They're gonna be gone after this project. Well, I mean, look, how long are they gonna be gone? Like, how many months are they gonna be gone? Like six months, a year, 18 months, three years. Like how long is too long to not train people? We stumble on an issue that is super annoying to me. It doesn't matter who you're working and how long they're staying at your work center. If you're, you're in leadership, that's your job. You're, you're, you're the product manager. Should be called product leader, right? If you're the product manager , hey man, your job is to train and to make better everyone that you work with, look, make every situation that you're in. Let me think about how to, how to phrase this. This is a statement, which I don't know if it fits in the podcast. This is, this is a statement like a personal worldview belief that I have. I try not to be binary in my decisions cause I'm a product manager. I was like, it's forget, everything's a shady gray, Right? But I like on this one, I am kind of b I am kind of binary. Hey, I am, I'm coming out as binary. Um, on this one, I am kind of binary. Because I kind of think that there are people who say any situation I'm in, I want to make it better for the people who come after me. If I'm handed something that's garbage, I need to improve it so that whoever picks it up after me doesn't have to deal with as much pain as I had to deal with. And then, and then there are people who say, I had to deal with this mess, so you should just toughen up and be able to deal with the mess. This is getting like way meta in my worldview. There are two types of people. There are. I had it rough coming up, so I should either turn a blind eye or make it rough for the people that are coming up so they learn what I learned or like I had it rough coming up, so I should make it better so that people coming after me don't have to deal with the nonsense I had to deal with. Yeah, yeah. Essentially the difference between leave the world a better place or let people step in the do-do themselves, right. but you know, a lot of times, , you're within the confines of your own budget. How you're measured isn't necessarily on how you leave things. Mm-hmm., it's how you perform here and now. Right? Yeah. So that kind of, constricts people a little bit on what they can do. That's interesting. But I would say even within the realms of your own product, without that training component, you might get there, you might just get there late, you might have subpar quality. Right. So you'll you're still paying for it. Yeah. You're paying for it in the longer term, medium to longer term. Right. Of duration of the product, let's say. So why not just invest up front and get it right first time there's many benefits to, to that, other than just the, the, the, the financial ones. Right. reputation. Right. You don't wanna be seen as failing, failing, failing, and eventually modeling through. Yeah. You want to be seen as, yeah, you actually made a success out of this product, so you have to train. And this idea of, Oh, we're not gonna enable our. You know, at TPL or third party labor contractors Yeah. That's asinine because you are hiring them to do something with, they're knowledge workers and they don't have knowledge, so they're just workers. That makes no sense to me. so we started with talking about, you need to know why. You need to know your purpose. You need to detail a purpose and spread that evangelize that through the organization. Mm-hmm., right. And, and, and through your customer base. Cuz now, now you're, you're finding users and you're finding customers and you're building your group of people that you're, either testing your assumptions on or, or doing surveys or testing your ideas, that kind of stuff. So you have a product goal, you have an initial set of users. You've probably started talking to those users to build your, to, to basically seed your backlog. If we're gonna slice it to just the role of product owner and say, Hey, what should a product owner be doing from the ground up? Well, you're gonna need a product backlog. Okay. That your team pulls from, and your product backlog is built off of a bunch of stuff that you've tested. so in the beginning, your team is not gonna be, Potentially, Right. Potentially not going to be building functionality. I mean, maybe your team, maybe your team would be like building some infrastructure out and stuff like that to support what you're doing, but like they're not building features. No, you're right. So they're, they're building the architecture runway perhaps. Right? Maybe, maybe. Um, but they could also be doing some sketches just early prototypes, wire frames. Right. Pick your words, bring those customers in and get that feedback early. And so don't poke at it, look at it and say, Does this look about right? And then next time they they come to your, your group, you can say, Well, look, now you can poke at it a little bit, but don't push it too hard. Right. But we get feedback and so keep doing that. You're not delivering anything into quote unquote, the wild production just yet. Right. But you are definitely getting there. Yeah. The reason I bring up the concept., experimenting, Hmm. With users is because let's assume the quickest, like a rolling start to this race, right? Let's assume that you've broken off half of a team an already working together, established team, and you've broken them off into a, into a team. So they have a new product owner, a new, already established developers who, they know your architecture. They already have a definition of done, They already have working agreements. They already they, they've already worked through the how to work together for all of the, the tuckman's model stuff, like all that low hanging fruit that most podcasts probably like, just to hammer on, like the whole, they've glanced over all it, They, they, they just glossed over all that stuff. They've been doing it for years. Yep., but you've given them a new subset of users and now the team has to basically they don't have anything to develop yet. They have to figure out what to develop, so Right. Everybody on the team potentially could be engaged in what you just brought up, what you just brought up. I might cut all, everything I just said, I might cut out what you just brought up about wire framing and experimentation with wire framing and putting stuff around the customers. Assuming that you have a team that's broken off from an already successful team, already established team, they might go from like a building stuff and like being on deadlines of like, Oh, gotta get this feature. I've gotta get this feature out. They might go from that to, I'm not writing a single line of code anymore. Because we don't know what we need to write yet. Yeah. So all of our time is building wire frames, getting customers on the phone, running surveys, doing demos, stuff like that. You know, e every, every day and a half, potentially whatever, every two days, whatever it is. Yep, getting a customer on the phone, showing them the wire frame, or we're sending the customer wire frame, whatever you're doing. And now they're in the, they're in a completely different line of work. Quite honestly, and this is, this is uncomfortable for a lot of the developers. Developers, because they want to get hands on code. Let me alone, let me code. So I would say in my mind at least. Mm-hmm., here's the next thing. Right. So instead of every day and a half, two days, bring your customers in your sprint. That's right. Bring them into your sprint. They're sitting with the developers and they're ideating together. Sure. Your architect, they, I mean, real time feedback. Yeah. And do that for Sprint or two if, as long as the customer's willing to give you time. Now, if they can't, that's different, but get as much time as you can from that customer. Mm-hmm. in these ideation sessions. And the developers, like I said, they, they're eager to get hands on keyboard. But this is critical, right? Because this sets the vision becoming reality. You know? It sets you off in that path. Otherwise you're gonna build something, come back, correct it. Okay, now you have technical debt. Right, Right, you might have technical debt regardless, but I mean, at least, at least you know what it is. You know, at least like, this is, this is why, like a big revelation for me was the concept of breaking my stuff into alpha beta production like like it, because it's assumed at each of those stages. It's less of a, it's less of a phase thing. Because when I say it in like, Oh, it's a alpha phase, beta phase product. Like, it sounds like waterfall, right? Yeah. Yeah. Like, it's, it's less, waterfall and more of when I communicate the state of the product, it's way more clear for me just to use those boiler plate., terms to say like, Hey, this product is an alpha, which means for example I've got it on some test servers that maybe some customers have access to. Maybe any internal customer has access to. You can bring it up. Like we can demo it to a customer, but we have to be driving it, it doesn't scale. You can't have people all over the internet hitting it. Like it only uses, maybe it only uses a subset of data that is curated or whatever maybe it doesn't cover every, but that's alpha. beta, maybe like, maybe beta is like, maybe only customers, , a few customers have access to it. Maybe, , if we have a, like a steering committee or whatever, like some of those customers have access to it, that kind of stuff., maybe it doesn't scale or maybe it scales to a point. Yeah. You're getting to a pilot stage now, right? Yeah, yeah. Yeah. So, so the, there are certain, like basically what standards does the software meet, and in order to encapsulate all those standards in one term mm-hmm. I'm using those terms, I'm using those terms as a product manager , to express what standards the software meets at the stage that we're at. In, in. Because, because we might explore some features in Alpha that we might abandon when we decide to go to beta. Yep. I was at a company one time where as on contract, I was at this company and I would say that they were a product led company but I would also say they were like borderline being a sales led company because sales was very influential at that company. And they, they were very good. I mean, they were very in tune with what the customers needed and, and the customers' desires. And that I, I tried to partner as closely to the sales people as possible. Cause they were all domain experts. They were all experts in the actual software. So they knew what the software. Right., and they had a, they had a strong vision, which I had to try to roll into my product vision as the product manager of the company. You can have staged exposure to customers that when you were talking about the, the alpha and the beta or whatever it was it, that the, that is the biggest thing it does, is it sets expectation. This product has rough edges, Right? It's not intended for production use necessarily. Not the first one, not the alpha, perhaps. Mm-hmm.. Just, just get some feedback. Oh, I, I, I know what it was. I'm sorry. I know what it was. So the, at that company sales had a strong vision. Right. But their vision was also informed. By what the competitors' products were doing, because as as salespeople, they felt a lot of pressure. You know, they would go into a customer, they would go into a sale and say, Hey, , your, your product can't do X, Y, Z and your competitors can do, some can do X, some can do Y some can do Z. Like how come your product can't do all that stuff? Right? Right. And, and then sales obviously would come back and be like, Oh, our product has to do X, Y, Z. Right? So I, as a product manager has had to say like, Well, I mean, what the way to take that stuff in is to do some experiments with X and Y and Z separately. See how difficult they're gonna be to implement, take them back to my development team, do some refinements, right? Get a customer that really wants that functionality on the line. Talk about what they really need. Right? Because when, look, when you're talking about feature. Feature parity. That's, that's the word that'll get thrown around here. Yeah. You're talking about feature parity. Like, and especially when you're talking about it with competitors of mine, like you have no idea if that's like the worst feature they have ever implemented in the history of their company. If it just drags their database down and it's completely unprofitable and only one or two people to use it, you have no idea. Like, all you're seeing is like, well, our, our product doesn't do it and their product does it. So it like, that's where I like the alpha beta production., like again, I try to stay away from the idea of phases. Cuz again, it sounds like waterfall, but if I'm gonna treat it like product discovery and let's look at it in that light of product discovery, alpha beta production, maybe I don't wanna develop the whole solution. Maybe I just wanna develop like a, some screen designs or some mockups or something like that. Yep. That look like what the feature could be to see, or maybe add it like, , other applications do this, They add it to menus to see who clicks on it. You know what I mean? That the fake door feature, Right. Yeah., to see who clicks on it. Facebook used to do that back in the day, like all, all over the place. Right., to, to inform them whether they should be putting money into it. Because like, my thinking is we have no idea if a customer has that and they're just touting it in their release notes as like, Oh, here's our hot new thing. But it like behind the scenes, it is just not a good feature. Yeah. Like we, because we're not users, we, the competitor, we're not users of their product. We would not know if the feature is really good or not. Yeah. Use Jason Parity, as you said earlier, right? Yeah. And we can, we can really run ourselves into a rut, like a profit wise, you know what I mean? Like expense wise. I wanna pull us back to the, I'm pulling this back to the topic under the banner of your, you have a new team and a new product. Like if you're chasing parity with competitors, Oh boy. Like you run into failure really quick if you don't have, if you don't have like,, really aggressive, , Let me try this idea. Feedback loop. Yeah. Feedback loop. Yeah, yeah, yeah. Chasing parity is a dangerous slope because when you've reached parity, what happens, right? So then you say, Well, we got, we gotta get ahead of the competition. Now let's build in some features. You think these are useful, but you really have no idea. Well also like it when you reach parity, a hundred percent pardy are you at the end of your vision? Because you were just doing what the competitors are doing. Right? so do you now literally have no other good ideas? Well you, you end up creating bad features now to get ahead. Right? Right. And hope in the hope that that will give you a competitive edge. Right. So that is a bad idea all around. I I do think they'll, just to go back to this, I this, I, I don't wanna use the word phase either, but, staggered, I don't know. Right, right. Different ways of launching the, the product to get feedback. You could do that in a number of different ways in practice. Right. And they probably are as many, again as as we are about to talk about. So you could do things like, , dark launches, you could do blue/green deployments. Yeah. Right., using b testing would be a testing. Right. And then perhaps using feature management with feature toggles just turn on functionality at will for certain users in certain cases, get feedback. And if it all goes to part, turn it off real quick without having. redeploy software right there, there are probably just as many again out there. Yeah, right. Well that, that, I mean that like that's a great point. Like a fe feature toggles for your like I Ira throughout the term beta users, Right. Uhhuh feature toggle to turn on the feature for your beta users. So you have a subset of users that have access to this new feature. Let them shake it down. Or like, I've been in other organizations that have a completely different environment that has the same data. They pipe the data over from production to their test environment or whatever. Some kind of stage environment, middle environment. Yeah. But then they have like wildly new Google, you should do this. Hey, we're all old on the podcast. Like back when goo back when Gmail used to be like Google Labs, like ear way early, like when you had to get invited or whatever. It was Google Mail back then too. Yeah. They had, they had features that were labs. Functionality that you could like I remember you can go into their labs and you can add functions from their labs to your normal products. Yeah. You had to go into the labs portion of the product and add it to the individual. Because I remember Google used to have like, like used to have back when they were good. They don't have this functionality anymore cuz it was too good, it was too hot for tv . They, they had a mark as red button in Gmail. You can add the mark as red so you can go click, click, click and click a bunch of messages and hit the, or click all messages and hit the mark as read button. It was just a big button that says Mark as read. And like they don't have that button anymore. Like, doesn't exist anymore. Right. I think, I think you can go to the vertical elipsis and hit mark as read now. Yeah. But there is, there is that capability now. You can't add it as a quick function button. In terms of having features available to your customers Yeah. On a need basis or on a will basis, I guess probably the best thing to do is the example you cited. You know, let the users pull those in, right? So give them the switch and say, Right, try this out. Right. If it doesn't work, you can easily switch it off and give us feedback. Or you could get that feedback integrate that in. Mm-hmm.. So whether it works or not, you get feedback and if they turn it off right away, well that's a signal right there. Right. So there's all these things that you can use to your advantage. Mm-hmm.. Right. I do think that, Bluegreen deployments have an excellent, potential here, right? Because as far as the user's concerned, Everything is just in production, and then they turn something on, and if it doesn't work, they turn it off and you're getting the feedback how it doesn't get any more real time than that with real customers. Now of course, you want to narrow down the scope of that. You don't want that open globally to everybody if it's a global product. But, these techniques are available. Maybe your teams then perhaps need some training on how to use these things if they, if they're not aware of it mm-hmm. or if they haven't used them before. What if I come to you as the newly minted product manager and, you don't have a team yet? Well where would you go from there? Like, Hey, oh, you're the product manager for Product X. Like, go figure it out. And I I, I'm, I'm the head of the business unit, I could assemble a team for you. I can go around the business and be like, Gimme developer X, gimme developer. But I'm not going about it that way. I'm saying, Hey, you can speak with my name. You're empowered to get a team. Whatever you need, or if you don't want to touch anybody and you don't think we have the talent to do it, go hire people. Like you have a budget now. I guess I'll, I'll give my guidelines to you home. Here we go., thanks for being the new product manager., I'm gonna give you a bunch of money with your new title. look nice. Yeah. Think about that when we're talking about, We haven't talked about that. No, that's, And we won't. We won't. Cause it's not in this smart guest. Yeah. Look, listen I think, I think that we have the developers in-house to, to deal with your initiative. So, I mean, Think about the people in your house first, but if you need to hire outside, that's fine too. But come back with your plan to meet tomorrow. You know, take the rest of the day and tomorrow take 24 hours. Come back to me with your plan. Talk to whoever you need to do. You know, invoke my name. This is the top priority. I want your plan by tomorrow, 24 hours. I want your plan. What, where you go from here? Yeah. It's pretty aggressive. to go back with a plan. I'm, I'm an aggressive guy. Yeah, you are. You're an aggressive guy. So one of the first things I would do is just sit there and I'm aggressive, try and fi try and figure out, once I've figured out the what, which might take me 24 hours by the way. then I would partner with somebody at a higher level, not just a developer or anything like that. Maybe a, an enterprise architect, uhhuh, somebody like that to sit down and say, This is what we're trying to do. Yeah. You tell. What technologies we need that will drive the discussion on the capabilities and, and who do we need? Do we then have those in house or not? We have some in house, some not. Okay, well what do we need? Right? Do we just need somebody in for a short period of time? Do we need to go hire somebody, et cetera., so I would take that approach and the 24 hour plan that I would have would be super high level. It would be I met with Mary over here as our enterprise architect, and we sat down and we sketched out, these things. And this is the direction we're going in. That's my plan. Yeah. Yeah. And I need some more time to detail that out, some more. So I would kind of do it that way. Yeah. You're assuming here that by giving me money, I am not the expert here. Right. I'm not, I mean, technical expert, so I'm gonna have to partner with somebody, right? Yeah. Well that, I mean, that's the core of my question. Like I, I, leadership, I., I am already assuming that you're not the expert. Yeah. You have to reach out to people and, but, I'm gonna send a blast out or a message or whatever to my leadership team, department heads, whatever it is I'm gonna send up, I'm gonna send out a blast letting them know like, Hey, I have asked Om to assemble this team. He's gonna be coming to you guys. Clear your schedule. There's nothing more important than this. Mm-hmm. I'm also assuming I gave you some lead time to figure out, like so you can come into my office, we can figure out the why. We can figure out what the product vision's gonna be. Yeah. If it's not just me, sit down with maybe the members of the enabling team, again, assuming we're using Team Topologies. We did, we did a whole podcast on Team Topologies. You should go watch it. I'll mark it as a card. I think it'll show up over o's head and yeah, somewhere there. The members of the enabling team will help you ba basically my, my leadership in the organization. Like they could be technical leadership, meaning for sure members of the enabling team, right? Yeah. Technical leadership and leadership of the organization. We will work with you everything you need, because I, the leader in the organization am sending out this blast that says, Hey, only's not the product manager. Everybody work with him. You know, he has some things. I'm making it a priority for him to launch. I want all blockers out of his way again, like I the leader in the organization and now being the scrum master of like, all blockers are outta your way. Right? I don't know why it's such, I don't know why it's so like amazing of a concept. Well, that's empowerment for you, right? There are servant leaders that can move blockers. That's so, Oh, my mind is blown. so I don't know if I'll leave that area. No, don't leave that. Yeah. But yeah, so I mean, look, once I've got that kind of a, a green light, okay. The first thing again that maybe this is the first, first thing or the next first thing, but I would form a coalition, right? Sure. So I would go out and start getting to these people saying, You've got the email. Let's get together and start ideating. What's our next step? Right? Right. So now what I'm saying is, instead of sitting down in my office, in my cubicle, sketching out stuff, ideating by myself, I, I want a force multiplier here and get some other brain power in there. People that actually might know what they're doing. Right. Sit down and orchestrate that conversation. Right. And see what comes out of that. I don't know why I would do it any other way. I wouldn't, Well, I, I mean, I can think of a million reasons. I can think of the I think immediately of the product owner slash manager without a scrum master who's like, I'm don't wanna say they were afraid to go out into the organization, to go into like different departments or reach out to different, different places in the organization that they have not worked within. We're talking about mainly development concepts, but like, maybe the people you need don't work on development teams. Maybe the, the subject matter experts like going back earlier in this podcast where we talk about like, Oh, I'm working on software for registered nurses or doctors, for example. Like, I gotta find a doctor you do in the organization and they need to be part of my team. Now you do. whatever your day job is as a doctor, I also need you. To serve my team, I need you to basically be the subject matter expert that my team has access to. Where we're your pseudo part of my team, but also pseudo a a user stakeholder. You know that? Yes. That's the, that's the conversation that happens in that coalition that I mentioned. We haven't even got to Scrum Masters yet, right? Right. We're talking about what is it that we're doing and, and what's the next, who do we need? Well, we need to your point, right? We need somebody who can give us feedback. So if you're building software for medical use, we need that expertise, so whether it's a doctor, whether it's a nurse, however we need, Yeah. And so the point of it is that this need isn't something that I'm saying we need. It's something that we are coming up with, Right. That coalition is coming up with. Right. And then the next step after that would be to go get those people right. That you need. I feel like we can box this entire podcast and, and do it completely again from the perspective of, of maybe you are a scrum master and the organization comes to you and says, Hey, we. Spin off this new initiative. Ooh, wow. That's, that's gonna be an interesting podcast. What I was going is, I, in the leadership have delegated to my teams, Okay, you're gonna use Scrum and you're gonna somehow scale Scrum or whatever. Like, okay, I don't, I don't really care as long as my stuff's getting done. Right. Right. I'm not an expert. I don't know how to develop products. I, I barely have expertise in the domain. Then like, I don't know even know why I'm a leadership of this organization , honestly, I have no idea. But, but the point is like, I'm not an expert in the subject matter and I'm not an expert in Agile or scaling or software development. Cuz organizations have delivery leads, right?. So I'm gonna pull my, one of my delivery leads and say, Hey, I think we need a new team because this product, this, this product investment seems completely different than the rest of my pro. So you as a delivery lead, can you go out into the organization and figure out who should be my product manager, and then figure out how I build my team and then go deal with Jira to make it happen. Go deal with Jira to make it happen and go deal with, talking through whether they should be Kaban or Sprint or a Scrum or whatever. Yeah. And whatever these other terms I don't like I as leadership I'm barely involved in this. I really don't want to be in the details. You know, that reframing helps because leadership shouldn't even say we decided we're doing Scrum. That's up to the team. They should just say, Yeah, right. Okay, here's what we want done. You go figure out how to do this stuff. The start of this podcast was I'm going to my product manager and saying, Hey, you are now the product manager. Go like, you're empowered. I trust you. Whatever. Go and like figuring out your way. Now I'm kind of pivoting into, I'm going to the scrum master and saying, Hey, I wanna do all this product stuff and all this team stuff together. I know I wanna do., Now you as a Scrum Master go. I think this is the perfect cutoff time to say that is a different podcast. It's, Yeah. Yeah. In the start of this podcast, the leader delegated to the product owner. Yes. Go do this initiative, build the team, work through all this, build a vision, come up with it, do the research, build a user group. Build a product. We, we barely talked about building a product, right? In this podcast. and now I'm pivoting and saying like, well, now we're starting with the scrum master to say, peel this product off of the existing. Development team and effort, So basically we're now in the advanced portion of this podcast, which is not gonna be part of this podcast where leadership is delegating the responsibility of successfully peeling off the product from the rest of the product. Yeah. To the scrum master, aka delivery lead, aka, whatever you wanna call it. Right, Right. And now that becomes, how do you do it when you've been delegated this task and you are not the product person and you're not the development team members and you're not, whatever. I don't, I feel you could still be successful. You, you can different dynamics though, but as you said, that could be a different podcast. Different podcast, right? Yeah. All right everybody, thanks for staying with us this far and let us know what you think down below. Smash that like button.