Hello and welcome back to another episode of Lessons in Product Management. I'm your host, Jon Fontenot. And today's episode actually comes from a question that I got on a LinkedIn post. So the post that I... put on linkedin actually got quite a bit of traction i'm pretty shocked this is probably like one of the better posts i've ever had but i was just
Stating an observation that I had around LinkedIn content and how delivery focused it was. And if you followed my content for a while, if you've been on the path to product platform, you'll know how much of an emphasis I put on. discovery as opposed to an emphasis on delivery, right? I really feel like the value comes from what you learn in discovery and that gets translated into delivery. but without discovery, your chances of creating valuable outcomes in delivery.
go down drastically. So my post was, I see so much product management content focused on roadmaps, delivery, shipping, creating PRDs. The unfortunate by-product is that some of the most important aspects of the role get ignored. Number one, discovery, early stage prioritization that centers on business and customer value versus the feature level prioritization frameworks like rice and Moscow, the stuff that gets all the post.
Number three, assumption testing and validation all throughout the various stages of the product development lifecycle. And number four, having cross-functional partners brought in so they can be bought in, right? And then I, and then I offer some advice, you know, instead of arguing about roadmaps, delivery processes, et cetera, let's start focusing more on value creation and the alignment between business and customer value. And like I said, I got.
way more traction than i thought it would i was literally just uh responding to some content i saw as i was scrolling through the feed but apparently it struck a nerve One way or another, there's a lot of people that agreed. Some people disagreed. But we had someone who asked a really thought-provoking question. I told him I'd give him credit. He didn't say I couldn't. His name is Sam Greenwood. So if you go find the post, I'll actually link the post in the show notes so you can go see it.
Um, and all the comments, I think there were some really good comments on there, but he asked, how do you think culture communication patterns and the quality of leadership should fit in here? Seems like these are more meta things, but have a longer term impact. And I responded to him. We went back and forth. You can go see the post, kind of what our conversation was back and forth. But his last question.
on there was, what do you think is at the root of the pressure to continually ship outputs, ship features? He asks, is it a blind commitment to endless growth year over year? What is it? And I'm like, hey, man, this could be a number of reasons. I feel like this would be a really good topic for the podcast. And here we are. Right. I really want to break this down of, you know, what is at the root of the.
of the pressure that PMs feel to constantly ship new features, right? Melissa Perry has the book Escaping the Build Trap, you know, really popularized the whole concept of a feature factory. And I think as PMs, we know that we should avoid it. But why at the leadership level is there still pressure to do it? Right. Josh Seiden. has a book that he co-authored called Outcomes Over Outputs. That book's been read by tons of product leaders, yet there's still pressure to constantly ship.
In my own company, I work for a very small startup. It's my first go at a very early stage startup. It's bootstrapped. I'm the first PM wearing a bunch of hats. And it's similar. It's like... When I came on, they were finishing rewriting a bunch of old code and really getting ready to hit the ground running for go to market.
And there was an emphasis on, hey, we need all these features. There's AI coming on board. We need to enhance our reporting capabilities. And we got to hit the ground running. We got to go. Like we did all this work to refactor the back end and the front end so we can move fast. And the expectation was features, features, features. And so we started to do that and we ended up playing whack-a-mole with bugs. And so we had to take a step back and reassess and say, okay, what systematically...
is causing these issues that every time we have a release, we break stuff in production. And so we had to audit, we had to troubleshoot, take a step back and kind of put a moratorium on new features until we can get the system stable. and ship predictably stable releases and get some infrastructure things in to do that from the standpoint of automated testing, make sure we had a process for QA and manual regression testing and all kinds of things.
But, you know, these weren't like sexy feature level things. These were things that we needed to do that should have been done. We just needed to get them done. But everybody faces this, but not everyone's given the freedom.
and autonomy and not everyone has the leadership team like we have even though it's small the founders understood they were quite frustrated with the whack-a-mole bug squashing that we were doing And we're willing to invest in taking a step back and saying, hey, if we can slow down to speed up, that's probably the wise investment to make right now. But again, not everybody's in this boat. I feel like I'm in a pretty rare scenario compared to most PMs where it's like, hey, we have our OKRs.
um you have these features that you need to ship it's on your roadmap we need to be shipping these features and all the while engineers are like duct taping back in code and you know having fancy workarounds on the front end to try to get around all these constraints that we have. And they're just accumulating more tech debt. And eventually, there's major problems that take a long time to refactor or rewrite.
and redo before the system just totally crashes or you just can't add any more features because it's just untenable, right? We all face these problems. So how do we, not how do we avoid it? That's probably a different episode, but. What is the root cause of this? And I did a lot of thinking and I think it's at least three things. Okay. The first one I'm going to say is leadership hubris, right?
Hubris, in short, is thinking that you know better. It's basically arrogance. A lot of leaders at companies think that they know what customers need. And I'll grant you that a lot of leaders have good intuition and good gut, but they're not always right. And even if like conceptually and categorically, they might be on the right track of we need these things from a high level.
they don't respect and appreciate the craft of product management to understand that success is in the details, right? I have a whole blog post on the Path to Product blog.
coming from the book Creative Selection by Ken Cosinetta, who is a staff, basically a principal software engineer at Apple, when they were building the iPhone and the iPad. And he... built basically the first safari browser and he did he worked on a lot of foundational tech that like lots of people use today and he gave a lot of great insights about what made apple great in the steve job days and that's something that he stressed a lot is how much how much the details matter
and how you have to sit with something and use something and feel it. It's not something that you could say conceptually, we need X, Y, and Z. and then just go build it willy-nilly like no like really the details matter and that's what i think a lot of product leaders and company leaders don't truly understand is that evaluative part
of the discovery process and the delivery process because evaluative research kind of bridges that gap between generative on the discovery side and then evaluative kind of plays into the delivery and post delivery side of discovery where you're trying to understand like Things like usability, desirability, adoption rates, and all these things that really go into a product or a feature success, right? And there's so much nuance that like if you're...
If you're on the ground, if you're an ICPM, you get it. And it can be head scratching to not understand why do our leaders not get it. And that can be hard. So I think that's one is hubris is just. arrogance of leadership, not understanding and respecting the craft of product management and assuming that they know what the customers want and assuming that it's easy to just go build it and it fulfills.
what the customer wants right so that's that's one is is hubris two i think comes down to external pressures right if you're a publicly traded company Do you have this short term pressure to show something specifically that's going to move the needle or at least not move the needle backwards? for your your stock value right um even if you're not publicly traded you you might have a board of directors you might have investors what what can you do to show value
And I think that kind of bleeds into the third one, which is something I've seen Shreya Stoshi tweet about and post about on LinkedIn quite a bit lately. And that's the overemphasis on optics. There's a lot of product leaders who have gotten to where they are, not because they actually did something worth doing, but because they got optics right and people believed something about them because of the way they presented themselves.
But there wasn't much substance. And I've seen that. I've seen that play out in my career where the substance really isn't there. There's a lot of hoorah. There's a lot of bravado. There's a lot of hype around launches, but there's not a lot of honest assessment of did we actually create value and did we actually move the needle? And those optics are often valued at a higher level.
unfortunately, to all the people who hold all the power in a company. And so I think that second part and third part kind of bleed in together where... there's this perceived value of shipping features that are visible and tangible, right? And there's, it's not sexy or tangible. to do a back-end refactor that's going to enable you to do X, Y, and Z thing that needs to get done in the future to truly create value or prevent churn because the system is so slow that nobody wants to use it.
that those things don't get people excited in a demo, right? A company I worked for in the past used to demo every Friday, every other Friday. And if there was some like, code optimization or refactor or some, you know, backend thing, it kind of got a yawn where like,
This neat little feature that was thrown in on the front end that like had this cool micro interaction would get a huge applause. Right. But which one created more value? Sometimes the front end features created value, but I think it just. It points to our human nature and psychology that the things that are visually pleasing and that we can touch and see and feel right away.
resonate more with us sometimes. And so I think kind of going into the hubris, the lack of understanding of the product discipline, I think all these things kind of play together holistically. But really, I think the optics of if you go three, six months without shipping a feature, some people just think that you didn't do anything. And in all reality, that might not be the case.
Right. If you're actually creating value and you understand the objectives that you're shooting for and how this investment of time and optimization or refactor or whatever it is. is going to create value in the long run and become a multiplier for your business, then that's probably the right thing to do than going build some feature that...
may or may not get adopted, right? Because you didn't actually go through the proper process of understanding is do people even want this? How much do they value it? Are they willing to pay for it? Like all those things that good product managers, those questions, product managers ask. We skip all that because we think we know better. And so I think I honestly think there's a lot of cultural issues today within product management. It still feels like a very immature discipline. I tried building.
a research repository for product teams and in all my research it was like hey this is good but the the desire to pay for something Even though everyone admits that it's a problem, like research and knowledge walks out the door all the time because it's not documented or it's lost in a Google Drive. I think it points to another piece of... the product management landscape and the maturity that very few companies on a percentage basis.
are investing in research teams and research tools and are willing to make that investment because they understand the value of research and discovery. And so I think those two things kind of go hand in hand around just the level of maturity. that the understanding of the discipline has or the lack thereof. And so I think it's just going to take time. I think it's going to take a seat change in leadership. I think it's going to take a new type of
startup leader or company leader who understands the value and the needed investment to slow down. So not necessarily just speed up, but also to slow down, to speed growth. We want to make sure that we're investing in the right things, not just feeling like we have to ship stuff for the sake of optics or to give the company something to do.
Product managers feel that pressure all the time of, I got to keep the developers busy. And if you're rowing in the wrong direction, you might be going fast, but you're going fast the wrong way. And now it's harder to come back because... Shipping the wrong thing constantly is just going to create more tech debt and more rework to have to come back from it whenever you finally figure out that you made a mistake, if you ever figure it out.
To answer your question, Sam, I think it's cultural. I think it's a little bit of human nature, a little bit of hubris, a little bit I think I know better. And I think it's just in general, the discipline of product management needs. some maturity and a seat change in company leadership who truly values the art of product and the need for product discovery.
I know this wasn't necessarily a lesson in product management, but I hope there were some things you could take away. And I hope as a community of product managers and product leaders, we help educate and teach. and instruct and push for the things that are truly valuable in this discipline. And that is making sure.
that the things that eventually make it into delivery and make it into the customer's hands are things that are valuable in that drive value creation for our customers and drive value capture for our businesses so thanks for joining me today for this somewhat lesson in product management i'll see you next week