S4E1: From Failure to Breakthrough: The Product Manager’s Journey with Lee Fischman

Welcome to Productly Speaking, the product management podcast where building products
is never a straight line, though the roadmap says otherwise. I'm your host, Karl Abbott.
In each episode, I talk with some of the most innovative minds in the industry. Together,
we share real stories, the breakthroughs, the missteps, and the lessons that usually
arrive, well, after the deadline. So whether you're a seasoned PM or just starting your
journey and wondering what really happens behind the backlog, let's give it a go.
Today's guest brings decades of experience as a developer, product manager, and executive
in companies of all sizes across B2B and B2C. He has worked on the digital side of publishing,
military and aerospace, fintech, financial, insurance, and healthcare. He has also co-founded
four companies. His pet project is the Worldwide Map of Love, which you can find at wherewemet.com
product.org. I am pleased to welcome to Productly Speaking, Lee Fishman.
Hey, Karl. Thank you. Great to hear from you. Great to be with you.
Yeah, it's good to have you here. So you wrote a book about digital product management that
goes beyond the typical PM playbook. What inspired you to do that?
So there are some good books out there. Matt LeMay comes to mind. He has a great book. But I feel
that they all have a bit of a narrative. They cover the bases, but none covers the bigger story.
For example, how do you know when you are fighting against your own biases? You don't even know they
exist necessarily. How do you do things like write copy? Copywriting is actually really important in a
lot of product management roles. What do other people do near you? What do your engineers do? What
do your marketers do? What does your CPO do? And also, no book that I found talks about how to deal
with people who are, to put it politely, arses. And I've had my share as everyone has. So what do
you do about that? And then there's a million other things I want people to be aware of. I wanted to
take everything that's been discussed in product management over the last 20 years and put it in
the book. And in the process, get people not into a narrative that they're reading, but really into the
mindset of product management. That's what I really wanted to do, get people into thinking the right
way. And what would you say that right way of thinking is, that mindset that people need to get
into? Humility is one big one. It brings better communication. It brings empathy. It brings an
understanding of where you're going wrong, the openness to that. It also brings the willingness to
learn. Humility is a neighbor. That's a really interesting point that you bring up. We've talked on this
show a number of times about how being empathetic with people is very much a key cornerstone of
product management, because at the end of the day, this is a job about building products that are
going to help people do what they're trying to do or solve their problems. So there's a level of
empathy that needs to be there. Humility is a very good one as well, too, because we've all seen the
people that really feel like they're just running over everybody to accomplish their own personal
objectives. How can you have empathy without humility? Humility is an enabler.
Yeah, the two really do go hand in hand. If you're empathetic, you're likely going to have
at least a degree of humility. Humility is one of those hard things to achieve. So we could talk
about the book, Humility and How I Achieved It, but that would not be very humble of us, would it?
If it's your book, we could do that.
So your book talks about excellence in digital product management. Tell me a little bit more
about what that means to you.
I think we first have to define things. What is product management? After you've defined things,
you could define what excellence is in that. Someone read one of the first drafts of my book.
They said to me, I still don't know what a product manager does. And I had to think about it and add
that definition to the book. What I wrote was, listen very carefully because it's not necessarily
what everyone else defines a product manager as. I wrote, product manager's job is to move her product
forward to best serve the interests of its users and the business. Inside the organization,
she represents the product. That could mean a lot of things. The definition is longer than that.
But the point of this is that not only do the domains vary, but the responsibilities of the
product manager vary tremendously. The one thing that you know being the product manager is that
you represent the product. There are some circumstances where you don't, in which case you have
the title, but you're not actually in the role.
I saw the other day, somebody said that product management was all about managing the chaos and that
the moment that your world was not chaotic, you were no longer doing product management or didn't
have a job.
I don't completely agree. I think that in many circumstances, things are moving fast and there's
a lot of stakeholders and you do have to manage chaos, but many professions have to manage chaos.
An ER doctor has to manage chaos. I don't get paid to manage chaos. I get paid for the skills I bring
while facing a chaotic situation.
Yeah, that's an interesting point there. What are some overlooked skills or mindsets that
product managers need to succeed?
It depends on the domain. Sometimes you need an experimental mindset. For example, I worked on a
consumer-focused product on a website where we constantly did A-B testing, looked at heat maps,
all sorts of things. Then I worked on a platform product where what we did depended upon what the
most politically connected person wanted. And that was fine because it was an internal platform product.
That was a fine way of doing it. You're also going to be limited. Sometimes you're going to do things
that aren't in specific people's best interest because you're in an organization that emphasizes different
things. For example, if you're in a big bank, you're afraid of getting laid off. You're not going to make
decisions that are necessarily in line with the users when you're trying to save your butt.
And that's a huge thing. I mean, in tech today, we see a lot of layoffs across all the tech
industry. It's been a handful of years of turmoil. And yeah, you really do kind of wonder what that's
going to do.
It's going to mess with your mind. You're going to be like, well, this is a great thing we need in
house. Let's buy it. No, you're going to build it. So people rely on you into the future. All sorts
of weird things happen when organizations don't treat their people well and give them security so that
they can make the optimal decision. I just said that there's a lot of different product manager
roles. So the skills do vary, but I think that there's some core skills. For example,
this is a personal thing. I hate sloppiness. I think that when you build something, if the
foundation isn't good, that's going to breed bad habits. So if I'm in front of a confluence board
or a notion board that my team's maintaining and it's a mess, I'm going to fix it. And I think you
should fix it because people cycle in, cycle out. You need to refer to those things, maintain clean
foundations, get rid of sloppiness and everything you do. And there will be dividends paid in what
your users see and what the business sees. That's one thing. I also do not ever send out anything
right away, anything, even a text. I let everything sit and gestate. I'll send it to other people for
review, depending upon how significant it is. It's not a skill, but it's a muscle that you should
never communicate to anyone right away. Always sit on it. Maybe send a response saying,
I've got what you sent. I have to respond to you. Let people know you're listening,
but wait for the response. Make sure it's correct. In that make sure it's correct,
you probably said what would happen if you didn't. But I'm curious to get your thoughts
on what happens when you don't wait to send that communication, when you don't let it gestate.
I've learned my lesson several times over. For example, if you send an email that has been
thought through, maybe that's politically sensitive and you don't involve other people
to give you a second thought about that, even one you've reviewed, the blowback can come when
someone forwards that email. And then the person who it's forward to says, why did they send that?
Or if you get a long text and you're in a hurry to respond because you have other things to do,
and this has happened, maybe you didn't read the whole text. Maybe you just kind of read the top
and you kind of got the gist of it, but the rest of the text was actually really important.
You end up looking stupid because you actually haven't answered the question.
Then there's always just accidentally leaking things. If you've got the wrong people in the
two or the CC and you didn't realize who all was on there, because let's face it,
a lot of email threads come with a ton of people in either of those lines.
Yeah. I don't know about Microsoft, but I'm finding very few people actually use email anymore.
It's all in chat. And so the mistake may come when the wrong people are on the chat and that's
happened as well using a certain chat thread. And then some people were included who
should not have been, but it's basically the same problem.
Yeah. We live in email. We have teams and we do some chatting, but we generally live in email.
What are some of the most common reasons that digital products fail in your experience?
Because that's something I'm really interested in digging into is why do products fail? Because
we talk about how to be a good product manager, how to make successful products, but a lot of times
products just don't make it or they don't make it for very long. So why do they fail?
Well, simply put, you can't make as much money off of customers as it costs to get them. That's the
number one thing. You've got a product and you're going to hope that you have revenue from it. Your
business models may vary. Maybe you're paying them and you're making money on advertising,
but they don't want to use it. I've been there a few times. Products have customer acquisition costs
that may only be known after the fact. I built products that we thought we knew who our customers
were. We had expectations and how much it would cost to get them. But until you actually commit
money and run those experiments, do that marketing, hire those salespeople, you may completely
misunderstand how much money it costs to get people. You can run experiments if you're doing
marketing and you understand where your marketing dollars need to go into influencers or YouTube
bumper ads or pre-rolls, things like that. You can do experiments and learn what those costs are.
And you can even go to those communities and understand what the basic costs should be, like
what's your success rate on a bumper ad? How much do they generally cost? And use those numbers to try
to estimate what your customer acquisition costs will be. That's for marketing. For sales, there's a basic
cost for hiring a salesperson. You can understand that upfront. But what you don't understand is what the
gestation time is, how long on expensive software, like enterprise software, costs to get a customer.
All those things are unknown until you've built the product and tried to sell it. Essentially,
estimating costs depends upon the channels that you're utilizing, the staff you're hiring, the kind
of software you're selling. And sometimes you could succeed to some extent, sometimes to a lesser extent.
Thank you for that. That was a great answer there.
There's a guy named Michael Girdley. He's a business vlogger, and I listen to him all the time because
he's got great business lessons. He recently said, the thing that creates your business is the same
thing that destroys it. He talks about Circa City, he talks about Under Armour, some other big firms
that basically made their money and then saw their entire market taken away by the same thing that
made their first dollar. You can build your own market, but then some advancement's going to come
in where all of a sudden that's no longer a need what you service. And if you don't stay ahead of that
and reinvent yourself over and over and over again, yeah, you find yourself in a bad spot.
There are some companies out there that have started with things you think should be out of
date already. RingCentral is one example. I just was recently taking a look at them. You think, oh my
God, RingCentral, they're beside the point at this stage of the game. But no, they reinvented
themselves and they're still going strong. Those are the most amazing stories. Those are the stories
of teams that know how to adapt to the market.
That's very interesting because you don't think of somebody like a RingCentral, I mean, right?
They did telephone conferencing, which it's been...
All-in-one communications.
I can't remember the last time I dialed into a phone number to join a telephone conference.
Right.
Done that, but it's been over 10 years at this point.
It turns out that an all-in-one communications company can reinvent itself.
Yeah. So with all these examples of failure, surrounded by failure, and quite frankly,
most product bets you take are going to end up with some degree of failure. You're never going to nail
it right the first time. But sometimes you get signals back from that failure that if you're
smart enough and you're wise enough and you read between the lines, maybe you could actually turn
that around or see where you fell. Do you have examples of where failures have been able to lead
to a breakthrough?
I have two, if I may. One, when I was working on JP Morgan's internal chatbot platform, I came into a
situation where adoption had been basically zero. And when I looked into the product, I understood what
was happening. It was using esoteric technology. In general, it was difficult to build chatbots or
whatever use of natural language processing people wanted to put these things to on their own.
And so I said, look, let's change the whole business model. Let's set up engagements to build
these things for people because we know how to do it. We can qualify what the best business uses are
based upon the people who come to us. Let's build it for them. It was a strange idea because I was
working on a platform and a platform is a do-it-yourself sort of thing. This wasn't compatible
with the platform's goals, but we did do that. And we ended up having a lot of business. This was an
internal product. That solved it, changing the business model. Another experience I had was for
a company that I'm now advising, Pricemetrics. Pricemetrics sells a system to help retailers
optimize the profit of what they sell. And we did build what people told us they needed,
but we still had a few takers. It turns out that when people are interested in your product,
it doesn't mean they're willing to pay for it. That led us back to the drawing board,
understanding that we had a usability issue. Despite the fact that people said they wanted it,
there were issues with the way we built it. We then evolved a really stunning visualization feature
that now really differentiates the product and is starting to get new interest.
Yeah. So I'm guessing that to get that type of feedback, you were probably talking pretty closely
with a handful of select customers at first to understand if what you were building was meeting
their needs. That's right. We did. And we showed them mock-ups and built prototypes. And yet they
weren't actual buyers. And that's where the disconnect occurred. So once we had built something,
we showed them that. In a way, when you have skin in the game, people are willing to be more honest
with you. We did at that point have something. And that's when we learned that we had to pivot and
build that visualization feature. And then with the visualization feature,
you had something people were willing to pay for. Right. It comes down to the sorts of people you're
dealing with for a specific product and how they want to view the world. You don't want to move them
outside of their comfort zone. The way that they view the world through your tool has to be compatible
with their existing way of looking at things. Yeah. We had a conversation in the first season of this
podcast where we talked about a company selling storage solutions that basically could deliver
speeds of up to like 15x faster than the corresponding competing technology. And yet
they couldn't sell the technology because of the retraining cost. People were very used to using
the incumbent's product. And even at a 15x improvement, it's like the cost of retraining is
just too high. There's a bunch of factors like that. If you're building on a platform,
you have to be worried about the platform being taken out from under you like Zynga on Facebook.
A lot of things can get you. It's like navigating through a forest of razors,
getting a product to be successful, usability, moats, platforms, markets changing,
customer acquisition costs. Everything's there to get you. Absolutely. Pivoting a little bit more
back to your book, you cover marketing and design and these aspects. Why are those critical for
product managers? PMs work on products that people interact with and design is how you mediate
that interaction. We live in a designed world. Design is all around us. Design has to do with what
we're doing right now. You can't just rely on a designer for that. You've got to develop your own
understanding of how that mediated interaction works. Marketing is central to product management.
That's what the first PMs were. They were brand managers. Much of product management is still
just one degree removed. I said there were lots of different kinds of product managers,
but still the classic kind of stereotypical product manager is one degree removed from marketing.
Marketing and you have the same goal. It's to understand the customer. You definitely should
use a lot of the same learnings. I've used marketing materials to inform my product management
practice. It was your guest, Austin Fuller, that said a lack of alignment with product and marketing
creates a lot of dysfunction for the customer. In a firm that has a marketing function and product
management function, you cannot have silos between those two functions. That's why I lavished a lot of
attention on marketing and also sales in my book. I've worked a lot with sales. If you have a sales
group, like for example, if you're a B2B enterprise software company, you're going to have a significant
sales component. Or if you're a car company, for that matter, selling to consumers, you want to
talk to your salespeople. They're your eyes on the ground. Yeah, absolutely. And in fact, you have
some customers, but you may not have direct routes to them. Those are your indirect routes to your
customers because those folks are talking to the customers quite regularly. Yeah. And they may not be
too knowledgeable about the product, which I've found, but they can set you up. If you need to talk to
a customer, they're the people to set you up. How would you recommend that PMs effectively
collaborate across these disciplines to avoid misalignment? I was on a communications committee
in my village a few years ago. And when I applied for that position, they said, why do you want to
be on the committee? And I wrote, lack of communication causes wars and divorces and everything that is bad.
And just like I've said, humility is kind of a core feature of how you should perform. I believe that
communication is part of that. Some people you're forced to collaborate, design, engineering.
You see this on job applications. It's kind of crazy. Of course, you're collaborating with them.
But beyond that, who are you informing and how? For example, are your release announcements
an opportunity to tell a story for people who want to dig further? Do you keep an internal product page?
Do you have regular one-on-ones with people farther afield in your organization? All that's part of
really good communication. Do you have a product channel? There's some great stuff out there that's
written on how to communicate properly. But also, how do you communicate? Do you draw pictures
for the visual learners? Do you abbreviate for the executives? Do you tell stories for people who
like to read? All those things are important to the art of communication. That last point, storytelling,
that is such a key part of product management because a lot of times we're telling stories to
different audiences and we have to adapt those stories for those audiences. But that's a lot of what we do.
A hundred percent. And everyone's reading a story, whether they're reading a sports column or whether
they're reading a political essay or whether they're reading the story about a kid who just
got his cure for cancer. They're all stories. We're built around that. That's what we learned growing
up. That's the books you read when we're three and four years old. That's kind of muscle memory. And so
when you build your communication around stories, you're appealing to something very deeply rooted in
everyone's psyche.
So would you say that reading stories is a good discipline for product managers today?
Like just reading fiction or nonfiction stories, depending on your preference?
That's a personal decision. I have found that long form is good for me. That doesn't just mean
books. That means reading things on Substack or Medium. To me, reading allows one an opportunity to
reflect in a way that you can't get, say, listening to a YouTube video, which I'm guilty of listening to
a lot of. It's only by reading that I can really kind of gestate and manipulate the thoughts that
are coming into me and consider them more deeply. I believe that's good practice for thinking in
general. So yes, it's your question.
Yeah, I think I personally find that reading is a huge help. A lot of what makes reading what it is
in terms of being probably still the best way to absorb ideas is you go at it on your pace.
When you're watching a YouTube video or you're listening to this podcast, okay, yeah, you can
speed it up or slow it down in the player, but you're basically going at our pace.
Right. That's a very good point.
Stopping and thinking about it and then like replaying it, then you're not getting the same
as in a book where if you read a paragraph and you're like, I don't really know what I just read,
you can just pick up and read again. There's a thoughtfulness and kind of a directed,
I'm focusing my effort on this that some of the other mediums don't necessarily have.
I think that's a great point. I'll add that there's something about language and how you
ingest it itself. So self-paced is one, but are you looking at words? Are you hearing things?
I think that our minds are tuned differently for those different media.
Absolutely. So piggybacking off of that, are there tools or frameworks that you would recommend
for developing that strategic thought for product development?
Well, first, what is strategy? My definition of strategy is planning how to succeed in the long
term. Are we agreed on that definition? That's a good definition. I like that.
Keep it simple. I'm not a big believer in strategy frameworks. There's a great newsletter called
Strategy Breakdowns. Tom Alder, who runs that, puts it this way. He says, you don't get better
at strategic work by memorizing theory and frameworks. And this is about reading. You do so by training
your brain to instinctively recognize the data points that you need to answer a question,
how to back up your idea. So starting with that fact that I don't believe in frameworks,
I don't believe in strategy as a specific set of steps you follow. I do, though, feel that there is
a way to go about it. Richard Rommelt, who many of your listeners know as the author of Good Strategy,
Bad Strategy, puts it this way. He says, first, figure out what's really going on. And you have to
very honestly assess your product, your company situation, what you know you can do, what you know
you can't do, and how that lines up against your competitors, customers, so on. Once you have that
understanding, decide on your approach forward. A great strategy will find the gaps in your
competitors, their strengths, their weaknesses. How do you navigate between them with a knowledge of
what you can do? You may be able to find a path between your competitors, but that path is not
something you yourself could achieve. Maybe because you cannibalize your existing product offering,
maybe because you don't have sufficient staff or sufficient money, in which case you could have a
problem at the decision stage. But if you can find a way through your competitors, it should,
in retrospect, have seemed obvious. So third party should look back at what you did and say,
of course they did that. But the truth is that in retrospect is fine, but it takes real work
to see any strategy clearly in the moment. I do use a tool very frequently for strategic exercises
called differentiation axes. To illustrate, you take a factor that you think is important,
for example, customization. Now you draw a line where the level of customization might be none
on the left to really extensive on the right. Different factors, different lines. Now plot out all
your competitors on that line where they sit. Some products may be very low customization,
some very high. And where do you sit now on that level? Using customization as an example.
And where can you go? Can you make your product, say, more customizable? Can you make your product
cheaper? Can you make your product more delightful? Whatever factor you're looking at. With a few of
these differentiation axes, you can actually get a sense of where you're particularly competitive.
You draw maybe 10 axes, each axis representing a different factor. And maybe on two of them,
you see a real difference between you and your competitor or where you can be versus your
competitors. And that's how you build a strategy using differentiation axes. There was a great book
that was just written called Click. And in that book, Jake Knapp and John Zeratsky basically create
an entire framework around the idea of differentiation axes. It's very helpful.
Yeah, that's a very interesting point because I find myself in a world of a lot of tactical work.
And a lot of tactical work on, frankly, a product that's doing quite well right now. So it's like,
how do you rise above the tactical work that you have to do to maintain your trajectory to actually
get to that strategic thinking that's going to help you build for the future and keep going?
I can speak to what you just said as well. Prioritization frameworks, rice is basically
a standard because rice isn't one thing. There's many variations of rice. But ultimately,
you're trying to gauge what the most important things to build are. And you can weight rice by
your strategic imperatives. So let's say you have a list of things and the impact is measured maybe
one to three. You can weight the impact by your strategic imperative. So there might be level two
item things that are more important strategically. They get pushed to one. There may be level one items
that are less important strategically. They get pushed back up to two or three.
So even your tactical day-to-day work can be influenced by strategic imperatives if you
incorporate that into your weighting scheme.
Yeah, thank you for that. Something to definitely consider as we go through and deal with the chaos
that comes along with product management. Because even if it's not the job, it definitely is part of
it and surrounds you.
So kind of talking about that, you know, there's challenging environments that we do have to work
with. And sometimes you have challenging team dynamics. And like we've talked about earlier,
you've got a series of layoffs in the tech industry and just kind of the challenges that
come with that being kind of an ever-present worry. What advice do you have for product managers
working in challenging team environments?
When you have a challenging environment, you know, what is that? Is that people with very
different personalities and it's difficult to navigate between those personalities? Is it
demands on your time or deadlines that you constantly need to meet? Are you being pushed
too hard? There's a lot of specific challenges that define a challenging environment. One problem
that I just mentioned is team personalities. What you need to do in there is understand how people
tick. That's not an easy task necessarily. There are personality profile rubrics that you can use
for that to help you along. But once you understand how people tick, they might be busy.
They might feel there are the priorities. Maybe it's their personality. Whatever that is,
understand what's happening with them. And then you can hopefully find a solution. But you can't
find a solution to specific sorts of people and their specific concerns unless you understand what
those are. That may come by talking to them directly, asking them maybe not being
confrontative what's up, but what their concerns are. And working around their concerns. That's
how you might handle different personalities. You might have an executive who doesn't communicate
well. I've had many people who did not communicate well. They'll say something, then they're really
busy and they'll leave the conversation and the meeting. And they'll say something and you're left
with the bag. You're like, what did they just say? Does that change everything? Does it not?
So what I'll typically do in a situation like that is send them a brief statement of what I know.
You have to be very careful when you do that to make sure that that statement is not considered
to be final. Put a disclaimer in there to make sure they don't blame you for misstating things.
It's simply an opportunity for them to provide clarity on what you're trying to understand.
That's another thing. Challenging environments can come, as we talked about before, from communications
where you send the wrong communications to the wrong people. But another thing is people don't want
to confront other people. Instead, they'll talk behind your back. You'll hear from third person,
oh, someone said something about you, something like that. You didn't mean it. You didn't know
what you did was wrong, but you didn't get that feedback to tell you it wasn't what the other
person wanted to hear or wanted you to do. And so when you go into a role, one of the first things
you should try to do is tell people that you're receptive to criticism. Say, before you give it to
someone else, please bring it to me. Give me an opportunity. And that lowers the barrier. That makes
people more willing to talk with you. It's not as confrontative. They understand that you're open
to even difficult feedback. That's another aspect of challenging environments.
That's excellent advice. And I think if we follow that a little bit more frequently,
we might find that we break through some of those challenges a little bit more often.
I just hope all your listeners out there take that advice. Please, if you have a problem with someone,
bring it up nicely with that person first. Do not go to someone else.
What types of organizational patterns can tend to hinder product outcomes? Because ultimately,
we form these organizations to build products to solve problems. So if you have these problems,
then the whole thing's potentially about to train wreck.
Companies on automatic, for example, let's say you make a lemon squeezer. Well, you make a lemon
squeezer. You don't need a product manager for that. You're not changing it. They don't need a product
manager. But it can get more complicated than that. Let's say you're in an insurance company.
Now, there are roles that have a lot of autonomy in insurance companies, but I've seen others that
didn't. For example, we're going to do this. And they hire a product manager to oversee it,
but the product manager has no autonomy. They're there to follow instructions. That can happen in a
big company where you have these grooved paths that people have to follow. And I've seen that in
other ways in other large companies where you have to follow this path. That's it. You don't have a lot
to say. But also in small companies, you're going to have founders still in those companies
who built the product, put in the sweat equity. They've been successful, and they're going to
control that product. They're going to tell you what they want. You're not going to have a lot
of control. You're not going to be able to say, oh, this is how we should do it, or these are what
the priorities are. If you have an enlightened CEO who wants to have his weekends off in time with his
kids, then they'll let you do that. But most don't. Most will work seven days a week just so
they can tell you what to do. And that's a problem as well. A company getting its first
product manager, if you have freedom and you have multiple offers, on the way into that company,
say, how much autonomy does the product manager get?
Yeah, I've definitely seen that firsthand before. You can certainly understand it. I mean,
if you built something that was already that successful that you were at a point you could
hire a product manager, you'd really not want to let that go anytime soon. You'd be kind of tied to
that. You'd want to continue to guide it very directly. That's a very difficult thing in a startup.
Absolutely. Your money's in it. I don't blame these people. It's their money on the line.
I completely get the founder mentality on that. But also at the same point,
oh man, it's so hard, but you've got to let go. Hire these people that you can trust,
which that's part of it. They have to build that trust in you to then take that on.
I think the compromise is understanding that everything's about collaboration. A founder could
say to himself or herself, my product manager is going to bring ideas to me from the sources that
I've given them the freedom to pursue. He's not, or she's not there to just follow my instructions.
He's not there to be a loose cannon. She or he is there to bring me ideas and further the product.
And that's a good compromise.
Yeah. Yeah. So it wouldn't be 2025 if I didn't ask this question. How do you see AI impacting the
product space? And what is your advice for product managers today navigating that?
Everything you do, ask yourself, how can AI do it? That's number one. Number two,
everything you do with AI, ask yourself, is it right and better than I could have done myself?
That's number one. And number two, I could go farther than that, but I can't really because
the technology is developing so rapidly and there are so many tools. The other thing is that the
two pizza team, I believe is going to become the one pizza team because the real people who are
being speeded up are the engineers. And where a product manager may have had five to seven
engineers before, now they're going to have three to five. And that means one of two things. Either
we're going to have more product managers, we're going to spread all the engineers out on smaller
teams, more product managers, or we're just going to get rid of engineers and maybe product managers
will have fewer engineers. There won't be more product managers.
Yeah. No, I don't think they're going to like all of a sudden decide they need more product
managers because you're right. I mean, one of the classic metrics as to whether or not you need
more product managers is your product manager to engineer ratio. And so if you reduce one side of
that, well, you could end up reducing product managers. And we've definitely seen that. I mean,
you look at some of the layoffs that have happened, you take out some product teams and you take out
some engineers, you take out some product managers. Do you take out the products that they managed or do
you give them to other people? You know, that kind of depends on the situation, but definitely seen a
shrinking in the market over the last few years. We have. And I actually think that the shrinkage
in some of these firms is not due to the gains from AI. I believe that they're making strategic
realignments. They're buying a whole boatload of NVIDIA chips, which costs as much as a small car each,
and they have to pay for it in some way. So they're paying for it with bodies.
And that's actually pretty congruent with what a number of them have said in their earnings calls,
is that we're retooling and rebuilding. So we'll see how all that continues to shake out as we go
forward. So what are some of your top points of advice for product managers looking to excel in
their careers? I asked DeepSeek that question. It came up with a great list. It's not rocket science,
you know, build your product muscle, look at product reviews, find a mentor. If you're a junior product
manager or a sponsor, if you're trying to keep your job, figure out how to create leverage in everything
you do, because you're there to actually move the business forward. And the way you do that is
by figuring out what leverage is. Don't just be busy. Incorporate that strategic aspect into
everything you're doing. That's great, right? That's what DeepSeek gave me. But product management
is about people, the people who use your product, the folks you work with, the men and women you report
to. It's very general advice. If you want to excel in your career, remember that it's about people
and double down on all the ways you work with and value people in your job. That's how you get ahead.
That's how you're an operator. Wow. That's a fantastic statement right there. And it does.
It brings it all right back to what we started talking about. And really what we've been talking
about throughout this conversation is it's all about how people interact with each other that
really drives all of this forward. So how would our listeners be able to find your book and also
connect with you if they had questions? I keep a fleet of carrier pigeons on my roof and there's
a certain whistle you can buy on Amazon to call the pigeon. Excellent. Yeah. Yeah. But if you don't
want to buy the whistle, it's cheap, but you don't have to buy it. You can just connect with me on
LinkedIn. Lee, L-E-E-F-I-S-C-H-M-A-N. And there's one of me and there's also an Israeli singer named Lee
Fishman. I think you'll know the difference. And also if you want to get my book on Amazon,
it's called How to Excel at Digital Product Management. And it has a big stork. Why does
it have a big stork? Karl, you want to guess? Storks deliver babies and product managers deliver
products. Too obvious almost. Here I was trying to think of some deeper meaning and it's, yeah,
there you go. One more question just to let the audience get to know you a little bit better.
If you had to give a TED talk tomorrow on something totally non-work related, what would it be?
My journey in pizza making. Wow.
Yes. So I started with Trader Joe pizzas, just adding toppings to them. And then I moved on to
buying the dough and making the sauce or buying the sauce, putting the toppings on. At this point,
I'm at making the dough, playing with the hydrations and all that, trying every brand of like about 30
different canned tomatoes on the market and figuring out how to make the sauce and then
playing with the cheese, doing it like Marseille style, doing it Napoleon style, doing different
kinds of cheeses. And then of course, there's the toppings. And of course, playing with the heat,
doing it on the grill, doing it in the oven, doing it in the uni, all these different things.
So you do have a pizza oven at this point?
No, I got rid of it, actually. It was too big for my dick. But it has something in common with
product management because they're experiments and I'm keeping a log and I'm looking at the
outcomes. It's very much a pizza product management story.
So I guess once you retire, it'll be opening up a pizza shop?
Yes. My sons have suggested it be called the Laboratorio de Fischmann. We'll see about that.
That's a fun name. Well, thank you so much for coming on the show.
Thank you, Karl. Appreciate it.
Today's episode of Productly Speaking was brought to you by the letters P and M.
If you enjoyed this conversation, subscribe so you don't miss the next one.
Share it with friends, co-workers, or anyone who loves a good product story.
Got feedback? We'd love to hear it. Visit www.productlyspeaking.com,
connect with us on LinkedIn, or email us at hello at productlyspeaking.com.
Thanks for listening. And remember, keep calm and build on,
especially when the meeting invites keep multiplying.