Do All Roads Lead to the Feature Factory?

Read The Transcript:

We're trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn't correct 100% of the time.

Hannah Clark: Feature factory—noun; a company that consistently releases products, features, and enhancements, but predominantly focuses on quantity over quality. Origin, John Cutler. Used in a sentence, "We've shipped three new features this quarter, and I don't know who any of them are for. This is starting to feel like a feature factory." If that definition hit a little too close to home, keep listening. 

In our recent panel event, "Do All Roads Lead to the Feature Factory?", we brought together three product leaders who have observed this phenomenon from different angles. Aakash Gupta—who served as VP of Product at a unicorn and is currently the author of 'The Product Growth Newsletter', Andrea Saez—product marketing leader and author of 'The Product Momentum Gap', and Paweł Huryn—author of 'The Product Compass Newsletter'. 

They share the uncomfortable truth about recognizing output over outcome thinking, practical frameworks for maintaining strategic focus and mid-market pressures, and actionable frameworks to transform your team from feature builders to outcome drivers.

Whether you're trying to scale past a hundred million ARR or just reclaim your team's innovative spirit, consider this conversation your punch card out of the feature factory mindset. Let's jump in. 

Oh, by the way, we hold conversations like this every week, so if this sounds interesting to you, why not subscribe? Okay, now let's jump in. 

So we're gonna get started with our discussion now, just looking at some preliminary poll numbers. It looks like we've got a pretty even split between people who consider their organizations to be feature factories and ones that are not quite clear on that. So we'll get into that actually with defining the term.

I think that'll be helpful for everybody just to get on the same page of what we mean when we say a feature factory. So the definition we were using is, I believe, pull from John Cutler originally coined the term. So a feature factory is a company that consistently releases products, features, enhancements, et cetera, and predominantly focuses on quantity over quality.

So they focus on output rather than outcomes. And what we're hinting at there is that we're in a situation where we see that we're shipping a ton of features, but it isn't always clear whether the features have a real strong business value or whether they really strongly resonate with our users.

Obviously there's, it can get tied up in some issues. We'll be covering this in three sections. Section one will be why a feature factory is so prevalent. We'll then move on to section two, which is the roads that lead out of the feature factory. And section three, which is, we're in factory mode, now what? 

And we're gonna get started with section one. The first question here, I'm gonna pass it off to Andrea first. How do well-meaning organizations become feature factories? Like, how does this develop? 

Andrea Saez: To be honest, there isn't a single path. People ask me a lot, how do I prevent it? How do I prevent it? There's a multiple of paths that can take you down that way.

Everything from, just trying to close sales, you maybe don't have a good product leader or head of product, or VP of product, whatever it is. Could be a hippo thing, could be a shiny object syndrome. There's a lot of different ways to get there, but I think the underlying, let's say, foundational problem would be a lack of influence from a product leader to be able to really set a strategy and say, this is what we're doing, this is why we're doing it.

And also just be able to run negotiations as to when you do have to ship a feature for certain reasons, but be able to then bring the team back towards the strategy. I think the reality is, as much as I would love to stand here and say we're never gonna do that, we can, I can absolutely avoid a feature factory.

There are moments in everybody's career, in every company journey where you might have to make those concessions and go, fine. We'll have to build that feature because we do have to get that, revenue in, we need the money. So it's not, I think something that is just a black and white situation.

There are negotiations and concessions that have to be made, but the important thing is to have a product leader in place that will be able to say, okay, we did that. Now let's bring us back to our strategy, to what we're really trying to do and to solve. 

Hannah Clark: Aakash, did you have anything that you wanted to add? I know that you've got like a, you shared a perspective with me before that sort of inspired this conversation, which is, it seems like all roads do lead to the feature factory. What's been your experience in the field? 

Aakash Gupta: Yeah, I think that we tend to say, okay, there are these awesome companies out there. They're in Silicon Valley, Google, Netflix, Meta, and they just do product the right way. And if you just do product like them, all your problems will be solved. You'll hit your metrics, your business will succeed and you'll grow in your career. And then people follow this advice and they quickly realize that.

There seem to be some gaps here. And the number one gap that I've seen is that when I go and talk to PMs who work at these companies and I say, oh, okay, what's the biggest feature you shipped last quarter? They'll say, oh yeah, it was X and Y. And I'll say, oh, what was the etymology of that feature?

Like, how did that feature get developed? Who came up with that feature? Invariably at these big tech companies, all the impactful features were decided by the executive team. They were heavily debated for six months before. There was no classical PM discovery where the PM was talking to users in a continuous discovery process every two weeks, and they came up with this brilliant solution that no executive at Google or Meta had ever thought about, and they changed the trajectory of the company.

That just never happens, and so I think that there is this sort of over glamorization of what actually happens at these companies and in fact app places, I would specifically call it like Apple for instance, or even Snapchat. Snapchat CEO, Evan Spiegel was recently on a bunch of podcasts. There's a couple designers and the CEO who are dictating like everything.

It's like a pure feature factory. And so people I think probably over glamorize this and in fact many roads do lead to a feature factory-like environment. If not for all the time, like Andrea was emphasizing some of the times, some of the time there might be a sales demand, there might be a customer success demand, there might be something.

So we all need to learn how we can handle ourselves when we're in that feature factory situation. 

Andrea Saez: Can I be slightly controversial since I was asked to be controversial before this call? I do a hundred percent agree with everything that Aakash has said, but one thing that I feel is really important to understand is that those companies that Aakash has called out very fairly have the budget to be able to do those things.

They can release to learn or release, just to see what happens because they can reabsorb that risk back in. Most companies do not have the budget for that. So when they try to operate like Google or Apple or whatever and just go, just ship it. Just ship it, right? There's this what was it? Facebook saying Move fast and break things.

Worst thing that you can do because you're not Facebook let's be super real about that. Most people don't work at a fang, and if they do, then they're in that situation that Aakash is describing, but they can afford to do those things. I can't afford to do those things, so I have to just play a little bit smarter.

Hannah Clark: Okay. So I think that we have a view now of how these things can develop, who can get away with it, who can't. 

If we're thinking about it on, a spectrum of good to bad, is being a feature factory inherently a bad thing, or can it sometimes work depending on the business model? Would you say that there's a realistic, viable alternative?

Paweł Huryn: Yeah, I do not fully agree with the framing that we need to make some concessions always when we choose to talk to stakeholders about features or just to implement features or review feature requests from the users because first some problems are not brainer. So if we get a picture from the stakeholders and for example, we need a Stripe integration.

Then we need a Stripe integration. We can, of course, we can try to pretend and reverse engineering it into the finance problem, but in some cases, this discovering the problem space, exploring the problem space isn't that necessarily. And in other cases, stakeholders might have insights like executives or sales or customer success that product manager talking to the users might miss.

So I also don't like discarding those insights completely. I have seen many product managers who just came to the new organization and start talking to users. There was no existing knowledge in organization, but many stakeholders spent hundreds of hours with the customers every month. So discarding what they know is for me is a waste.

And also, at the end of the day, businesses need to make money. So for some companies doing, for example, if they work in the customer supplier model, doing what customers ask for, even if product managers or product teams are not happy, this is a viable way to make money. So in that case, we can just leave the company rather than trying to change it because this is their business model.

Hannah Clark: Yeah, and it's a fair point. That's the other side of the coin is if it works, if it's keeping the business afloat. So sometimes that's just how the cookie crumbles. 

We'll throw it back to Andrea right away. We're gonna move into section two, which is the roads that lead out of the feature factory. So it's abandoned sort of the moral question or kind of the, is it good or bad question and just talk about evaluating whether an organization would be considered a feature factory. So how do we know if our org is over investing in short term and under investing in long-term value? Where's that balance? 

Andrea Saez: I think that the first science to that just comes down to are you receiving a ton of negative feedback? Are you seeing high churn? Are sales cycles taking longer? Those are indicators that you're probably slipping on your product market fit a little bit. And that is usually the moment when those decisions of, oh, let's just ship this thing.

Let's just build this thing, start happening in an attempt to try and save certain accounts or try to close certain deals. And that's when things start spinning outta control. And then you start. Seeing, I'm not even gonna name certain tools, Jira. Yeah. You know this, you have all these features like do they connect?

Does it make sense? Is it for your audience? Does the UX make sense for the love of God, Jira? What are we doing? Can people easily navigate through UI, et cetera. But generally it's when you start seeing that kinda product market fit, start to divulge a little bit, and it's not as strong as perhaps it used to be before.

Hannah Clark: Let's talk a little bit about early intervention. So if we're starting to stray a little bit, what kinds of checks and balances could we implement just to frame the context of who I'm asking this question to. We discussed before that there is limited influence at certain levels of product management where you can't necessarily influence the direction of the company depending on the maturity of the company. 

There's a lot of factors, but assuming that you're in a position where you've got some significant influence in the company's trajectory, what kinds of early inventions or checks and balances can we implement to really remain focused on delivering value and staying true to our company's vision?

Paweł, do you wanna take this one? 

Paweł Huryn: I will start by aligning about what is the important, what is our strategy for the entire organization? Because if there are, if the teams are not aligned about how we create value, what customers do we want to solve, what problems we want to tackle. What is different about what we are building then it might be extremely difficult to deliver value by, by different teams.

So first is the strategic alignment and choices that we make so that everyone is aware of the strategic context. This is what in no rules. Yeah. Netflix calls with context not control. And then another thing would be aligning teams around the objectives so that everyone understands what is the most important thing.

In the organization or what are the most important objectives in the organization? For example, in the quarter or nah, during the year so that the teams can align the team objectives or department objectives with those key priorities for the organization. And then there is an empowerment that might require coaching because not every product team necessarily knows how to perform continuous product discovery.

But broadly speaking, we would like to by default, not in every situation because there are exceptions. But by default we would like to empower teams with meaningful problems to solve clear desired outcomes so that they can either, they can discover how to solve those problems and create value for the customers, and ultimately create value for the business.

That would be it. So starting from strategy and and in with empowering teams so that they can start this discovery process. 

Hannah Clark: Yeah, something that kind of feels relevant to add to that. I recently had a conversation with Cem Kansu from Duolingo, who's the CPO of Duolingo, and we talked a little bit about some of the ways that Duolingo thinks about vision and values and that kind of thing.

And they, at their company, they have some sacred cows that they've as a company, agreed that we don't touch this or we, we don't make any changes to this specific area of our business 'cause it's just core to who we are. And that becomes like a compass for how they make some of the decisions and what decisions they say no to.

So I thought that was an interesting way to approach that as well. 

Paweł Huryn: So try those are extremely essential. So not just things that we would like to focus on, but also things really stated. Things that we don't do, customers we don't serve for. Yeah. Issues that, strategies that we don't implement so that everyone can avoid it.

Hannah Clark: Before I move on to section three, did we have anything else from panelists that wanted to add checks and balances or early interventions to ensure that we're staying away from feature factory mode? 

Aakash Gupta: I think feature factory is a pejorative, right? You don't want to be in the feature factory, but if we break down what are the elements of the feature factory that are gonna be most destructive. 

The number one thing that you can do in a business is not actually focus on the right part of the business. So getting your executive team to focus on the parts, the metrics, the user problems that actually matter. That is I think always the area that has the highest leverage. And so it's about bringing in insights.

That establish your credibility along the way. And I typically think about two types of insights that I want to be bringing to like almost any of these conversations that I have with executives. I wanna have some user insights, hopefully substantiated by, session replays, user analytics, data conversations, or ideally call recordings that I have of conversations with customers.

Then actual data insights, like usually around a growth model or a size of opportunity. For example, did you know that 16% of our customers haven't done Y? If we get just 50% of those customers to do that, it could lead to x million dollars in revenue, right? If you come with a sort of these two types of insights to executives, you're gonna start being able to sculpt, focusing on the right metrics and the right problems.

That's the first point. That's what Paweł was saying with strategy. And then the second point is you want to allow your teams on the ground, your designers and PMs, as they're actually prototyping, as they're actually putting mocks in front of users to iterate and change direction from what the executives had in mind.

And so to do that, I find that implementing checkpoints. Product review meetings where executives still feel like they have a say along the way. What you don't want is the executives hand you a design at planning. Three months later, you send them the future results, write up that it didn't work, and they say, you didn't implement my design.

That's why it didn't work. I. In those three months, you wanna bring them along with several product reviews. Your design was put in front of users, we improved your design for X and y reasons. That's what we actually launched. And so those to me, are the two really important leverage points to add on some tactics to the high level strategy that Paweł gave.

Hannah Clark: That's really valuable insight. Before we move on, does anyone wanna respond to that? 

Andrea Saez: I don't think I would say anything different. I completely agree. I'm not gonna be controversial on this one. I think both Aakash and Paweł are a hundred percent right on that. The only thing I would add is, as you're gaining alignment, make sure that there is alignment, right?

That's one of the things where I see a lot of team fails is they'll say yes, and then a week later everybody's running around trying to do their own thing. So absolutely executive alignment. It has to start from the top. Everybody needs to be aligned around what you're doing, why you're doing, how you're doing it, who you're doing it for, and the who tends to be the biggest source of misalignment because everybody's trying to, there's no lying around the ICP, so everyone's trying to sell to someone different.

And when you're trying to sell to different audiences, that's when you start sneaking in features that perhaps don't fit. 

Hannah Clark: In regard to question number two, as in shortsighted feature development, is it also true that sometimes companies release features that are disconnected from the path to vision realization with a full intention to circle back and refine the features?

However, once a company that gets into the feature factory spiral, it's then tough to get outta that cycle and then it just never manages to return to suboptimal features that were originally intended to be improved, like a, feature debt. Does anyone have anything they wanted to respond? 

Paweł Huryn: I assume that this is about releasing features that are not ideal or far from perfect, at least in my experience, this is exactly what we should do.

So release features without implementing every possible detail, every corner use case, but rather do something that solves the problem for maybe 70, maybe 80% of the users for the most common use cases and just get feedback. Of course, sometimes it might not be possible, but in most cases, in most of the product organizations I worked in.

We started simple. Even if there was some design or idea, what we would like to achieve in four or five months, we quickly got feedback from the users. And also often after getting this feedback, we improved our initial assumptions because even if you test your designs, you run those usability tests and you interview customers, you automate those tests.

And for example, I did it with Mac. The actual results from production when customers start using the real data might be different. So I'm 100% for releasing features that are not ideal. 

Hannah Clark: I wanna toss it to Andrea a little bit because, so how does that fit into the strategy? 'cause you mentioned, in your organization you don't necessarily have the budget to release features at that rate, and you have to be more strategic about what you do. So do you have a different approach or how do you see that? 

Andrea Saez: No, I agree with what Paweł said. You should be releasing with intention, right? Not everything needs to be perfect, I think, I don't wanna make assumptions, but Todd said half-baked and I think that is something I have seen before where we release something and say, okay, we'll get back to improving this later. And then you just move on to more new stuff. But the teams don't go back to make improvements. And I see Aakash nodding a lot, so maybe you have a bit to add there. But that is a little bit of that feature trap where it's let's just release new.

And then we don't go back and make improvements to what sometimes feels like very basic stuff, like some basic usability stuff. Where we assume that people will just get it because it's there, so go figure it out type thing. 

Aakash Gupta: Yeah, I think that all our commenters are right I think Brent, Todd, both are pointing to this phenomena that happens, which is why the feature factory is so bad, is we have this shiny object syndrome release, half-baked features.

We never fix the features afterwards or update them even though we know a bunch of things because we're just moving on to the next shiny object. That's one of the things you wanna avoid, right? And so when people are then asking, I think Agua asks like, how do you move out of this? So when people have that syndrome it's about bring those user insight that, hey, user insight.

We looked at a hundred session replays last week. Three people clicked on this feature data insight, like of people who you click on this feature, the 30 day retention is 7%. It's like nobody's adopting this feature and nobody's retaining with this feature. You try to bring those insights to the executives and the feature factory leaders, the hippos driving the feature factory, and because you're speaking their language now and you've brought these insights, hopefully they will allow you to either iterate so it's not half baked.

Oftentimes if we're talking about a 7% adoption, like actually get people to see the thing and try it out. But there also seem to be a retention problem, so fix whatever retention issues there are. So that's one option or the second. And often what people really need to do is just kill features, right?

There's way too many features out there that are actually getting in the way of the core job to be done of your user. And this is particularly pernicious in B2B where we all try to become platform companies. We all try to extend beyond one product. As soon as we hit 10 million ARR, we think we need a second product.

But in fact, like just focusing on that core often is so much more high impact for you. 

Andrea Saez: I think it was Pendo that did a study that said 80% of features don't get used. There's a huge number. 

Hannah Clark: That's wild. 

I think a fitting segue into our final section here, which is, so we are in factory mode, now what? I imagine that a lot of folks decided to tune in today because they're either already working in what they would consider to be a feature factory, or they're concerned that you're increasingly going off of the deep end.

So let's assume that changing that model, at least in the short term, is impossible or it's a very goal just because of the way that things are currently working in the entrenched infrastructure of the company. Are there any kind of steps that we can take from a leadership perspective to get back away from the future factory mindset and become more value focused. 

Aakash Gupta: If you're the leader, then it's actually incumbent upon you, right? So if you're the VP of product, you're the chief product officer, you're whatever title that it is, if you're that top person, right? Fundamentally, if you're doing your job well, you're always calling out all of the deficiencies in your organization, all of the problems that you guys need to fix.

That's actually the job. It's not to like toot like, we are so amazing. We launch all these amazing things. It's like you're there to solve problems for the company, so you should be trying to call out. These are the big problems, and the feature factory is actually one of those ones that people are pretty responsive.

You know what you do is you say, okay, hey guys. What was your strategy last year? What were all of the features that we committed to building and how did those perform? How many of them succeeded? And you take a look at that and you say, okay, 75% of them didn't succeed. Is that what we want to do this year?

If not right, how are we gonna break chip away at that? How are we gonna break that down? And so again, you're speaking their language. You're not saying, Hey, Marty Kagan says I need to empower my PMs. And that's what's broken about our product management process. Marty is right about that. But you're speaking the language of the stakeholders.

So you're taking what you learned from Marty and you're bringing it to the stakeholders. And so that to me is the job of a great VP of product. And I think Andrew said it in her very first response. It's like what's led to this feature factory is the lack of a great VP of product or a great chief product officer.

I would also say though, sometimes founders especially, but some CEOs, they're just hard to work with and you can have the best VP of product ever and the founder CEO is just gonna force things down anyways. And if you're in that scenario, you need to think about playing chess with your career and going somewhere else.

Andrea Saez: I was actually gonna say exactly that. You can be the best CPO, the best VP of product, you can do or try to do all the right things, if you don't have the support of your CEO and the rest of the C level, you are not gonna get anywhere. It's just, it's not gonna happen. There has to be alignment, like I said, at that C level because once there's real alignment there, then everything's a lot easier. 

And I have worked with CPOs where they had absolutely no influence and it was really sales that was driving development, not the CPO. The other thing I would add to that is having alignment and understanding around measurable user behaviors, and that's obviously part of my book.

But a lot of features that are built don't focus on repeatable, scalable behaviors. So things that people are gonna come in and do every single day because they're indispensable to the user. Sometimes features are just put out to ship, right? But are they really thinking about the value to the customer?

Is it actually gonna help them solve a problem? Or are we putting out a feature that's making their lives harder? And maybe there's like a whole ethics chat there as well of, how does it impact the life and the behavior and the workflows of the user. 

Paweł Huryn: I agree with everything what has been said so far.

I cannot add also from the perspective of a product manager, product team that don't have this influence in the organization. It's also often possible to move things in the right direction. Obviously you won't to change the entire organization, how the organization works. But for example, in the past I was able, I work at bc, which is a resource center for more than 30 banks from Denmark.

My initiative was the only initiative that escaped safe, so scale agile framework, which is, for me, it's like a waterfall with this long term planning. So how we did that was we analyzed the previous initiatives. We tried to highlight the problems. So like in the case of CPO, just from the product manager perspective, show the problems and measure the problems with the current approach and that if we are going to continue, one of the most complex initiatives will probably fail like all the previous ones.

And we suggested an experiments so that our initiative, so that was one core team and four other that collaborated with us, just started working in an agile way without this heavy framework. So the same arguments and it worked. Obviously we didn't change the entire organization, but for my initiative it worked pretty well.

Hannah Clark: Yeah, I really appreciate you chiming in with the perspective of folks who have a little bit less influence, 'cause I'm sure that there are folks who are finding themselves in that position where they're not necessarily a VP of product, but, you still wanna try and make your work as impactful as possible.

Paweł Huryn: Can also influence a lot of things that are inside your team. So just don't ask about permission and start collaborating with your designers. Inviting your engineers to brainstorm about solutions and rather than preparing everything kind upfront, talking to the customers alone. 

Andrea Saez: One thing that I'd like to add, if possible, that Paweł I think has brought up is how much hard work that entails.

And I was amazed when you said that, what you were just talking. I was like, how did he do that? Because it is a lot of hard work and I, most of the time in my career have a life war with Aakash, where it's I'm not gonna bother with this time to find a new job type thing. But it is really difficult to do a transformation like that.

So power to anyone that can do that or is going through that because it is draining to your wellbeing, to your mental health, to your everyday. But I think you once, or if you're able to get out of that on the other side, there's a lot of learning as well. 

Hannah Clark: Yeah, that's definitely an incredible trajectory to be able to bring into whatever experience you have next, whether you stay at the company or not. 

If you wanna follow our speakers also today, each one of these folks are amazing thought leaders. We've got a lot of great content from each of them. Andrea's book, the Product Momentum Gap is available on Amazon. You can look it up there. Aakash's newsletter, the Product Growth Newsletter. So make sure you subscribe to that. It's a fantastic resource.

And Paweł's newsletter is called Product Compass. Aakash and Paweł have collaborated on some podcasts, but I know Aakash is really active on his podcast as well. Please make sure you subscribe to our panelists stuff 'cause they're putting out great stuff all the time, not just today. 

And I guess we can move right along into our Q&A. We've got some great questions from our audience today. The first one here is from Aqueda. I hope I pronounced that correctly. 

So how do we get from feature factory to continuous user and customer value creation that creates positive business impact? I feel we've touched on this a little bit, but maybe there's some stuff to add.

She says seems like the customer value piece of the equation has been obfuscated by a quick profit result. Andrea, if you wanna give maybe Cliffs notes of what you cover in the book, that might be helpful. 

Andrea Saez: Literally that. So it is about bringing together product strategy and customer value. So we talk a lot about customer value, how to identify it, how to track it, how to focus on it, how to bring your team together, and I think that's a really key part.

So we have a little template called the product VCP or the product Value creation plan. The key part that's really important, something that Paweł touched on earlier is that it's really not about the product team making those decisions in isolation. It's about listening to sales. It's about listening to customer success.

It's about listening to support and bringing all those key stakeholders into this workshop and collaborating with them and understanding then what value means in order to then deliver it. 

Hannah Clark: Actually, if you want a taste of that, we discussed exactly that on the podcast about a year ago. So the podcast episode on the Product Manager podcast was how product leaders are unintentionally hindering business growth.

Okay, so next question from Parker. So what tools slash methods do you use to foster strategic discussions and alignment around a common product goal? What has been most effective for you? This is interesting, so a little bit more tactical here. Does anyone wanna jump in on this one? 

Aakash Gupta: If we're trying to create alignment on a particular goal, the first thing to do is not to just suggest this is what the right answer is. Here you go. Let's go for it. Ideally, you want to set up this context with the people who're not haven't brought along and say, Hey, I think we may not have the right goal at this point. Can we go through a process together where we try to figure out the right goal?

Then you wanna set up this process in a very collaborative way. What I like to do is actually like work with an analyst or somebody who's super well respected by both parties, some external third party and say, Hey, can we get some sort of like research report or something going and you present that to us and then we can talk back and ask questions to you so that you're learning with the people who you disagree with.

You're learning about the metrics and the options, then you have some sort of a brainstorm, a setup, brainstorm. Often do it over like Miro, remotely. It doesn't need to be in person. Like these are the optional metrics and goals that we could be focused on. What are the pros and cons of these options?

Let's talk about these together, and then as the PM using the power of the pen to record now. Okay. These are the options. These are the pros and cons. Again, going back to your third party person now and working with them, who's saying okay, the data science team has gone and looked at this. We have gone and looked at this.

We've involved some of the PMs, designers and engineers who have been building on this for the last six months as well, to get their feedback on what metrics are easy to move versus not. And then you have a final discussion where it's like. Again, you're not coming in with the right answer. You're willing to even hear out what the other person says, but you guys make a decision in that meeting.

So that's how I like to structure it very tactically for folks, is a sequence of things, and it takes longer this way, but hopefully you have more buy-in. 

Hannah Clark: I always leave it to you to give like a very clear, specific process, so I appreciate that. 

We'll move on to Mikayla. We have a revamp request for a product by the business and from the UX team. We wanna properly understand the pain points, gain insights, and understand the journeys. So far, it's been a feature factory and it's disconnected because we use many systems to stitch together the UI, but the PM is pushing to do something quick because we already know things, quote unquote, but there's not clear direction. What do you think is a good way to get out of it? 

Okay, so this is a very specific situation, so let's just note the facts here. So we have all these insights, but they seem to be disconnected from the features that you're actually developing. And the PM is just looking to just do speed over quality.

It sounds like, Mikayla, you'll have to correct me if I'm getting any of the details of this incorrect. So it sounds like we've got a number of different issues. Insights are disconnected from what's actually being built and PM is, doesn't seem to be making that connection. 

Paweł Huryn: In this case, in this situation, it's product manager who is pushing features without proper validation.

So that might be difficult, but overall, if someone is pushing features, I would try to reverse engineer and ask about the problem this feature is solving, and then explore, validate the problem and maybe the rather solutions. I would also like to understand if this problem is aligned with the broader objectives that are currently important for the organization and strategy and company vision.

Perhaps someone from the team other than product manager can try to reverse engineer or at least maybe, if not everything, then find some inconsistencies between data, between what analytics, what data analytics funnels cohort analysis presents and the features that we are building. There must be some set of assumptions behind those features that I would like to validate those assumptions.

Andrea Saez: I agree with Paweł. There's two magic questions. What problem are we trying to solve and why? And also who we're solving it for. 'cause don't forget about the who, but yeah I've been in a situation like that recently and the product team just wanted to ship because they knew what they were doing and I just went in and said, Hey, I don't wanna disrupt.

But I'm just wondering if you can explain the problem to me and the decision making process so that I understand it. Because as a product marketer, I need to sell this and I need to understand the value, and I need to understand the decision making process and just getting them to work through that logic.

It's this little product problem outline where you can just ask what problem are you trying to solve? Why for whom? What's the business impact? What's the customer value we're delivering? And talk through that logic and that can help steer the boat with a little bit of influence and really get the team to think about like why are they doing things at the end of the day?

Hannah Clark: Yeah, taking them to task or, I think that's a great suggestion. We have some more questions coming in, so in the name of time we'll move in, but I think that was a great chat. Thank you for asking Mikayla. 

Okay. Brent has our next question here. In an ideal situation, should a company or product become less of a feature factory as it matures potentially, can this trend be a signal of misapplication of product teams?

Andrea Saez: Who's got thoughts? Hannah, I wanna hear yours. 

Hannah Clark: I'm an outsider here really, but it seems to me that a company should become, they should be the least of feature factory at the beginning. When you really have a specific goal that you're trying to achieve and a specific user problem that you're trying to solve.

Kind of seems to me that you become a, like the feature factory creeps in as you make concessions in order to keep your business alive. And so it seems to me it is something that a scaling business is gonna run into a lot more. But full disclosure, like I have not been in the position to have to deal with these concerns.

I don't know. Fact, check me. 

Aakash Gupta: I think they're probably like roughly equivalent percentages at all life stages. Sometimes when you're really early on, you feel like, okay, all we need to do is just like copy this other product. Just like fully copy it. Know? Like, so everything is clear. Like it's just a future factor.

Like you guys, you're just gonna go build gong's, call recorder now. Just go build that now. Don't you have the exact roadmap right there? Can't you just see it? So I think that future factory, they can, it can hit in anywhere. Really though, what you want to think about, regardless of what environment you are in, is what are the parts of the feature factory that are hurting me.

And from that, it's really am I not able to deliver an ROI on my salary? If I'm being paid $150,000, like an average pm, am I generating $150,000 a profit for the company? Because if I'm not, then the future factor is really becoming a problem for me, and I need to start to fix those areas one by one.

And so in terms of the sociology of what percentage there are, I personally think that they're probably everywhere. You'll see really good companies that are huge, like Enterprise, like I think Meta is an example that a lot of people hold up where Hey, PMs, they're actually empowered to do stuff. But then there's also series C companies.

There's series A companies. I think even what I was hearing is the recent OpenAI launch of image generation. Like it wasn't like a Sam said we need to ship a much better image generation today. It was like. The researchers and engineers working at OpenAI uncovered these new things and they brought them up.

So there's even open eye stage $300 billion companies that are doing great. So at every stage you'll find a similar proportion, which is like more than 50% feature factory. 

Hannah Clark: So I'll move on to Sahi. What are some of the value added benefits that a product manager coming from a business and technical hybrid background brings to the table versus a purely technical background product manager when it comes to features and design?

Andrea Saez: I do think that there is a link in that. I could be a hundred percent wrong in this, but in my very biased experience, purely technical PMs tend to lack business focus, and at the end of the day, we're all building stuff to self. I'm not suggesting everyone should be a hundred percent ROI focused, but just having that sense of we are building something that needs to be sold and how do our decisions impact the business and our ROI and all of that.

PMs with a business background will understand that from the beginning and their decisions will be targeted that way, whereas sometimes technical cams are just like focused on the technical side of things, but not necessarily worried about. That return on investment or what that looks like. A really great example of this is I've been in situations where we're talking about building a particular feature or I'm jumping in at a point where this has already been done and I'm jumping in at the end and my first question will be, have we thought about how we sell this?

And everyone's whoa, nope. I'm like that should have been the first question. How are we selling it? Who are we selling it to? If you're a B2B and you have everything from like an individual to an enterprise package, is the feature that you're building set up to take the customer through that journey?

Because an enterprise customer is not gonna have the same problem as an individual in a pre-seed startup wanting to use your product, and not a lot of people might go through. That thought process. If they don't have that business background, that could be biased. I could be wrong. So feel free to correct me on that.

Hannah Clark: Does anyone feel the need the right? 

Aakash Gupta: Yeah I think he's just trying to ask, like he probably has a technical business background and he is comparing himself to people with a purely technical background and wondering like what advantage can he bring? He spent a lot of time talking about impact, right?

In today's conversation, the impact of your work. And so I think if you have a business background, try to think about leading on those types of PM skills. Build the growth model for your team, impact size all your features, write really great feature results, write-ups. So always try to play to your strengths and don't worry so much about what other people are doing.

It's up to those technical PMs to learn the business skills. To be honest, they're not that hard, so most technical PMs can learn them pretty easily and. Just focus on yourself, like how do I leverage my strengths? If I'm really strong in Excel, do more Excel stuff as a pm. That's the magic of the PM role is you can make it your own.

Andrea Saez: A hundred percent agree with that. 

Hannah Clark: Todd has said, Paweł, you mentioned earlier that you'd like to keep all insights. At what point do you turn insights into backlog items? Our backlog feels like the feature factory floor. We recommend archiving backlog items that are older than 12 months. Paweł, would you mind just responding to that question so that others can take away from it?

Paweł Huryn: So first I'm not sure I really mentioned keeping all the insights. So what I might have mentioned is leveraging insights from different sources. So not just customer interviews, but also stakeholders, market research, data analytics, surveys, and so on. So this is the first thing, and when it comes to organizing insights and product backlog items, I have always avoided placing user stories or features in the product backlog for the developers prematurely. 

So I would rather complete the discovery, share the designs, test the key assumptions, and share our findings with the organization. And only after we get enough confidence than split it into user stories and find with the team or user stories or other formative someone uses something else.

So it's like having two backlogs though. It doesn't have to be the same tool. It can be just Miro or some other visual tool to collect those insights and connect them to user needs. When it comes to a hiding, there was another question I would typically just get read are hi and height. So all the items that are sitting in the backlog for too long because it's, if the product backlog has more than let's say 8,100 elements it's not manageable.

So this, in my experience will never be tackled, and if they are important, they will be bring up again. 

Hannah Clark: Thank you for everyone for joining. And of course, a huge thank you to our panelists for volunteering their time today. So panelists, thank you so much, Aakash, Andrea, Paweł. It was really fun. Very informative session. I just want to thank everybody for participating in our event today and being such an engaged audience. We hope to see you next time. 

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.