Another great way is to get your engineers involved in customer calls and user research as much as possible. This makes them aware of the problems and helps them to think from a product perspective as well
Haha I struggle with this too. I always let them know about all the customer calls and user research I’m involved in and ask them who wants to come be a fly on the wall. Generally 1-2 always volunteer. Sometimes none. Obvs I can’t force them but they’re aware and based on their time schedule and need to basis will show up accordingly.
This is a paradigm shift. I've held the same opinion based on my short experince of 1 year as a dev (haha), and what I've read others on reddit saying. Several mentioned product managers they had that were ex-developers were the best they've had. And that nontechnical ones just couldn't understand. This for example: reddit.com/r/ExperiencedDevs/comments/17z8fnp/how_to_deal_with_nontechnical_pms/.
In my experience, the PM did not have the level of detailed thinking required to make clear tickets so I constantly had to ask for clarifications. Not saying they are all like that, but just that being a dev forces you to think in detail which is crucial as a PM.
I have a friend who worked at a startup and his PM was a former dev who switched after burning out. In the same startup I believe. For those devs looking to break into a PM role, a startup or your current company may be willing to give you a chance. Make sure you learn the ropes through a senior PM before you switch or have one to guide you after.
Take a look at Marty Cagan's writing, especial "Inspired". I'm not sure where you're pulling these examples from, but this is textbook bad Product Management. No one in the PM field is advocating for separating engineers and customers, or treating PMs as ivory tower, context-free roles.
I have empowered and inspired in my backlog, maybe it’s time I have them a go 😅
I don’t think product people want it to be that way. The examples are from my own experience and those of my friends - almost of us experience the same reality.
I enjoy this text a lot! It resonates with a mindset that I push engineers towards. Get closer to product and learn how to influence them. Focus more on WHAT instead of only HOW. It can make a a difference between a good engineering and one that exceed expectations.
I completely agree with the Product Engineer view.
Many times products assume something can be done easily because they lack the engineering knowledge, so they push it. They waste days writing papers and then days fighting over it with the team leaders.
Unfortunately, in my experience, the PM manager is fighting for the CS against the team leaders to push features through. That absurd and it's an insane waste of time and money.
Perhaps a better approach is to put the engineers on the call with the customer and send them to the field to understand how things are managed out there. That way the engineers and product can work together to make the customer happy :)
“Perhaps a better approach is to put the engineers on the call with the customer and send them to the field to understand how things are managed out there.”
For sure! I completely agree this is the right path forward for most businesses.
Great article. I am senior product manager in payments and I have been thinking about product engineering approach for a while. Do you have any suggestions how would it be possible for “business” PM move to product engineering side? How to start to dive deeper into engineering side of a project for someone with 10+ experience in payments and finance?
Honestly, I can mostly advice for people doing it the other way around (engineering desiring to understand the product part), as I've never been in your shoes.
I think the best way is to get your hands dirty. I would choose a single language/framework the team you work with uses, and do a beginner course in it. Then I would start to ask engineers to explain a bit deeper what they work on, and write down terms you don't understand and research them later. When we (as engineers) see a PM that really wants to understand, we are usually happy to spend the time and explain.
I've seen just one PM try to bridge that gap from the other side, and he really dives deep into engineering concepts. He understands the DB structure and learned SQL (which can let you generate very interesting insights in the BI parts), and the conversations with him are on a much more technical level.
When I stepped into the PM role at Microsoft, my view of product management got a serious upgrade. We're not just talking PM here; we're talking PPM – Product and Program Management. This is where the game changes.
A product isn't a lone wolf; it's a piece of a larger puzzle, blending customer needs with business goals.
Over two years, I built five teams and onboarded several PPMs. One pattern emerged crystal clear: the most exceptional PMs had roots in software engineering. This background granted them a holistic vision, blending tech debt, customer needs, and business imperatives into a cohesive strategy.
That’s one type of PMs I saw succeed (and most enjoyed working with). The other type comes from the industry, with a great understanding of what the product aims to solve, and gives a lot of freedom to the engineering manager.
I am a p.m. and I have never had a job where I made decisions without consulting engineers. That might be because I have a background in agile and we have a lot of discussion about work before we plan to do it but you’re experiencing this. This is a clear indication that the leadership in your company does not know what they’re doing. Sorry not sorry.
It's not just about consulting - it's about engineers being part of deciding WHAT to do. Maybe it worked well in your case, but what I've experienced is not unique to my company.
Consulting is a loose term that I use to explain a very complex process in which engineers receive product intake request that are highly scrutinized before they can even make it in front of the special board of software engineer, database and engineers and infrastructure architects. That came about because people kept making promises to customers that we could not deliver on. Also, product manager should be able to be objective. This really fails when you have a product team that’s more aligned to customer success, and customer management than technology and engineering. It also fails when you have developers that do not want to go to meetings. How can we ask you what to build if you don’t want to talk about it So there’s that. It’s all about communication and process. Product manager shouldn’t be just throwing the greatest idea at you and there should be interaction from the time that the idea is vetted for profitability or sustainability of an application to the point where it’s fully built.
I think that if they are neither, they should at least AIM to be close to one of them. Try to learn the basics of coding and software architecture, or learn the ins and outs of the industry.
I spent about ten years working on a team with a setup similar to your suggestions, with a range of product owners. For the most part, it worked really well.
Our setup:
I was working developing software for mostly internal customers in a fairly complicated domain (scientific research). Our developers can from quite a range of backgrounds, some from the traditional CompSci backgrounds, but a large portion with lab experience at some part of their distant past.
The PO was external to the team, and was a domain expert. Their aim was to represent the needs of the organization and would then work closely with developers to set priorities. They were usually one of our stakeholders, but things typically worked best when they were a step removed, as it would reduce conflict of interest. They would do very little in terms of requirements gathering, but would quite often help in steering the conversation to help define the MVP.
The main strengths of this process were building up excellent domain knowledge in the developers. It also built strong customer relations, which really helped when speccing out new features. We actually sat in the same room as the majority of our users, which sounds like it should be horrific, but worked remarkably well. Just as we came to understand our stakeholder and user needs well, our users came to understand more about the development process.
None of our product owners were 'professional' product owners, and they definitely had variable skills when it came to understanding the development process. That didn't stop some of them being absolutely fantastic - and those who lacked the skills were generally happy to delegate to those who did.
Also, not having a dedicate role meant we occasionally dealt with the 'absent product owner', which could mean needing to guess a bit as to priorities.
Thanks for sharing James. That indeed sounds like a good setup to me - the guessing and ‘hole filling’ part has some advantage, as developers have no option but be more involved in the process.
The domain-expert part is what I’m missing the most. From my experience, the domain experts are never in the Product organization, and almost never in direct contact with the developers.
There is certainly variability in PMs just like any discipline, but the lack of a degreed qualification as PM I think is the crux of the problem. I think people do end up focused on a few dimensions naturally already - the B2B vs B2C is a common divide. Beyond that, the business metrics are pretty universal and can be applied everywhere.
The key to a lot of success in the role is around getting feedback and effectively communicating - and making the right judgement calls. Know that people are there to help you though. The PM role builds community when done well and learns from it; acts on its behalf. That's exactly why we built out Korl, so that the PMs can work on the human part of community and let AI do the rest!
In my opinion, it's about clearer definition, processes and expectations. When the success at the job is based solely on character traits and personal intuition, it's bad for the organization.
Another great way is to get your engineers involved in customer calls and user research as much as possible. This makes them aware of the problems and helps them to think from a product perspective as well
Exactly!
Any suggestions for convincing engineers that they should be apart of those conversations? I don’t think mine want to be that creative .
Haha I struggle with this too. I always let them know about all the customer calls and user research I’m involved in and ask them who wants to come be a fly on the wall. Generally 1-2 always volunteer. Sometimes none. Obvs I can’t force them but they’re aware and based on their time schedule and need to basis will show up accordingly.
This is a paradigm shift. I've held the same opinion based on my short experince of 1 year as a dev (haha), and what I've read others on reddit saying. Several mentioned product managers they had that were ex-developers were the best they've had. And that nontechnical ones just couldn't understand. This for example: reddit.com/r/ExperiencedDevs/comments/17z8fnp/how_to_deal_with_nontechnical_pms/.
In my experience, the PM did not have the level of detailed thinking required to make clear tickets so I constantly had to ask for clarifications. Not saying they are all like that, but just that being a dev forces you to think in detail which is crucial as a PM.
I have a friend who worked at a startup and his PM was a former dev who switched after burning out. In the same startup I believe. For those devs looking to break into a PM role, a startup or your current company may be willing to give you a chance. Make sure you learn the ropes through a senior PM before you switch or have one to guide you after.
One of the PMs I mentioned did exactly that - he was a developer on a team and became a PM of it, and was great at his job.
Take a look at Marty Cagan's writing, especial "Inspired". I'm not sure where you're pulling these examples from, but this is textbook bad Product Management. No one in the PM field is advocating for separating engineers and customers, or treating PMs as ivory tower, context-free roles.
I have empowered and inspired in my backlog, maybe it’s time I have them a go 😅
I don’t think product people want it to be that way. The examples are from my own experience and those of my friends - almost of us experience the same reality.
We are not alone in that too: https://www.reddit.com/r/programming/comments/192fv76/product_management_is_broken_a_change_is_coming/
I’m not sure why the common-sense methods are so different from the reality
Great piece Leonardo!
Thank you Akaash! The credit definitely goes to Anton though :)
This was an enjoyable read
Thank you!
PMs owning sales numbers is great idea
Great read @Anton Zaides!!
Thanks Sarah!
I enjoy this text a lot! It resonates with a mindset that I push engineers towards. Get closer to product and learn how to influence them. Focus more on WHAT instead of only HOW. It can make a a difference between a good engineering and one that exceed expectations.
Thanks Dani!
I completely agree with the Product Engineer view.
Many times products assume something can be done easily because they lack the engineering knowledge, so they push it. They waste days writing papers and then days fighting over it with the team leaders.
Unfortunately, in my experience, the PM manager is fighting for the CS against the team leaders to push features through. That absurd and it's an insane waste of time and money.
Perhaps a better approach is to put the engineers on the call with the customer and send them to the field to understand how things are managed out there. That way the engineers and product can work together to make the customer happy :)
Thanks for the great article Anton!
“Perhaps a better approach is to put the engineers on the call with the customer and send them to the field to understand how things are managed out there.”
For sure! I completely agree this is the right path forward for most businesses.
Great article. I am senior product manager in payments and I have been thinking about product engineering approach for a while. Do you have any suggestions how would it be possible for “business” PM move to product engineering side? How to start to dive deeper into engineering side of a project for someone with 10+ experience in payments and finance?
Thanks Piotr.
Honestly, I can mostly advice for people doing it the other way around (engineering desiring to understand the product part), as I've never been in your shoes.
I think the best way is to get your hands dirty. I would choose a single language/framework the team you work with uses, and do a beginner course in it. Then I would start to ask engineers to explain a bit deeper what they work on, and write down terms you don't understand and research them later. When we (as engineers) see a PM that really wants to understand, we are usually happy to spend the time and explain.
There are probably some resources online, this looks like a nice article: https://medium.com/@aHev/software-architecture-for-product-managers-c3223a15be19
And this short course might be useful:
https://www.udemy.com/course/technology-for-product-managers/
I've seen just one PM try to bridge that gap from the other side, and he really dives deep into engineering concepts. He understands the DB structure and learned SQL (which can let you generate very interesting insights in the BI parts), and the conversations with him are on a much more technical level.
Thanks Anton for this insight. I will try.
When I stepped into the PM role at Microsoft, my view of product management got a serious upgrade. We're not just talking PM here; we're talking PPM – Product and Program Management. This is where the game changes.
A product isn't a lone wolf; it's a piece of a larger puzzle, blending customer needs with business goals.
Over two years, I built five teams and onboarded several PPMs. One pattern emerged crystal clear: the most exceptional PMs had roots in software engineering. This background granted them a holistic vision, blending tech debt, customer needs, and business imperatives into a cohesive strategy.
That’s one type of PMs I saw succeed (and most enjoyed working with). The other type comes from the industry, with a great understanding of what the product aims to solve, and gives a lot of freedom to the engineering manager.
I am a p.m. and I have never had a job where I made decisions without consulting engineers. That might be because I have a background in agile and we have a lot of discussion about work before we plan to do it but you’re experiencing this. This is a clear indication that the leadership in your company does not know what they’re doing. Sorry not sorry.
It's not just about consulting - it's about engineers being part of deciding WHAT to do. Maybe it worked well in your case, but what I've experienced is not unique to my company.
Consulting is a loose term that I use to explain a very complex process in which engineers receive product intake request that are highly scrutinized before they can even make it in front of the special board of software engineer, database and engineers and infrastructure architects. That came about because people kept making promises to customers that we could not deliver on. Also, product manager should be able to be objective. This really fails when you have a product team that’s more aligned to customer success, and customer management than technology and engineering. It also fails when you have developers that do not want to go to meetings. How can we ask you what to build if you don’t want to talk about it So there’s that. It’s all about communication and process. Product manager shouldn’t be just throwing the greatest idea at you and there should be interaction from the time that the idea is vetted for profitability or sustainability of an application to the point where it’s fully built.
I agree about the balance of it, that it can't work without engineers willing to cooperate and invest the time.
From what I see and hear around me, the behaviour you outline is the exception and not the norm.
PM should either be an ex-engineers or an ex-customers.
That’s a nice summary :)
I think that if they are neither, they should at least AIM to be close to one of them. Try to learn the basics of coding and software architecture, or learn the ins and outs of the industry.
I spent about ten years working on a team with a setup similar to your suggestions, with a range of product owners. For the most part, it worked really well.
Our setup:
I was working developing software for mostly internal customers in a fairly complicated domain (scientific research). Our developers can from quite a range of backgrounds, some from the traditional CompSci backgrounds, but a large portion with lab experience at some part of their distant past.
The PO was external to the team, and was a domain expert. Their aim was to represent the needs of the organization and would then work closely with developers to set priorities. They were usually one of our stakeholders, but things typically worked best when they were a step removed, as it would reduce conflict of interest. They would do very little in terms of requirements gathering, but would quite often help in steering the conversation to help define the MVP.
The main strengths of this process were building up excellent domain knowledge in the developers. It also built strong customer relations, which really helped when speccing out new features. We actually sat in the same room as the majority of our users, which sounds like it should be horrific, but worked remarkably well. Just as we came to understand our stakeholder and user needs well, our users came to understand more about the development process.
None of our product owners were 'professional' product owners, and they definitely had variable skills when it came to understanding the development process. That didn't stop some of them being absolutely fantastic - and those who lacked the skills were generally happy to delegate to those who did.
Also, not having a dedicate role meant we occasionally dealt with the 'absent product owner', which could mean needing to guess a bit as to priorities.
Thanks for sharing James. That indeed sounds like a good setup to me - the guessing and ‘hole filling’ part has some advantage, as developers have no option but be more involved in the process.
The domain-expert part is what I’m missing the most. From my experience, the domain experts are never in the Product organization, and almost never in direct contact with the developers.
There is certainly variability in PMs just like any discipline, but the lack of a degreed qualification as PM I think is the crux of the problem. I think people do end up focused on a few dimensions naturally already - the B2B vs B2C is a common divide. Beyond that, the business metrics are pretty universal and can be applied everywhere.
The key to a lot of success in the role is around getting feedback and effectively communicating - and making the right judgement calls. Know that people are there to help you though. The PM role builds community when done well and learns from it; acts on its behalf. That's exactly why we built out Korl, so that the PMs can work on the human part of community and let AI do the rest!
In my opinion, it's about clearer definition, processes and expectations. When the success at the job is based solely on character traits and personal intuition, it's bad for the organization.
do not agree completely here, so every unit in business has their defined role