Reflecting on a career in product management | Hacker News Reader

Reflecting on a career in product management

newsletter.bringthedonuts.com

84 pointssgpl26 comments

It seems like there’s been a rush to the science mindset and the art part has been ignored by many in industry for the last 5-10 years.

I remember wanting to be a PM, but experience with the MBA-ification of the field has embittered me.

Seeing products (like Xamarin.Forms) systematically destroyed by focus on shallow metrics has been really sad. I remember being excited for that product to get a PM. Then the product just kept getting worse and kept stagnating. Developer interest has dropped precipitously and they haven’t managed to stay competitive with React Native or Flutter, despite having Microsoft’s resources.

All the time I give feedback on Visual Studio. I am a loyal customer, but I can only get “We’re closing this issue because we only prioritize problems with a broad customer impact, and you haven’t gotten enough upvotes” so many times. I’m sick of it.

I don’t think I’ve met a PM in the last 5 years that hasn’t made my impression of the company they work for far worse. And it comes down to focusing on business metrics and ignoring the two other sides: customer experience and interaction, and interactions with internal developer partners.

I don’t know why companies are only hiring and cultivating MBA-style, metrics-oriented, value-blind PMs, but the abandonment of art has made the industry worse for everyone involved.

If it makes you feel better, these PMs are ruining development too: the developers can absolutely see that issue you referenced and were probably telling the PM they can knock it out in a few minutes or even started working on it already. PM will step in and say no, you do what's on the backlog. Developers lose all agency and start quitting. Product further deteriorates.

As a dev, the best kind of work is when you're connecting with your users and solving a real pain for them. Being robbed of these opportunities is how you get burnt out.

And this is why Product Engineers are a thing now.

This is entirely because of a weak product culture at those companies. What does that mean? It means product is unable to make recommendations based on experience or design, only metrics. This is because engineering management only listens to metrics and data. (And yes, it could also be because the product team lacks talent) If there's a strong product culture, for example what Jobs had at Apple for a long time, the product team has executive backing and is able to make what others would call risky decisions. However if you are the product manager, speaking to the customers, these decisions are actually pretty obvious, and not particularly risky at all. Fortunately, in this situation you are empowered to make the right decisions for the end users. (To take a dead-obvious example: No macbook pro product lead would have ever suggested to remove all the ports. This decision was made by design. Had there been anyone in product with serious backing, this would never had been allowed to happen.) If you are in product management, the most important career decision you can make is to find companies with a strong product culture. Don't pick firms that do not value product, you will only be sidelined and blamed for their poor product decisions. The biggest challenge with your chosen career is that nobody outside of it understands it. It takes a certain confidence and a great deal of skill to be consistently successful.

Yep. It's a very logical, data-driven mindset that is only concerned about "pushing the needle closer" rather than providing actual value.

Many of the mechanisms of how those teams operate are flawed. You may have filed the same issue that was closed previously because of low upvotes, but now there are multiple reports of it! It's almost an anti-pattern of being data-driven.

Most companies know that business metrics follow great products when teams have full autonomy, competence, and relatedness. (i.e. VS Code, JetBrains Suite, etc). Sadly in the process they end up killing those very things that made them successful when reaching certain scale.

The PM discipline is getting more definition in the industry, but to your point, hardly anybody practices the art. The art to me is being "data inspired", not driven or informed. It's hard for PMs in big tech to do that nowadays unless it part of the culture from the top-down or taught/mentored from the bottom-up.

The COO at my last job kept touting the aphorism "Data Trumps Opinion" to the point where he had T-shirts made with that (facepalm!)

I'm just glad those just sat on his table and never made it onto anyone's back.

Uck. I get that people can feel that way as opinions are often way worse, but tshirts? Haha

I was briefly a PM in a past company and I agree 100%. The obsession with chasing business metrics over actual performance, quality, and end-user value is demoralizing. And it’s not just chasing metrics: it’s chasing vanity metrics like 7-day retention and number of weekly new installs (ignoring uninstalls).

I could never give the engineering team time to fix bugs, improve efficiency, or clean up tech debt, because of the constant pressure to feature-cram and juice “engagement” metrics.

I’ve since moved on to being a Program Manager so I can focus on the “when” and “how” and be a neutral third party when it comes to the “what”. Only way to keep sane.

Even if that kind of article is interesting to read, I like the science vs art part (even if I believe the art part can't be learned). There is not much one care learn about the post. Experience is difficult to learn by another way than experiencing it.

I would add the list, that the biggest thing that people never understand in product management. Is that working on a B2B SMB/ B2C product vs a B2B Enterprise product needs a totally different mindset

I don’t necessarily disagree with you re B2B vs B2C but I think we should question it. There is nothing fundamentally different between apps for these audiences. So why do they require different mindsets?

The audiences are fundamentally different and that is your job in product management, aligning those interests

B2C - you have to design an app that appeals to people who will buy and use it.

B2B - you have to design an app that appeals to people who will buy it and force other people to use it.

This is still true in pockets but in some spaces it’s falling out of favor. Companies and leaders know that they need to worry about adoption, so there’s slow but increasing focus on end user UX and incorporating these folks into the buying process.

Yes, this has been my experience too. The buyers of enterprise software today have been raised on B2C software and are starting to expect the same level of usability, comprehensibility and friendliness.

It is not a case of form over function, so much as it is that form and function are interdependent.

I’ve worked as a senior manager for a couple of enterprise app developers, and if I was to do it again, a great UI would be a prerequisite.

On the other hand, many large enterprises are still beholden to consulting companies which tend to be checklist driven.

I didnt say B2C vs B2B. I said B2C or B2B SMB vs B2B Enterprise

In B2C or B2B SMB the goal of the company is to deliver the best product for doing some use case

In B2B Enterprise the goal of the company is to deliver a vision to customers, the product doesn't come first and should be more 'complete' than 'good'

Sorry, I understood what you meant but overly abbreviated my response.

I understand your point about “complete” versus “good” but I have always wondered about the economic impact of the decision to deliver low quality user interfaces (“more complete than good”) to front line operators.

I’ve worked in a number of enterprise domains and I’ve found that the more I empathise with the uses of my software (ie, the front-of-house workers, not the end customer) the more I see benefits to the organisation in terms of staff motivation and efficiency, which translates to a better end-customer experience as well.

I’m just not convinced that something can really be said to be “complete” if it is not also “good”.

You need to convince a user to adopt in B2C. There needs to be a benefit to them and you need to understand them.

I run a large line of business in a big “E”. Our requirements may not even be known to the end users and may make their lives miserable. Nobody cares.

We have lots of money, but I can’t tell the taxing authority that we can’t comply with some demand in 3 months because our finance clerks will be miserable, and I can’t get the engineering resources allocated to some administrative process at the expense of the customer. We do look at process engineering and often find ways to fix things that are really bad — but end of the day making things pretty for enterprise users is at best a secondary priority.

I understand this. And in your case maybe it makes sense. But does the enterprise ever consider the cost of making the finance clerks miserable? These costs can be in terms of staff retention, acquisition, and especially efficiency.

Honest question. I’ve done consulting in big-E (telco) and internal user ergonomics are more often than not thrown under the bus in the name of pet product feature from some noisy but inexperienced stakeholder that are not needed in practice. This doesn’t apply to your example, but in my case compliance was already considered, and didn’t change often. Yet still, they seemed to hate the internal users.

I always felt that there was an economic case to be made for making users lives less miserable, and I’ve come to the conclusion that in most cases enterprise software is bad due to cultural and political reasons (lack of ability to say no to stupid features, lack of discipline around feature implementation, lack of domain knowledge, artificial time pressure, etc) rather than economic reasons.

You can learn the art.

You can learn and reflect.

For learning, read. “How to Win Friends and Influence People” by Dale Carnegie, or “Start with Why” by Simon Sinek come to mind. They will grow your communication, vision setting and influencing skills. Skills which are part of the “art” of product management.

And every day provides an opportunity to reflect and learn from the day’s events.

Sinek is a fraud. There's nothing useful to be learned from that book that you can't get from common sense.

You would be surprised as to how sparsely distributed what one thinks as "common sense" can be.

Indeed.

BTC/SMB is about creating a complete product to serve many customers in the marketplace and take advantage of economies of scale. Marketing is key.

B2E is about working with perhaps just a few clients to develop bespoke solutions (that may have a product element) targeting their specific business needs. Relationship building is key.

Where do you see solutions like Twillio and Cloudflare in this? They have a complete solution taking advantage of scale but make most of their money in Enterprise deals?

Cloudflare and Twillio are special, they are dev tools. Classical business rules dont apply to them

B2C markets with long-tails.

This is really good advice.

Technical PM in big tech here. Going to chime in with some thoughts as I made that same transition after 5 years in engineering. And been doing it for the last 5 or so years.

Given that PM has two definitions:

Product manager - what & why

Program manager - when, who, how

Some companies simply get these two disciplines mixed up or a single PM handles both(hard job). Some PMs act more like engineering managers & other PMs act more like MBAs.

The number one way to grow as a PM? Read and embed yourself with your users & product.

Learn from other accomplished individuals, find mentors on what works and try new things for yourself. It's amazing to me of how many complements you may get about some strategy or tactic we used as a product team successfully that just came from a book & applied to our space. Lenny's newsletter is great too, but even books about successful / failed products are just as helpful.

> Don’t let gaps form between you and your customers and between you and the builders

This is commonly an Ivory Tower problem in which teams don't do any customer research or get out of the building to talk to people they're building for. It's hard to blame them when they've never done it before to be successful nor have a PM who understands the value of embedding themselves in the product they're managing.

> People matter most

My personal motto for any new product or effort is to "work the people, then the problem". It doesn't matter if there's deadlines if nobody is talking to each other or learning from the very people you're building the product for. Once everyone is rowing in the same direction & agree on a common vision, it's smooth to execute upon it.

> Write your resume in ten years.

My ten year plan when I first started in software was to become a DBA(wrote it in 2010). And that DBA dream was more close to modern data science today. The data science side of PM work is an absolute joy and fun. It's exactly what I wanted when I wrote that 10 years ago. Oh how things have changed. Now that I'm a more senior PM, that 10 year plan has shifted to be a director and/or running my own successful product with all the skills learned over my career.

> The “art” of product management matters more than the “science” over the long term.

The art is the right brain(creativity), the science is the left brain(logic). I personally like to see this as emotions vs. facts. How you feel about something is much different than the reality of it. The art of being a good PM is by invoking emotions. How engineering feels about the backlog priority? How do users feel about an upcoming feature/change? How do leadership feel when you present your next year plans? There's a reason why many popular PM books are called "Inspired" or "Empowered". It's because of the emotion being invoked when your team is firing on all cylinders and your users are happy with your product decisions.

Reply on news.ycombinator.com