The Product Manager

How to Succeed in a Feature Factory as a Product Manager (with Aakash Gupta, The Product Growth Guy)

• Hannah Clark - The Product Manager

Share episode

In the ever-evolving world of product management, the term "feature factory" has become somewhat of an industry buzzword, often thrown around with a mix of humor and resignation. But what does it really mean to work in a so-called feature factory, and more importantly, how can product managers not only survive but thrive in such environments?

In this episode, Hannah Clark is joined by Aakash Gupta—Product Leader & Author of the Product Growth Newsletter—to explore these questions.

Hannah Clark:

Feature factory - noun. Definition - a software company focused on constantly building and releasing new features rather than building a product that users actually want. Used in a sentence, "I thought I was hired to guide the product team in a bold new direction, but instead I'm just plugging away at a feature factory." Tell me, would your picture be next to that dictionary entry? You and thousands of other PMs, my friend. So if that's just the way it is, what can you do about it? My guest today is Aakash Gupta, who writes the iconic Product Growth newsletter. Before focusing on the newsletter full-time, Aakash spent the last 12 years in senior and executive level product roles at companies like Epic Games, Affirm, and Apollo, meaning he's experienced just about every level of influence a product manager can have. And as you can imagine, Aakash is all too familiar with the circumstances that create feature factories, and his playbook for managing as a PM in these orgs is both ultra practical and refreshingly realistic. This is an episode you're going to want to pay close attention to all the way through, so let's jump in. Welcome back to The Product Manager Podcast. Aakash, thank you so much for making the time to talk to us today.

Aakash Gupta:

Absolutely. Glad to be here. And thanks for having me.

Hannah Clark:

Yeah, our pleasure. So can you tell us a little bit about your career background and how you got to where you are today?

Aakash Gupta:

Yeah, when I started in product management back in about 2008, I feel like the discipline wasn't as developed. I think INSPIRED published right around that time. I think that that actually really helped a lot of things. Before that, there was maybe like Ben Horowitz piece, like good product manager, bad product manager. But outside of that, the field wasn't truly professionalized. In fact, it primarily existed in Silicon Valley companies and startups. I got introduced to it because the founders at the startup I was working at were religious followers of everything Y Combinator. And a lot of Y Combinator companies at the time had product managers. So despite working at a startup of only six people when I joined, I joined as a product manager. Luckily, I had an engineering background, so I had coded many apps, program, and had dallianced with using Photoshop. So I would pinch hit with absolutely everything when I started. Designed our website entirely, designed, redesigned huge parts of our app even though I have very meager design skills. And then for our website, I managed our CMS and all the technology behind it. So pinch hitting in every single way as the early stage product manager, as I was figuring out what product management was, as I was learning what product management was, but it was really that startup style. And I went and worked on my own startup after that called Rap to Beats. And that was basically me doing the exact same thing except more coding. So I was building a lot more versions of the app. So I really have this like builder background into product management. And from there I went into true product management at a company called thredUP, which is now a public company. I joined it when it was series C and left in series E. And together we built out a lot of the early growth teams there. So back in 2014, if you remember, Uber's referral program was like the hot thing. I remember when we released our referral program, it was like a huge growth driver. You could just do simple things like that. It wasn't even optimized. So I started to ship products. I started to realize that we could fundamentally change the trajectory of growth of companies as a product manager. So that's when I really committed to the craft of product management. Since then, I've been a product manager at places like Google, Affirm, Epic Games, and most recently Apollo.io, where I was a VP of Product. And now I'm working full-time on the newsletter.

Hannah Clark:

Awesome. And I know so many people enjoy it so much. Today we're going to focus on feature factories and specifically how PMs can survive in that feature factory organization. That is almost like a swear word in the industry now. So let's start at the beginning. How do organizations devolve into feature factories and why is this such a common outcome?

Aakash Gupta:

I actually think that all roads lead to the future factory. So let's say you're in an environment that is empowered, like classically empowered. What's happened over the last four to five years is one of a couple things. Either in a case like Airbnb, the founder has retaken control and they have said like, okay, these are some of the things I want built. Or, another thing that might have happened is that product leaders have taken control by having lots of layoffs and reorganizations. And what they'll often do is they'll use like constant reorganizations as a way to get people into positions and work products and features built that they want built. So ultimately what's happening is either CEOs or product leaders, because of the pressures of the recent environment have said, like, we can't just be empowered. We can't just hand this over. Sometimes I see product managers are 26 and have four years of work experience. We can't just hand over our 1 billion dollar business product decisions to them. And so what's happened is that even in those classically empowered environments, all the way up to Google and Netflix, I talked to people there. It's not like all of a sudden product managers are determining 100% of the roadmap. Many times there is a bottoms up process and a top downs process that happens in parallel that's invisible. So this bottoms up process, the PM is coming up with their ideas, they're submitting it into the planning, but when you look at the outcome of what's ultimately agreed upon, a lot of that is stuff that executives had to okay, they had to be convinced of, they often had the ideas of themselves. And so, I think that a lot of people put window dressing in the empowered environment around OKRs and quarterly planning, but the end result is that feature factory at the end of the day. And that is maybe to begin with only a quarter of companies that are really empowered and they descend into the feature factory. For the other 75% of companies, I'd say like about 30% of them are in their transformation phase. Those companies are like, we understand we need to move to agile. We understand we need to move to empowered PMs. But what ends up happening there again is that as PMs work with other functions, let's say design, engineering, business, sales, in those industries like banking or healthcare, where a lot of this digital transformation is happening, those people are still used to the feature factory way of working, the waterfall way of working. So even if the product org wants to implement those changes, it takes years. I was talking to Marty Cagan and he said it takes three years. And I think that's about right. It takes about three years. So there's some companies that are in that mix. And what's ends up happening is that PMs are held accountable for metrics, but at the same time they're dictated what features to build. And it's this messy middle ground. And then the final ground is like just obviously waterfall, obviously feature factory environments and plenty of places are totally fine doing that. If you talk to your average PM at Apple, the executives are determining a lot of the product feature decisions, Jony Ive and Steve Jobs when he was there. We're making a lot of the key decisions. So that model can still succeed and people think like, Oh, it doesn't succeed. Marty said that the best companies are all empowered, but I found that all roads lead to the future factory.

Hannah Clark:

I can see when you follow the train of thought, it all logically, it makes sense. Let's chat through some of the steps that you outline in the blog that you wrote on this topic. If you haven't read the blog, it's really interesting how you've broken it down and you've taken a bit of a controversial stance on how to react to being the PM in a feature factory as well. Before we jump into the steps, can you talk a little bit about where you stand with that and the alignment that you have, like specifically with Melissa Perry?

Aakash Gupta:

Yeah, so I think like there's the idealists and they're the realists. On the idealistic side, you have people like Marty Cagan, Teresa Torres, John Cutler, all three of which I love, admire, and read everything they write. But I think that they believe, like, as a PM, you should try to transform your org if you're in a feature factory. That's fundamentally what they preach, that's a lot of the tools that they share, the insights that they share so generously for free. So I love and respect them, but that's what they believe. Myself and Melissa Perry and other people like that, I'd say like Clair Vaux, there are like different other influencers, Powell Hearn, are a little bit more on the realist side of the spectrum, which is to say like, you know what, as a PM, I don't think, unless you're maybe have eight, ten years PM experience, plus have like that group product manager or above title, you really have the experience or the influence to effectively transform your whole org. So instead of just doing that, maybe think about some other strategy. And why do I say that? Because I've seen so many people try to live this idealistic lifestyle. And so, the anecdote, some people might have heard me give because I might be a broken record on this, but I love to sort the product management subreddit by top all time posts. I think it's still today that 8 out of 10 of those posts, the PMs are like, I hate my job, my job is miserable. And if you read the details, it's PMs in a feature factory. Some of the quotes that they'll use, they'll say like, I joined product management after reading INSPIRED and I thought that I would be able to dictate the roadmap, but I'm just an order taker for the CEO. This is like an extremely common scenario, which is that people are in the 75% of companies, which are feature factories explicitly, and they're just upset with their job because they are. And so if we think about that, I feel like just to avoid all that mystery, because I have a ton of product management readers of the newsletter, my advice to them realistically is like, just embrace it. Surrender to the factory. You're better for knowing that you're in a factory. And now you can say, okay, well, as a factory worker, what do I need to do to embrace this and move forward?

Hannah Clark:

Yeah, I think that mindset has so much to do with how well we do it in any difficult situation. But yeah, it doesn't have to be difficult. So let's talk a little bit through the steps that you provided in the blog post, starting with surrendering to the factory, which you touched on already. For you, when did that really click as sort of like a necessary step in the process?

Aakash Gupta:

Yeah, I think failed actually transformation attempts. So for instance, I've been in different types of environments. Actually, a lot of PMs haven't been in, for instance, a gaming environment. So I was working at Epic Games on Fortnite. A lot of people think about the future factory in terms of like maybe the CEO or the chief product officer, the chief design officer dictating. Actually, in a games company, it's usually like the designers who are just coming up with super cool things and the creatives and they're coming up with like, this is going to be awesome. The 14 year olds are going to think this is the most rad experience ever. And so then they like stuff the next season release with like the most rad experiences ever. For me as a product manager, it's obvious like there's really low hanging fruit on our performance. There's really low hanging fruit on our onboarding. There's really low hanging fruit on our updating. If anybody's tried to update Fortnite before, to this day, we've made a lot of improvements, but I would just updated it recently. It was a 42 gig file. My computer took two hours and I run a Mac, which is like horrible. So it took like 50 minutes to install the update as well. So we're talking like extreme friction and the company releases these updates like twice a week. So we're talking about hours of friction twice a week. And then in the monetization store, very low hanging fruit around, just creating more variants to target people who are spending three, 4000 a year in the store. But to convince people who cared about, well, what's cool, one approach I could have taken and I initially thought that this might be smart. It's like, tell them like, Hey, we need to embrace outcomes, how to outputs, not cool features and all of this fell on deaf ears. So it was me actually like trying some of this. Then I was at a firm, very centralized planning infrastructure. I thought like, okay, you know what? On my roadmap, I'm a GPM. Like my team is going to have more fuzzy problems. That did not fly at all as I went through my first planning cycle. And like the executives looked at it and they're like, did you guys do any work? Like everybody else's roadmaps are way more detailed with like these amazing wireframes of their feature and their analytics team is estimated down to seven significant digits with the revenue and profit impact is. So you just look horrible. It's actually like making these mistakes myself. Plus now I've been coaching a lot of PMs and I've run into a lot of PMs who actually they come to me because they might be struggling a teeny bit in their career. They might've received like a lower performance rating that they wanted. And as I investigate deeper, one of the things we'll often do is like do like a 360 review, is I'll find that they all have like designer and engineer counterparts will say, yeah, his PRDs weren't as detailed and like I find that these PMs think that they're living in the empowered world. But in reality, they're living in a feature factory and in the feature factory that demands an amazing PRD that's really detailed. And so they miss those fundamental tenets and then they perform worse. So all to say, it's all motivated by, you got to improve your performance. And in my real world experience in these different environments, I haven't seen that you can just immediately affect change. The only place I was really able to is once I hit the director and VP level. When I was at thredUP, when I was at Affirm, in those places, actually what your job is, is to uplevel the practices of your orgs. And so as that happens, then you need to chip away at it really intentionally. And it's great that we've defined what the feature factory is, because you can basically say like, I'm going to slowly chip away at each element of the feature factory, cause it is an anti pattern. But my point is basically as a career advice, if you're not at a certain level, you shouldn't try to fix that anti pattern.

Hannah Clark:

Which brings us to our next step, which is adapting to the environment. So what you wrote is all about focusing on what's your real job, like do your real job. Can you elaborate a little bit on that step and kind of the sub steps that accompany that?

Aakash Gupta:

Yeah. So what I find like amazing is like, as I reflect on the types of work products that I created in each of my PM jobs and especially the ones that were received well, they were totally different. At Epic Games, ultimately it was like pitches of cool features. Oftentimes I like sat like until 2am with some tech designer and we created like a playable demo of the cool feature with hazy graphics. And that is like what did well. Now, if I look at like a firm, I've already explained a little bit of the environment. It was when I came in with an amazing well impact size roadmap that had all of the spreadsheets of data with all the impact sizing models. Complete polar opposites, essentially, right? And so the thing is that you need to evaluate what product management success looks like in your environment. And I recommend interviewing the people who have been PMs at your company the longest. That's one good way. And then PMs who have been recently promoted. These are like two really good things to look at. And then obviously not just sticking to the surface level with these relationships. So what I recommend is try to get a lunch with this person. Try to get a lunch with this person in person. Maybe don't even like pry too deep on that first one. Maybe try to offer some value to them first. After you've gotten a really strong relationship with them, they're helping mentor you. Then you're starting to talk to them. I like to ask questions like, do you write a PRD for every feature? Can you share your best PRD? Can you share your last promotion packet? Can you share your last one-on-one notes with your manager? Like, really highly tactical things, but you can never ask anybody if they're not your friend, right? So I actually say, like, make them your friend first. Make them your mentor too, maybe. Although I don't recommend, like, explicitly asking them to be your mentor. Because a lot of people actually, they want to see that their product managers and product leaders have like their own center of gravity. So I would say what they'll read that as is like, Oh, he's an investigative guy or gal, and they really care about succeeding. So what you should do is like, you have these interviews, it's just like your own product, right? When you join a job, you're going to be interviewing customers, non customers, competitors, and other people at your company. And then as you do these interviews, I highly recommend having a direct one-on-one conversation with your tech lead, engineering manager, designer, user researcher, analyst, and probably even map boss and skip level, where you clearly define your roles and responsibilities. And you should try to be super explicit. You should ask your designer, what do you think about PM sketching and wireframing? Most designers will say like, no, I'm maybe not that interested. Some might say it's okay, but as long as it's not in Figma. You need to know those nuances. So understand how to work with your specific stakeholders. Because a mistake I've seen with some people who do these interviews is they assume that their PM job is like this other PM in a different team. But actually the designer engineer you work with and the analyst you work with, they have their own set of expectations. And so everybody wants to climb the mountain of product leadership to hit the VP. But just for now, just focus on that one step ahead of you, focus on those close people around you and create like a contract and then once you have that contract, then I think you can start to test into it, see what's well received, what's not. Sometimes, maybe the engineering manager doesn't know that the engineers on his team really love to be invited to customer discovery calls. That's only something you'll learn in practice. So then stay super attuned to like your small group. This is like basic career advice, but the reason it's, I'm putting it here is because it's all about understanding what your PM job is. I don't think any PM job is the same.

Hannah Clark:

It sounds like I think in every work environment, the people you work closest to, you kind of form like a micro culture. So it's important to understand like the nuances of that culture, what languages everybody's speaking, making sure that the expectations that everyone has of each other are aligned and totally appreciate that. And that kind of ties into, you'd mentioned having one-on-ones with folks who've been successful in the role for a longer period of time. So the next step in your trajectory is to create a promotion path. And those people are really factor into that step. Can you tell me a little bit about that strategy for creating that kind of career roadmap for yourself?

Aakash Gupta:

So essentially, if you think about the future factory, there's usually a very consistent set of criteria that you need to meet. These criteria are often unwritten and unsaid and misinterpreted by your own manager. And so a lot of people, they tend to lean on their own manager. They might even, I've had some people on my team who are like fairly pushy and one on ones with me about like getting promoted, et cetera, et cetera. But what they failed to understand and what I had to coach them on was, I'm not the only one making your promotion decision. In one example, let's take a firm. I'm writing up a packet for you that I submit to a promotion committee. And that promotion committee compromises everyone in product leadership at or above my level. So all of those people tend to at least chime in once in the conversation. So realistically what you need to do after you've convinced me is convince each one of the product leaders at a firm at or above my level something positive to say about you. You need to work with them and that is what has actually worked at a firm. And so it's really about understanding what is the unsaid. And I was working with some other PMs at a firm who are having trouble getting promoted. One was like, I believe a senior PM for like three years had done a bunch of good work. And so I just started taking one on once with her, even though she wasn't on my team and she got promoted the next cycle. And this was the advice I gave her. I said, like, I was in your last promotion committee and only your manager was speaking up about you. And her manager didn't give her that advice. So I think your own manager, you can't always rely on them. So you need to basically form relationships with other managers who are getting people promoted. You find these people, you form relationships. Again, I would say be a friend first, do some work maybe in collab with them first so that they can see you're good. Then go to them with an ask about Hey, like what is your experience with promotion committees? And for me, like the best insights I've got on that, again, is like in person over beers after work, then you can really learn what is going on. And so some people, I feel like they take like the 40 hour, nine to five approach to them. And I said, that's fine. I would say actually subtract 4 to 5 pm on Thursday and Friday and make it 8 to 9 pm because that's going to be much more effective for you for these conversations. You take that time to like learn how are people getting promoted. Because a lot of people have asked me like, how did you get to VP so fast? And the fundamental answer is I understood the promotion paths at different companies. Almost every company I joined within like a year or two I was promoted. And I had different people added to my team, had more scope. That was because I was just dead focused on this promotion path. And when I asked my friends like, Oh, have you talked to someone about this? Or what did you know about this? A lot of times they wouldn't even know that there was a promotion committee at a firm, even for instance, I've met many people like that. And I was like, Hmm, so there's like truly a knowledge gap. And so just filling your knowledge gap is step one. And then step two is thinking about, okay, what are my unique strengths? As a PM, I think everybody's going to drop some balls somewhere. Maybe your design feedback is an 8 out of 10. Maybe your ability to manage cantankerous stakeholders is a 7 out of 10. Whatever it is, then lean into whatever your strengths are. Maybe it's writing. That was an obvious one for me. Then really lean into that. How can you maybe create a weekly update? How can you socialize an amazing product strategy with more product teams than you normally would? So you're leveraging your strengths within the unique promotion criteria. How I did that was I would often share like my writing and I would say like, Hey, there's this part of my strategy, pay foundations, product leader that affects the foundation's product team. And so before we finalize our roadmap, I just sharing you a screenshot of this and that would interest them enough that they might look at the rest of the document and say, Oh wow, he's doing good product work. So it's about leveraging your strengths against those criteria.

Hannah Clark:

This is so smart and so tactical. I really appreciate the tactical approach. So the next step is up leveling isolated practices. When you refer to the isolated practices in this context, what does this step refer to and what are some of the concrete examples of ways that folks can hone these skills?

Aakash Gupta:

Yeah, so I mentioned like, especially GPM level and above, this should be done at the org level. So you should be basically piloting with certain teams what I'm about to say and proving that it works. If you're below the GPM level, I think you should pilot this within your own team. So after you've proven in those one on ones where you set up the contract with your design engineering and analytical partners that you can succeed under the contract they expect, it's time to say, Hey, let's shift this up. And you should actually ask for their feedback too and shift some things up based on what they say. But your feedback should be this. And this is like the order of, I've played around a lot with this order since I've been coaching folks and this is what I find is like the most effective order of techniques to move. So number one is feature results write ups. I feel like these are really non threatening in a feature factory or environment. We've shipped a feature, it came from this Brian Chesky, the CEO, yes, but he does want to know what happened and why. And in Feature Factories I find that actually leaders really do care about'why' something happened. So what PMs will really report is like, yeah, A outperformed B, so I'm graduating A, but that's not so impressive as A outperformed B because, and boom. All of a sudden you're influencing what comes next. Even though it's a feature factory and they may not listen to what comes next, it just follows from your narrative too, right? So I'll give you like a really concrete example. If you're at Airbnb and you just shipped total price, because Brian Chesky told you to ship total price. Well, you want to go back to him with what happened and why. And well, what's really interesting about that as well, we know that the conversion rate is going to go down on what people purchase, but the question is how much. We know that the NPS is going to increase because people are going to get surprised by pricing. We actually think that the conversion rate, once people add to cart and finalize their booking is going to go up. So we're thinking, we're not sure, like we know the conversion rate at the top of the funnel on the map is going to go down. We know the conversion rate on the purchase page is going to go up. We don't know how much conversion rates overall going to impact. Right? So Brian's really going to care. Now the data comes back. It's actually puzzling. Conversion rate went down by only 2% on the map page, but went up by 6% on the purchase page. So overall conversion rate went up by 4%. So his brilliant idea apparently was brilliant. We see a 4% increase in conversion rate. Why did that happen? You need to go further, I would say. Interview a couple more people, watch them, talk to your user researcher. What you might find is that, well, in the olden days, people didn't believe our map pricing anyways, our 357. They always just were so distrustful of that, that we solved this trust problem. And so then you can go back to Brian and you can say, Hey, the reason that total price outperformed on conversion rate, and I want to show you this really cool insight, it actually outperformed on maps too, is because people had so low trust of us on a nightly price. Then I think that he can take that and he can say, okay, where else do people have low trust for us? Maybe people have low trust for us in some of our reviews. Maybe they have low trust in us in some of what our Airbnb plus locations, whatever it might be. And then you can go through and you can really create a roadmap based off of that. So I went through this really long example to just explain that feature results write ups are really non threatening, and they move you down the first path. The second thing that's really interesting is impact sizing. So what I find is that PMs are really stuck in being accountable for outcomes, but they're being given outputs. So, in that world, what I think is really exciting and what's been very effective for me is when you're handed an output to build your steel man case, your best case scenario with the most data possible of how that feature is going to perform. And so I'll give you an example. Actually, our CEO at thredUP believed that taking the referral program from 10/10 to 30/30 might suddenly cause like a 5% increase in our revenue the next month. So I gave him the most generous assumptions, the most generous amounts of shares, the most generous amounts of referral acceptances from our best campaigns, put it all together and it was obvious. The highest I could get to was like a 0.1% increase in next month's monthly revenue. Then it was really obvious to him, like this feature is not going to accomplish the goal I wanted it to accomplish. So building a financial model for impact size is number two. Number three, I think people usually put the cart before the horse. They want to do discovery first. I say discovery is number three. So you've started to do feature results write ups and you've started to impact size features before they happen. Now I think when you're handed an output, you say, okay, thank you for the wireframe, Mr. CEO, Mr. VP. We are going to now do proper discovery on this and bring you along the path. I'm going to show you some of the videos, maybe using the new software like Dovetail, where I can really get the highlights out in 30 seconds of these are the problems with that. And so this is the new design. And some people do have that part of it. So then it's even expanding into problem discovery. The problem you attempted to solve by this design was, we actually think there's a totally different part of the product to solve that problem in. So you move from like solution discovery to problem discovery. That's like 3A, 3B. Number four is moving into OKRs. And here we're really getting into the GPM territory. Like, as principal product manager, do I recommend you adopt OKRs if the rest of your company does? Probably not. But if you're a GPM, OKRs I think are very effective to institute once your teams are doing discovery. And a lot of people do OKRs second. So they'll do like discovery first, OKRs. But they won't have built the muscle for future results write ups and impact sizing. And I find that those companies, their OKRs are just BS. They generally miss all their OKRs. And I would say this is probably like 90% of companies. So that's why I have this very intentional ordering. And then after that, between OKRs, I say like OKPS trees, which help you connect your OKRs to problems and solutions. And finally, product strategies. And it's funny because everyone thinks product management is product strategy, but I don't think it until you actually have control over the entire OKPS tree that you can write a product strategy. Until then, the CEO is writing your product strategy for all intents and purposes. Once you are fully empowered, then you can layer in product strategy.

Hannah Clark:

The next step, of course, is to build your coalition. We've already discussed a little bit on this topic about forming those really tight relationships with your design and engineering resources. But I'm just curious if you have a story of how this has played out for you in real life as well?

Aakash Gupta:

Yeah, so let's go into Epic Games. We were talking a little bit about that scenario, right? So actually it was relationships that were at the heart of any influential success I had there. One of the things that I really wanted to do was work on the performance of Fortnite. So if you think about Fortnite, it's a high skill game. People play it like 2,000 hours a year. It's like a full time job. People are just crushing on that game. And the reason is because as you put in that many hours, you get that much more out of it. There are people competing at that level and there are techniques to learn. The problem is if you have a really high latency, if your frame rate is really bad, your skill cap kind of ends. And so what I was noticing in the data was that people who have really bad performance because they're on a bad machine or have bad internet, tend to churn after like 1 to 2,000 hours versus people who have really good performance, they'll stay for 12s, 14,000 hours. There are people today still playing Fortnite, right? And that game came out a really long time ago. This is my crucial insight, but I couldn't just lead with that insight like I would at like a Google or something. And like, thus, we would prioritize performance. Instead, what I had to do was be really influential with key designers and engineers. And so what I had to realize was that there was this fellow named Jason. He had created Call of Duty and now he was leading Fortnite. He ultimately made all the decisions about what actually happened on Fortnite. And he really respected the opinion of the hardest working engineers and designers. The ones who work like 120 hours. They were just like shipping everything. And in gaming, unfortunately, that's the reality. There are just people like pulling investment banking hours. He really respected all those folks, rightfully so. So I decided these are the people I need to build into my coalition. So what I would do is like all these people, because they were working so hard, had no time to see how all the things they were doing were performing. So that was my little in. Like I said, future results, right up. That's your in, right? So I just started to show them like you guys shipped Fortnite Chapter 2 Season 4 Patch 6.4 Okay, like this is the grind, right, that they're in. Nobody's telling them how Patch 6.4 performed, let alone if Season 2 Chapter 4 performed. So, I'm coming in there with like, Patch 6.4 did this, this, and this to the game. Snipers are up by 8%. Kills are down by 6%. Low elo players are beating high elo players at rates never seen before in the game. They're getting hyped up by their hard work. They started to actually care about what I had to say. I just sprinkle in some performance fairy dust on top of all this. Players who have latency of higher than 200 milliseconds are churning at rates higher than ever before. These little things like adding in rifles and ballers and cars into the game meant that people with ping of over 100 millisecond are losing their elo at unprecedented rates. These types of insights then help them just casually start to work performance into the game. They started to realize how much performance was affecting the game, and we chipped away a ton at performance. So that's an example of how I'm thinking very strategically about who my coalition should and can be, that I'm like building backwards to build the relationship and influence that.

Hannah Clark:

It's smart on so many levels. You're building those great relationships. People trust you. You become influential almost passively. Brilliant. Before we wrap up, I do want to touch on some of the common mistakes that you've noticed that PMs make in feature factory environments. Obviously, one of them is not recognizing that you're doomed to be in a feature factory. But what are some of the other ones that we could go over for folks listening?

Aakash Gupta:

There's maybe like six that I want to mention. The first is that they're chasing only output metrics. Basically, they heard my advice, surrendered to the factory. The factory cares about Jira story point velocity. The factory cares about number of big features I release on time. The factory cares about how few times I push a due date on a feature, how few times I push the date. That's all I optimize for. I think that's still a mistake. I think that you still have to look at the outcomes of all of your features. So I don't want it to be that surrender to the factory. Now I'm not doing good PM work. Yes, the factory might tell you to build this really horrible, non impactful feature, but I want to make sure that you do have that product sense before you build it too. And that's going to do two things. One, on the edges, you're going to make the right decisions about resource allocation where you can. And two, you're going to be building that muscle of good product work. I find that a lot of people, they might enter a feature factory and their skills plait up. I'm like, Hey, Ben, he went to that feature factory over at J. P. Morgan for four years, and I feel like he's a worse PM than when I knew him at Google. Stories like that have actually happened, so I think that it's about keeping your skill progression high, still understanding what the metrics impact and user impact of everything you ship is. I think the second mistake that feature factory PMs make is that because they've embraced the rush for big features, their CEO's on high. It's like, CEO's like giving you all the big features that he loves. You're on high about that. You're just shipping, shipping, shipping. People tend to neglect technical debt at some point. It keeps coming up. Like the developer experience, they start to say the build time is three hours. It's taking me a day just to make a simple change, but you just keep saying, we have this important Fortnite Season 16 coming up, and we need to ship that, so we just have to ignore it. And I think that that's very common. I've seen that in most feature factory PMs, in fact. So, the way I like to think about it is, what is your accidental and what's your intentional tech debt? Your accidental is like your tech debt that is brought from your user experience and I want to minimize that. And I do want to save some time to like address that. And then there's your intentional tech debt, which is like, you're just running after the big feature. We made these compromises as long as you're making those. And then you occasionally, if you invest in that feature, it goes from 0 to 1 to 100 feature that you go back and correct those, it's okay. I think that mistake three is ignoring user feedback. So I like casually said like, just even showing your wireframe and changing it. Some people like that is a big step up. And I don't think that should really be a big step up for any product manager. Like it's always like, when I asked someone like, You shipped this big feature, how many users did you show, like, the final designs to? And it's like, I would say for the product managers listening, like 50% of them are like, yeah, my last big feature, we didn't show it to any users. We just had to rush to ship it out for whatever reason. And I think that's a huge mistake. So even if you're stuck in the feature factory, it's your career on the line, whatever your team ships. And I don't want anybody to get that twisted. Fundamentally as a PM, what your team ships, that's your resume for whether you get fired or get promoted. So, make sure that that's the best version of that bad idea it could be. Mistake four is letting FOMO drive the roadmap. So this is like the classic reason, actually, that we have the feature factory. HubSpot released a CRM, so we need to have a CRM. Typefully has LinkedIn posting, so our Twitter tool, Tweet Hunter, needs LinkedIn posting. We feel this sense of fear missing out, that they're stealing some of our customers. Maybe we had our biggest customer churn. And all of a sudden, why don't we just build everything that would have saved that biggest customer? I think that that's like a huge mistake. And what I would do is try to show to your executives the scope of what a feature is. That's what I mentioned about impact sizing. After you have feature results write ups, it's about impact sizing, where you might say, what is the addressable population? You want to build a whole new product in our suite. Our last new product is used by 0.2% of users. Do you really think that we need to invest in another product that 0.2% of our users are going to use, right? Anytime you see FOMO in whoever's directing your feature factory, that's a good sort of red flag. This is where I need to maybe deviate from the feature factory. I think mistake five is burning out your team. And I think this is super common even in empowered PM environments or just trying to push hard. But even though shipping fast is important, I think that a team that is really well motivated, really healthy, they tend to produce the best results. You might be able to get by with like a 10% growth with a burnt out team, but if you want that 50% growth change, you want to have your team operating at their best. And so as a PM, what I say is like, Always advocate for better tools. Advocate for a learning and development budget. Advocate for a well-timed team offsite. This is like my favorite personal technique. I often tend to organize or advocate for these. I'll ask, my boss, like, Hey, we just shipped X big feature or X big feature is about to ship. I think it would be really cool if my product team could get together to celebrate that. Just doing those little things, I think as a PM, it goes back to like the old days when I joined product management where our conversation started. I used to, bring in brownies for the developers when they shipped a big feature. I used to just give high fives to the designers when like the design was great. Some of these little things I think really go a long way in any feature factory environment because it's not just the PM who tends to be miserable. The designer and engineers are also upset. And then mistake six is like losing sight of the bigger picture. So, essentially, we're given the what, we're given the what, we're given the what. We often forget about the why. And I talked about the why in the context of metrics, I talked about the why in the context of user problems. But also don't forget product strategy. Even though I put product strategy is like the last thing to do, I think that along the theme of mistake one of developing your skills, you want to develop this product strategy skillset. In fact, since we're nearing the end of our conversation, we touch on the fact that PM as a field has really compressed over the last three to four years. There are simply less PM jobs than there were while PM product design and product engineering continue to grow. So those are growing at the expense of product management. And if we want product managers to succeed in this environment where there's job compression, then we have to try to have product strategy impact. And so when you're in the feature factory, even though you're embracing it, even though you're going step by step through isolated practices, in every factory, there's going to be that 10 to 15 percent of the roadmap that you can influence. There's going to be that 10 to 15 percent of the sprint that the designer wants you to, an engineering manager wants you to pitch in on. You're still part of the team even though it's a factory and we've now surrendered to what they care about. Let's make sure that those features we ship are so crazy strategic. So one of the best feature factory PMs, he's still working at Epic Games right now, and I know when it's just still working at a firm, both of these PMs that I know, every feature they ship changes the trajectory of the company. And they don't actually ship their own features that often because they're stuck in this environment. But when they do, it's a game changer. So at a firm, what this guy shipped is essentially ML to organize loans you should repay. So it's like this really deep backend ML application, but it made like a 15 percent improvement in repayment rates, which is like giving a firm an industry leading advantage and you've seen a stock price is like three, 400%. So he's making like these huge impacts. And so I think that that's what people should really be motivated by. I'm stuck in the feature factory. I've just listened to Aakash and Hannah for 45 minutes on the feature factory. Try to have these like genius feature ideas that you are coming up with on your own and slot them in where you can.

Hannah Clark:

That's a mic drop moment right there. Aakash, thank you so much for making the time to chat with us. So for the five people listening who do not follow you yet, where can they follow you online?

Aakash Gupta:

Ideally the newsletter. I'm on Substack. I know that some people don't like that pop up for your email address. You can just hit ignore and continue reading if you'd like. These days, like my average piece, I talk to like 10 plus people. My last piece, I had a guest collaborator. So each of us talked to 10 people and we interviewed people. We actually got real insight. So it's not like the type of product content, like maybe you see me on LinkedIn or X and you think, yeah, he's got some like regular product content, like everybody else. But no, these are like research studies from actual people. So for the product leadership job search, we talked to product leaders who had actually recently gotten VP or director jobs. We talked to recruiters are actually placing in the industry. So what I'm trying to do is bring real data or real insights. So if people are interested in that, that's what I'm basically working on and where you can find me.

Hannah Clark:

Fantastic. We'll see you there. And thank you so much for coming here.

Aakash Gupta:

All right, appreciate it.

Hannah Clark:

Thanks for listening in. For more great insights, how-to guides, and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The Product Manager, wherever you get your podcasts.