Unsolicited Feedback S3, E2: Product Management In The Age of AI, featuring Shaun Clowes - podcast episode cover

Unsolicited Feedback S3, E2: Product Management In The Age of AI, featuring Shaun Clowes

Mar 05, 202552 minSeason 3Ep. 2
--:--
--:--
Listen in podcast apps:

Summary

Brian Balfour, Fareed Mosavat, and Shaun Clowes explore the evolving role of product management in the age of AI. They discuss the fears and opportunities arising from AI-driven automation, emphasizing the enduring importance of strategic vision, judgment, and leadership. The conversation covers adapting to the changing landscape, exploring new skills, and focusing on high-impact activities like exploration and innovation, rather than rote processes.

Episode description

In this episode, Brian and Fareed discuss the challenges facing product managers in the AI era with Shaun Clowes, CPO at Confluent. Many product professionals are questioning their future as traditional PM workflows—documentation, basic prioritization, and coordination—become increasingly automated. Yet this technological shift isn't eliminating the product management function; rather, it's elevating what has always differentiated exceptional PMs from average ones. While low-value processes are being automated away, the core elements that create product success—strategic vision, judgment, taste, and leadership—are becoming dramatically more valuable.

Transcript

Hey everyone, welcome back to Season 3, Episode 2 of Unsolicited Feedback. I'm Brian Balfour, founder and CEO of Reforge and your host. Today I'm joined by Fareed Masabat, my co-host, and our good friend Sean Klaus, who's the Chief Product Officer at Confluit. Today we tackle a topic that is on everybody's mind and honestly is I think creating a lot of stress, which is what happens to the product profession with AI? How does it change?

You know, there's a lot of things out there that are just making big claims about how the product profession is dead and other things. And I just wanted to wipe away all of the hype and talk about this with two very thoughtful people in Fareed and Sean. And think about it from first principles about... might happen, and more importantly, what to do about it if you are in the product profession. So before we get to the episode...

I want to make sure that you know about two things that if you're a product manager or a product team that is looking for a way to help leverage AI to create better products. First is the new product from Reforge, Insight Analytics. which helps aggregate all the messy qualitative data that you have about your customers across your CRM, support, user research, in-product surveys, and a ton of other places into one place, uses AI to do a ton of analysis.

marries it with quantitative data, generates a bunch of insights that would otherwise be impossible to get, and more importantly, gets all of this information at the fingertips in the tools where your product team is already working so that they can act on it. The second is our new AI courses, AI Foundations and AI Strategy that will be released soon. Both are new core programs that go incredibly deep on the topic. AI Foundations for those that are just getting started that need to understand.

all the different levers underneath the hood of the AI technology that helps create good products in AI strategy more for product leaders, which is going to help you navigate this incredibly intense environment that we are in right now. both being created with a bunch of heavy hitters from the AI industry that we will announce soon. Just go to the reforge.com website and check out both of those products. We hope you enjoy the episode.

Honestly, I had put this topic on the do not cover list until about a week and a half ago. I was doing a event around the topic of product market fit collapse, which Fareed and I talked about in the last episode with Casey.

And at the very end, the very last question, a PM asked, I feel like product management is experiencing product market fit collapse. And the way that they asked it, you could tell there was... tons of anxiety and other feelings around it and immediately everybody else was like hitting the plus button the upvote button and where i found myself afterwards was essentially giving a mix of some brutal, honest feedback to folks.

but also a bit of a motivational speech. And everybody stuck around 10 minutes afterwards to hear this part that I didn't even think that we were going to cover. So anyways, I actually, I walked out of that, even though a lot of people are talking about this.

There is still a lot of questions and energy being spent, thinking about this from product management. And I think part of that is just a lot of the stuff that I do see out there has been... erred towards like the clickbaity hype so i felt like it was worth talking about it in an opinionated way but bringing more sense and rationality to it and i actually thought you two would actually be good at it because one farid i've always appreciated your take

on playing the long game on careers. And Sean, I think even some of my memories of some of the earliest conversations about you were just like some deeply held opinions about the product management role and what it should be and what great and what bad kind of looks like and how it's going to be evolving. So anyways, that's kind of the setup was, it was, I have never seen so many.

heart emojis bloom on Zoom from that 10 minute topic that I covered in that event. So I felt like we needed to at least spend a little bit of time on it. You know, I've had the same experience. I've been to a couple of different dinners with... product people over the past couple months.

And there's two conversations that tend to dominate. One is, what are the tools you're using that make your life better and easier and make you more effective as a product leader? So there's this sort of excitement, which is taking away grunt work. solving problems more effectively, moving more quickly. So there's this excitement curve. And on the other end is, is there a PM job in the future becomes the follow-up. So it's sort of like this doom curve.

at the same time and i really like your framing around this so maybe that's a great place to start hey sean Do you think that the product management job is undergoing product market fit collapse itself? So I think if you think about it, I would actually frame it a little bit differently.

If you're like, okay, product market fit collapse, what is that? So when I read the post, I thought that was really interesting. It was a really interesting take on things. But honestly, since the beginning of time, general purpose technology has been deflationary for single purpose technology.

So the only thing that's different here is that LLMs are a specific type of general purpose technology that none of us saw coming. So in the same way, I think you even might mention this in the blog post, Brian, but I can't remember.

You know, the iPhone, as a general purpose tool, took over a whole bunch of special purpose tools. Like a whole bunch of them got blown out of the water. And actually, the history of technology is always that. Literally always that. And it's usually slowly than quickly.

It's a slow collapse and quickly, and you've got your chart, and then you've kind of shown, I guess, the steepness of that chart. It would be naive. I'd be an idiot if I said, hey, MLMs are not different. They are. They're clearly different. But some of the outcomes are like 100% the same as every other technology collapse or every other technology evolution. So then I go, okay, there are the things that LLMs enable, like the products we can build and et cetera. But when you're talking about...

you know, the fear, you know, in people and the inspiration. I'm like, what is going on? So ultimately, product management has always been a relatively ill-defined discipline. It's actually hasn't been especially clear what you're doing. Like, you know, it's easy to say, hey.

It's all about deciding what should we deliver that delivers distinguished market value that only we're set to provide, that we can uniquely deliver to the market in a revenue and margin-enhancing way. Sure, it's a chestnut, very, very easy to say.

But in practice, how do you do that? How do you extract competitive advantage? How do you understand a market? How do you prioritize ruthlessly? How do you do all those things? At the end of the day, people, in my experience, people are often very good at saying the high-level things.

They're often very good at the process things, but all of that stuff in the middle is very complicated. It's messy. It's messy. You know, Sun Tzu said this thing, like, you know, I don't even know if it's really a quote from Sun Tzu.

But he said, like, the really interesting thing is to think about how to play chess when the board is disappearing. People might say it's 3D chess, but actually product management is about playing a game where the market will respond. Every person you're playing this game with will respond.

So there are no three moves. There's no four moves, five moves, six moves. Everything you do is on shifting sand. All of it's moving all the time. And I've heard Farid say, you know, now it feels like we're all on quicksand, like product management is on quicksand, especially strongly right now.

That's true, but it's only an acceleration of what it always was, which is like really good product management is hard because of the shifting circumstances. So if I try and put my finger on what is the problem, like what's going on? I think there are two separate things we're seeing. Firstly, we're seeing knowledge value collapse.

So in other words, previously, your knowledge of what customers had been saying, like your knowledge of the market, your knowledge of the technology, your knowledge of your own product was valuable. Why? Because it was difficult to get. It was difficult to get, difficult to keep and difficult to query.

Now, with LLMs, that's collapsing. And you can ask yourself, well, is that a good thing or a bad thing? I don't know, but it's factually true. Actually, I do know. I can chase some opinions. But regardless, you're seeing a knowledge value collapse. But you're also seeing process value collapse.

So if you think about knowledge value collapse, that's one of the legs of the product management confidence stall is your knowledge, right? Then one of the other legs of the product management confidence stall is process value. So in other words, I have a system by which... I do the following things that bring my knowledge to bear to deliver a uniquely valuable product into the market. And you're seeing that collapse too. Why? Because those processes can either be executed by LLMs or agents.

Or anyone can design one of those processes using an LLM or an agent because it's a generic concept. It's like, I want a process that does the following things. So the process design is easier. The process execution is to some degree easier. The knowledge value collapses a problem. So what's left?

If you think about a stool as having three legs, what's left? I would argue that what's left is actually the leg that has always been the most important leg, which is the action and reaction mode. In other words, as a product manager... You should always be exploring the counterfactual. You're trying to learn about the things that aren't directly in the bullseye right now. You're trying to know what are other people doing? Why are they doing it? What is the market doing? Why is it doing it?

Where is technology going? What is driving those trends? You're trying to actually get below the literal sense of what's happening in the world to try and understand what's driving all of those changes and to see around a corner, to be ahead, to predict. And I would argue that LLMs are, in fact, a fantastic tool for that. So if you put away the fear and you say, hey, you know, analyze for me what my major competitor's plan is and what are they planning to do? Why are they planning to do that?

What is the angle that they see? And then if you ask, you know, what's happening in the technology state, et cetera, et cetera, and then you take all of that stuff and you synthesize it again.

Now, you may say that, and then you synthesize it, and you're constantly trying to get ahead. You're trying to find the angle, the question that has not yet been asked, that gives you an insight that is not being actioned by other people. Remember, it doesn't just have to be an insight. It has to be an insight that others are not actioning.

Because if you find that insight and others are not actioning it, that's your advantage, your competitive advantage. And so you could say that, hey, deep research and LLMs and all the rest of it, they may devalue that process. But I would argue that that finding an angle... and executing it has always been what's delivered real product advantage. This just pipes that cycle up. It gets faster and faster and faster.

So, you know, there may not be three legs of a stool anymore, or certainly the other legs may be harder to rely on, but it's hard to imagine a world in which there is just no product management anymore, because that would mean that nobody's pursuing those angles. Nobody's pursuing a specific view of the world. I want to talk about the knowledge collapse piece a little because I think that's a I haven't heard that insight yet and it really resonates with me. And I wonder whether one prediction.

that I would make, assuming the knowledge collapse is true, is that there's a sort of style of PM. If you look at like the different scopes of career or different types of career that you can have, one is like deeply understand an industry. Right. Like be an industry insider type product manager and grow by being a pro at marketplaces and by having worked at 10 of them and really understanding them or.

certain kinds of enterprise software or certain kinds of customers. And I think if you believe the knowledge collapse is real, that that's not a viable path. to long-term career growth, right? Sybil, if you can become an expert in an industry relatively quickly using LLMs, using the research tools, et cetera, the downstream decisions of that knowledge, that help you. Why does knowledge help you?

It helps you because it helps you short circuit decisions, right? I can make a decision more quickly because I don't have to do all this background. But if I can get all that background or I have an intuition. Right. I always think of knowledge as developing intuition. Right. So I like the analogy of poker versus chess for product building because. Yeah. Random chance and always changing dynamic.

And it's just like, oh, I can make better intuition without having to do the math. But if the math is really fast to do, then intuition doesn't matter. And I think that's an interesting one. So like maybe a piece of advice is you should probably be more of a generalist.

be good at making decisions generally versus decisions for a specific kind of customer does that seem reasonable i think i think i agree with everybody judah said for it i think if you step back a little bit there's no real substitute for at bats Like you can read about someone else's experiences and what they did in X circumstance and Y circumstance.

But unless you did it, like you were there, you were on the field, you were on the playing the game, you were literally about to get sacked and then you did get sacked and you learned from that experience. It's not the same. I think we all know that kind of intellectually. And so I agree with what you're saying.

But at the end of the day, if you think about, let's say, for example, you yourself, like, you know, marketplace expert, a bunch of different experiences over your own career, you might say, hey, your knowledge is one of your keys of power. But actually, if you step all the way back, you might say instead, no, no, no, that knowledge was odd by taking these at-bats, taking different angles, going left, going right. So I discovered that knowledge through my actions, not by receiving it.

In fact, I created it in a way. And so to me, the LLMs will accelerate that cycle. And the more at-bats you have, the better. You still, still. Okay. I like that as a nuanced take. I think I've heard this called like specific knowledge, knowledge that can only be gained by activity. It's an interesting perspective. Just market knowledge is commodity.

But the action knowledge is not. I kind of agree with you, but it's a little bit different. It's also like general market knowledge is a barrier to entry. So in other words, let's say, for example, you're doing a job in finance, right? If you don't have general knowledge necessary to be, for example, a merchant banker or whatever, you cannot enter that career at all. Effectively, it's like a barrier to entry. But once inside...

It's not really that differentiated. It doesn't really help you very much. And so from my perspective, the LNAPs are going to blow some of that stuff up in terms of like the barrier to entry into any new discipline is basically going to zero or at least certainly it's dramatically scaled back.

But I still think that navigating knowledge matters. So let me give it an anecdote more in engineering. You know, I started my career as an engineer early on when I started, you know, I'm old. But basically, at the time I started... You know, all of the world's programming knowledge was not on the internet. And there used to be these people they called wizards. I don't know if you ever heard this concept, but basically they were thought of as wizards. And they were often the people who had...

read all the manuals, like they'd read the systems manuals. They knew the magic incantations necessary to make the machine do the following things. And often they knew about like undocumented APIs or obscure APIs or obscure ways to make the computer do stuff.

And they were seen as wizards and they used to like hoard their knowledge. In many cases, they tried not to share it because they viewed it as a form of like a job protection. I am successful because I have these secrets. And, you know, they quickly got stripped of their robes, right? You saw back overflow. You saw the internet blow up. All of that knowledge suddenly became open. And sure, some of them went by the wayside, you know, but actually most of them survived.

Why? Because they were smart enough. They had discovered this knowledge. They knew it was important. They realized it was going to be one of the arrows in the quiver very early, and they put it in the quiver. And so I would argue that...

Kind of that cycle of knowledge acquisition, of knowledge application, of knowledge evolution, and doing that as quickly as possible, you know, is often what separates the very good in any field from the, you know, modestly okay. Like the average from the very good.

And so is this really anything other than just acceleration of that cycle that we all know about? So this kind of hits on, I think, one of the things that I was thinking about, which is I think part of that question, that original question that somebody was asking me was a different version of that is like.

Yeah, is the product management function dead or it won't be around in whatever number of years? I kind of find that question to be useless to ask for a few reasons. One is like, I don't think anybody can perfectly predict. even a few years out now at this point, given the speed of things are moving. And two, related to that, even if you did think there was a non-zero chance that you were in product management and the product management.

was going to die what safer waters do you move to like every single not piece of knowledge work is going through a substantial ship whether it's engineering or design you want to be an engineer But there's an equal conversation is engineering dead. So, yeah. Right. And so to me, it.

Like spending energy on that style of question and trying to figure that out feels like a waste of energy. And instead, what everybody needs to be doing is using another gaming metaphor is rather than trying to find the map that has been perfectly revealed, it's going to. give you the answer it's the gaming map that has all of the clouds in front of it and every step you move three tiles reveals itself and the faster you go through that cycle that you're talking about the the

That's how you navigate this environment. You do not navigate this environment by trying to find that perfect, pristine map that has it spelled out. And so I get frustrated with the articles and stuff that are trying to make this prediction that these...

Certain functions are dead because at the end of the day, the only thing you have left to do is to basically reveal the map going through the cycles like you're talking about, Sean. What's really ironic about that, Brian, is those same people who are fretting about that.

They may or may not know that product management as a discipline, like the title product management is less than years old anyway, right? Right. And then you go, okay, so this product, this title is already brand new, but maybe we're going to kill it off. But the actual more interesting question is...

Will the world need people whose job it is to think about how to win? Will the world need people to think about how to apply technology to meaningful problems to win? If you tell me the world will not need that, I'll be like, well, all bets are off. Now we can't possibly rationalize about that situation because now none of us can imagine that world. So I'd like to think about exactly what you just said, which is the fog of war.

Or the map where you can't see all of the map, that is literally all the time. That's all competitive domains. That's all careers even, actually. And so under those circumstances, knowing that that is the case, what do you do?

Like you can't change that. All you can do is be better at it. How do you play that game better than the person next to you? You know, you don't have to outrun the cheater. You just have to be faster than the person next to you. And so how do you do that? And I think product management actually...

It's a fantastic discipline for that. It's actually relatively easy to outrun your competitors because many of them are not playing a sophisticated version of the game. They're playing the textbook version of the game. But, you know, once you're, you know, you need to get away, like once you're good enough, you know how they say that, you know, a sign of like when professional sports people choke, they say that they're falling back to playing the game as it was defined.

Malcolm Gladwell talks about this in his book, Outliers. You fall back to your training. Basically, the idea is when you fall back to your training, you are now entirely predictable. You're mechanical, you're robotic, you don't respond to the world as it is, and basically you get destroyed by anybody who's really capable. That, to me, makes perfect sense. That must be true. Because if everybody's playing the same game, but they're trying to beat you...

they're gonna they're gonna throw the rule back out the window they're gonna they're gonna try and find any angle they possibly can so isn't that isn't that doesn't that make it a great time to be alive right now yeah now you've got like a gun to bring to a knife fight right and actually I think a lot of people, if you just plug in the same questions, you get roughly the same answers from Manila, right? And I always think of the job of product management as...

is really the primary thing is prioritization and focus. And the reason I say that is because the world of solutions is infinite. And you can look, look, there are 50... answers to the same problem, but which one is the one you are going to pursue based on what you know so far, what you've learned from customers, what your specific competitive advantage is, your technical capabilities.

Your team's prioritization right now, how many engineers you happen to have at your disposal, what you learned down the path, that all of a sudden the thing you thought you were going to do is hard, which is why we've seen a shift towards more... agile, I don't like the word, but agile, more iterative product development is because it really is the act of making decisions quickly based on the field in front of you, not based on what you assumed it was up front. And I think there's an...

you can do the rote work so much more quickly. And that's definitely true. Like, I mean, I can whip out a spec in like 12 minutes now. That would have taken me seven hours of procrastination and, you know, two hours of real work. is now like zero minutes of procrastination to 12 minutes of actual work, right? At the same quality. But it is all the little micro decisions, things we always call things like product sense, taste.

you know, prioritization. These things are actually harder now because the realm of possible solutions is even wider and I think even easier to build. You know, when engineering costs goes down, you actually have more decisions to make, right? And I think that that, I don't know how to grab onto it, but yeah, process, not a differentiator. Like if you focused your life on like moving Jura tickets around and like writing great requirements docs, like, yeah, that version of the job is commodity.

But it's the decisions and the prioritization that feel still deeply important. I have not seen anyone take that part of their job away on some level, right? You can write a strategy doc, but deciding whether it's right for you right now is still real work, right?

It's really interesting, you know, like it's interesting because you started off talking about agile and about how, you know, agile is sometimes a dirty word or people have different opinions. I spend a lot of time running an agile product and kind of I, you know, as part of agile transformations and stuff like that.

And I think what's really interesting is, like, people lost what Agile was really about, and instead they've got this, like, kind of reproducing some weird set of, like, you know, stone tablets that came down the mountain. But actually, and so, you know, at a prior company... The concept of a PRD, product compliance document, was a dirty word. Like, if you said that acronym out loud, like, people would be like, what are you even talking about, right?

And actually, personally, I feel a little bit like that, too. Like, I understand that they're, to some degree, a necessary evil. But really, with a product requirements document or a document like that, what you're trying to do is you're trying to communicate to another human brain what matters and why. What matters and why.

Why this? Why us? What matters? And you're trying to do it because you want that other person, once they've read this document, to be autonomous and to make good decisions. And so originally in Agile, the purpose of user stories...

Actually, quite literally, it's defined as a placeholder for a conversation. So it's actually meant to be a one-sentence thing that says, as a whatever, I want blah so that I can do whatever. And then it's meant to be a placeholder for a conversation. So even to talk to each other.

you know, about that thing and share the context so that you can make good decisions. And so, you know, when you were describing what you're describing, Freed, like saving nine hours on the document, I agree that it does do that. I also wonder if now we're going to get back to the real stuff. Maybe instead of doing all these docs and all these kind of words, like all these words we pitch at each other, instead we'll be like, hey, how can I very quickly...

Like right now, tell you what will matter to this customer because we've got to move quickly. Like imagine, let's say, for example, you're a new startup or whatever against other startups armed with the same technology. They're going to move as fast as you are. So you can have to move really, really fast.

And the fastest organizations move fast when they're highly aligned. Like, they all understand what the problem is. You don't need to stop. You don't need to stop and have a Slack or have a discussion with the PM. What am I building? Who am I building it for? So I wonder whether or not this, like...

might lead to a return to the core bits that matter. Not everybody needs to know everything, but they need to know enough to really be dangerous. They need to know enough to understand what the real problem is and the space which it can be solved in.

I want to also be aware we're three product guys bringing an opinion to products. We might be a little biased, just a tad biased. However, because I think one of the arguments out there is... chunk that is left that is still like really important why not just absorbed by somebody else the engineer the designer right like a different role i have this running joke that's like

Every product has a product manager. You just sometimes have to figure out who it is. It doesn't matter if someone has the role. I mean, in the first startup I ever worked at, there were no PMs. But guess what? I was the product manager for large parts of the product as an engineer. Designers were often the product manager for large parts of the product because they were closest to it.

And it really boiled down to what are we building? Why are we building it? Why is it differentiated? And who's making decisions about the marginal cases, right? The things where you could go A or B, who's deciding? And how are they deciding? Are they using data? Are they using taste? Are they using design? I do think that's the contrarian opinion, Brian, which is maybe there isn't enough process work to make it worth a whole separate job.

And that's the part I struggle with. Is a designer way more equipped to be the product leader for a feature? than a separate person who's only doing that as their job. And I don't have the answer to that. Let me answer part two of my question before Sean gives a take on that, which is, you know, Sean, you described these three legs of the stool and you're saying, hey, this...

These two kind of go away. They're not important anymore. This one is left. Does the stool grow more like new ones, right? Like new things that, and as a result, to your point, Farid, you know, does justify it. So I think that's part two of.

the question in my head as well. I think you're going exactly where I was going to go, Ryan. The problem is that there's circular logic eventually. You're like, okay, it may be true that the product management job would collapse into engineering, but you could just as easily say the engineering job collapses into product management.

Right. That's where my brain goes to. And so, you know, you've got to be careful what you wish for here. Like, I don't think it much matters. Like, at the end of the day... Will things need to be built by more than one person? In other words, for the foreseeable future, will there be teams of people that build things? If that's true...

then what Fareed was saying kicks home. Like, it still matters. It doesn't matter whether or not you're Titleist Product Manager or its designer or its engineer or Grand High Puma. It doesn't much matter. There does have to be somebody who's, like, bringing that intuition, the value, that judgment, the taste.

And also the one who gets to decide, like, if it's a lineball, is it A or B? What are we going to do? And so we think that even if we killed off the role, the role would still be emergent. In other words, there would still be that need, that that role would still exist in some person.

It doesn't necessarily help the people who are like fretting, you know, because you were saying that what kicked this off, Brian, was people were fretting. You know, it makes sense to fret. But just similarly, you know, if you're worried, hey, I'm a product manager, is my job going to exist?

then maybe you should be thinking, hey, I'm a product manager and I also want to use LLMs to become a really good designer. At least know enough to be a half-decent designer. Or I want to use LLMs to get a little bit more dangerous with code. I think that if it closes some doors, it definitely opens some too. I think of this as like Rise of the Builder, that like the person that has the idea and an idea of what needs to be done and can communicate or show the path the best on individually.

removes a lot of the alignment job right like the more a single person can do i think your point is a good one complex problems are always going to require teams of people to build so like I do think there's this builder mentality that will become more and more important. Can you prototype instead of spec? Can you write a little bit of code? Can you do complex data analysis? These kinds of things.

Versus telling other people to do them. But I do think leadership, and I mean this not as management, but leadership, which is how do you get a bunch of people excited about doing a thing, which really is if you think about it. at least for great product management, a big part of the job, is still important. Because I don't think people do things just because the robot told them to. I think for at least the next three to five years, there's still going to be...

Humans are going to follow humans, right? I think the builder point kind of goes back to also what Sean was saying before, is that's what made great PMs great PMs. Always is like I've always had a bias towards people who have had some form of building background, whether that is from a little bit of the engineering side or the design side.

Or some other aspects of creation and just the pure process manager types that just never lean towards. But it also kind of brings into my question of going back to those three legs of the stool. I think a big trend over, you know, especially the past five years, six years has been.

Product teams basically hire all of these adjacent roles to help them with the process and the knowledge, whether that's the product ops, the user research roles, the PMM roles, right? So the triad... all of a sudden became like an octagon at some point or an octopus yeah like eight little tentacles like all over the place i think

a lot of that will end up collapsing more to kind of getting back to the question of like, even if you take some of these pieces away, other things will collapse towards this role and new legs of the stool will emerge. Yeah, I think... I mean, I totally agree with you, Brian, and I don't want to be Pollyanna-ish about this, because I think that at the end of the day, what you just said is a bit alarming.

Right. Because, you know, if there's an octagon today and now it's back to a triad or who knows, a singularity, then, yeah, there's less work. There's going to be less manual work. And so actually that does mean that there's a bunch of people who are going to have to adapt or find another kind of way of work or find another line of work. I mean, because there are a bunch of, you know, you just named a bunch of.

roles where I do worry. I'm like, okay, how would you prove your value? How would you go from kind of doing manually what can now be done dramatically more easily? That is real. That's real. And we're going to have to figure out what to do about that.

Luckily, I hope that people are adaptable, right? You would argue, let's say, for example, you're a user researcher. If you're a user researcher, you would have to imagine that LLMs are a bit of a target on your back. There's no doubt that that's a problem. I would imagine anybody in the user research field is like, oh, no. So, you know, if I was in that field, I'd be adapting as quickly as possible. Like, okay, how do I make it to higher ground?

How do I get, you know, better, faster, you know, faster access to inbound data sources, better, you know, interrogation of the data to... find angles that others can't see. You'd basically be thinking about, how do I run faster than the next person when the cheater is chasing us? You'd really have to be thinking that again, because the status quo is not going to cut it. It is definitely true that this is not going to have zero impact for people.

I think the job as it is today is definitely going to collapse in a bunch of different fields. Not to pick on the research, but I think that's a really good example because it's sort of happening very quickly. If you think about like... the list of things a user researcher did, a lot of them were pretty rote, right? notes, clipping, tagging survey data, setting up interviews, annotations, setting up interviews, you know, all of that sort of stuff. That stuff's all collapsed.

If you think the job isn't going to change, then yes, there will be fewer of them. You will go from one per two teams to one per 10 teams because that work has collapsed. But I do think that in almost every job... Like looking at the Industrial Revolution, for instance, I don't know, like not to be weird and historical about this. What we've actually done as a human race has generally been to expand the scope of the things we're trying to do.

There is so much data analysis I would love to do that I didn't do because it was too hard. Like meaning the activation energy, the cost to get to any insight was high enough. That even if the insight were valuable, it wasn't worth trying because it was just going to be too much SQL, too much data, too hard to get to, especially around things like user research. And now maybe the list of things I'll ask.

as a product leader is just going to be longer because it's easier to get at. And I do think that there will be an expansion. I do think the number of companies that exist. is going to have to grow, or at least the scope of the biggest companies will grow. If you think the job is dead, I mean, we thought this when software engineering was being outsourced worldwide.

It's just the amount of software we decided to build accelerated. I think you still have to believe, and I think that's true with research, Brian. I don't know about you. You obviously are working on products to help people with research right now. Are you seeing that people are coming in and saying, just want to make the things I did before easier or is it that the scope of the things they're trying to answer has grown dramatically I mean this is where I get into my own circular

logic where you look at any one of these functions and you kind of end up on the same things, which is what made a great user researcher great? It was the one that spent the time finding the question to ask that nobody else was asking, you know, the ones that were able to like synthesize the angle.

that right and so in the same way of all the things that we're saying about product management there's there are some elements of truth to those other other pieces but yes to your to your point is like a lot of the stuff with insight analytics the new product is just It takes all of that rote stuff and more. It enables things that orgs were not able to look at before. And as a result, like not only like empowers everybody, but at least on the research side.

empowers them to focus on the long-range, messy, strategic topic, hopefully the questions that nobody else is asking or the customers are not currently saying that they might not have been able to before. That's a shift. It kind of goes the same thing as like process value collapses. Just that, yeah, that analogy, you know, I've worked in companies that have great self-service data infrastructure. I've worked in companies that have awful.

self-service data infrastructure, right? And what do I ask a data analyst to do in each of those? In the one with terrible self-service data infrastructure, I'm asking them to make dashboards and give me basic you know, answers to questions every week. I need to report a bunch of things. Please go do that. And they have to spend a bunch of time on it and it's hard. And you know what they don't do is.

answer complex questions that are future looking or are deeper analysis. In a place with great self-serve analytics, I spend a ton of time goofing around, looking for stuff, finding trends, and then the questions that I am posing. To a now not an analyst, but rather more of a data scientist, somebody with like deep statistical knowledge, like the bar of what's good goes up because the questions I'm asking are like orders of magnitude more complex.

And we're actually doing all of the same stuff plus more. And I just feel like... I hope that's true for product management as well, that it won't be just like deliver the same product, but deliver much more complex, much more thoughtful, much more analytical work that is much more reasoned. because your access to knowledge is so much higher, right? Humans are insatiable beasts. They're never like, wow, this is enough.

Let's just like eat this food and be done with it and stop working. We're always looking for more, right? I mean, there's... Gotcha. I mean, but you said earlier, Freed, you said like judgment and taste, right? Judgment and taste are like two of the key attributes of a good leader or a good product manager, judgment and taste.

If there are unlimited problems to be solved, unlimited things to be thought about, unlimited data questions to ask or whatever, you have to know when to stop, right? You have to know when to start, where to stop. You have to know when near enough is good enough.

You have to know when you're basically p-hacking, you're accidentally p-hacking a bunch of stuff anymore, which happens all the time as people follow data threads. It's easier said than done to do this well. And it's really funny because I think we all probably retreat to our...

kind of easiest mental models or the things that matter the most to us. One that I go back to a lot is the design double diamond. I assume you guys know it. But basically when you're looking at a problem space, you first spend a bunch of time going expansive in problems, problems I might solve.

and then contract it into choose a problem to solve. Then once you've decided the problem to solve, you go expansive in the solution space to decide all the ways that might exist to solve, then go contract again on the other side to decide how you will solve it. That, to me, turns out to be a really useful analogy for a lot of different walks of life. Product management is like that too, not just from a design perspective, but from a market problem perspective.

What market problems exist? What market dimensions exist? What is the strengths and weaknesses of my competitors? You can kind of do that. Or data analysis, like Fareed was talking about. What are the problems I might learn about through with data? How might I narrow down the one I care about? What are the answers that exist in my data? How might I narrow down the ones I care about or find the ones? I think that the judgment and taste to do that and to decide when the loop should finish.

Like when to start the loop and when to stop the loop is actually much more complicated than it sounds. There's one, maybe two potentially more angles I want to explore this from. So we talked a little bit about some of the fundamentals of PM and how some of those things are changing. Another way to potentially look at this is through the different types of product work in how they change or what gets more important or less important. So the different types of product work from...

The product strategy program, there's initial product market fit, there's core feature work, there's growth work, scaling work, and then product market fit expansion. So I'm interested from like you two, are there any of those buckets that you think fundamentally... change more than others either they get more important less important or how do you think about that think with zero to one like initial product market fit interesting thing let's use sean's description of

expanding the problems, narrowing down on a problem, then expanding the solutions. The evaluation of possible solutions is a lot faster and I think more precise. given the advancements in the tooling and our ability to create real prototypes, real products at faster scale and speed for initial zero to one product development. And I think what that does is...

We're making decisions on slightly more complete data. Hopefully now there's still magic to product market fit. I don't think that it like changes that you're all 20 of your solutions might be garbage. I feel like in a lot of early stage startups, you're kind of picking something because it's your best guess. And it costs so much to like figure out if it's true or not that you don't have a lot of time to do the next thing, the next thing, the next thing.

And I think that that piece of the double diamond, the like, okay, we've narrowed on a problem. Let's try a bunch of solutions and see what works. I think is at higher fidelity. At least that's one opinion I have. I think broadly speaking, the return on investment from exploration has always been higher than the return on investment from extraction, right? So if you think about your goal is to explore.

find, you know, seams of like valuable minerals or whatever it is, and then extract them. Extraction is more, is more, you know, operational. Like it's more, it's more executional than is, than is exploration. And expiration is where most of the money is made. And so if I use the model that you're talking about, then that kind of, to me, makes me feel like feature work, for example, you know, very useful, very, very important.

But clearly, you know, the incremental value or the, you know, your competitive value is going to go down. And if I think about, you know, scaling work, so work to, you know, help the organization be more effective or...

be operationally more scalable, that is also like a low leverage activity. And so what that leaves behind is you've got product market fit stuff, which is obviously very high leverage and it's an expirational gig. Growth work is expirational because you're trying to figure out... One way to think about it is how do you accelerate adoption and drive usage? So doing work to accelerate adoption and drive usage.

I actually think about it as exploring why the product doesn't grow. Why do people not adopt it? Why do they not grow it? Why don't they love it? Why don't they click the buttons I expect them to? That's fundamentally explorational. And I'd argue that product market fit expansion is also explorational. And so explorational seems more defensible in the face of AI than, you know, executional or operational sorts of endeavors. I also want to...

get your perspective from this. I don't know if either of you have seen this yet, but there's a blog post. They called it the LLA curve of impact on software engineers. Have you seen this? Yeah. Did you see Tom Tungus' follow-up to it? No. That's where I saw it. That's where I saw the curve was in Tom Tung. Oh, yeah, yeah. So for those listening, there's a graph here on the y-axis. There's the impact that LM is going to have. And on the x-axis...

There's the levels of a software engineer, junior, mid, senior staff. And then Tom created a couple axes, impact to the individual, impact to the business. And the y-axis now goes from negative impact to positive impact. If you had to think about it for a second and plot that for product manager, what do you think the shape of that curve would look like? I mean, this is something that, you know, I'm not generally a person who frets. I'm more of an optimist, but I think that...

The junior PM, impact on junior PMs is potentially catastrophic. It's bad or worse than engineers, because at least engineers still have to take the code, compile it, run it, deploy it. If the job of a product manager is to prioritize, decide, make decisions, find competitive advantage, at the junior level, usually that's feature work. It's the stuff I was talking about a second ago, Brian. It's the operational rather than the explorational.

work that they typically get tasked to do. And if that collapses to zero, then that's a big problem. I think of a junior PM as known problem, known solution, drive execution. That job kind of doesn't exist, right? It's pretty scary. And so then maybe traditionally a product management, you remember how I said the product management didn't exist 30 years ago? It actually mostly emerged out of engineering.

So oftentimes they were like engineers who were like the lead engineer, the lead engineer or the team lead would also be kind of co-opted to be the product manager. So I wonder if we're going to see, you know. kind of honestly some of the opportunities for PMs early in Korea to collapse, like to not exist anymore and to fall back into other disciplines. So that... Those were few and far between anyways. I mean, APM was not as...

never been a very high volume thing anyways. So most companies start at PM, senior PM and transitioning people. That's true, but even more, but basically like imagine that even further. So we might see a case where... People don't, you know, bounce out into product management until they're like, you know, principal product manager. They might be principal, but maybe it's GPM. It's now the kind of the entry level of a product manager, which you obviously have a profound impact on.

Yeah, I think the impact, the positive impact on the junior person feels not as high for product as it is for engineering. Like if I'm a capable engineer, but like new. And just, I am helped immensely by LLMs, right? Like I'm just able to get knowledge of a code base, get going quickly, et cetera, pretty extremely fast. I think the positive impact on leadership.

is incredibly high. I mean, I spent an hour today with OpenAI's Deep Research doing some longer-term analysis of a market or two, mostly just to play around. And I was surprised by how much it helped high-level decision-making about what the big exploratory bets I should take. I want to transition this to advice. I just want to connect the dots here with something that I haven't taught.

I haven't talked about yet, but connects to the junior PM and honestly, like the entry level of any profession, which is, yes, there's a lot of challenges there, but I actually think there's some advantages there too, because as I've started to talk. more about this and you know we've been doing courses inside reforge is The resistance is real for those who have been in the profession for some period of time. We have these ingrained habits, right? And habits are a tricky thing to change.

And so if I was earlier in my career, the advantages you really have to play into are one, you have nothing to lose. You don't have those habits ingrained. Two is you tend to have more time. You tend to be younger. And you just tend to be more multiple and be able to like try and see things from different ways from first principles. Now that we have all these new tools that I think are a little bit harder to see when you've been doing something.

in some way for a long period of time. And so kind of going back to what we were saying before about... Hey, it's the fog of war. You just got to keep revealing the map. You got to keep going through those cycles. That's the advantage that people earlier in their career have is that they have more time. They have a little bit more flexibility to try to get those cycles in.

and do that whereas i think people later stage in their career look most companies right now 99 of them are like i would love my team to be playing with this stuff more and it's like well have you created time for them to do it and they're like no yeah we're too busy I think there's never been more opportunity for incredibly self-driven, ambitious people because the amount of stuff you can do on your own before you need to convince a single other person.

is so much higher. So I think that's fair. I have teenagers now. They're starting to get their first jobs. And I give them what I call my three rules of work. Rule number one is show up on time. Rule number two. is do what you said you were going to do when you said you were going to do it. And third is don't wait to be told what to do next. Meaning like, think ahead, step ahead.

The advice I give is you're better than 90% of people if you do those three things. Tech's a little different. We are surrounded by highly ambitious, highly hardworking, intense people. But I think it's true in most companies, most industries, most places. That if you are ahead of the curve on this stuff, if you don't wait to be told to use these tools, but instead just use them because it makes your life easier.

I think you will find ways to stand out amongst the crowd of people who are just showing up. I really like what you guys were just saying. If I play it back a little bit differently, I think that being adaptable and curious.

is at all points of your career a superpower. Like, it's just kind of the thing that's unstoppable. Why? Because when everyone else is standing still, you're getting better, right? And so it's a form of outrunning a cheater. It's like a sustainable, competitive outrunning of the cheater.

What you're saying, Brian, is not just that, but it's not often that you see an epoch change. It's not often that you see a new tool show up that is outstandingly great. Like it's like that happens once every 10 years, every 15 years. And we're at the dawn of one of those.

So if you're adaptable, curious, and the first in your cohort to start applying these tools, you're a god. Like you can stand out. Like you can stand out wildly. No, really. It's amazing. You're making a good point. You're like, you can not just outrun people. You can run rings around them. And so I think that's really good advice if you're earlier on in your career. But actually, it's good advice for everyone else because you're about to get rings run around you if you don't do that.

But if I step back a little bit, hey, one problem that I really worry about is at the end of the day, we talked about you have to have reps, you have to have swings at this, you have to really have to have at-bats to learn. And one of the problems with product management is that an at-bat... typically involves shipping something. It actually involves something happening in the real world. When you're an engineer, the code compiles, it runs, it does what you hoped it would do.

So you can have our ads at a clock cycle that is different than the clock cycle of the world, right? So in other words, it's clear that this technology delivers disproportionate advantage to different people.

So if I was in a, you know, I am a product manager, so I am in these product manager shoes, like I'm thinking, okay, how do I apply this technology to get more at bats? One way to think about that is that, you know, it's always been hard in product management to ask history, the history of software, like, hey. What companies have tried X? What did they try and what happened?

Right. So I would encourage people to do more of that. You know, if you did an MBA, you would remember you always did these HBS reviews or whatever, where what did this golf company do in a highly competitive golf market or whatever? Like to try and be.

You know, if you're early on in your career, try and be a student of what people have tried, what has worked, what hasn't. Try and understand the dynamics of those things, because that is a superpower, like really being able to see around the corner.

Being able to predict what's going to happen if you can't necessarily get an at-bat on that problem is certainly going to make you stand out from the rest of the crowd. If you have those stories, you have that intuition, you have that understanding. All right, everybody. I hope you enjoyed all of those thoughts from myself, Farid, and Sean to help you kind of navigate this really messy environment. If you have any questions to us,

feel free to reach out. You can also check out all of the different episodes of Unsolicited Feedback at unsolicitedfeedback.co. Also want to make sure you know about the two products we mentioned here. First, Reforge Insight Analytics, which helps product teams gather and aggregate all of that messy qualitative data that they have about their customers from all the different tools across their stack and organization into one place, uses AI to analyze it.

and get it into the fingertips of the actual builders, the engineers, the PMs, the designers, as they are building the products and making all of those decisions on a day-to-day basis. The second is our new AI courses, AI Foundations, and AI Strategy that will be coming out soon.

We're creating these with some heavy hitters from the AI industry, including OpenAI and other companies that we will announce soon. Both programs go incredibly deep on the topic and really help fast forward your knowledge in this space. Check them out at Reforged.com. We hope to see you there.

This transcript was generated by Metacast using AI and may contain inaccuracies. Learn more about transcripts.