The Best Premiere Episode Ever

Episode Transcription:

Jay!

Rob, what's up, man? It's been a minute. Yeah, dude. It's been a couple years.

Yeah. I think the last time we did this was December of 2020. 2020 . Wow. Holy cow.

Dude, look at you. You looking back in your scrapbook and finding that date. That's sweet. I, I'm sure I've got a Polaroid in here somewhere. ? Yeah. Classic.

With a little heart button on it.

Oh, you're the guy. So sweet. I know. Yeah. I try.

So where you been?

Oh, you know, uh, working, trying to work, uh, selling a house, moving. Doing chores, gardening. I've been gardening a lot lately. Wow. So civilized. That's incredible, man. You have no idea how domesticated I am now.

That was the word I was looking for. Domesticated. Yeah. Yeah. Well, it's an honor to be back. It's an honor to be across the microphone from you. It is. Likewise, sir. All right, let's do this thing!

Welcome to the product hour featuring your hosts: veteran product leader Rob Hall with special guest host, Jay Cosgrove. Thanks for tuning in!

What in the world is the product hour well I have been in product management for nearly 15 years now. I have a background in building digital products in the agency space as well as in B2B marketplaces. And it is my absolute privilege and honor to introduce my dear friend, Jay Cosgrove.

Well, thanks Rob.

Yeah, it's an honor to be here. And, um, yeah, I've been in software for 11 years now. Been in product management in some shape or form for the last nine. And it wasn't always called product management. I think we're going to talk about this a little bit later. But yeah, I started off in project management in software and kind of figured out that I was actually doing product management and there was this whole thing called Scrum and blossomed from there, I guess.

Jay and I have built

dozens, if not, I don't know how many, an obscene number of software applications for startups and mid market and large enterprises. Uh, across many verticals. I mean, how many verticals have you touched Jay? I don't even know how many verticals there are, but easily five. Yeah. Quite a few at least.

Anybody know why they're called verticals? I don't know, but people love to say verticals. It makes you sound smart, doesn't it?

It definitely does. Yeah. So we're, we're here to share some of our knowledge and probably mostly have a good time. I feel like.

By joining the product hour, you are going to get.

Knowledge, wisdom and experience from Jay and I about the process of building products from the ground up. And we're going to talk a lot about product management and business generally. However, you're also going to get to hear Jay and I shoot the shit on any number of topics. And because this is not the official podcast of any company, we may occasionally use foul language.

Um, sorry, trigger warning. Uh, but not too much though.

We're here to have a good time. Yeah. You know, I think at the end of the day, you know, as people, as humans, we're all looking for a tribe of some kind or shape or form. And someone that can experience our woes and laugh with, and I feel like, um, in the product world, there's a lot going on and, uh, to find a safe home, even on a podcast is helpful sometimes.

You're absolutely right. I, I can't tell you how important it is. I think for folks, especially in product management and product design these days to have, uh, A place of safety where their voices can be felt and heard and received warmly. And it's tough because out there in social media land, especially on the LinkedIn's of the world, there's a lot of, uh, cannibalization happening.

You know, I see there's, and we'll talk about this a little bit more later in the show today, but. It seems like there's an awful lot of finger pointing in the sense that, well, if you're a product manager and you're not doing it in this particular way, using this particular methodology, according to this very tightly prescribed definition of what it means to be a product manager, you're not really doing product.

Yeah. It's the like, it's the age old thing of like, I want to be the guy that's actually doing it right. You know? Yeah. And everyone else is doing it wrong. And got something to learn from me.

And by the way, please, please, uh, sign up today and buy my course that's not for free. Watch all my videos and, uh, do exactly what I say because I'm right.

I just happened to have a very expensive masterclass for you. Yes.

Ooh, do you

now? Take my money. So we're, uh, we're not that, uh, I think we've learned over the years and especially working, having a background in agency life, you gain a lot of flexibility when you've worked for a product agency and because you have to, you're kind of forced into it or you don't last really, you know, that's my take.

And so, I think we're, I would say we're both, we're opinionated, and we're definitely opinionated. Sure. And, um, but I think at the same time, we're pretty, uh, we're, we're pretty open, you know. What,

what are you open to, Jay?

Like, in your example of what a product manager is, or how a product manager can function, There's definitely wrong ways and there's definitely ways I would disagree with leading a team or building a product.

And we'll get into that, but I think in general, you're a little bit of a product of your organization and where you live and work. And I think that's okay.

Absolutely. I mean, I think this notion that there's only one right way to do product is silly. I mean, how many different highly viable, highly useful and profitable products are there on this planet?

No two of them are built and shipped and measured in the same two ways. Yeah, they all come from different organizations, from different people, from all different walks of life, different countries, nationalities, languages, et cetera. Having the willingness to embrace a plurality of approaches to building product is a good thing.

Yeah, I think it's good. We can all learn from someone else too. That's the other thing. I mean, it's a little cocky to be like, I'm the guy that knows all the things. I mean, there's a lot to be learned even from more junior PMs. Yeah. Don't be, don't be cocky, Jay. Yeah, I'll try not to.

Alright, so what are we getting into today, Rob? Well, that's really a great question, and I'm so glad you asked. So, a couple of things. I want to touch on Two big topics. And we've already tapped our fingers on it a little bit so far. One is a struggles in the market around layoffs and hiring a lot of people out there, uh, many talking about

the software market or product product manager market.

What market we talked

about? Uh, yes, you're correct. You're right. More product people. Uh, than I've seen in my entire career, at least have the little green circle that says open to work, uh, turned on on their LinkedIn profile. I've seen a lot of really good people who are very talented, who would be a gift to any organization, have a really hard time finding a job.

There's something going on in the industry right now. Yeah. There's no doubt of that.

Oh, absolutely. Other thing I want us to discuss a little bit is, is this debate that seems to be never ending about what the purpose and scope of a product manager really is. And this is where there are a lot of very, very strong opinions.

We certainly have some opinions on that topic as well. But I, I want to just kind of debate about the debate a little bit, uh, because I think there's very meta of you. Well, We're, we're going to get a little inceptiony on the, this whole product. What's a product manager, you know, what's the debate?

What is truth?

There we go.

Yeah.

Okay.

Thanks a lot, [Pontius] Pilate. And it was just Easter. Fresh on the mind. Yeah. Yeah. Uh, anyway, so I want us to talk a little bit about that. And because I think there's several different angles to that whole discussion that are being missed, at least in the, in the, the popular consciousness of social media.

So getting into the topic of the day, uh, thinning the herd, uh, there is. If you've paid any attention to news from the technology sector seen over the last year, really many rounds of layoffs at large organizations, especially those of the Fang variety. Uh, as well as others like Salesforce, even most recently, Amazon last week, uh, or earlier this week, uh, had a series of layoffs, several hundred people.

It was announced just yesterday that Apple is laying off some 600 employees from their top secret autonomous car division that of course they're not going. That was pretty top secret. Yeah.

I mean, that came out of nowhere. When I saw that, I was like, what? They're doing what?

Uh, I mean, talk about having a, An R& D project with 600 people staffed to it and nothing coming out.

Yeah, it's pretty top secret.

Yeah, but also tough for the people that just lost their jobs, you know. But so I, you know, I want to ask the question, what in the world is going on, first of all, and then second, well, For those that are in product, there's a struggle there because now not only have these people been laid off, but there's now a seeming oversaturation of product managers in the market and not enough jobs to go around.

And there's a lot of product people who are struggling to find work and some are getting snatched up fairly quickly. Possibly due in part to the fact they have well known logos on their resume. And there's others that I've, I've known who are exceptionally talented people who just can't get another job.

Curious what your thoughts on that are Jay?

Yeah. Well, you know, I'm a economics major, so I'm immediately going to go to the economy. And be really boring about it and just say, Hey, the economy is not in the best spot. Um, we also had this surge around COVID that I think was unwise. And at the time I remember just thinking like, man, this is crazy and unsustainable.

So what I'm specifically referring to is we had a lot of specifically government money flowing in or cheap money flowing in to various industries, the

COVID hiring spree.

Yeah, the COVID hiring spree and tons of people moving remote, tons of people making tons of money. And, uh, I mean, at the time, like I had multiple recruiters reaching out to me and, um, yeah, just nuts.

So we had that go. And then you just know that like, man, this isn't going to last forever. So I think we hit a bit of a bubble and I think the economy is in not in a, maybe not in the worst spot, but it's not in a great spot. And then we've also got an election year coming up. That's a thing. Okay. You know, so people are a little bit tighter what's going to happen.

And yeah, so, I mean, I go there. You also have the phenomenon of nearshore becoming more legitimate. So that's the thing. So

the nearshore piece, that's, that's an interesting point. Let's dig into that for just a second. Should we,

should we define nearshore? Do we need, need to?

Well, I think, you know, there's offshoring, which is a, often a pejorative term.

I think for a lot of folks, right. Pejorative or offshoring?

That's your vocabulary word for the day, kids. But yeah, I mean, sometimes offshoring is an effective method of getting more people on your team for less money, but that usually involves outsourcing either a project or an entire function of your team to another country. Very often it was India. Uh, often it was, uh, Ukraine before the war.

And Increasingly to South America or even the Philippines now. Um, nearshoring is, well, we're still going offshore, but we're a lot closer.

Yeah, Google says the difference is offshore is in a different time zone that doesn't cross over with your country's time zone, where nearshore is in the same innate time zone of your country.

That's a much better definition than the one I gave.

I've never heard that until I just looked that up, so that makes a lot of sense. It does, yes. So I think right now, the big boost I've seen, at least, is, uh, Central and South America. So you have, um, like, the DR is a big deal right now. You have Columbia.

There's a lot of crews in Colombia. Um, other various countries around that. And part of that, from what I've heard, I could be mistaken, but I think certain governments in that, in those regions, have, a few years ago, funded a lot of, Folks to go through tech schools or code cams or colleges even. And now there's kind of fruit of that in full teams being set up.

Um, that's right. Countries

while it is not as inexpensive as say, going to the far East. It is still a very cost effective alternative, especially if you need more headcount faster, uh, and you don't have the runway to support multiple six figure salaries plus benefits, uh, for onshore teams.

And the quality is different.

Like I've worked with some of them, not all of them, definitely not an expert, but I've worked with some nearshore teams. And I'm very picky when it comes to teams. You know, I'm in product management because I love working with the team. And so I want my team to be the best. I want them to be able to trust them.

And I will say some of the near short teams I've worked with have been pretty top notch, been great at what they do, and I'm sure not all of them are created equal, but the ones I've worked with have actually been very impressed with that, with their, uh, just their training and their communication, you know, which is, You know, sometimes lacking when it comes to offshore or at least in my experience.

So that creates an interesting challenge if we are offshoring, nearshoring talent. And I think the majority of these layoffs really aren't because of that phenomenon necessarily. I think the majority of the layoffs we're seeing is business units being shut down, like Apple, Apple's car division, for example, um, or whole product lines just being canceled.

Um, what really is the issue there? And I'm looking at it from the perspective of the product manager. Is there a lack, is there a lack of value that's being demonstrated? Because these are, these are all organizations that are highly profitable still. It's not like Apple's going belly up. It's not like Salesforce is struggling to, Well,

maybe.

Maybe. I don't know. It depends. I mean, probably not, but like, still, they, when they, when they do layoffs, they do large layoffs and I'm sure there's big decisions kind of driving that. Big financial decisions. Reasons for that, you know, yeah, well to your point value. I mean like if they don't see the future financial specifically Value of whatever that's that piece of software or that whole initiative then that's probably a reason

Well, I think we have this issue of growth in a capitalist economy.

Everything is not just about profitability. It's about growth And I, this is one area where I typically will turn to Jason Freed from, uh, 37 signals or base camp for his wisdom on that topic, because he preaches this gospel of building a sustainable, profitable business. If growth happens organically, that's great, but growth isn't necessarily.

The light at the end of the tunnel. It's not necessarily the goal. The goal is to build a sustainable, practical business that generates a profit. And, and I think we've, we've got this interesting dynamic where these layoffs are happening in organizations where they may have highly arbitrary growth goals.

In order to satisfy, say an investor or a group of stockholders or whatever, shareholders, whatever. Um, and if the growth goal is missed, then there's consequences for that. Yeah, that's definitely a thing. And I think that kind of honestly sucks because it's a little like creating magic. It's not to say that, I mean, think about how many times have you seen the title growth product manager over the years where a PM's role is tied to growth.

I mean, I would argue that Any product manager who's responsible for delivering value, which should be all of us. We're all tied to growth ideally. Yeah. But how much and over what time horizon is, is certainly a variable that's up for debate and up for negotiation within, uh, one's respective company.

Yeah.

I mean, I think all those things are true. And so, I mean, you kind of. In that statement are saying two things at once. Like you're saying the, we're all responsible for growth, but at the same time, growth can be overstated or overemphasized, right?

Well, well, I think it's the difference between organic and arbitrary growth.

Right? And to say, we're going to grow 25 percent year over year this year without a clear strategy, without a clear plan, without any clear understanding of the fundamentals of the business, we're just going to magically materialize this growth, that's a very different discussion than, well, here's where we are, here are the logical steps that we're going to take, here is what our customers are saying, here's the need that we see we have an opportunity to fulfill in the marketplace, and if we fulfill that need in this amount of time, We have a reasonable expectation of that effort bearing some amount of fruit this year or next year.

We don't know, but there's, there's definitely a sense of, of focus and maturity and, um, what's the word I'm looking for? Oh, yes.

Effort involved there. So you think it's a factor of that and just like companies overstating their, their growth goals, essentially not, not making them and then cutting teams. I think it's more around lack of strategy.

Or naive strategy, maybe. Potentially, sure. Absolutely. I mean, how many AI driven companies are out there right now that are spending gobs of other people's money that are going two fold?

Yeah, a lot of them. A lot of them. Yeah. And like 99 percent of them, that's too many, like 75 percent of them are based on chat JPG.

Yeah, right. Yeah, we should, we should build an app, Jay, and name it, you know, PM dot AI. I mean,

so what would your app do? It would, uh, forward emails, right?

We don't forward emails. That's ridiculous. We do a lot more than that. Yeah. Yeah, that's a great point and I mean, I think a lot of that can be overstated at times. And I think that's the reason why Basecamp is kind of one of those like ideal companies to work for because it just seems from the outside looking in at least and from the books you read from their, their founder, like it looks like a more ideal, less chaotic environment to work in.

Which as PMs is kind of what you want, I would imagine. I mean, there's some PMs that are built different than me. So I'll, I'll acknowledge that for sure. But it's like, I want to work with a good team and be proud of the work that I'm, I'm working on. Absolutely right. Deliver software. I want to see results, but at the end of the day, I don't want a lot of chaos.

Like I want just a clear direction and, and then go do the thing.

Yeah. I couldn't agree with you more. Whenever I've been able to focus. With a team, partner with others, do really great work, see the, it resonate with the customer and then they keep coming back for more, like it doesn't get better than that.

Yeah. It's pretty great. Very fulfilling. Yes. I think that's one thing. This is definitely a tangent, but one thing that's interesting about being a product manager is sometimes you have this feeling that you don't produce anything and what I mean is more like tangible things, right? So like you look at a software developer on your team or you work, you work with a UX designer.

And they design this thing. And at the end of whatever this certain period of time, they have this body of work that they're really proud of, that they can say, I did this thing. And as PMs, you don't often have a lot of physical things that you can hold onto and say, I did this thing. It comes in big chunks that are delayed.

It's like at the end of a phase or a release that you're like, you get that moment of satisfaction.

Yeah. Yeah, yeah, yeah. That's exactly right. Yeah.

Okay, on the topic of value.

What a, what a loaded word. Can we just say that?

Well, yeah, that's, that's kind of the point of the question is what is value? Everybody loves to throw that word around as if there is one singular definition of what value really is and what it means to a company. And, and I think we can agree that value should equal something that nets a financial return.

Yeah. In the black. At least.

Yes, dollars. Dollars. Value can take on a lot of different forms, right? Like it would be an incorrect statement to say that the creation of a detailed design system for a SaaS company is not valuable. Of course it's valuable, but can you put a single dollar amount on the value of that thing?

Yeah, exactly. I mean, I think this is where, I mean, there's lots of discussions that spin off of value and how you prioritize things. KPIs come to mind. That's a big, you know, big, or OKRs specifically, you know, um, have a whole convo on that if you want to, but um, Essentially, I'd rather drink

Drano than talk about OKRs.

Yeah, yeah. But essentially, you know, Our work should be laddered up to value in some shape or form. And it doesn't mean like you said, uh, like a design system or something is a support piece, but it does support something that also produces value, you know, financial. In the black dollars and cents.

So maybe there's categories of value.

Sure. Value that can be directly realized versus indirect value that contributes to the whole, but in a way that may not be directly measurable by the business. I think it's one of the challenges for product manager to be able to articulate that type of value, especially to executive stakeholders. The number of times I've heard you're working on things that are not valuable.

Hearing that statement is a, honestly, it's an instructive reminder that even though it may seem obvious to me, the PM, it isn't always.

Yeah. And I think the minute you dive one step deeper into what that means, you get into the conversation around features and delivery. Oh my

God. It's funny to me, most people in the product world nowadays have a serious allergy to those words.

Delivery and features. Oh, definitely. They are trigger words if I've ever heard a trigger word. Yeah, trigger warning coming up now. I don't think features are the enemy. Yeah. I don't. I think we've created This top down dictation of what problems to solve and in what manner to solve them in the form of a list of features.

That is really the the boogeyman that we're after here. But yeah, what do we call

that the software death march?

Yes, absolutely. No one wants to work for a feature factory. However, if you really break down what it is that we do, We figure out

what features to build. Well, well here, here it is like to tie it up to value is, um, it's features that create value.

Right. And, and that's kind of the North star is like, what is actually going to push the needle, you know, to use, okay. Our language, like what is the objective that we're headed after? And less being tied to this specific feature in the app, you know? So for a PM, man, even you saying that gives me just like a frustrated mindset to put it nicely where, uh, where I hear it.

And I'm just, because I've done the, I've done the software death March, you know, where we're just working against a list from some executive is out of touch with the year user, right? That's the

concern. You, you and I both work, have worked on projects where we're not. Thinking critically about anything that we're doing.

It's just, well, it's got to do this thing and it has to do this thing and it has to do this thing. Why does it have to do those things? Well, because the sales team sold them to some client some years ago and, and they'll terminate the contract if it doesn't do the thing. Well, does the customer even use that feature?

Well, no, nobody uses the feature, but it has to be there. Like, okay, that's the kind of thing where the word features rightly become, uh, anathema.

Yeah, because there's not a clear line to value. That's the thing is like the minute you've essentially gone through your, if you're doing a, a well researched in design phase, you know, for whatever it is, a feature or an app or an MVP or whatever is you, you are trying to get, To another word job to be done that the user is looking at, right?

Like the, the user actually needs the reason that they're hiring you, you know, or hiring your app to, um, to be in their life and on their phone, you know, you're looking for, how do I solve this thing? And the minute you see, we are solving this thing. Then you're like, okay, this feature is gold. Right. And it's totally fine.

Like, I mean, at the end of the day, dev is working off the list. Like you said, of well defined, hopefully requirements or that build into features that get launched and often have feature flags, you know? So, I mean, yeah, there you go.

Yeah. We don't call them opportunity flags. They're feature flags now, but I think you make a really good point there, Jay.

You, you use my favorite expression, jobs to be done, a huge fan of that. Um, I think, you know, there's something else here though that I, I think is, another tip of the hat to the good folks at 37signals, one of the things I love most about the shape up methodology, uh, that they utilize over there is the idea of having a betting table, where they, The whole leadership team and the product team, they all get together and they make proposals about what problems they believe are the most valuable to be solved.

And then the interesting, I

don't know if I've heard that. It's really cool. Wow. So it's like, literally they're, they're sitting around. Oh, I assume it's like a virtual table like online or whatever. Yeah, sure. Okay.

Right. It's a metaphor, but it could be a real table too. You know, if you're, if you're in office, but the point being is, Each product manager or, or business leader, whoever you are, you're putting together a structured proposal for something and, and you're tying it saying, this is a problem that the customer's having, or here's an opportunity that we perceive is of high enough value that we should make an investment in doing something about it.

And you put it all out on the table and then the leaders in the business make the decision as to which bets they're going to make. That year or that quarter, then they prioritize them accordingly. And then each team has a constrained amount of time to go solve for each bet. There you go. And I think it's super, super simple and it's super elegant.

And I think that the whole crux of the outcome there is that they're going to ship something. That's going to directly solve the problem, but they also have a built in failsafe mechanism that if they get into discovery just far enough and realize that they're not going to succeed at solving that problem in the given amount of time, then the business has the opportunity to say, well, this is important enough that we're willing to invest more resource.

Or to say, nope, thanks for your effort. We're going to put you on something else now. I love that

it's even termed as a bet because that's the reality. Yeah,

exactly. I

mean, you're doing everything you can. And I think Agile and MPPs and all those kinds of things are structured in a way. To help reduce risk, right?

So that the best, the bet is more, um, or less risky, you know what I mean? Like more confidence going into the bet, but at the end of the day, it's still freaking bet dude.

And I think that's the thing that no matter what tools you have in your toolkit for doing good discovery and assuming. Well, hopefully if you're a good product manager, you're always doing discovery.

Um, you're always talking to customers. You're always speaking with sales reps and, and customer support people to learn. The reality is you don't know until something gets to the market, how it's going to perform. And you just, you don't, it, it is, there's always, always a

risk involved. Yeah. And that's why you want to get to the market as quickly as possible.

Yeah. You know, and test it. You want to test it. You want real users on it.

What's another word that people are allergic to these days?

Delivery. Delivery. I think there's a connection. And it's not wrong, but this idea that if you're in a feature factory, your sole purpose is to churn through tickets. If you're a product manager, your job is to write tickets based off of some arbitrary requirements that have been handed down to you from on high.

And if you're a developer, your job is to not question those tickets or ask critical thinking questions, but to just chug through them and deliver the work. Now, I would argue that Similar to my argument about features shouldn't be a dirty word, I don't think delivery should be a dirty word either. And I do believe that product managers should have shared responsibility for delivery.

Now, I, I, I strongly disagree with organizations that try to put responsibility for delivery squarely on the shoulders of a product manager because there are so many variables that are outside of PM's control that can affect successful delivery. However, a PM always has the ability to communicate. And if there's one thing we ought to be doing better than anybody else, it is communicating to the organization, progress, difficulties, pain points, obstructions, blockers, whatever you want to call it.

Um, things that are hindering success.

Yeah. I was told pretty early in my career. By a VP of engineering. He was like, your first and foremost job is to raise the red flag. It's like when things are off, when you feel like they might be off, when there's something going awry that you raise your hand, you raise the flag, you, you, you know, you call a pause, you bring attention to it from management or people that need to see it so that as early as possible, things can be dealt with.

And that was really helpful to hear. Like I needed someone to tell me that because it's, to your point, the reason PMs and a lot of companies are frustrated with scrutinizing over or being scrutinized over by, uh, on the term of delivery is usually because there's a lot of forced delivery. There's a lot of, um, deadlines that are picked for them, you know, for various reasons.

And that's, I mean, to be fair to the business, Um, it's a business, you know, at the end of the day, there's dates you got to hit and there's like, there's going to be times where you got to work a lot of hours to make the thing happen. But hopefully as a PM, you're figuring out how to make that more.

Reliable like your predictions and your estimations, but yeah up front freaking hard to do that So many things out of your control if you haven't worked with a team for a long time The term delivery is going to scare the crap out of you.

But jay, what about work life balance?

Yeah, I mean That should be a thing.

And like, frankly, I'm not going to work somewhere that I don't have good work life balance. But at the end of the day, again, you, the PM, you're responsible for things. You got to make sure you can deliver the thing. And, um, and to do that, there's going to be times where you got to work real hard, you know?

Jay,

uh,

how do you balance the concern between hitting deadlines and delivering things of quality? Because, I mean, how many times have we, we worked on something where an arbitrary deadline gets set, we push back on it because we know there's more work to be done than in the time that's allotted, the dev team starts freaking out, the design isn't fully locked, there's approvals that need to be had, we say it can't be done.

Leadership goes, Oh, yes, it can. You have until next Friday, you better be prepared to put in extra hours. And suddenly team morale sinks into the toilet. How do you address that? But on the other side, how do you still deal with the manifest reality that if you don't hit a date and you don't deliver something, you're hosed?

Yeah, I think it would come down to why, like, why are you in that predicament? Like if you're in a situation where that is the regular, Work life balance, you know, where like your, your work life is literally just, um, is that like emergency drills all the time happening, then, um, you probably don't want to work there.

Like, it's just not a clear understanding of good team, like morale and like how to, you know, not burn out a team, but actually create a team that works and enjoys their work and works quickly. Um, but yeah, I mean, it's. It's hard to answer that question. I mean, how do, how do you balance it? You educate, you do your best to predict and continue to raise that flag, right?

And then if there's still no understanding and acceptance of it, I mean, if you're at an agency, um, there's a good chance that client's not going to be with you for long, you know, either they're going to get frustrated that you're not hitting their deadlines that they have prescribed, you know, no matter how naive they are, or that you as an organization don't want to work with them because of the type of situations they put you in.

Or, uh, if you're an internal company. Yeah, your job is just to educate pretty much. I mean, you can't really do too much else.

I'm happy to be told that I'm totally and completely wrong on this, but I feel like this tends to happen most in organizations that have a veneer of agility, but they're really not agile.

Yeah. There's this, this built in like anxiety and, and honestly, uh, a misinterpretation of Agile principles in the first place that, Oh, we can't have deadlines. Well, yeah, you can. However, I'd go back to the shape up methodology and people are going to get sick and tired of me talking about this, but what a fan boy you are.

I totally am. Yeah. I bought the book and everything, literally, literally, but they have a set of rules. frame of time. You have six weeks, period, the end for any given problem. You're going to solve it in six weeks. And we'll have this debate when we talk about contract types and things like that down the road, but fixed time, flexible scope.

And I think that's the problem. Yeah, you can't

fix two, two of those.

No, you can't. You can't say this is the scope and everything's going to be that way and this is the time as well. It's, you get one or the other, pick it.

I mean there, there are obviously situations where you've estimated well enough and they've given you the budget you needed and you, you hit the date.

But it's pretty rare in custom software that it's going to be dead on. Um, and sometimes you could over, I mean that could be on the other side where you just completely, Overestimate it and you finish way early though. I've never been a part of that Um, I mean i've i've finished things early but never like way early I think a key thing here to go back to just overall delivery is that you need To be able as a pm to be able to trust your team And have a good enough feel that you're going to be able to do this thing.

And it's not just feel, I say feel, but I really, what I mean is like verifiable evidence from previous sprints of velocity and what the team can do. That's really what I mean, to be able to hit the date that's being prescribed, you know, and if you're not doing that, then you're not likely going to deliver on time and you're likely not going to connect that to real value and going to frustrate a lot of people.

It seems that one of the real soft skills are really kind of a thing that product managers need to develop in their muscle memory is just a good strong sense of a team's capabilities. And I would extend that from the developer also to design as well because I've worked with some designers who the quality of their work is exceptional.

But their pace is slower than others or some who they can turn out a whole lot of work really fast, but I know that they're going to require more direction and, and more revision time. So there's always a balance of concerns there, but with, if you're working on a team or multiple teams to be aware of people's strengths and weaknesses and their skill sets and figuring out how to compliment them.

And come alongside those people so that you are empowering them to do their best work.

I mean, I think this goes into our next topic of like a little bit of what, what does a PM do? But I think one of the most important traits is their soft skills, like you said, and the skills around how people work. And it's like, you're going to figure out very quickly, like you can't just set a date and crack a whip and make it happen.

Like it's, you're not, it's not going to work that way. You know, you might, you might get through a few sprints or an initial phase or something, but at some point you're going to burn out a team or frustrate them. You know, like the, what you want to do is be able to hear your team, like honestly have empathy for your team.

Support your team, you know, really be an advocate for the product team. And through doing that, you're going to figure out just like what you said, how do people work? What do they work best in? What scenarios do they not work best in? And that doesn't mean you don't challenge your team. It just means like you're going to figure out what their strengths and their weaknesses are.

And then accommodate to it with your, your scheduling.

Very good. Jay. When we come back after a brief word from our sponsors, we're going to discuss this debate around the purpose and scope of product managers. We'll be right back.

Are you starting a new podcast? Do you have an existing podcast and you're looking to up the quality of your show? Do you need custom music or mastering work done, but you aren't sure where to start? Then call CastMate. CastMate is a full service podcast, audio, and music composition agency specializing in high quality, long form podcasts.

Where others focus on quantity, we focus on quality. With multiple packages to meet your budget and show needs, Castmate can be your partner in telling your story in the most compelling and immersive way possible. Give Castmate a call today at 770 765 7883, or visit them on the web at castmate. pro.

I've been such a baby because it's been a little cold up here in the mountains, you know, and, um, It's been like 60 in the mornings, and I'm just like freaking shivering. I can't get myself out of bed early Like yeah 60 in the house in the house. Yeah. Oh, wow. Yeah, cuz like the AC unit does the heat too You know, yeah, I started a fire We have a wood burning fireplace at this new place and I've started a fire every morning We have a blower that's built into it, which is pretty cool So it does a good job.

Does it work? The blower does okay. It's not great. Yeah. It's more like So if this is the fireplace front the blower like blows To the walls of the fireplace, which is weird. It's underneath it. So I think it's like blowing around it and then out. But if you put your hands in front of the vents, you don't really feel like airflow.

So my, my old fireplace in my old house was the same way. Um, first of all, you had to get the fire really hot to feel any heat coming out of it. And if you turn the blower on, it made an incredible amount of racket. It sounded like a jet engine taking off. Yeah, it's pretty loud. Um, but it may, you can feel almost no air circulating.

It was very strange. It's

strange, but we've noticed the kind of radiant heat and what the guy told me, cause we bought, we had to install this unit when we, Redid the house. He was like, you're gonna notice it, like kinda lengthwise, like, you're not gonna notice it a ton surrounding, but you'll be, it'll be wild, like kind of past your couch or whatever.

You'll start feeling the heat. We also have really tall vaulted ceilings, so that's an element too, where the heat's just like going up. Yeah. You know? Yeah.

No, I, I did too. I get it.

Yep. Yep.

All right. Jay, you, you claim to be a product manager? Uh, . I think you should prove it because. Okay,

so I assume what you mean by that incredibly rude remark is, um, Yeah.

I should define to you what I believe a product manager is. Sure. Is that what you're saying? Yeah. Okay. I dare you. You dare me? Okay. Um, okay. I'm gonna take a swing at this. I'm gonna, I'm gonna fail miserably, but I'm just gonna go for it. You'll, you'll be fine. Okay. Yeah, for all our listeners, very little, uh, preparation has gone into this definition.

So a product manager is responsible for the product team. That's what I would say. And where, uh, he's responsible for building a thing of value and with a team. There we go.

So you mean, does that mean you're leading the team? Yeah. A team of what?

Yeah.

Uh, you're leading a team, uh, yeah, I'm fired. Um, you're leading a team of typically software, uh, developers and designers and researchers. Yeah. Some combination of those. Sure. And depending on how mature your product is, maybe a CS team too, you might have customer success looped in there too.

Absolutely. Uh, or, or you're working with salespeople or enterprise account managers.

Marketing. Absolutely. Yes. Go to market. Go to markets. Huge.

Yeah. So, I mean, you're, you're building a thing and like you're leading the thing and, you know, I kind of reject the, you know, CEO type thing. You've heard that I'm sure. Oh

yeah. That's garbage.

Yeah. I don't, I don't really like that. Like I think there's a lot more to my previous conversation.

I think there's a lot more to product management around team enablement and direction providing very clear direction to the team around the thing that you're building. Yeah. Um, then there is like this executive view of like, you know, you're the, you're the, What the boss that says you're fired kind of thing, you know?

Yeah, the ceo is the ceo and no one else is and unless the ceo Very specifically delegates certain powers and tasks and responsibilities to other people including say the chief product officer and his or her lieutenants You're you're not the ceo and that's it and Depending on the, and that, that definition can vary so wildly from one organization to the next.

And I've seen some where the CEO very intentionally delegates incredible amounts of responsibility to other teams. And then others where the CEO wants to be deeply involved in every decision of the placement of a button or the selection of a color on every page of the website, it runs the gamut. I would argue one's more right than the other, but it's still, it's a personal preference thing.

depending on the company, depending on its maturity and the size of the organization. Sometimes that's more right than, than what I think we often conceive as the empowered product team vision.

Yeah, I would agree. I think to add a little bit more to my definition as I've thought about it for one more minute, um, I think you're a bit of an advocate for two teams.

You're an advocate for, for the user, Team user, who is the user of your product, you know, and then you're the advocate for your internal team and which includes your business too. And so you kind of balance these hats of like, you're a big advocate, right. For making sure that you're providing value to the end user.

Back to the value word you're right ensuring that the business that you work for is seeing dollars and cents in the black And you're also at the same time advocating for the team that is building the thing and producing the value Yes, and so you've kind of got internal and external or maybe three teams if you want to look at it in those three bubbles I just defined that you're you're You're wearing a lot of hats just by nature of that.

I think your definition is really good, Jay. So thank you for that. I want to,

can I remain a product

manager? I mean, that's the question. You may. Yes.

Okay.

I mean, talk to your, your new boss, but I, if you're on my team, I'd keep you around. Yeah, I'm going to spin it a little bit. I think going back to our conversation about bets and taking risks, I think a product manager's first responsibility, number one, figure out what's next.

Number two, mitigate risk. And number three, figure out what risks the organization needs to take that have the greatest chance of succeeding. And when I say succeeding, I mean generating a profitable return. Uh, against whatever investment was made to take that risk in the first place.

Yeah. And like, none of that is wrong.

Like, these are all different lenses that are totally legitimate.

We are all George Costanza giving speeches about risk management. Every single one of us. Yes. Very quickly, I think we've come to this realization that we can have variations on a theme when it comes to defining what a product manager is and is not.

Sure. Jay, does a product manager do project management or should that role and responsibility be owned by a project manager?

Depends on the side of your organization. It depends. Ooh, depends. Yeah. It depends on the size of your organization on whether you're, you're involved in the project management or not.

You know, I think it's very hard for me personally and anyone, you know, that's been on my, my product teams knows this to stay out of the weeds and stay out of the project management. And that comes from years of. Lack of trust, which I'm working on. Um, but, but just like, yeah, I mean, you're, to some degree you're involved in project management as a product manager, but are you a project manager?

Are you saying you have trust issues? Jay?

I definitely have trust issues, dude. Yeah.

Hmm. Well, well, we'll have to dig into those in other, I would love,

I would love to hear in the comments. Any other product managers that have trust issues?

I certainly do.

Yeah. I mean, it would make me feel just a little bit better about my life because I'm working on it.

I'm really working on it. I've been given that feedback. Hey, you need to learn to trust your, your SMEs more or your individual, you know, contributors more in certain things, but there's just times where it's very hard to do that. Okay. But that, that goes right back to what

we were talking about with delivery.

Does it not? It does. Yeah. Like if it's your responsibility to own delivery, then yeah, you're going to be up everybody's, you know, craw trying to

make sure they're getting their stuff done. I mean, I'm not, to be clear, I'm not a micromanager. I don't desire to be a micromanager, but I guess maybe I take more of a like trust, but verify stance.

I'm going to like lean into trust, but I'm definitely not going to just be hands off and let someone else like present without me seeing what they're presenting.

No, absolutely. I know that you're working. I believe that you are working, but before we talk to the CEO, I would really like to see your work.

Yeah,

exactly.

So another thing, if you will allow me just another grandstand here on one more roles, okay, one more that the roles that a product manager is going to fulfill, let's get a little more tactical and less theoretical. So, Again, advocate of the user, right? So you're responsible in my opinion, more so than your UX team.

If you have a UX team, if you're so blessed to have a UX team, which if you have one, you are blessed just so you are aware, um, seriously, you are responsible for what the user's base needs are and like truly understanding those needs and how it works itself out into your software. You have to have that.

If you do not understand that, well, you cannot advocate for them and you are not going to create sustainable value. You might create short term value, but you won't be able to, you might get lucky. You might get a couple of releases, a couple of features in there that end up just circumstantially kind of working maybe a little bit, but at the end of the day, if you don't understand your users needs, you're missing it.

So that's my first thing I want to say. The second thing I'm going to say is, uh, related to leading a team. So likely depending on the size of your organization, you're probably leading a scrum team if you're an agile or you're leading some sort of, um, you know, crew of designers and developers to accomplish whatever task you're working on, build that feature, design that feature, research that feature, uh, or that, that need that is coming up for your user.

And as part of that, you're wearing potentially a scrum master hat. And a lot of times you might wear the, uh, business analyst hat, the BA hat of defining the thing. Another hat that you're potentially wearing, um, is as part of your advocacy is the account management hat. So as a agency, um, brat, I guess if you want to call it, I've kind of grown up in agencies, uh, different agencies.

I'm always kind of wearing the hat of, Working with my client, whoever that client is, and making sure the account as a whole is, is cared for. But internally, you're going to have stakeholders and it's the same exact thing, you know, they work internally. They have the same email address as you, but otherwise they are still someone that you have to care for your account for with.

You would be surprised that even within A single organization, how often you find that the stakeholders you refer to have competing interests.

Oh, for sure. Yeah.

Right. And so much of the job is gaining alignment with those people. Oh yeah. And not just to convince them that your way is right, But rather just to get folks to work together and to have productive conversations with each other.

Um, diplomacy is so

much what we

do.

Definitely. And like, and I, and then back to the soft skills thing, it's like, it feels like one of the most important things when you're hiring a PM or if you're being hired is just making sure you're a good culture fit to that end. Do you have the soft skills necessary to be successful in that organization?

Because certain organizations require different skills, you know, some are much more cutthroat. And you have to just be really, you know, kind of calloused in some ways or aggressive, more aggressive in some ways. And not necessarily negative, you know, it could just be a different type of culture where in other companies, it's just a lot more Kumbaya and you got to be very careful with what you say.

You know, I've worked on both spectrums over the years and uh, and I think that's part of the fit. But yeah, at the end of the day, you're trying to figure out how to work well with other people.

To kind of put a button on the conversation. One size does not fit all. And, and even from well seasoned, well meaning product experts who believe they have it figured out about this is the best, most effective, right way to do product, even they can be wrong because there are so many variables at play in any given organization about What product management is, the role that it has, its level of empowerment, the degree to which it is staffed.

All of that varies from one company to the next, and it really comes down to what the DNA of your particular company is that defines what product management is and what it looks like and how it functions.

Well, that's our episode for today, folks. Thank you so much for tuning in and listening to the Product Hour with Rob and Jay. Up next, we're starting a series called Product from Scratch, and we hope you'll join us.