I've worked 6 years as a PM, last 4 at FANG

Here's some advice, which you are free to take or to leave, (and that's very reasonable since my advice is generic and I can't speak to your exact circumstances)

1) Just start doing it. Don't wait for someone to give you permission to prioritize customer needs. Pick up the phone and call them. Go to a store and watch them shop for your product. Talk to people. When you set OKRs/KPIs, just make them about customer needs. Be the change you want to see. Especially if you have spiritual buy-in from your manager. But your intentions have to be crystal clear on point about wanting what's best for the customer and the business and doing so in a rational way until you earn some social capital. It cannot be interpretable as political or they'll construe it as that and fire you

2) Use bureaucracy jiu-jitsu. Do what you think needs to be done in order to make the customer and the business successful. When someone tries to make you work on their arbitrary BS, give them a form to fill out and tell them it's in your team's triage queue. Make them force you to deprioritize a project which has clear value and then when that happens, make sure you announce loudly to all stakeholders why that project was depriortized and what's going to be implemented instead. If your stakeholders have even 2 braincells, they'll do the pushing back for you - you don't need to do it alone.

Lastly, you can't change an entire culture by yourself. For some places, it's just too late. But if you can find allies who feel the same way you do, you can be the beginning of a large change for your whole org by just being a good example

See also: Getting Things Done When You’re Only a Grunt (2001):

https://www.joelonsoftware.com/2001/12/25/getting-things-don...

That advice reads as "If your job sucks and you can't safely quit, defy your manager and work overtime until you are thanked for it or fired."

Well, yes. Sometimes your options are limited.

A perennial classic. Still pertinent after nearly twenty years.

Seems like great advice.

Great, practical advice for companies of that size. We can debate about whether it's unfortunate that it's necessary (I'd tend to agree that it is), but learning how to do this is the basic block and tackling required to get things moving at BigCos.

Many thanks!

#1 is really solid advice.

I'd be cautious about this advice. Many times even though the company in general might be a feature factory [0], there might very well be a human who actually meets customers, or at least tried meeting them and failed for some reason.

So a much better and safer idea might be first to figure if there were any attempts in the past, or is there any ongoing similar initiative right now, find the participants if there was any and then to proceed.

By the way if all the PMs at FAANG are like you, that might be a terrible place to work at.

[0] https://cutle.fish/blog/12-signs-youre-working-in-a-feature-...

> By the way if all the PMs at FAANG are like you ...

This comment doesn't seem necessary!

And lo and behold, still it is there

This problem isn’t unique to big tech. It’s much easier to tell each other you are customer driven than to actually pick up the phone.

I’m in b2b SaaS, and the best approach I’ve found to combat this is to get involved in sales meetings. Salespeople look at you funny if you ask to come along, but if you convince them you aren’t weird it usually works. And you tend to make the meeting more successful, as well as getting actual useful insights into what prospects actually want.

While this works on the surface; many times you'll find what sells is often features your competitors hit you on, but not what will actually sustain customers.

One issue with "buyers" is that they aren't the one using the software.

I worked at a big tech company many years ago and it's precisely this disconnect that I will never work for a big successful company again. Successful companies tend to have a lot of "buffer" in terms of resources so they feel no urgency to ensure that resources and time are allocated to something meaningful. The objectives of middle managers are often not aligned with the companies. I've been on projects that were delivered on time and under budget only to be canned just before shipping because after two years the market has shifted. No one in those two years felt the need to change anything or make the hard decisions. Rather it was easier to just act like everything is fine until the last possible moment after wasting 2 years of worth of engineering resources with 50 engineers. The problem isn't you.

>Because I’m still new to this role, I wonder if I’m being naive or idealistic around how we approach our feature development, or if this is just how most companies operate.

IMHO, the way to answer this question is from a sales perspective. What's the revenue of the product? Is the product doing well financially and are customers renewing? Are the sales teams able to hit their targets?

I work in a customer facing role for a huge company and you've described the situation here well. We've got a ton of products, some of which are doing really well and one of which is tanking. The one that is tanking is something the company is placing a huge bet on.

Whenever I speak with product management for the product that is failing, they have this grand vision looks amazing in slides, but when I work with customers it's obvious that vision isn't grounded in reality. It's like they spoke with a bunch of CIOs and drew up this vision that has nothing to do with how the market actually is. It's almost painful to talk with product management because they just keep going back to this grand vision and anything that goes in their ears gets filtered by this viewpoint.

And it absolutely shows in the dismal sales and high customer churn.

If the product is doing well, maybe you are naive. If the product is failing or barely treading water, you're not the one being naive.

It's important to keep the customer in mind when you're looking at sales figures. It's too easy to be lulled by solid sales and low churn into not actually seeing the customers at all anymore. That's usually the beginning of a downward slide ending in massive churn once a competitor releases what your customers actually wanted from you. This advice is easy to keep as an individual, hard to keep as an organization (unfortunately).

You work in a fortune 100 company, welcome to bureaucracy.

Those middle managers do not give a shit because they are middle management! Big companies have tons of people like who's only motivation is to simply not get fired (this is one point the movie Office Space nailed by the way.)

A fish rots from the head. If your executive leadership is not obsessed with its customers, nobody else will be. And you guys will continue to be rudderless which is demoralizing.

Big, fat, companies get lazy and that sucks for a guy who wants to make a difference. Go work somewhere that encourages logical (black/white) thinking and values engineers who want to turn customers into raging fans.

Or just work each day enough to not get fired, and build your own product on the side.

What you're missing is that the 'customer' in this case is not the buyer of the product, but rather a proxy for them found in the PM.

Big, heavy, complex products, the kind one imagines F100 companies build, are not suitable for literal agile where a paying customer as willing and able to iterate with the development team.

With that kind of product, you have many customers. When you have many customers, they always have conflicting requirements. You cannot engage in an agile process with more than (say) three of them for the same product. You'll very quickly reach an impasse and lose all of them as customers, and end up with the same product anyway. And you'll open the kimono, so to speak.

Instead the PM has to decide (based on various activities such as seeing what other companies are doing, where the space is headed, and yes, talking to customers) what the product is to look like, and he (or more likely, you the product owner in this case) has to engage with the dev team. You have to be the customer that actually needs and wants something, and that the dev team has to satisfy. This is why PMs have to have significant industry experience. Often, CEO of a small company slots into PM role in larger companies.

Agile as written, with paying customer in mind, is for consulting style engagements. But that doesn't mean it can't be applied well when PM is a stand-in for the customer. It keeps the dev team moving, and brings the 'C' players up to 'B' level. (Unfortunately it also brings the 'A' players down to 'B'.)

> Because I’m still new to this role, I wonder if I’m being naive or idealistic around how we approach our feature development, or if this is just how most companies operate.

yes and yes. You are being naive, and this is how most companies operate. That your boss can't explain it to you just shows that the company doesn't understand the application of agile and are just cargo culting, like most companies, and doing a very poor job of "Agile" because they don't understand it. Most companies implement agile as a way to micromanage devs, not as a way to get a better product, and even then they suck at it.

Customers can be a nightmare simply because they don't want to be closely involved and on their end, they usually are not engineers so the requirements can easily not make sense.

I don't blame people for avoiding such tasks, especially in a Fortune 100. The bigger the company, the more diffuse responsibility and the harder it is to steer the ship anyway.

It's worse when they /do/ want to be closely involved, but then also thinks that being closely involved means dictating functionality to a T.

Using software does not translate remotely well into /designing/ software. Too many people want to play small-time user interface designer while realistically having no design knowledge beyond "I've used software before, and I have IDEAS about how to do things better."

So much effort is wasted on implementing things people think they need, having recognized a problem and conceived one idea that might solve it if only someone could implement their vision.

I sometimes envision a world where (layperson) patients show up at a hospital with a medical condition, describe a novel surgical treatment to the physicians, and then the physicians follow their instructions exactly because, hey, why not? It might work! There definitely won't be consequences if it doesn't!

Another issue I found while writing software that customer service agents used was we did not get feedback from CS agents without being deliberate, only from the managers of the users (CS agents). The managers were interested in other features like, time tracking, conversion/sales reports, while CS agents were interested (when we finally talked to them) about things that would improve their sales (ex: show available manufacturer rebates for skus to help make a sale)

This is often because people don't understand that the real deliverable is knowledge gained throughout the process and the software is actually an artefact of this knowledge.

You might enjoy reading all the things that Marty Cagan has written about product management. I think he has a good take on what it means to be a good PM, and what you're describing sounds like what he calls a Feature Team [1]. Unfortunately, it's really common to be in an organization like this where the roadmap is driven by outside stakeholders, and product managers are treated like project managers who just implement their ideas.

[1]: https://svpg.com/product-vs-feature-teams/

I dogfood my product. I write what I need.

Works for me. Some folks like what I do, as well.

This is exactly my approach. Years ago I wrote a set of tools to help me in my day to day operations. In this way I was able to work very fast. I added more and more features. Then at some point I decided to distribute the tools to the rest of the team. Now, nobody can live without them ... (about 30 individuals)

> I’ve been told that someone in leadership described me as being too “black and white” in this area, but I consider myself both pragmatic and flexible to alternative ideas.

When I've seen responses like that in the past, it's often somebody who just doesn't want to listen to any complaints, for various reasons. I recommend a quieter approach, where you don't tell anyone what you really think about the problems, but just wait for an opportune moment to ask "can we do X for Y?" in a public forum. That way you can't be ignored, you aren't complaining at all, and somebody else can later take credit for implementing your idea, without them having to admit that they were the cause of the problem to begin with.

I often refer to this diagram when in doubt

https://www.scrumexpert.com/knowledge/how-to-detect-agile-bu...

Agile bullshit starts with the attitude that some of our people are not client facing

Off topic, but would you mind sharing how you made the transition from design to product management? I'm considering making the jump myself and am curious about what the experience has been like.

The bigger the project or smaller the company the more customer involvement is demanded. You may not be in that nexus. If the app runs with new features perhaps that is good enough.

The problem is the definition of customer and the actual commitment to a customer focus, in my experience.

It's usually hijacked away from the actual customer - that is to say, a person who pays your company for products and/or services - to various internal "customers" who are nothing of the sort.

Spotify are ostensibly the Gods of Agile, but how many Spotify music customers were actually begging for podcasts? How many of them were begging for Spotify to lock podcasters behind their paywall and stop podcasts working with any tool? Was there even a single paying Spotify customer demanding that?

It wasn't the customers, it was the beancounters. Spotify itself doesn't have any "original programming" as the video players have, so the logical move is to capture a market worth something for a lot of listeners. This wasn't about doing something for the listeners, it was about capturing and milking a market.

Spotify is a growth company. They build for future customers.

Podcasters at also business partners, just like songmakers are. The only relevant difference between podcasts and music is that you've been conditioned to expect that music costs money but expect podcasts to be free.

Spotify didn't blackmail Joe Rogen into licensing his podcasts for $100M.

Spotify feels natural to me to listen to Podcasts. So i am at least one paying customers, who was just waiting for it.

(Never knew, that spotify also has video. Who is using that?)

Isn't the entire point of agile to get rid of the product managers?

No.