Bring me problems. Don't bring me solutions.

Hello and welcome into another episode of Lessons in Product Management. I'm your host, John Fontenau, and today we're gonna talk about your problems. But not in the way that like uh therapist or a psychologist would talk about your problems. Today we're gonna talk about why problems are really the only thing that matters. That that that's a bit hyperbolic, but truthfully Problems are the the primary thing that matters when it comes to product management.

But before we dive in, I wanna take a step back for an experience that I had as a a young professional getting my first people manager job. So I was in my mid-20s doing contract work for Intel Software Group. And I had the opportunity to lead an international team of about 15 account managers directly reporting to me. And this was uh scary to say the least. I was, you know, just a few years out of college. I had a degree that had, you know, management and stuff associated with it.

But I had never managed before. And I was by far the youngest on our team in the US. There were some folks close to my age overseas, but My closest direct report in the US to my age was, you know, ten, fifteen years older than me. So it was it was a bit nerve-wracking and I didn't want to screw up. I wanted to do it right. So I I set out to read 30 management books, 30 of the best management books.

Uh, which ended up leading to me writing my own book on um why great leaders always follow. But that's that's kind of a a side note, not the main point here. The point is one thing I read and listened to over and over again. was this this theme, especially from like John Maxwell and and some of the the great leadership thinkers and writers. around don't bring me problems, bring me solutions. And and over time that's been kind of changed and and molded to

You know, if you're gonna bring me a problem, bring me at least three solutions and give me one to choose from, right? And a recommendation. I think I think I heard that recently on like a Lenny's podcast or something. But anyway, point being, I kind of grew up, so to speak, professionally with this mindset of don't bring me problems, bring me solutions. And as I got exposed to product management, eventually made the pivot into product management.

And now that I've been in product for a while in a in a variety of roles. I've learned that it's actually the opposite for a for a product manager. Or a product leader, right? Don't bring us solutions, bring us problems. And and I I think This is something that still product managers get wrong today, is that We have customers or we have senior leaders.

And they bring us solutions and like, hey, you should put this on the roadmap. I heard a customer ask for this. And it's like, that's great. Thank you for that feedback. But that's one data point, right? You can't base a strategy or a roadmap on one data point.

Unless you're, you know, selling to enterprises and that's, you know, you have a guarantee that they're going to sign whatever the size contract is and that's your first customer. Maybe you do it then to make sure the company stays afloat. But those are rare exceptions, right? Most of us are in situations where we're in established companies, there's a revenue stream, there's more than one customer.

And we can't just go and implement feature requests, right? So we need to have this mindset as product people. That when when people bring us solutions, we need to identify them as solutions. And we need to understand that solutions don't do us very much good.

Granted, some things may be obvious and it's like, Oh yeah, that's obviously something we should do. But in most cases, it it's helpful to take a step back. And to say, okay, they're asking me for something specific. I have no idea what the problem is. And if you can't articulate the problem you're solving. You shouldn't do it'cause you you can't stand behind it.

Right. Somebody comes later and like, hey, why'd you do this thing? And it's like, oh well, you know, Joe from accounting, you know, the SVP of accounting said this was a solution they wanted. So we did it like that. Anybody could do that role. They don't pay you what what they pay you to be an order taker, right? You can go do that at a restaurant. Don't do that in product management. So what you should do is take a step back. and ask yourself or the person asking you.

What is the underlying problem that's driving the request for a solution? Because people only want solutions to problems they have. If they don't have a problem, they don't need a solution, right? That's just kind of common sense. So flip it, right? And this takes practice, this takes skill, this takes tact to be able to have this conversation successfully and productively, especially with senior leaders.

But if you're genuinely curious about the problem and you're genuinely wanting to do your job well. it it should start to come natural where it's not pushing back and it doesn't come off as pushing back. It comes off as like intellectually curious of, oh, that's really interesting. Like what what's driving that? Right? Or

you might respond another way, like, oh, that's that's super interesting. Like, is that something that that you found when you were using the product? Is that something that came from a customer? Like, hey, what's driving this? really want to understand it better so we can go solve it the right way. Right. And and you kind of frame it subtly that way. I found that to work pretty well when you're like, hey, I want to make sure I really understand the problem so we can so we can fully solve it.

Right. And you could tell them like sometimes we've gone and we've implemented solutions and it didn't hit the mark because we didn't fully understand it. So it'd be really helpful for us and the dev team if we really understood the problem so we can nail it. Right. So now you're not pushing back, you're not saying no.

you're becoming a partner and a champion for the idea. And if it come if it turns out that it's a lower priority problem to solve, you can have that conversation later through the lens of the strategy. But really in that moment, it's not the it's not the moment to say, oh, that's not on the roadmap or oh, that's not part of our strategy. Cause frankly, you have no idea at that point because you don't understand the problem. Yeah.

If the problem is consistent with and coherent with the strategy, you might want to put a potential solution to that problem on the roadmap. You you don't know. So instead of coming off as defensive, really get curious. about the problem, curious enough to where you get excited, you want to understand it. You ask them for more information and and frame it in a way that makes it sound like you're going to take action on it. It doesn't mean you have to go build it. Taking action means

A lot of things. You could go do follow-up research. You could send out a survey. It gives you an opportunity to go get data to see how many other people have this problem. But without understanding that problem, you're really in a tough spot. to be able to push back immediately and explicitly to that senior leader. I've done that before, it doesn't go well.

Um, you you get your product leaders um getting feedback from those cross-functional executives that are like, oh, this person's hard to work with. When in reality you're just trying to do your job. Um, so hopefully your senior leaders can see through that a little bit, unlike some of my past senior leaders, but that's beside the point. So Um, still my fault. I'll take full credit for it because I probably didn't handle those situations as well as I could have and lessons learned.

And since this is lessons in product management, I'm sharing those lessons with you so you don't repeat the same mistakes that I did by just immediately pushing back and getting defensive. That just doesn't it doesn't help anyone. So Don't Ask for solutions, ask for problems. Don't accept solutions, only accept problems, but do it in a tactful and artful way. It takes practice.

Um, if you come if you come at it from a curious and humble place, humility is another part where it's not about who's right and who's wrong. It's about understanding. If people feel heard and understood, they'll usually approach it the right way. Um, if you approach it the right way and you have executives that are yelling at you just telling you just to go do the thing, go implement the thing, that's probably not a healthy environment. So uh something else to think about.

But I hope I hope this was helpful. Um don't be someone who brings solutions. Well, you need to be somebody who brings solutions, but don't be somebody who accepts solutions. Be somebody who looks for the underlying problem. And your product career will serve you very well as a result of it. So thanks for joining me today for another lesson in product management. And until next time. Keep looking for those problems.