How to succeed as a PM in a feature factory

I work in a feature factory. It sucks and I wish I could leave.

I’m really struggling. I keep thinking that I should just resign myself to basically being an order taker for executing x features from my CEO.

— Reddit PM

This is often the life of a feature factory PM. Upset and feeling unsuccessful.

Interestingly enough, it’s not just PMs who feel this way in these environments. Product leaders often do, too.

I’ve put in my reps as both a PM and product leader in feature factories. And through trial and error (lots of error), I’ve learned some key lessons about how to succeed.

This is my guide to improving your happiness, succeeding, and setting yourself up for a better job down the line.

Today’s Post

Words: 7,133 | Est. Reading Time: 33 mins

1. The Basics:

• What are the (Subtle) Signs You (Might) Work in a Feature Factory?
• What Drives Feature Factories to Exist?
• Where did the Term Come From?

2. From Sadness to Success:

• The Key Principles of Feature Factory PMing
• Tactics: How to Influence Your Roadmap
• The Art and Science of Execution

3. Advanced Techniques and Mental Game:

• Most Common Mistakes in Feature Factories
• Setting Up For Your Next Empowered Role
• Product Management and the Art of Zen At Work

1. The Basics

1.1 What are the (Subtle) Signs You (Might) Work in a Feature Factory?

Sometimes, it’s dead-clear that you’re in a feature factory. I’ve been there.

It’s when you’re:

1. Handed solutions, not problems
2. Delivery-focused, with very little discovery work
3. HiPPO’s (highest paid person’s opinion) drive the roadmap

But sometimes, you can sign up for an empowered environment. And then, 9 months later, you wake up and find yourself in a covert feature factory.

I’ve been there too:

1. PMs are held accountable for outcomes, but it’s window-dressing because outputs are dictated to them
2. The vast majority of discovery work is confirmatory, and very few HiPPO ideas are actually disregarded
3. HiPPO’s inevitably get their way, but more chaotically via product reviews and back-room conversations

It’s almost like “all routes lead to the feature factory.” Even if the three main principles aren’t violated, it can manifest in other ways:

• Culture of hand-offs: this is when sales & customer support share their requests, PM creates the roadmap and shares perfect PRDs, design creates the design, and engineering builds it. It’s modern waterfall or ‘departments as agencies’
• Constant re-organizations: this is another hidden form of control, where executives keep changing the charter in an effort to dictate what’s built
• Mismatch between planning and validation rigor: in this scenario, there appears to be planning science and principles. Problems and metrics are shared. But when it comes time to validate and discard HiPPO solutions, that never happens

Generally, the way things end up happening in these feature factories is: you have this heavy planning process, where teams share their ideas. But, in the end, it’s exec offsites, enforced through product reviews, that determines what folks really build.

Here’s your cheat sheet 1-pager to remember all that:

1.2 What Drives Feature Factories to Exist?

It’s easy to vilify the situation and blame “the execs” for a feature factory.

But having gotten closer and closer to the sources, I’ve realized a lot of different, relatable factors drive the feature factory:

1. Only PMs speak product lingo
2. Metrics aren’t hitting targets
3. Execs feel disconnected from the work that got them there

Let me explain.

Driver 1 — Only PMs speak product lingo

While PMs are well-versed in product lingo around feature factories and empowered product teams, other executives are not.

Centralized planning is just what feels natural. If you’re a head of marketing, or sales, what matter most is getting the solutions right. You don’t obsess over what problems to solve. You obsess over their solutions:

• CMOs obsess over big marketing play details, they don’t just hand them over
• CROs hop into conversations with big prospects, they don’t leave it to their team

So, when the product team is the only one using the language of problems and metrics, and no one else works that way, it sticks out like a sore thumb.

Product execs can’t really do that.

The result is: ways of working from other functions seep into product.

At an exec offsite, it plays quite badly if product has the least concrete plans. In fact, everyone prefers the most concrete plans from product — because they can do a better job at their job if they understand the future product.

This results in product leaders unwillingly falling into feature factory planning practices.

Once planning falls prey to the factory, the whole process continues in a waterfall fashion.

Driver 2 — Metrics aren’t hitting targets

Even if product leaders have gotten the team to believe in metrics and problems, instead of solutions, as they say:

Sh!t eventually hits the fan

It’s inevitable in product. Sometimes, you miss moving key metrics.

Or, as has happened to me more, another part of the business moves them. EG, Growth is focused on activation but core product or marketing tanks it.

There’s only so much “explaining” you can do as a leader.

Missing the metrics results in the CEO, and other C-level executives, getting themselves involved in the process. They want to give their own perspectives on how to move the missed metrics via product.

It’s nearly impossible to keep these people from thinking in problems instead of solutions. They’ll generally argue, “We’ve already identified the problem,” and they don’t want to empower the teams that are missing the metrics.

At that point, you begin to descend into the feature factory.

Driver 3 — Execs feel disconnected from the work that got them there

The third reason feature factories pop up is the Brian Chesky reason.

As he said in his interview with Lenny:

I started to feel disconnected from the work

These execs tend to have felt like they over-delegated.

This is especially true with founder-CEOs. Brian Chesky isn’t the only one skeptical of “empowered PMs.”

Here’s what Mark Zuckerberg had to say about delegation:

I don’t believe in delegating that much. The way a founder should work is get involved in as many things, and make as many decisions, as you can.

These types of people are in the ear of your C-suite, and drive the feature factory.

In a world where Airbnb, Brex, and Meta are seeing their CEOs get involved, other CEOs get motivated.

It’s usually not because of your VP of Product.

1.3 Where does the Term Come From?

From my vantage point, 3 people are most directly responsible for the popularity of the term, “feature factory:”

1. Marty Cagan, who talked about product management practices of the “best companies” in his book Inspired, which first published in 2008
2. John Cutler, who actually coined the term via several conference talks and articles from 2014–2016. He’s continued to write about it since
3. Melissa Perri, who published Escaping the Build Trap in 2018

All three sources are worth reading to get a better understanding of it. One of my favorites is John’s 2016 conference talk:

What’s my take on the whole thing?

2. From Sadness to Success

2.1 The Key Principles of Feature Factory PMing

I agree with Marty, John, and Melissa. They’ve got the broad strokes right on the ‘what’ and ‘why.’ Where we might differ here or there is the ‘how.’

I suggest a more incremental approach:

Summarized, the game plan sounds straightforward, but the challenge is in the execution.

Principle 1 — Give up trying to transform… Unless you’re GPM+

The first step is a mental one: accept that you’re in a feature factory, and that’s okay. And if you’re not a Group Product Manager or higher, you don’t need to change it.

Too many people read Marty Cagan in the years leading up to their PM job, and when they get into the job, immediately undertake the journey of trying to operate as an empowered PM. That’s an easy way to get low performance ratings.

And even if you’re a senior PM that’s sad about being in a feature factory, it’s worth thinking about whether the “ideal” product model is better.

The purist attitude surrounding the PM working in a product-driven org vs feature factory is tiresome… [Especially if] you’ve been beaten down in a toxic product-driven company drunk on Marty’s idealistic Kool-Aid.

— Reddit PM

Every company has problems, even those with the idealized product model.

If you’re GPM+, it’s on you to drive transformation

If you’re in the more senior product leader category, the onus is on you to consistently raise the bar of your org’s product practices.

I generally have done this incrementally, where we adopt one practice at a time. Easy ones are:

• Leaning on the scientific method to say no
• Doing more user research to discard more initial ideas for better alternatives
• Showing mastery over the metrics to get trust to own them

Eventually, you’re ready to drive more pure transformation from solutions to problems and outputs to outcomes.

The hard truths to remember about this transformation are:

1. It has to start from the top-down: you need to win buy-in from your leadership chain, including the CEO
2. Your org can be a pilot group, but it has to be a real pilot: there needs to be exec-level buy-in that if your pilot works, you’ll expand it
3. It’s worth being candid with your reports where things are: they live in a feature factory now, but things can slowly be chipped away at

The higher your level, the more responsibility is on your shoulders to drive this transformation. I wrote more about how to do that a few weeks ago.

Principle 2 — Focus on succeeding in your environment, not transforming

Instead of tilting at windmills, focus your energy on figuring out how to thrive within the system you’ve got.

Think of each PM job as its own unique snowflake. Learn the intricacies of how decisions get made, who the key influencers are, and what levers you can pull to get things done in your job.

Honestly, forget all the product content for a few weeks.

Your role is different:

• Different from your boss’, from your peer’s
• Different from your last role, and your next one

Pay close attention to your stakeholders.

• What does your design counterpart value? And the engineering one?
• What are your strengths and weaknesses as they relate to those values?

I tend to see 3 success patterns for PMs in feature factories. Figure out which one is closest to your strengths and what your stakeholders want:

1. Work products: these are PMs who have really next-level feature factory work products, like roadmaps and PRDs.
2. Velocity driven: these are feature factory PMs who embrace speed, and help their teams execute with speed.
3. The people pleaser: these are PMs who get everyone to love them as an unblocker and obedient factory manager.

Emulating one of those success patterns is generally your best bet.

Not wishing for the fancy things you read in books or other PM blogs.

Principle 3 — Own the things people who get promoted do

I recommend messaging, and then booking 1:1s, with PMs, designers, and engineers who have gotten promoted recently. Then drill in on what PMs need to do to succeed.

I like to frame these as lunch chats. This allows you to go deep on what actually drove their promotion, not the story they tell themselves.

I ask questions like:

• Do you write a deep PRD for every feature? Can you share your last PRD? Why did you make X choice?
• How did you handle the last planning process? How many of the features did you come up with? Where did each idea come from? How did you make that happen?
• What did your manager say about the conversations about your potential promotion? Did they share what factors helped most? And what was tough?

These types of factual question threads get me really into the facts of how they were promoted.

Note: Usually, you do have to dig in three-four questions deep on a topic to get the real insights. But if you do it with enough people, inevitably, you’ll find there are certain trends at your company:

• Maybe it’s documentation: you find several PMs improved documentation like JIRA tickets, PRDs, and QA test cases. That’s a great data point
• Or perhaps it’s the importance of product reviews: everyone promoted had several good product reviews with the heads of product, design, and engineering

Whatever works at your company, learn it. Then, create a path for yourself to achieve that.

Principle 4 — Bring sense to your process where you can

Life as a feature factory PM tends to be busy.

But, remember school? How much more competent were you as a senior than a freshman?

Once you get your bearings as a feature factory PM, and are succeeding without doing any transformation, then it’s time to ask: Where should the product process level up?

You want level-ups that will:

• Help you as a feature factory PM
• Be acceptable for your immediate colleagues
• And not cause planning stress for your bosses

Remember that.

Usually, for me, the activities I have layered on, are in this order:

Feature results write-ups

• Bringing metrics to the forefront when talking about how features of the past have performed, and linking to well-written docs, has been one of my primary tools to build credibility to new practices in feature factories
• It helps people realize there’s a better way

Impact sizing

• The next step is to start to show people that metrics are actually predictable, and that the scientific process can actually be applied to product development
• This gets people more in the mindset of talking about how much a feature can move a metric before pushing for it

Discovery

• Some people start with discovery as the first new practice they adopt, but true discovery is problem discovery and solution discovery
• I find this is really only possible when people have a hunger for doing a better job of building things that move metrics

OKRs

• OKRs are often tacked onto feature factories, and I think that’s the worst anti-pattern of them all: being accountable for outcomes when you must deliver outputs
• That’s why I prefer OKRs after the team has bought into a discovery process and can truly empower teams with metrics and problems, not solutions

OKPS trees

• Once everyone is speaking the language of metrics and problems, you need an organizing framework for conveying progress
• The OKPS is my favorite tool for demonstrating progress on the product learning agenda towards moving key metrics

Strategy

• It’s all too-easy to jump into strategy right away, but I highly recommend against it
• Driving a feature factory to a strategy takes time

Each of these isolated tools eventually come together to create an empowered team, but are fairly non-threatening to feature factory managers when introduced one-by-one.

Principle 5 — Build Your Coalition

It’s not just PMs that are upset with the feature factory.

In fact, the people often most frustrated are the individual contributor designers and engineers.

They usually feel the immediate after-effects of the constant context-switching and lack of strategy.

It’s worth winning these folks over:

• For engineers: Fight for more time for refactoring, testing, and addressing technical debt. Advocate for investing in tools and processes that will make their lives easier in the long run
• For designers: Advocate for more time for user research and testing, push back on unrealistic timelines that sacrifice design quality, and involve them early in the product discovery process

If you find ways to have their back, they’ll have yours.

The same goes for your researcher, your analyst, and your bizops counterpart.

The more folks you have in your corner, the more you’ll be able to influence the feature factory to adopt empowered practices.

And the more you’ll like being a feature factory PM until then.

Principle 6 — Learn to Love it

Working in a feature factory is an endless parade of tasks and tickets, with little time for deep thinking or creative problem-solving.

But there’s an upside to the grind, if you choose to see it.

It’s an opportunity to hone your execution skills, to get really good at shipping fast and managing stakeholders.

These are transferable skills that will serve you well even in empowered PM roles.

And they’re especially valuable early in your career, when you’re still learning the ropes.

So rather than resenting the grind, try to embrace it.

Now, we’re going to get even more tactical on top of these principals — as it relates to roadmaps and execution.

2.2 How to Influence Your Roadmap

In the empowered world, the product roadmap is driven by a strategy — one crafted at the intersection of user needs, business goals, and what’s most recently technically possible.

But in a feature factory, the roadmap often looks more like a game of Whac-A-Mole, with stakeholders constantly clamoring for their pet features to take priority.

It’s the #1 sadness driver for feature factory PMs. After all, as a PM, it’s our job to bring some semblance of order to this chaos.

Here’s how to flip the situation upside down:

1. Speak the Go-To-Market Team’s Language
2. Make Your Team Your Cheerleaders
3. Influence the Real Decision-Makers
4. Use Data as Your Weapon
5. Lean to Prioritize (and Re-Prioritize)

Step 1 — Speak the Go-To-Market (GTM) Team’s Language

In a feature factory, the roadmap is often driven by the GTM team’s needs.

These are things like: the need to close deals, keep up with competitors, or meet arbitrary deadlines. Become the ultimate translator of those needs:

• What is needed to close deals? You already know because you attend pipeline review weekly, and author the backlog of requests.
• What is needed to keep up with competitors? You are the company’s thought leader, and publish a weekly competitor deep dive.
• Arbitrary deadline issued by executives? You keep the calendar.

This is generally the #1 leverage point for influencing a roadmap in a feature factory. It ties back to key principle 2: focus on succeeding in your environment.

If you author the key input areas your GTM team needs (with their participation), then you become the ultimate expert on that form of input to the roadmap.

So when the CEO says, “we need to do that to close a deal,” you expand it on for 3 minutes with all the details of a deep investigation on the client and tech side.

That’s what really impresses the people driving the feature factory in the first place — and wins you authority to influence your own roadmap.

Step 2 — Make Your Team Your Cheerleaders

In the day-to-day scramble of a feature factory, it’s easy to lose sight of the big picture.

But as a PM, it’s your job to think strategically, even when no one else is.

That means keeping an eye on the long-term vision, and advocating for foundational work that may not have immediate business value, but will pay off down the road.

Often, coalition-building work is the best candidate for this:

1. Maybe it’s investing in a design system
2. Or building out a more robust data infrastructure.

These aren’t sexy projects, but they’re essential for scaling the product over time.

Help your team balance the short-term demands with the long-term needs. These investments in the long game will make them all want to prioritize your ideas.

So when it comes to discussion time, they all have your back. Just like you had theirs.

Step 3 — Influence the Real Decision-Makers

Now that you have your own cheerleaders, it’s time to bring on their broader network.

Who are the key stakeholders who do have a say in the roadmap?

Sometimes, these might include:

• Your engineering manager’s boss
• Your design director
• Your sales VP

Find out what those 2nd degree connections care about, what their pain points are, and how you can help them achieve their goals.

Which one of those are the most impactful things for your team to work on?

Try to get those on the roadmap, involving them in the process.

The more you can position yourself as a partner, not just a PM, the more they’ll begin to work with you as a strategic ally.

Then, you can begin to influence them, to influence the CEO.

You’d be surprised how many middle and senior managers are just yearning for good insights.

Arm them with the type of information they can take to the CEO on your behalf.

And soon the roadmap will be filled with a higher percentage of items you approve of.

Step 4 — Use Data and User Insights as Your Weapons

And what about when you actually end up in conversations with the people making the decisions?

I think the sturdiest thing to rely on tends to be a good data point (assuming you’re not pre-PMF).

If you can show quantitative evidence that a feature is (or isn’t) working, you’ll have a much stronger case for its inclusion (or exclusion) from the roadmap.

Getting several impact sizing models out in the open and iterating on the assumptions to come to a consensus is one effective method here.

If you can show that Feature X drove a 10% increase in engagement, and people believe you, you’ll have a much easier time getting buy-in for your roadmap recommendations.

If the HiPPOs in your company aren’t receptive to impact sizing models, they may still be swayed by data points like:

• Percent of population likely to use said feature: addressable population is often smaller than people realize
• Past performance of similar features or features in similar surface areas
• Analogous conversion rates in other parts of the product

Figuring out what data points HiPPOs are receptive to, and wielding them as weapons is generally the surefire way to sway them.

Some people are less data driven, but those people tend to love a good user insight.

For them, do all the discovery and validation work they would want.

When I was in a feature factory, my go-to move was to text some customers who loved the product questions. They would instantly answer.

And then I could reference these conversations with our execs who valued insights more than data. It worked wonders.

Step 5 — Learn to Prioritize (and Re-Prioritize)

So what happens when you are influencing the roadmap? It doesn’t mean things transform away from the feature factory.

Instead, it usually means you need to move faster than ever.

In a feature factory, priorities can change on a dime. One day you’re all-in on Feature X, the next day it’s been bumped for Feature Y.

You can add value by helping the team roll with these punches and keep the roadmap on track.

A lot of this means knowing when and how to push back. Even in a feature factory, you have to be able to say No to the unimportant people and requests, so you can say yes to the important one’s.

The key is to:

• Figure out what’s important
• What’s an acceptable excuse

This is much easier said than done, which is why I mention this last.

Final Words on Roadmaps

Influencing the roadmap in a feature factory is no easy feat.

But by speaking the language of business, playing the long game, rallying your allies, using data as your weapon, and learning to prioritize ruthlessly, you can start to bring some order to the chaos.

And who knows? With enough small wins, you might just be able to steer the ship towards a more strategic future.

2.3. The Art and Science of Execution

In a feature factory, execution is perhaps the most transferrable skill. So it’s worth seeping into the details of how to do it well.

I like to think of execution as two sides of the same coin:

• Art: breaking all the rules
• Science: bringing added rigor to the process

Let’s tackle some of the key principles on each side of this coin.

The Art of Getting Shit Done

My #1 takeaway would be that: in a feature factory, the art of execution is all about hustle.

If you’re all science, you’ll ignore the key decisions needed to push things out fast.

You need to be scrappy, resourceful, and always on the lookout for opportunities to get shit done.

This is what I recommend:

1. Embrace the MVP mindset
2. Use shortcuts and workarounds
3. Negotiate like your life depends on it

1. Embrace the MVP mindset

MVP has, wildly, become a negative concept in PM circles.

Nothing could be further from the truth, in my experience. Chunking up work into iterative steps is always the answer.

When speed matters, I’ve found you generally don’t want to be a product perfectionist.

Whether it’s a Minimum Viable Product, or a Minimum Lovable Product, or whatever you want to call it, it’s very helpful to down-scope grand visions into bite sized pieces.

2. Use shortcuts and workarounds

In a fast-paced environment, you can’t always follow the “proper” process.

Sometimes you need to find creative ways to bypass bureaucracy and red tape.

I always try to identify the work that is neutral or overhead, so I can stay focused on leveraged work.

This might mean using a prototype to get buy-in instead of a lengthy spec document, or leveraging a personal relationship to get resources you need.

3. Negotiate like your life depends on it

In a feature factory, everyone is fighting for resources and priority.

Your job is to be a skilled negotiator, able to build coalitions, make trade-offs, and find win-win solutions.

This means knowing how to speak the language of different stakeholders, and being able to find common ground even in the face of conflicting agendas.

The Science of Flawless Execution

On the flip side, the science of execution in a feature factory is all about precision and discipline.

You need to have rigorous processes in place to ensure that features are delivered on time, on budget, and to the highest quality standards.

Here are a few key elements:

1. Clear requirements and acceptance criteria
2. Rigorous testing and QA
3. Development cycle optimization
4. Strong project management

1. Clear requirements and acceptance criteria

In a feature factory, there’s no room for ambiguity or misinterpretation.

Every feature needs to have clear, measurable requirements and acceptance criteria that are agreed upon by all stakeholders.

This means taking the time to properly scope and spec out features, and making sure everyone is aligned before development begins.

2. Rigorous testing and QA

In a high-volume environment, even small bugs or glitches can have a big impact.

That’s why it’s critical to have a robust testing and QA process in place, with automated tests, continuous integration, and dedicated QA resources.

Embracing your project manager hat, build in adequate time for testing and bug fixes.

It’s worth not cutting corners, even when the pressure is on.

3. Development cycle optimization

In a feature factory, you need to be constantly measuring and optimizing every aspect of the development process. Not just the product.

This means tracking key metrics like:

• Cycle time
• Mean time to recovery
• Subjective developer experience

It also means being willing to pivot quickly based on data, even if it means rifling through process like a “process person.”

4. Strong project management

Speaking of types of people folks don’t want to be, embrace your inner “project manager.”

With so many moving pieces and dependencies, strong project management is essential in a feature factory.

This means… having timelines. That thing all the PM influencers tell you to hate.

I say, embrace them. I define my timelines in three buckets:

1. Fine grained and high certainty: this is for the next sprint
2. Committed: this is for the next quarter
3. Speculative: this is for the next few quarters/ years

On top of timelines, focus on the basics of project management:

• Communicate relentlessly

Make sure everyone on the team knows what’s expected of them, and provide regular updates and status reports to stakeholders. Don’t be afraid to over-communicate, especially when it comes to risks or blockers.

• Celebrate the wins

Whether it’s a big launch or a small optimization, make sure to acknowledge the hard work and dedication of the team. A little recognition can go a long way in keeping everyone motivated and engaged.

• Learn and adapt

Make sure to take the time to reflect on what’s working and what’s not, and be open to feedback and suggestions from the team. The most successful feature factory PMs are the ones who are constantly learning and adapting.

Putting It All Together

In the end, execution in a feature factory is not for the faint of heart. It requires a willingness to get your hands dirty and do whatever it takes to ship.

3. Advanced Techniques and Mental Game

3.1 Most Common Mistakes in Feature Factories

Working in a feature factory is wild. With so much pressure to ship, it’s easy to get caught up in the frenzy and lose sight of what really matters.

Over the years, I’ve seen PMs make the same mistakes time and time again in these environments.

These are the most common, and how to avoid them:

1. Chasing Only Output Metrics
2. Neglecting Technical Debt
3. Ignoring User Feedback
4. Letting FOMO Drive the Roadmap
5. Burning Out Your Team
6. Losing Sight of the Bigger Picture

Mistake 1 — Chasing Only Output Metrics

In a feature factory, it’s easy to get fixated on vanity metrics like number of features shipped or lines of code written. But these metrics don’t necessarily translate to user value or business impact.

You can chase arbitrary output goals for leaders who demand them.

But for yourself, focus on outcome-based metrics that tie back to your core product strategy. Things like user engagement, retention, and revenue growth.

It’s okay to celebrate shipping velocity externally, but don’t let it become your internal north star.

I know I’ve built up project management in this piece. But there’s also a flip-side.

We still have to think like owners as PMs and have a higher cause. Keep your eye on the prize of delivering real value to users and the business.

Often, our plans will be foiled by HiPPOs. But it’s about taking the hits and making long-term progress on the right metrics.

You’d be surprised how many product leaders have built their entire careers on this way of working.

Mistake 2 — Neglecting Technical Debt

There’s multiple types of technical debt:

• Intentional
• Accidental
• Rot

When you’re shipping at breakneck speed, it’s tempting to always choose the option with intentional tech debt.

But over time, this technical debt will catch up with you.

The end result is slow development — which hurts your ability to deliver output quickly.

As a PM, you have to turn people’s heads to the long-term. Be the voice of reason when it comes to technical debt.

Carve out time in every roadmap for refactoring, automation, and other foundational work.

Mistake 3 — Ignoring User Feedback

In the rush to ship new features, it’s easy to lose touch with what users actually want and need.

But if you’re not regularly seeking out and incorporating user feedback, you risk building a product that no one actually wants to use.

Make sure you’re setting aside time to talk to users, whether through user testing, surveys, or just picking up the phone.

I always recommend having a group of ‘textable customers’ that you can text — and do — every few weeks.

And don’t just listen to customers — watch what they do. Use analytics and user behavior data to validate or challenge your assumptions.

Remember, your job might be to ship features — but in the long-term you want to solve user problems.

And the only way to do that is to stay close to your users.

Mistake 4 — Letting FOMO Drive the Roadmap

Feature factories are always trying to keep up with the Joneses.

Instead of letting FOMO (fear of missing out) drive your roadmap, ask HiPPOs questions like:

• What are the core problems we’re trying to solve for our users by copying this feature? Can we do it in a different way
• If we copy this feature, how are we going to differentiate?

It’s your job, again, to be the voice of reason. Because if you’re constantly chasing after competitors’ latest features or trying to tick every box on the RFP, you’ll end up with a bloated, unfocused product.

Help clue your executives and HiPPOs into the art of addition by subtraction. They’ll like the volume of shipping anyways.

Mistake 5 — Burning Out Your Team

Once you embrace it, the pace of a feature factory can be exciting. But it can also be exhausting.

If you’re not careful, you’ll end up with a team that’s burned out.

As a PM, it’s your job to be the guardian of your team’s time and energy.

That means being realistic about what can be accomplished in a given sprint and quarter. Then, presenting options for trade-offs to decision-makers to keep things reasonable.

It also means making sure your team has the resources and support they need to do their best work. Things like:

• Better tools
• A learning & development budget
• Or just a well-timed team offsite/ outing

Being the cheerleader with small investments in your team’s happiness and productivity can pay big dividends.

Remember: shipping fast is important, but it’s not worth sacrificing your team’s well-being.

Mistake 6 — Losing Sight of the Bigger Picture

It’s easy to get bogged down in the day-to-day grind of a feature factory and start to hate your job. When you’re just cranking out features without a clear sense of purpose, it can feel like your work doesn’t matter.

But as a PM, it’s your responsibility to keep the big picture in mind, both for yourself and for your team.

Remember why you got into product management in the first place. What excited you about the opportunity to shape the future of a product and have a real impact on users’ lives?

Hold onto that sense of purpose, even when the day-to-day feels tedious.

Keep coming back to the core problems you’re trying to solve for users and the larger vision for the product.

And help your team connect to that sense of meaning as well.

Regularly communicate the ‘why’ behind the features you’re building. Celebrate the impact you’re having, even if it feels small.

Most importantly, don’t lose sight of your own growth and development.

Even in a feature factory, there are always opportunities to learn and stretch yourself. Embrace the challenges, and use them as a chance to build your skills and resilience.

The feature factory grind can wear you down, but it doesn’t have to define you. By keeping the bigger picture in mind and finding purpose in your work, you can avoid burnout and even find fulfillment in the chaos.

3.2 Setting Up For Your Next Empowered Role

If you play your cards right, your time in the feature factory trenches can actually set you up for success in your next, more empowered role.

The key is to be strategic about the experiences and stories you collect, and then leverage them in your job search and interviews.

Let’s go deeper.

1. Collect Your Interview Stories

When you’re in the thick of the feature factory grind, it can be hard to see the value in what you’re doing.

But every challenge you face, every obstacle you overcome, is a potential story for your PM arsenal.

• Maybe it’s the time you rallied your team to hit a tight deadline, or the time you negotiated a tricky trade-off between competing stakeholder demands.
• Maybe it’s the way you bridged the gap between engineering and design, or the creative solution you came up with to work around a technical constraint.

These are the kinds of stories that showcase your grit, your problem-solving skills, and your ability to lead in challenging circumstances.

Start a “brag document” where you keep track of these stories as they happen. Write them down while they’re fresh in your mind, with all the juicy details.

Not only will this help you answer behavioral interview questions later, but it will also give you a boost of confidence and perspective when you’re feeling stuck in the feature factory muck.

2. Build Your Resume Bullet Points

When it comes time to update your resume or LinkedIn profile, don’t just list out your feature factory responsibilities.

Instead, frame your experience in terms of the impact you had and the lessons you learned.

• Instead of saying “Shipped X features per quarter”, try something like “Led cross-functional team to consistently deliver high-quality features in a fast-paced, high-pressure environment.”
• Instead of “Managed backlog of stakeholder requests”, go with: “Owned X product area.”

See the difference? You’re taking the true facts that are relevant to the empowered world.

3. Build Your Red Flag Detector

When you’re interviewing for your next role, don’t just hope it will be different from your feature factory experience. Be proactive about sussing out any red flags.

Prepare a list of probing questions to ask your interviewers, to get a sense of how empowered the PM role truly is.

Some of my favorites:

• Can you walk me through a recent example of how a product decision was made? Who was involved, and what was the process?
• How does the team prioritize between feature requests from stakeholders and work that comes out of user research or data insights?
• What’s an example of a time when a PM on the team pushed back on a request or proposed an alternative solution? How was that received?
• How does the team balance short-term feature delivery with longer-term, more strategic initiatives?

Listen carefully to the answers, and don’t be afraid to dig deeper. If you start to hear echoes of your feature factory experience, that’s a red flag.

But if you hear examples of PMs who are truly empowered to shape the product direction, who are able to push back and propose alternative solutions, and who are focused on user needs and business impact, not just shipping features — that’s a good sign.

It’s Not Forever

Remember, your time in a feature factory is not a life sentence. It’s a chapter in your PM journey, one that can actually make you a stronger, more resilient, and more adaptable PM in the long run.

By being strategic about the experiences you collect and the way you frame them, you can set yourself up for success in your next role — and beyond.

And who knows? Maybe one day, when you’re leading your own empowered product team, you’ll look back on your feature factory days with a weird sense of fondness (or at least, appreciation for how far you’ve come).

3.3 Product Management and the Art of Zen at Work

One of my favorite books of all time is Zen and the Art of Motorcycle Maintenance by Robert Pirsig.

Picture: Robert Pirsig, with his son Chris, in NPR

And as I was re-reading it while writing this piece, it hit me — being a PM in a feature factory is a lot like being on that motorcycle trip.

You’re just trying to keep the bike on the road and get to your destination in one piece. But you’re constantly getting thrown off course by:

• Potholes
• Detours
• And, the occasional existential crisis

And I think that’s the key to surviving (and even thriving) in the feature factory chaos.

Embrace the Chaos

As we’ve done already in this piece, let’s just acknowledge that the feature factory is a messy, sometimes downright absurd, place to be.

You’ve got stakeholders coming at you from all sides and priorities shifting under your feet.

It’s easy to get just plain burnt out. But what if, instead of fighting the chaos, you just… embraced it? What if you approached each day with a sense of openness, curiosity, and even a little bit of humor?

Sure, your carefully crafted roadmap might get blown up by a last-minute CEO request. But hey, that’s just another opportunity to practice your Zen mastery of non-attachment.

And yeah, you might have to sit through yet another painful sprint planning session where everyone’s talking past each other. But that’s just a chance to hone your skills of patient listening and diplomatic translation.

The point is, the chaos isn’t going away. So you might as well make friends with it, and even find a weird sort of joy in the absurdity of it all.

Find Quality in the Details

But embracing the chaos doesn’t mean giving up on quality. In fact, I’d argue that it’s in the midst of the feature factory madness that the pursuit of quality becomes even more important.

This is one of the most important concepts in the book.

Pirsig talks about quality as a kind of elusive, almost mystical thing — not just “good” or “bad,” but a deep, abiding sense of rightness and excellence.

And as a PM, you have the opportunity (and I’d even say the responsibility) to be a champion for quality.

That might mean pushing back on a half-baked feature request and proposing a more thoughtful alternative.

Or it might mean taking the time to really dig into a thorny technical problem with your engineering team.

It’s in these small, daily acts of quality-seeking that you can find a sense of meaning and purpose in your work.

Tune Your Process, Tune Yourself

Finally, I think the art of PM Zen is about constantly tuning and adjusting — both your motorcycle (your process) and yourself.

Just like a motorcycle needs regular maintenance and fine-tuning to run smoothly, your PM process needs constant iteration and improvement.

That might mean experimenting with new ways of running sprint planning, or finding more efficient ways to communicate with your stakeholders.

But it also means tuning yourself — your own mindset and ways of engaging with the work.

Maybe that means carving out time for Thursday afternoon swims.

Or maybe it means practicing the art of “beginner’s mind,” approaching each new challenge with fresh eyes.

The point is, just like riding a motorcycle, PM’ing in a feature factory is a constant balance of control and surrender, of steering the bike and leaning into the curves.

And the more you can find your own rhythm, your own flow, your own weird little pockets of Zen in the midst of the madness — the more you’ll not just survive, but thrive.

Namaste, my feature-shipping friends. Keep on riding.