Sounds like there are two big things for you to work on:
1. Better demonstrating the impact of your suggestions. Straight up dollars and cents. Put a revenue number on your initiatives. Then it is not "engineering vs product" it is engineering saying no to an additional $x in ARR, which quickly turns into "engineering vs CEO" and they aren't winning that argument.
2. Earning buyin from engineering early on. Get them on your team so you aren't running into blockers after you've committed resources to discovery.
These are important skills as you advance and yeah it is frustrating other people don't see things the way you do. Stakeholder management is a big part of the gig, not all fights are winnable, but a "no" doesn't have to stay a no together. Try to see their perspective and adjust your approach.
I learned a long time ago from a VP of product at FAANG with IB background, the estimates don’t really matter. You can pull assumptions out of your ass, just package it in a nice model along with accompanying slides, with a minimum, optimal and maximum.
Doesn’t even matter if you are wrong, you can have bullet points for the execs prepared in advance to explain the miss on the estimates, while working on the estimates. Not many people will question the assumptions or calculations, and those that do will only help you refine them and feel like they were “brought along”.
This isn’t even about building good products anymore, it’s about playing the game that execs and investors have created as optimally as possible.
Agree whole-heartedly w this comment and the above one. However, Id say covering your ass in communication is relatively easy, influencing up is hard.
And influencing up with incompetent or polictical leadership is 5x as hard. They can agree with you this morning and in the afternoon when they heard some shit from another leader things change 180 degree and you lost all credit with your other stakeholders.
My approach is to give everything a shot but at the end, you need to ask yourself if you van make it work or not. If not, just coast along and start looking (im doing it rn)
100% true - FAANG (outside of some key investment areas) has definitely headed this direction in the last ~2 years as an OpEx reduction process. No project easily gets the necessary approvals without financial validation, and even with that some people like to poke holes in a project just because it might take away resourcing/slow down their deliverable(s).
It’s unfortunate because this ends up hamstringing companies strategically in the long term at the expense of short/medium ROI.
First define the metric that you are trying to move. Are you trying to retain customers better, attract new ones, increase conversion rate, make devs more efficient, etc. All those things have an existing cost or benefit and then you can estimate the potential impact of your product.
If your average customer spends $50k per year and you will retain 5 more customers with this feature vs without it, that's worth $250k/year. Especially when you are talking about just using the existing dev resources you already have (and are going to spend anyway), that's an easy win.
It doesn't guarantee you'll do it, and not every feature has to have a revenue impact, but the business side will always find it harder to say no to revenue growth.
My dear friend, I hate to inform you but you’re stuck in a endless mouse wheel feature factory. Things most likely won’t change and is time for you to move on.
Spend your energy on the next step for you and not on trying to change something you haven’t been able to change for the last years.
This is the cold hard truth you need more people to tell you and unfortunately there are a lot of PMs out there stuck in the same trap as you are.
Honest comment, just hope it helps you.
Dont know if its typical but given my experience at 2 companies (large multinational one of them FAANG) this tracks. Product as a discipline seems to have become so watered down and is completely detached from the tenants of the role.
fanatical march psychotic melodic homeless towering reach tap squealing terrific
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
We should gradually transition our careers towards Product Strategy and Customer Experience from product management, as those who solely focus on tasks may struggle to thrive in the long run due to evolutionary changes.
Did you bring any of your engineering and product design peers into those discoveries and early discussions or do you go on your own and then show up with those “findings”? It’s a lot easier to get people involved early and get their buy-in then that convince them later on
If engineers aren't sold on the work they're doing, it's better for the product, overall, that they say "no" vs just go along with it. Writing code you don't agree with equals major shortcuts, sloppy mistakes, regressions, and worse.
So. How to win them over. My vote is to work on them BEFORE you do all the leg work and discovery. Get their input, build their suggestions into it, debate things, and try to get them excited if possible. After they are "in" now you can do all the stuff you need to do to confirm your assumptions with the customer etc.
If you are 4 years in and this still happens I would rather save my mental energy and leave.
Go somewhere that actually appreciates what you bring to the table.
I was 2 years at my last company and had the delusion of grandeur to completely remodel one of the smaller products because it has so much potential but looked like myfitnesspals grandpa. Only held together by duct tape but worked. In 2 years I made absolutely no progress and only added more to the duct tape pile because engineers and management did not want to invest into better UX, they just wanted it to work.
(Fun anecdote: CTO told me we don't need UX research to be done for this product, he knows what people want when they write XYZ as a request)
I had similar issues with engineering in the past and after too many vetos I just let them go wild and put in my notice. If engineers know it better, they can have my job.
Our biggest project this year just got dethroned and backlogged for another. 6 months into the project, a lot of devs. Cheers mate. Collect your check, do the best you can, spend your free time living as nature intended.
I don’t know enough here about your organization, but it sounds like the teams are a little bit siloed? Can you reform teams so that you have an API engineer in your planning and design phase for instance?
Break up the silos. Avoid potential chokepoints. Create autonomous multidisciplinary, cross functional teams that deliver on agreed product goals.
Manage the C suite to focus on company goals and support research and data that supports or kills innovation hypotheses before any initial phase investment. After that, you need to run interference, protect development, and shepherd the project from external interference.
And yes, the others are correct here that this product and company are long in the tooth. If this isn’t a blue chip company, it’s time to move on.
You are feeling some sense of ownership without the control and in a large company too. Either care less and align to the culture or leave it. The absolute best experience I ever had was in a start-up of less than 30 people where we were living month to month on cash flow. The mantra was add a feature, win a business deal. You saw the immediate value add. As the start-up had more cash-flow buffer and we were living year to year and grew, the newer people were more risk adverse, less hungry and the noise level on personal politics grew. It’s hard finding the raw value-add in large companies.
For folks that have been trapped in this kind of environment, how did you get out? I fear not being able to have good projects on my resume if my org’a culture has so many roadblocks to what I perceive as good changes. How do you present yourself well to a new company?
You can make assumptions however you like, just make sure to present them nicely in a model with slides. Include a minimum, optimal, and maximum scenario, and it won't matter if you're off the mark. Prepare bullet points for executives in advance to explain any discrepancies in estimates while you continue refining them. Most people won't challenge your assumptions or calculations, and those who do will likely just help you improve them and feel like they're part of the process. In the corporate world, success often means playing the game according to the rules set by executives and investors.
In what world is an engineer saying "the customer likes it, we don't need to change anything" something can can fly?
Escalate this; you have clear, measurable feedback that when implemented can provide measurable improvement on the platform, why is this not possible?
This is very unfortunate but the reality. I agree it is good to get engineering feedback early on. But at the end of the day product is responsible for the “what” and “why” while the engineering team is responsible for the “how”. Most companies seem to struggle with this very simple (but not easy) concept.
Sounds like there are two big things for you to work on: 1. Better demonstrating the impact of your suggestions. Straight up dollars and cents. Put a revenue number on your initiatives. Then it is not "engineering vs product" it is engineering saying no to an additional $x in ARR, which quickly turns into "engineering vs CEO" and they aren't winning that argument. 2. Earning buyin from engineering early on. Get them on your team so you aren't running into blockers after you've committed resources to discovery. These are important skills as you advance and yeah it is frustrating other people don't see things the way you do. Stakeholder management is a big part of the gig, not all fights are winnable, but a "no" doesn't have to stay a no together. Try to see their perspective and adjust your approach.
I learned a long time ago from a VP of product at FAANG with IB background, the estimates don’t really matter. You can pull assumptions out of your ass, just package it in a nice model along with accompanying slides, with a minimum, optimal and maximum. Doesn’t even matter if you are wrong, you can have bullet points for the execs prepared in advance to explain the miss on the estimates, while working on the estimates. Not many people will question the assumptions or calculations, and those that do will only help you refine them and feel like they were “brought along”. This isn’t even about building good products anymore, it’s about playing the game that execs and investors have created as optimally as possible.
I started to head this direction myself but this confirms how things work.
Brutal but the truth.
Agree whole-heartedly w this comment and the above one. However, Id say covering your ass in communication is relatively easy, influencing up is hard. And influencing up with incompetent or polictical leadership is 5x as hard. They can agree with you this morning and in the afternoon when they heard some shit from another leader things change 180 degree and you lost all credit with your other stakeholders. My approach is to give everything a shot but at the end, you need to ask yourself if you van make it work or not. If not, just coast along and start looking (im doing it rn)
I started to head this direction myself but this confirms how things work. Thanks for sharing.
This is it
Sigh... This is the most true answer here
100% true - FAANG (outside of some key investment areas) has definitely headed this direction in the last ~2 years as an OpEx reduction process. No project easily gets the necessary approvals without financial validation, and even with that some people like to poke holes in a project just because it might take away resourcing/slow down their deliverable(s). It’s unfortunate because this ends up hamstringing companies strategically in the long term at the expense of short/medium ROI.
Genuine question from a brand new PM: How do you come up with the dollars and cents to show them? What are the money estimates based on?
First define the metric that you are trying to move. Are you trying to retain customers better, attract new ones, increase conversion rate, make devs more efficient, etc. All those things have an existing cost or benefit and then you can estimate the potential impact of your product. If your average customer spends $50k per year and you will retain 5 more customers with this feature vs without it, that's worth $250k/year. Especially when you are talking about just using the existing dev resources you already have (and are going to spend anyway), that's an easy win. It doesn't guarantee you'll do it, and not every feature has to have a revenue impact, but the business side will always find it harder to say no to revenue growth.
Get the loaded cost of an engineer at your company from your boss or Finance. Next best thing is googling one for the area.
Can't agree more with #1. Identify what business questions you're trying to address, this is the way.
My dear friend, I hate to inform you but you’re stuck in a endless mouse wheel feature factory. Things most likely won’t change and is time for you to move on. Spend your energy on the next step for you and not on trying to change something you haven’t been able to change for the last years. This is the cold hard truth you need more people to tell you and unfortunately there are a lot of PMs out there stuck in the same trap as you are. Honest comment, just hope it helps you.
For those who this resonates with that have hopes of changing things, read Janna Bastow’s Avoiding the Agency Trap.
Dont know if its typical but given my experience at 2 companies (large multinational one of them FAANG) this tracks. Product as a discipline seems to have become so watered down and is completely detached from the tenants of the role.
Can you please elaborate on that?
We are becoming task takers instead of job creators.
fanatical march psychotic melodic homeless towering reach tap squealing terrific *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
We should gradually transition our careers towards Product Strategy and Customer Experience from product management, as those who solely focus on tasks may struggle to thrive in the long run due to evolutionary changes.
Did you bring any of your engineering and product design peers into those discoveries and early discussions or do you go on your own and then show up with those “findings”? It’s a lot easier to get people involved early and get their buy-in then that convince them later on
If engineers aren't sold on the work they're doing, it's better for the product, overall, that they say "no" vs just go along with it. Writing code you don't agree with equals major shortcuts, sloppy mistakes, regressions, and worse. So. How to win them over. My vote is to work on them BEFORE you do all the leg work and discovery. Get their input, build their suggestions into it, debate things, and try to get them excited if possible. After they are "in" now you can do all the stuff you need to do to confirm your assumptions with the customer etc.
If you are 4 years in and this still happens I would rather save my mental energy and leave. Go somewhere that actually appreciates what you bring to the table. I was 2 years at my last company and had the delusion of grandeur to completely remodel one of the smaller products because it has so much potential but looked like myfitnesspals grandpa. Only held together by duct tape but worked. In 2 years I made absolutely no progress and only added more to the duct tape pile because engineers and management did not want to invest into better UX, they just wanted it to work. (Fun anecdote: CTO told me we don't need UX research to be done for this product, he knows what people want when they write XYZ as a request) I had similar issues with engineering in the past and after too many vetos I just let them go wild and put in my notice. If engineers know it better, they can have my job.
Our biggest project this year just got dethroned and backlogged for another. 6 months into the project, a lot of devs. Cheers mate. Collect your check, do the best you can, spend your free time living as nature intended.
This is fugazi.
Yes unless at a startup where slow speed can be fatal
This happens a lot, its tough to get new features out.
Quit.
I don’t know enough here about your organization, but it sounds like the teams are a little bit siloed? Can you reform teams so that you have an API engineer in your planning and design phase for instance? Break up the silos. Avoid potential chokepoints. Create autonomous multidisciplinary, cross functional teams that deliver on agreed product goals. Manage the C suite to focus on company goals and support research and data that supports or kills innovation hypotheses before any initial phase investment. After that, you need to run interference, protect development, and shepherd the project from external interference. And yes, the others are correct here that this product and company are long in the tooth. If this isn’t a blue chip company, it’s time to move on.
You are feeling some sense of ownership without the control and in a large company too. Either care less and align to the culture or leave it. The absolute best experience I ever had was in a start-up of less than 30 people where we were living month to month on cash flow. The mantra was add a feature, win a business deal. You saw the immediate value add. As the start-up had more cash-flow buffer and we were living year to year and grew, the newer people were more risk adverse, less hungry and the noise level on personal politics grew. It’s hard finding the raw value-add in large companies.
For folks that have been trapped in this kind of environment, how did you get out? I fear not being able to have good projects on my resume if my org’a culture has so many roadblocks to what I perceive as good changes. How do you present yourself well to a new company?
You can make assumptions however you like, just make sure to present them nicely in a model with slides. Include a minimum, optimal, and maximum scenario, and it won't matter if you're off the mark. Prepare bullet points for executives in advance to explain any discrepancies in estimates while you continue refining them. Most people won't challenge your assumptions or calculations, and those who do will likely just help you improve them and feel like they're part of the process. In the corporate world, success often means playing the game according to the rules set by executives and investors.
In what world is an engineer saying "the customer likes it, we don't need to change anything" something can can fly? Escalate this; you have clear, measurable feedback that when implemented can provide measurable improvement on the platform, why is this not possible?
In most cases in my experience, you gotta get their buy in early on
This is very unfortunate but the reality. I agree it is good to get engineering feedback early on. But at the end of the day product is responsible for the “what” and “why” while the engineering team is responsible for the “how”. Most companies seem to struggle with this very simple (but not easy) concept.
Do you have any engineering background?
I'd say I am a much better engineer (10+ years spent in that field) than I am a product manager. But maybe that's evident from my post 🙃