Reflecting on a career in product management(newsletter.bringthedonuts.com) |
Reflecting on a career in product management(newsletter.bringthedonuts.com) |
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.
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.
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.
I'm just glad those just sat on his table and never made it onto anyone's back.
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.
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
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.
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.
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.
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'
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.
B2B - you have to design an app that appeals to people who will buy it and force other people to use it.
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.
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”.
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.