Here's how to safely learn/practice product even if your org feels like an irreformable feature factory.
Figure out how to instrument what you ship. At a minimum, that will give you some experience measuring impact (even if no one pays attention). You will not get fired for presenting what you learned; it may even open people's eyes to the fact that some things aren't hitting the mark. Bonus: the metrics may help you present the impact of your work when applying for another job. If someone says you don't have metrics, ask an engineer to get some access to a DB (and learn SQL).
Do whatever you can to interact with customers, even if it is for something you just have to get done—practice interviewing, discovery, note-taking, etc. If PMs typically don't do this in your company, invite yourself to sales and support calls. Pair with UX Research if lucky to have them on your team. Bring these humans into your discussions with stakeholders and your team whenever possible. Forget personas—talk about real humans.
Do whatever you can to learn how the business makes money (or not)—financials, KPIs, etc. Being inside a company gives you a unique opportunity to learn how a business works (even if it doesn't prioritize continuous improvement). Listen to the quarterly investor call, assuming you're a public company. You may even get insights into the big elephant in the room that keeps it from modernizing its work. There's a good chance that the elephant in the room is, drumroll, success. Your company prints money, and being more product-forward is an aspirational goal that gets consistently swept under the carpet because of pressing short-term goals.
Set aside time to collaborate with designers and engineers whenever you can. It helps to get in the reps, even if you're shipping a predetermined roadmap. What works? What doesn't? How do they work? So much of being a good product manager is building awareness of the rhythms of collaboration (e.g., maker time, deep work, design reviews, feedback giving and receiving, mapping object models, looking for quick insights, etc.).
Write good goal-focused one-pagers as if you were starting efforts without something specific to build (as if you were starting with an objective, not a solution). Just slap the predetermined thing in a section with other potential opportunities and market it as a "selected opportunity." You will not get fired for this. Get feedback on these.
Set usage and adoption goals, even if no one cares. At least you'll have fun testing your intuition. Again, this will come in handy while interviewing for your next job if you choose to look for another job—bonus points for piping these into a Slack channel or similar. General awareness of failure and missing the mark can go a long way if you're nice about it.
Practice interacting with stakeholders across the company and learn how to understand their context and problems. Don't try to solve everything, but know how to approach these conversations with an open mind. Start by mostly listening. Every conversation is an opportunity to learn about their domain, the decisions they have to make regularly, what drives them, and how they conceptualize work.
Show up at every review and review your work from an outcome perspective. You will not get fired. Start with, "To remind you, the goal here was _____, and the key hypothesis is/was that ______." Then, talk through all the other stuff—practice presenting the right things in order. You want this type of presentation to become second nature. Practice! The same goes for roadmap presentations. Weave in a driver-based view before you show the Gantt /calendar view. Use every opportunity to practice your storytelling and context-framing skills.
Find someone in the company currently advocating for a business model change or why better products will drive business results. Who is feeling the most pain because of the feature soup? I bet there's at least one. Could you get to know them? They probably want to nerd out with someone. Be their product thought partner. Look for a chance to work together. Pull some data for them. Do some competitive analysis with a product lens.
Consider all sorts of language hacks. Don't try to replace company language (e.g., projects), but seize opportunities to use words like bet, assumption, value, opportunity, outcome, job, etc. Words have power. You probably don't want to sound like an abstract product theory wonk, but strategic language use can go a long way.
Hopefully, you've noticed the theme here. Pretend you are doing it correctly with the caveat that someone else decided what to build and when. You might confuse people by doing more work, but you will not get fired. This will help you get in reps.
It really is all about the reps, even if things are less than perfect.
To conclude, some take-it-or-leave-it wisdom.
A lot of companies are (or strongly believe they are) great at product but crappy to work for. Many people I know finally got their dream job from a craft perspective, only to discover that their company had deep flaws (including being inflexible and not entertaining new ideas and ways of working). Hubris is a thing. Some companies have great cultures/effective leaders but there are a lot of systemic challenges like architecture, existing customer relationships, the business model that need to get worked out over time.
If you can find a company making steady improvements and feel supported and rewarded, you might consider sticking it out. Ask yourself whether 1) you're learning and growing as a person and 2) you're taking safe and sane steps to continue learning. You may discover you have far more flexibility in ways of working than you would in a company that believed it had it all figured out.
The benefit of taking the steps above is that you'll be sharp and ready to explore getting a new job. But, you may even discover that you were happier than you thought in your current job.
(Fun fact: I first wrote about feature factories in 2016. Looking back, I can't believe how snarky and simplistic my thinking was. But that's how we grow. It "went viral," leading many people to think I coined the term. I may have—I came up with it independently—but there's nothing super original about it! I probably wouldn't be writing now if I hadn't written that post since it led to many interesting opportunities. I wrote a follow-up here that may be interesting.)
Feature factories don't help existing customers adopt the feature. They often don't help internal people learn about new features either. In addition to instrumenting the feature to measure usage, partner with customer success and the teams that write the technical and non-technical documentation, the knowledge bases, and the website. Having both "How to Use Feature" information and "When and Why to Use Feature" Information can help feature adoption.
Thank you John! I feel this is important encouragement and actionable advice!