(highlight:: Being a Product Manager Means Being A Ruthless Filter - Be the Umbrella, Not the Funnel
Summary:
In any company, there are countless demands from different departments.
Product teams must learn to say no to most requests in order to focus and be efficient. The constant interruptions and distractions can be overwhelming, so filtering and prioritizing is crucial.
Delaying decisions often leads to less importance given to certain requests.
The product managers act as the protective umbrellas, shielding the designers and engineers from too many demands.
It's not always perfect, but the team brings dedication, patience, and effective filtering to allow everyone to excel in their respective roles.
Transcript:
Speaker 1
One is that every single department in whatever company you're in has this really short list of things they want from the product and therefore engineering and design teams. And none of them have a list of more than let's say 400 items. And when you merge all those lists, you get something like 20x or 50x or 100x, the capacity of your engineering and design team. And so what that means for product folks is we are expecting every day to find some nice polite humane way to say no to 95% of all the stuff people want to give us and tell us is important and They've thought through. And that takes a lot of resilience and some thick skin and good technique. And it's wearing on a lot of folks and they move on to something that's a better fit. So I think we're trying to do a lot of filtering, intense filtering. Because if even a half of the 35 interruptions a day I get from Slack and email and post it notes and customer advisory boards and salespeople call me up in the other 15 channels. If we let even half of that through to the rest of the team, they'd get nothing else done. So how do we hold the line on whatever our plan was for the week and think about what we might consider next week when most of the fires are out and most of the excuses for all we need are those Things have disappeared. If you slow it down just three days or four days or two days, much of it evaporates and people move on. But if I let my designers and engineers get pelted the way my product managers get pelted every 13 minutes, which is why we're all ADHD, they'd all resign or give up. So we're the umbrellas here rather than the funnels if that's the analogy everybody likes. And we don't always get it right. But I think we bring a lot of heart to that. We bring a lot of, we try to bring patience and we try to bring good filtering so that the rest of the team can do the work that they've signed up to do that they're so excellent at.)
- Time 0:04:57
-

(highlight:: The Importance of Saying No
Transcript:
Speaker 2
So you're making it so that you're making them successful and you're helping them be successful. How? But I mean, that's a really difficult position, right? You're saying no with a smile hopefully, but no matter how much you smile, ultimately it's going to be no, no and more no. And as the person doing that and really kind of getting battered from many directions by people needing, wanting, trying to influence you, how do you maintain the ability to keep saying No and yet maintain the respect of the people you're saying no to?
Speaker 1
I think if we turn it around some, I don't think the goal is to say no. I think the goal is to show what we're doing that's higher priority.)
- Time 0:07:10
-

(highlight:: Roadmap Amnesia: How to Say "No" as a Product Manager
Summary:
Maintaining the ability to say no while maintaining respect is a challenge.
Instead of saying no, the goal is to prioritize higher-priority tasks. Roadmap amnesia is a common issue where new requests wipe out previous priorities.
Showing the current list of projects helps others understand the importance of existing tasks.
Sales teams may not be interested in other deals if it affects their personal commissions.
Trade-offs and prioritization are key. There is limited capacity, so existing plans must be considered. It's important to involve stakeholders in the decision-making process.
Transcript:
Speaker 2
How do you maintain the ability to keep saying no and yet maintain the respect of the people you're saying no to?
Speaker 1
I think if we turn it around some, I don't think the goal is to say no. I think the goal is to show what we're doing that's higher priority. So things I always assume, there's a phrase we use sometimes on the product side, which is called roadmap amnesia, right? And it's the effect that as soon as there's something new I want or a customer told me or I saw an opportunity. My brain is wiped completely clean of everything else. And the fact that it's Thursday and just on Tuesday, we all agreed on the quarter's goals and we all agreed on what was priority and there were five things at the top when a, you know, particularly An executive, when a customer calls an executive up and says, I can't seem to get your three factor authentication working or whatever it is, right? That executive puts on their armor and drives through all the walls and knocks all the obstacles down, goes to product engineering and sometimes down and says, this is broken. We need to put this at the top of the list, right? Customers are suffering. Users are hurting, right? And so one of the first things I always do is I bring out the list of what we're actually working on. Okay. Here's the three or the five most prominent, biggest, most important projects that we're trying to get done this quarter. And you can just see the lights go on in the other person's eyes and the other head because suddenly they see that, you know, making sure that we're not violating GDPR for our European Customers may in fact be more important than fixing this particular issue, right? Or if they're on the sales side because useful to know, sales teams don't get paid unless they close the deal in front of them. And the fact that some other sales team had a bigger deal that got waived through isn't of interest to them, right? If I can go back to the VP of sales and say, here are the two of the huge deals we're supporting you this quarter out of band because we have to. If you want to sacrifice one of those two deals for this number five or number nine deal that's smaller, we'll do that for you, but you'll make less money this quarter, right? You know, in some ways it starts with the exclusive or description or trade off, right? Because in fact, there is no more room at the end. There's no engineering team hiding in my pockets, right? There's nobody sitting around on the design side eating bonbons and reading, you know, romance novels, right? Everybody's busy. And so good product folks will start with the status quo with the current plan with the list and say, I would love to give you what you wanted. Help me figure out what we've already prioritized that's less important than this. And then by the way, we're going to need your help going to all those stakeholders and convincing them that they no longer want what they wanted and they want what you want.)
- Time 0:07:42
-

(highlight:: Dealing with Executives in Product Management Who Won't Take No For An Answer
Summary:
As the executive, you have the final say, but sometimes it's up to you to negotiate with other stakeholders.
You can't just make vague promises, you need to offer specific trade-offs. If you want something special, you'll have to sacrifice other things.
And remember, the lifespan of a chief product officer is short, so the rest of the team will eventually get tired of always getting what they want.
Constraints are a reality, and there are limits to development and design resources.
Transcript:
Speaker 2
But do you ever find what I'm sure you do that the executive says, I don't care. I'm the executive. Yeah, yeah, yeah. Make it. That's what I'm just saying. Yeah. So, you know, they're the hippo and what happens? You get put in a position where you have to be the one going to those others stakeholders on behalf of the executive.
Speaker 1
Or we say no or we propose one for one trade offs here, right? Okay. Okay, Mr. Mizexac, right? We can do that. Here are the two things we're going to cancel, right? And you have to name specific things, not some vague, oh, yeah, we're going to look at the roadmap and pull some things out. That doesn't help, right? You have to say if you really want us to build this special cool thing because you just got off the phone with JP Morgan Chase and they said they'd spend a million with us if, right? Here's the thing we're going to throw out of the car window for Ford because I'm sticking with my analogy there, right? And here's the thing we're not going to do for this other customer. And you're going to have to take the call. You know, on the other hand, it's useful to know that MTBE, mean time between executives, okay? The half-life of a chief product officer is pretty short. I put it about 20 months. And coincidentally, that's about how long it takes for the rest of the executive team to get really, really tired hearing that they can have what they want, right? Yeah. Yeah.
Speaker 2
You know, just listening to you, what you're doing, obviously, is you're bringing in the reality of constraints, the fact that there's not endless cycles of development and design And so forth that are available.)
- Time 0:10:48
-

(highlight:: Examining "Can't We Just" in Product Management
Summary:
Sales and marketing often prioritize the money side, but executives unfamiliar with software development tend to expect quick and easy solutions.
They might suggest hiring an offshore team or assume that throwing more people at a project will speed it up. However, Fred Brooks's book Mythical Man Month teaches us that adding people to a project actually delays it.
The idea that hiring overseas developers who already know our system will result in a perfect product with no maintenance is flawed.
Despite this, people naturally want what they want and will justify why they should have it.
Transcript:
Speaker 1
No, it so turns out that the money side usually belongs to sales and marketing. But you know, the response I usually expect from execs who aren't really steeped in the software side of the business are any sentences, it includes the word just, as in, can't we just, Right? Or anything about how easy it is and it's probably only 10 lines of code and can't you just do it, right? And the other one that says, well, look, the customer is going to pay us $100,000 for this. We'll just take half of that and hire some offshore team, right? And that's coming to mind because I was sad to hear this week that Fred Brooks died, which most people don't remember. But he wrote the 1973 book, I think, Mythical Man Month. And he taught us that when you add people to the project later, it makes the project later, right? And this idea that we're going to grab some money, go hire a team and you tell me where Buenos Aires. And they're already going to know everything about our system. The thing they're going to build is going to be perfect and it's never going to be maintenance, right? It's simply wrong. But the natural human response is, I need what I need. So let me give you reasons why I can have it, right?)
- Time 0:13:21
-

(highlight:: Roadmaps, Strategies, and Vision Should Have Time Anchors
Summary:
In order to anchor our roadmaps and strategies, we need to attach time definitions to them.
A three month roadmap should be 90% certain, while a six month roadmap should be 70% certain. A 12 month strategy is necessary for anchoring our work, and a five year vision provides long-term direction.
However, vision alone is not actionable. When someone proposes a new venture that would take several years to develop, we need to focus on our current plans for the next three months.
Making hard choices within the three to six to 12 month window is crucial for shipping products in the enterprise space.
Transcript:
Speaker 1
So we talk about roadmaps and strategy and vision and we don't anchor them. And so I would be using phrases like the three month roadmap because certainly in enterprise space, we should probably be 90% sure what we're going to build in the next three months because There's a lot of moving parts. And if we have to change something we do, right, but I pegged the three months at 90% and I pegged the six months at 70%, right? I think you need a 12 month strategy so you can anchor your work in something. And I think you need a five year vision and I only say that because here in Portland, Oregon where I live, there's a dispensary on almost every block. And vision is something we all need, right? But vision is not actionable. And so when somebody comes at me and says, oh, we need to be in this other business, right? We need to be in the oil refining business. Well, that's like a five year or a 10 year or a 20 year trip, right? And I can say go off and do whatever thinking you want it to do, but here's what we're doing for the next three months, right? So attaching time definitions to these means that a three month roadmap is different from a 12 month strategy is different from whatever is bigger, right? And if you're not making a hard choice, it's in the three to six to 12 month window, at least in the enterprise space, you're not going to ship anything.)
- Time 0:17:35
-

(highlight:: Being a Product Manager Means Being A Ruthless Filter - Be the Umbrella, Not the Funnel
Summary:
In any company, there are countless demands from different departments.
Product teams must learn to say no to most requests in order to focus and be efficient. The constant interruptions and distractions can be overwhelming, so filtering and prioritizing is crucial.
Delaying decisions often leads to less importance given to certain requests.
The product managers act as the protective umbrellas, shielding the designers and engineers from too many demands.
It's not always perfect, but the team brings dedication, patience, and effective filtering to allow everyone to excel in their respective roles.
Transcript:
Speaker 1
One is that every single department in whatever company you're in has this really short list of things they want from the product and therefore engineering and design teams. And none of them have a list of more than let's say 400 items. And when you merge all those lists, you get something like 20x or 50x or 100x, the capacity of your engineering and design team. And so what that means for product folks is we are expecting every day to find some nice polite humane way to say no to 95% of all the stuff people want to give us and tell us is important and They've thought through. And that takes a lot of resilience and some thick skin and good technique. And it's wearing on a lot of folks and they move on to something that's a better fit. So I think we're trying to do a lot of filtering, intense filtering. Because if even a half of the 35 interruptions a day I get from Slack and email and post it notes and customer advisory boards and salespeople call me up in the other 15 channels. If we let even half of that through to the rest of the team, they'd get nothing else done. So how do we hold the line on whatever our plan was for the week and think about what we might consider next week when most of the fires are out and most of the excuses for all we need are those Things have disappeared. If you slow it down just three days or four days or two days, much of it evaporates and people move on. But if I let my designers and engineers get pelted the way my product managers get pelted every 13 minutes, which is why we're all ADHD, they'd all resign or give up. So we're the umbrellas here rather than the funnels if that's the analogy everybody likes. And we don't always get it right. But I think we bring a lot of heart to that. We bring a lot of, we try to bring patience and we try to bring good filtering so that the rest of the team can do the work that they've signed up to do that they're so excellent at.)
- Time 0:04:57
-

(highlight:: The Importance of Saying No
Transcript:
Speaker 2
So you're making it so that you're making them successful and you're helping them be successful. How? But I mean, that's a really difficult position, right? You're saying no with a smile hopefully, but no matter how much you smile, ultimately it's going to be no, no and more no. And as the person doing that and really kind of getting battered from many directions by people needing, wanting, trying to influence you, how do you maintain the ability to keep saying No and yet maintain the respect of the people you're saying no to?
Speaker 1
I think if we turn it around some, I don't think the goal is to say no. I think the goal is to show what we're doing that's higher priority.)
- Time 0:07:10
-

(highlight:: Roadmap Amnesia: How to Say "No" as a Product Manager
Summary:
Maintaining the ability to say no while maintaining respect is a challenge.
Instead of saying no, the goal is to prioritize higher-priority tasks. Roadmap amnesia is a common issue where new requests wipe out previous priorities.
Showing the current list of projects helps others understand the importance of existing tasks.
Sales teams may not be interested in other deals if it affects their personal commissions.
Trade-offs and prioritization are key. There is limited capacity, so existing plans must be considered. It's important to involve stakeholders in the decision-making process.
Transcript:
Speaker 2
How do you maintain the ability to keep saying no and yet maintain the respect of the people you're saying no to?
Speaker 1
I think if we turn it around some, I don't think the goal is to say no. I think the goal is to show what we're doing that's higher priority. So things I always assume, there's a phrase we use sometimes on the product side, which is called roadmap amnesia, right? And it's the effect that as soon as there's something new I want or a customer told me or I saw an opportunity. My brain is wiped completely clean of everything else. And the fact that it's Thursday and just on Tuesday, we all agreed on the quarter's goals and we all agreed on what was priority and there were five things at the top when a, you know, particularly An executive, when a customer calls an executive up and says, I can't seem to get your three factor authentication working or whatever it is, right? That executive puts on their armor and drives through all the walls and knocks all the obstacles down, goes to product engineering and sometimes down and says, this is broken. We need to put this at the top of the list, right? Customers are suffering. Users are hurting, right? And so one of the first things I always do is I bring out the list of what we're actually working on. Okay. Here's the three or the five most prominent, biggest, most important projects that we're trying to get done this quarter. And you can just see the lights go on in the other person's eyes and the other head because suddenly they see that, you know, making sure that we're not violating GDPR for our European Customers may in fact be more important than fixing this particular issue, right? Or if they're on the sales side because useful to know, sales teams don't get paid unless they close the deal in front of them. And the fact that some other sales team had a bigger deal that got waived through isn't of interest to them, right? If I can go back to the VP of sales and say, here are the two of the huge deals we're supporting you this quarter out of band because we have to. If you want to sacrifice one of those two deals for this number five or number nine deal that's smaller, we'll do that for you, but you'll make less money this quarter, right? You know, in some ways it starts with the exclusive or description or trade off, right? Because in fact, there is no more room at the end. There's no engineering team hiding in my pockets, right? There's nobody sitting around on the design side eating bonbons and reading, you know, romance novels, right? Everybody's busy. And so good product folks will start with the status quo with the current plan with the list and say, I would love to give you what you wanted. Help me figure out what we've already prioritized that's less important than this. And then by the way, we're going to need your help going to all those stakeholders and convincing them that they no longer want what they wanted and they want what you want.)
- Time 0:07:42
-

(highlight:: Dealing with Executives in Product Management Who Won't Take No For An Answer
Summary:
As the executive, you have the final say, but sometimes it's up to you to negotiate with other stakeholders.
You can't just make vague promises, you need to offer specific trade-offs. If you want something special, you'll have to sacrifice other things.
And remember, the lifespan of a chief product officer is short, so the rest of the team will eventually get tired of always getting what they want.
Constraints are a reality, and there are limits to development and design resources.
Transcript:
Speaker 2
But do you ever find what I'm sure you do that the executive says, I don't care. I'm the executive. Yeah, yeah, yeah. Make it. That's what I'm just saying. Yeah. So, you know, they're the hippo and what happens? You get put in a position where you have to be the one going to those others stakeholders on behalf of the executive.
Speaker 1
Or we say no or we propose one for one trade offs here, right? Okay. Okay, Mr. Mizexac, right? We can do that. Here are the two things we're going to cancel, right? And you have to name specific things, not some vague, oh, yeah, we're going to look at the roadmap and pull some things out. That doesn't help, right? You have to say if you really want us to build this special cool thing because you just got off the phone with JP Morgan Chase and they said they'd spend a million with us if, right? Here's the thing we're going to throw out of the car window for Ford because I'm sticking with my analogy there, right? And here's the thing we're not going to do for this other customer. And you're going to have to take the call. You know, on the other hand, it's useful to know that MTBE, mean time between executives, okay? The half-life of a chief product officer is pretty short. I put it about 20 months. And coincidentally, that's about how long it takes for the rest of the executive team to get really, really tired hearing that they can have what they want, right? Yeah. Yeah.
Speaker 2
You know, just listening to you, what you're doing, obviously, is you're bringing in the reality of constraints, the fact that there's not endless cycles of development and design And so forth that are available.)
- Time 0:10:48
-

(highlight:: Examining "Can't We Just" in Product Management
Summary:
Sales and marketing often prioritize the money side, but executives unfamiliar with software development tend to expect quick and easy solutions.
They might suggest hiring an offshore team or assume that throwing more people at a project will speed it up. However, Fred Brooks's book Mythical Man Month teaches us that adding people to a project actually delays it.
The idea that hiring overseas developers who already know our system will result in a perfect product with no maintenance is flawed.
Despite this, people naturally want what they want and will justify why they should have it.
Transcript:
Speaker 1
No, it so turns out that the money side usually belongs to sales and marketing. But you know, the response I usually expect from execs who aren't really steeped in the software side of the business are any sentences, it includes the word just, as in, can't we just, Right? Or anything about how easy it is and it's probably only 10 lines of code and can't you just do it, right? And the other one that says, well, look, the customer is going to pay us $100,000 for this. We'll just take half of that and hire some offshore team, right? And that's coming to mind because I was sad to hear this week that Fred Brooks died, which most people don't remember. But he wrote the 1973 book, I think, Mythical Man Month. And he taught us that when you add people to the project later, it makes the project later, right? And this idea that we're going to grab some money, go hire a team and you tell me where Buenos Aires. And they're already going to know everything about our system. The thing they're going to build is going to be perfect and it's never going to be maintenance, right? It's simply wrong. But the natural human response is, I need what I need. So let me give you reasons why I can have it, right?)
- Time 0:13:21
-

(highlight:: Roadmaps, Strategies, and Vision Should Have Time Anchors
Summary:
In order to anchor our roadmaps and strategies, we need to attach time definitions to them.
A three month roadmap should be 90% certain, while a six month roadmap should be 70% certain. A 12 month strategy is necessary for anchoring our work, and a five year vision provides long-term direction.
However, vision alone is not actionable. When someone proposes a new venture that would take several years to develop, we need to focus on our current plans for the next three months.
Making hard choices within the three to six to 12 month window is crucial for shipping products in the enterprise space.
Transcript:
Speaker 1
So we talk about roadmaps and strategy and vision and we don't anchor them. And so I would be using phrases like the three month roadmap because certainly in enterprise space, we should probably be 90% sure what we're going to build in the next three months because There's a lot of moving parts. And if we have to change something we do, right, but I pegged the three months at 90% and I pegged the six months at 70%, right? I think you need a 12 month strategy so you can anchor your work in something. And I think you need a five year vision and I only say that because here in Portland, Oregon where I live, there's a dispensary on almost every block. And vision is something we all need, right? But vision is not actionable. And so when somebody comes at me and says, oh, we need to be in this other business, right? We need to be in the oil refining business. Well, that's like a five year or a 10 year or a 20 year trip, right? And I can say go off and do whatever thinking you want it to do, but here's what we're doing for the next three months, right? So attaching time definitions to these means that a three month roadmap is different from a 12 month strategy is different from whatever is bigger, right? And if you're not making a hard choice, it's in the three to six to 12 month window, at least in the enterprise space, you're not going to ship anything.)
- Time 0:17:35
-