Product Manager vs. Product Marketing Manager vs. Product Owner(damilolaa.xyz)
damilolaa.xyz
Product Manager vs. Product Marketing Manager vs. Product Owner
https://www.damilolaa.xyz/Product-Manager-vs-Product-Marketing-Manager-vs-Product-Owner
121 comments
Agreed. There's nothing like being in the field with real users.
Ideally, you don't just talk to them. You watch them work. Observe, and gather clues about what will serve their needs. And when people tell you what they think they want, don't assume that's the product spec; treat that also as an opportunity to listen to clues that will help you understand their needs.
The best products are designed around how people work, not necessarily what people say about how they work.
Ideally, you don't just talk to them. You watch them work. Observe, and gather clues about what will serve their needs. And when people tell you what they think they want, don't assume that's the product spec; treat that also as an opportunity to listen to clues that will help you understand their needs.
The best products are designed around how people work, not necessarily what people say about how they work.
[deleted]
> The best products are designed around how people work, not necessarily what people say about how they work.
This reflects a lot my experience: People actions >>>> People words.
This reflects a lot my experience: People actions >>>> People words.
i’m an in-house recruiter and discovered steve banks’ advice on my own. why would i be in an office where everyone who i might hire is outside of that building?
while there are problems with that assertion, hiring is largely serendipity. as an extrovert, serendipity for me is found while out and about.
while there are problems with that assertion, hiring is largely serendipity. as an extrovert, serendipity for me is found while out and about.
On a related note, it's really important to hire a solid PM and keep them on for the life of the product, or at the very least through major releases. I worked on a product where the PM got changed several times and it caused total havoc and pretty much killed the project dead as basically each new PM thought the previous direction was wrong.
Agreed. But would add: as a developer my least favourite thing has been Product Managers who keep the customers exclusively to themselves. Requirements inevitably have a technical component to them, and getting the end users and developers together in a room and talking to each other directly is invaluable. It's so important that it's actually a key requirement to taking a job for me.
Very true! Aside from all other benefits, bringing the Dev team to meet customers is highly motivating to everyone, including the customer
I have alternatively heard this distinguished as:
- UX Product Managers (close to users)
- Technical Product Managers (close to developers)
I've written about this a little bit here for the curious: https://alexpetralia.com/posts/2019/10/14/product-management...
- UX Product Managers (close to users)
- Technical Product Managers (close to developers)
I've written about this a little bit here for the curious: https://alexpetralia.com/posts/2019/10/14/product-management...
> Technical Product Managers (close to developers)
In my humble experience, I think the real value of a TPM is being the interface between management and technology. They're able to frame technical jargon in a way that the business can understand. i.e. Why we have to do this refactor? If we don't it will cost the company money. (contrive but you get the point)
In my humble experience, I think the real value of a TPM is being the interface between management and technology. They're able to frame technical jargon in a way that the business can understand. i.e. Why we have to do this refactor? If we don't it will cost the company money. (contrive but you get the point)
"Getting out of the building" in metmorphical send might give you view from people / customers you can visit. This is likely to be a biased sample, and unrepresentative of the true customer.
Running A/B tests is IMO, a good proxy, to understand customers unbiased binary views on feature changes, and objectively better.
Running A/B tests is IMO, a good proxy, to understand customers unbiased binary views on feature changes, and objectively better.
Talking to users lets you know what the problems are.
A/B tests let you know if you've solved the problem.
A/B tests let you know if you've solved the problem.
True!
A/B tests work only for features you've built. You don't get insight into what customers say they want, you only can observe if they like what you built or not.
There is a use case for both.
There is a use case for both.
I agree but how do you keep abreast of this best practice in times of COVID? Product Analytics might just be the life saver.
Product analytics may tell you what is happening, but they won't tell you why it's happening. To your question, I don't really have a good answer. From a B2B SaaS perspective, we try to complement analytics with a lot of video calls but that's not nearly as good as sitting next to people while they do the work.
Definitely not a replacement for watching people do their work but we've been using Cohere (https://cohere.so) to help us watch what our users are doing and how they're working.
It tells you what is happening that is easy enough to track and measure. Most empiricism in the business world is poser empiricism, people want to say they are "data-driven" because that is virtuous in our current culture but when push comes to shove no one wants to invest the time to do it properly.
Zoom, teams, etc. You can still talk to customers, and they can still show you what they are doing, and what they might need.
> the key thing a product manager has to do is get out of the building.
Well, no, that's the sales job. First being a product manager is different in every company. And second there is a lot of differences depending of the type of business you are working in.
For example if you work in Saas b2b enterprise you can easily be a very good product manager and almost never meet the customers nor the users [1], because that's not what is important for the business.
On the contrary if you work in Saas b2c, talking (or doing surveys) to customers is crucial. So I would say that your advice apply well to B2C, in which there is no sales people
[1] https://blog.luap.info/product-management-in-saas-b2b-enterp...
Well, no, that's the sales job. First being a product manager is different in every company. And second there is a lot of differences depending of the type of business you are working in.
For example if you work in Saas b2b enterprise you can easily be a very good product manager and almost never meet the customers nor the users [1], because that's not what is important for the business.
On the contrary if you work in Saas b2c, talking (or doing surveys) to customers is crucial. So I would say that your advice apply well to B2C, in which there is no sales people
[1] https://blog.luap.info/product-management-in-saas-b2b-enterp...
No, sales goes to the customer when you have a product to sell. The product manager need to go to the customer to understand what they need, and what product needs to be created.
I would say 1 salesperson in 20 has the ability, interest and influence to alter a product roadmap. The other 19 exist because of their competitive drive and ability to bang their head against a wall without losing enthusiasm.
In my experience 100% of salespeople will try to influence the product roadmap if it means they can sign a new deal
Yes. “What can I promise on the roadmap to close this deal?” is very different than “What is best for the roadmap?”
You can’t trust a salesperson to think about the broader good when half their comp is tied to specific deals.
You can’t trust a salesperson to think about the broader good when half their comp is tied to specific deals.
Usually any impact a salesperson has over the product roadmap is too slow to have any impact on the sales opportunity.
Salespeople usually have more influence on the customers than on the roadmap, so they're better of trying to influence the decision making of the customer, than the product.
Salespeople focus on their sales targets, trying to change a product roadmap is not a very effective way to reach short term targets.
Obviously, a product manager should reach out to sales to try and understand their perspective on the product and the customer needs.
Salespeople usually have more influence on the customers than on the roadmap, so they're better of trying to influence the decision making of the customer, than the product.
Salespeople focus on their sales targets, trying to change a product roadmap is not a very effective way to reach short term targets.
Obviously, a product manager should reach out to sales to try and understand their perspective on the product and the customer needs.
Depends on the company. I worked for a small company that was a real clown show. Sales would come down to the engineering area and say things like "I just closed a huuuuuuge sale for the company. We need a product that does A, B, and C, now so we can deliver it!" And, that became engineering's scope for the next 4 weeks...
Hey, I also worked at this company! (and left after 6 months)
I’ve been at similar though 4 weeks would have been generous.
It would be 4 weeks because Sales told the customer that A, B, and C were already part of the product.
Yes small companies commonly works like this. Basically, they hustle sales and the development team needs to cover for them.
If your product is B2B enterprise then your end users' delight at your UX might not matter very much, but you definitely want to understand the decision makers' interest in getting additional reporting/auditing tools and how much value [if any] they get from their staff being more accurate in using the tool...
The issue is most of the time the decision maker has no clue about that. In B2B enterprise the product is not a big part of the decision to buy or not.
The decision maker is usually someone in the C-suite or a little below it who cares very much about whether the system gives them the reports they asked for, whether it ticks all the boxes on the operations plan someone drew up for them, whether middle management are frequently complaining about errors, how much resource is needed to switch from service Y etc.
That's a different product focus from the end user (who probably finds the new operations checkboxes demanded by the decision maker a horrible pain) and instead of actually using it, their perception will be shaped by middle management feedback and some claims made by the enterprise salesperson about how much money their business can save from staff being able to complete X faster or Y being shared, but it very much is a product based decision. Otherwise the lowest bidder (or at least the lowest bidder with an SLA) or incumbent would win every time.
That's a different product focus from the end user (who probably finds the new operations checkboxes demanded by the decision maker a horrible pain) and instead of actually using it, their perception will be shaped by middle management feedback and some claims made by the enterprise salesperson about how much money their business can save from staff being able to complete X faster or Y being shared, but it very much is a product based decision. Otherwise the lowest bidder (or at least the lowest bidder with an SLA) or incumbent would win every time.
This is an outdated stereotype about enterprise buyers.
That reminds me of the time I was heading the Product Management department of a large company. We had so many discussion about what a Product Owner, Manager, Technical Product Manager is. Their role. Their responsibilities. Endless discussion with much feelings involved about respect, ownership and so on. Nowadays I am convinced that a great company just doesn't need any PMs. It is way better to empower the tech and UX people. They have to have the ownership, the product role should be filled by one the people building things. There is no need for another role in my opinion and creates more discussions than necessary. It also reduces the ownership of other roles. My 2c at least.
The challenge I've had with that model is that as a company gets more complex, having someone whose sole job is to focus on the business <> technology interface is invaluable as people start to specialize. It's often more valuable to have engineers with (say) 6/10 expertise in the business and 10/10 expertise in their technology domain, working alongside PMs with 10/10 expertise in the business and 6/10 expertise in the technology. It's simply very hard to be 10/10 in both domains.
I agree that PMs are largely overhead in the early days of a company, provided that you have strong product-minded engineers/designers.
(Also just my 2c from heading a PM department / being a former engineer)
I agree that PMs are largely overhead in the early days of a company, provided that you have strong product-minded engineers/designers.
(Also just my 2c from heading a PM department / being a former engineer)
Not intended as a rhetorical question, can you describe the dynamics of a long-term successful team where the PM had more business expertise than the engineer?
I agree with the division of labor you describe, in principle, but I've never had the opportunity to observe it in practice. Maybe I've only worked at places that are not old + big enough yet.
In the (relatively few!) teams I've known, the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up.
I agree with the division of labor you describe, in principle, but I've never had the opportunity to observe it in practice. Maybe I've only worked at places that are not old + big enough yet.
In the (relatively few!) teams I've known, the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up.
I work in an area like this. I'm in the automotive space where there's just a whole slew of industry knowledge to stay on top of; both business practices that change frequently as well as regulatory information.
It's pretty rare to see engineers that know the industry as well as the PMs, so we focus heavily on having good communication and dedicating time to make sure features are well understood before any work starts. Our structure works well for us, but I can definitely see how it would be advantageous, where possible, to have engineers who knew more about the business.
It's pretty rare to see engineers that know the industry as well as the PMs, so we focus heavily on having good communication and dedicating time to make sure features are well understood before any work starts. Our structure works well for us, but I can definitely see how it would be advantageous, where possible, to have engineers who knew more about the business.
Hey good q. I work in enterprise SaaS and our team builds a fairly complex product. We have a range of technical and non-technical users within a given account, who use our product in different ways, and we have accounts that range in size from dozens to hundreds of thousands of employees with the differences in terms of usage patterns and needs that you'd expect. We also operate at high scale so our engineers need to know a lot about distributed systems and the integrations that our product has with other vendors/platforms/etc. We aren't unique in any of this from my experience.
(sorry for being somewhat vague but I try to keep this account anonymous!)
It's simply too much for our engineers to spend time deeply understanding every nuance of our business ("how should we make this product tradeoff between the needs of SMBs in Asia vs. the needs of our largest 10 customers across all countries? How will this then impact our pricing strategy?"). But PMs have more context here, because in exchange they don't (for example) know every nuance of how our data pipeline works.
In terms of how we make it work, we 1. try really, really hard to align incentives between Eng/PM so that they win together, 2. make sure that teams work together closely and have time to bond, and 3. write things down in planning docs as much as possible, as that's one of the best ways to reduce conflict and also fully leverage non-overlapping expertise.
"the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up."
That's rough... those don't sound like good PMs to me fwiw.
What I have seen are cases where very senior engineers have a better grasp of the overall product vision than some PMs, due to experience and tenure. But they usually don't have more expertise in all of the business questions simply due to relative lack of time spent in that domain.
***
All of this isn't to say that engineers don't need to know about the business, or that it isn't a huge advantage if they do (it is). Just that there are so many hours in the day and eventually you've gotta get some division of labor.
(sorry for being somewhat vague but I try to keep this account anonymous!)
It's simply too much for our engineers to spend time deeply understanding every nuance of our business ("how should we make this product tradeoff between the needs of SMBs in Asia vs. the needs of our largest 10 customers across all countries? How will this then impact our pricing strategy?"). But PMs have more context here, because in exchange they don't (for example) know every nuance of how our data pipeline works.
In terms of how we make it work, we 1. try really, really hard to align incentives between Eng/PM so that they win together, 2. make sure that teams work together closely and have time to bond, and 3. write things down in planning docs as much as possible, as that's one of the best ways to reduce conflict and also fully leverage non-overlapping expertise.
"the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up."
That's rough... those don't sound like good PMs to me fwiw.
What I have seen are cases where very senior engineers have a better grasp of the overall product vision than some PMs, due to experience and tenure. But they usually don't have more expertise in all of the business questions simply due to relative lack of time spent in that domain.
***
All of this isn't to say that engineers don't need to know about the business, or that it isn't a huge advantage if they do (it is). Just that there are so many hours in the day and eventually you've gotta get some division of labor.
Thank you for the super detailed response! It's illuminating.
For the product you're describing, it seems the division of labor is a no-brainer and highly-productive.
It seems there is a spectrum of maturity/complexity (correlated with age and scale), and depending on where your product falls along that spectrum, it either makes sense to have a PM "role", or not.
Additionally, it appears that the domain-relevant experience of the PM is a big factor. If a company is hiring to fill an org chart, rather than hiring to fit an expertise gap, it's more likely to end up with PMs in the scenario I describe. I suspect this is also correlated with age and scale.
Finally, I guess there are orgs that expect PMs to be (or become) business domain experts and orgs that expect PMs to be highly-educated secretary-task-masters, and these expectations weight the outcome.
In any case, thank you for sharing your experience, this was a very interesting snippet of insight!
For the product you're describing, it seems the division of labor is a no-brainer and highly-productive.
It seems there is a spectrum of maturity/complexity (correlated with age and scale), and depending on where your product falls along that spectrum, it either makes sense to have a PM "role", or not.
Additionally, it appears that the domain-relevant experience of the PM is a big factor. If a company is hiring to fill an org chart, rather than hiring to fit an expertise gap, it's more likely to end up with PMs in the scenario I describe. I suspect this is also correlated with age and scale.
Finally, I guess there are orgs that expect PMs to be (or become) business domain experts and orgs that expect PMs to be highly-educated secretary-task-masters, and these expectations weight the outcome.
In any case, thank you for sharing your experience, this was a very interesting snippet of insight!
No problem! A colleague and I actually write a lot about these types of topics (link in bio) if you're curious.
A few quick reactions:
"It seems there is a spectrum of maturity/complexity (correlated with age and scale)"
100%, I don't think that early stage companies really need PMs, and IMO PMs at early stages can be actively harmful by causing overhead / trying to make themselves useful and failing. At early stages the founders/engineers/designers/even some sales or support people should fill the necessary parts of product management. Product management at this stage can be more like a set of activities that produces good decisions, rather than a formal department.
(Fwiw the company I work at has many hundreds of employees)
"there are orgs that expect PMs to be (or become) business domain experts and orgs that expect PMs to be highly-educated secretary-task-masters"
Yeah, the latter is kind of terrible I think. If you need secretaries or task masters you should probably hire engineers/designers (and management) that can keep the trains running on time or set up mgmt processes to do so automatically. PMs ideally only get involved in project management because they have the skills and they're incentivized by outcomes to roll their sleeves up when needed, not because it's part of their core job.
Good PMs also don't want to primarily do admin project management work, so (to bring it all back to your first comment) you'll end up with crappy PMs who are strictly less knowledgeable than your engineers.
A few quick reactions:
"It seems there is a spectrum of maturity/complexity (correlated with age and scale)"
100%, I don't think that early stage companies really need PMs, and IMO PMs at early stages can be actively harmful by causing overhead / trying to make themselves useful and failing. At early stages the founders/engineers/designers/even some sales or support people should fill the necessary parts of product management. Product management at this stage can be more like a set of activities that produces good decisions, rather than a formal department.
(Fwiw the company I work at has many hundreds of employees)
"there are orgs that expect PMs to be (or become) business domain experts and orgs that expect PMs to be highly-educated secretary-task-masters"
Yeah, the latter is kind of terrible I think. If you need secretaries or task masters you should probably hire engineers/designers (and management) that can keep the trains running on time or set up mgmt processes to do so automatically. PMs ideally only get involved in project management because they have the skills and they're incentivized by outcomes to roll their sleeves up when needed, not because it's part of their core job.
Good PMs also don't want to primarily do admin project management work, so (to bring it all back to your first comment) you'll end up with crappy PMs who are strictly less knowledgeable than your engineers.
As a PM who works with multiple scrum teams / products - I agree with this and I understand where OP's message comes from as well. While I work with 4 teams, my involvement in each team is dependent upon the product mindedness of the team. I take care of internal/external enablement, customer documentation, bargaining design bandwidth exclusively for all the cases, for a couple of teams, I call team leads into more than half of my customer conversations, product strategy discussions. I believe the team collectively can decide the best work item for them 80% of times without my inputs. Only when org strategy or market reactions change, we reset.
That being said, product mindedness is hard for engineering teams. 2 of the teams I work with, I am giving them inputs on every single feature they need to build. While I dislike doing this for every feature, its upto how the engineering leader envisions their team to function. For some, unless there are jira tickets, properly prioritized, with designs ready, they dont want to involve engineering teammates.
That being said, product mindedness is hard for engineering teams. 2 of the teams I work with, I am giving them inputs on every single feature they need to build. While I dislike doing this for every feature, its upto how the engineering leader envisions their team to function. For some, unless there are jira tickets, properly prioritized, with designs ready, they dont want to involve engineering teammates.
[deleted]
I agree but I don't think an individual can be 10/10 in both domains like you inferred. I think there will always be the need for a product person outside the engineers and developers.
This is a good comment, but It's easy to generalise one specific experience that works successful and mistakenly think it applies universally.
You may be right within your company, but I can offer an alternative anecdote.
I work at a company that makes energy trading risk management software. It's complicated and niche, and the customers are varied and have very different mindset to develops and testers. We have traders, hedge funds, energy generators and retail suppliers all with different use cases.
We absolutely need a product manager who has the time to dedicate to understanding the customers needs, understanding the changing landscape of the market and understanding the competition. This is not something we can just expect a developer or tech lead to do through ownership.
I'm certain your way works for many though.
You may be right within your company, but I can offer an alternative anecdote.
I work at a company that makes energy trading risk management software. It's complicated and niche, and the customers are varied and have very different mindset to develops and testers. We have traders, hedge funds, energy generators and retail suppliers all with different use cases.
We absolutely need a product manager who has the time to dedicate to understanding the customers needs, understanding the changing landscape of the market and understanding the competition. This is not something we can just expect a developer or tech lead to do through ownership.
I'm certain your way works for many though.
That is never, ever going to work. I do think some companies have too many PMs, but eventually there needs to be someone driving actual product development and making business & customer focused decisions, if not for an individual team then at least at one level above. If an engineer or designer is doing that then you are just wasting their skills.
I agree completely. I was a lead engineer on a product in a situation where we did not have a real product owner or a project manager. While I could manage the team and organize work, I struggled massively to come up with well defined and focused features for us to work.
I would spend lot of time talking with different customers and trying to move that into development, but I was losing so much time I could have spent solving serious technical problems.
Having a good product owner that sees the big picture and can write down a rough specification of features would have helped massively and allowed me to do what I do best.
On other hand, I was also in a situation where product owner depended on me to do his work. That is even worse.
I would spend lot of time talking with different customers and trying to move that into development, but I was losing so much time I could have spent solving serious technical problems.
Having a good product owner that sees the big picture and can write down a rough specification of features would have helped massively and allowed me to do what I do best.
On other hand, I was also in a situation where product owner depended on me to do his work. That is even worse.
I was a PM in a long ago prior life and, at one point, we decided to bring development managers into more customer meetings. It wasn't a bad idea but they had their "day jobs" so would end up being only in a few meetings. So it ended up as almost mirroring sales where the last customer they spoke with was taken as gospel and a blueprint for what we ought to be doing.
To one of the broader points, in both my personal experience and what I see software PMs doing in my current non-PM role, they spend a lot of time talking to customers.
To one of the broader points, in both my personal experience and what I see software PMs doing in my current non-PM role, they spend a lot of time talking to customers.
I worked in a role in healthcare for a few years where I was the lead engineer and sat in on most customer meetings, and even did some field observations. It was an invaluable experience. It was super useful for disabusing me of certain notions I had about which features mattered. I learned a lot about product work from the experience and started asking myself and the team different questions during the development process.
I got to see a broad swath of users with pretty different needs, and learned a lot about how their clinics worked. It was really good for thinking concretely about tradeoffs.
I got to see a broad swath of users with pretty different needs, and learned a lot about how their clinics worked. It was really good for thinking concretely about tradeoffs.
[deleted]
Perhaps it works at your organization. I've been a PM where engineers and UX had no sense of ownership nor business sense. A PM's role is to understand what is important, how to prioritize, how to validate ideas fast, and how to avoid the tail wagging the dog (the tail could be UX, tech or your VP). If you have engineers and UX folks who can do this, more power to you!
If the product is something engineers and UX use, then they'll probably _want_ to be a PM. If it's something they don't, you might need a PM.
Having worked in both situations, many times, I'm pretty sure this is the most underrated factor in success. Companies where the staff doesn't use the product are facing a huge uphill battle. Oftentimes, this is inevitable and I think the only solution is a huge salary premium - but more often than not, these are the companies on the lowest end of the pay spectrum (double whammy spells near certain failure).
Having worked in both situations, many times, I'm pretty sure this is the most underrated factor in success. Companies where the staff doesn't use the product are facing a huge uphill battle. Oftentimes, this is inevitable and I think the only solution is a huge salary premium - but more often than not, these are the companies on the lowest end of the pay spectrum (double whammy spells near certain failure).
> how to avoid the tail wagging the dog
Hahaha.
I once worked at a major telecoms equipment manufacturer. Our competition analysis group had two functions. One was to work out what our competitors were doing. But the really good people were tasked to find out what our engineering group was up to. Basically, they were powerful enough to do whatever they wanted, and screw the product managers and technical marketing folks who actually spoke to customers.
This company is basically no longer in existance.
Hahaha.
I once worked at a major telecoms equipment manufacturer. Our competition analysis group had two functions. One was to work out what our competitors were doing. But the really good people were tasked to find out what our engineering group was up to. Basically, they were powerful enough to do whatever they wanted, and screw the product managers and technical marketing folks who actually spoke to customers.
This company is basically no longer in existance.
This is a bit of a devil's advocate argument, but perhaps the reason engineering and UX didn't feel ownership was because you were the PM. Not you specifically of course, but if the role of PM exists, and the culture is such that the "business" outside of eng / design treats the PM as the owner, it's natural that the engineers and design folks won't feel empowered to take ownership themselves.
I can't imagine how that would work at my current company. It's an IoT startup, and the hardware, firmware, software, and operations timelines all have to be coordinated to deliver on a tight release timeline. I can't imagine developers also having to take on the requirement and dependency management on top of building the actual product.
I've also worked at places where the P*M level seemed to mostly get in the way and just serve as a middle-man and information degradation layer between design and engineering.
I've also worked at places where the P*M level seemed to mostly get in the way and just serve as a middle-man and information degradation layer between design and engineering.
That sounds like you had several people to do one person's job, not like it's a job that doesn't need to be done.
Solid UX people think like product people, but you either over-burden them, have them shift part of their roles off to others (research, user testing, etc),or do both jobs poorly. Good product people not also doing design, research, technical work, etc...they should be able to manage several teams / projects in a related area at once.
Solid UX people think like product people, but you either over-burden them, have them shift part of their roles off to others (research, user testing, etc),or do both jobs poorly. Good product people not also doing design, research, technical work, etc...they should be able to manage several teams / projects in a related area at once.
Yep.
This all sounds nice, but developers/designers rarely want to do PM work. The PM position is as much a creation of developers who don't want to interact as it is management.
Even developers that do don't want to spend all day in meetings. A PM can help there.
This all sounds nice, but developers/designers rarely want to do PM work. The PM position is as much a creation of developers who don't want to interact as it is management.
Even developers that do don't want to spend all day in meetings. A PM can help there.
I don't know--I think there are plenty of developers who would love to have more of a say in what they're building, rather than toiling away building someone else's pet feature that they (the developer) know is going to fail.
A lot of developers think that way, just like everyone else in their jobs, thinking they could do it better.
When they realize it's more soft skill oriented, endless meetings, power point deck after power point deck, stakeholder after stakeholder, and 1 hour left to code, they finally get the picture.
I was once that developer, thinking I knew what was best for everything. I scoffed at management and project managers. Now I know the real truth - their job is way harder than it seems.
When they realize it's more soft skill oriented, endless meetings, power point deck after power point deck, stakeholder after stakeholder, and 1 hour left to code, they finally get the picture.
I was once that developer, thinking I knew what was best for everything. I scoffed at management and project managers. Now I know the real truth - their job is way harder than it seems.
I think, you're right.
I'd even go as far as saying management roles aren't needed at all below the C-level.
The problem is that many companies already moved their engineers and designers away from the customer, and I think this model only works with small autonomous teams that talk direktly with customers.
Most engineers don't even want to talk with customers, they just want to solve what they think is the most important technical problem and be done with it.
I'd even go as far as saying management roles aren't needed at all below the C-level.
The problem is that many companies already moved their engineers and designers away from the customer, and I think this model only works with small autonomous teams that talk direktly with customers.
Most engineers don't even want to talk with customers, they just want to solve what they think is the most important technical problem and be done with it.
Exactly. That mirrors my experience. Devs start saying things like “go ask the PM, I just care about code quality”
There is the 'only so much time in the day' issue too. If you have millions (or even 1000's if they are high touch) of customers, you'll never be able to code if you're spending your time talking to them - and it will probably be required to develop specialized skills in talking to them too.
At some point, specialization has to happen. It also has drawbacks. Small teams are often dramatically more effective than large teams for similar reasons (ownership of the problem, less communication/education overhead), but they can only scale so far.
At some point, specialization has to happen. It also has drawbacks. Small teams are often dramatically more effective than large teams for similar reasons (ownership of the problem, less communication/education overhead), but they can only scale so far.
I tend to agree with you, but the hardest part is when it comes to making coherent decisions about priorities and direction. You've got to have an agreed upon way to set those priorities, otherwise it will just end up going to whoever the loudest person in the room tends to be.
I'm a big fan of the idea behind the Weighted-Shortest Job First approach but the trick is balancing the time investment to do it to the size of the decisions that warrant it.
I'm a big fan of the idea behind the Weighted-Shortest Job First approach but the trick is balancing the time investment to do it to the size of the decisions that warrant it.
> It is way better to empower the tech and UX people
And who empowers them if not the PM ? I mean in theory you could say that to get a product, you only need a designer and a developer. But you know the reality is different. This is not a hazard that most successful tech companies have PM (except Apple)
And who empowers them if not the PM ? I mean in theory you could say that to get a product, you only need a designer and a developer. But you know the reality is different. This is not a hazard that most successful tech companies have PM (except Apple)
Thanks for the comment! I know that I am putting something out here, which is definitely controversial. I was a PM myself for a long time...
To your question: I think it is the role of management to empower the devs and UX people. To your point about Apple: Isn't it amazing that one of the or even the most successful company on this planet doesn't have any PMs?
To your question: I think it is the role of management to empower the devs and UX people. To your point about Apple: Isn't it amazing that one of the or even the most successful company on this planet doesn't have any PMs?
One role of the PM is to close gaps between departments and make people work together toward the same goal. It is very hard for a manager to do the same thing. For a PM it is easier because he is not the boss of anyone and don't try to gain power over other's stuff. On the other side if a manager is trying to do the same thing, you will have other managers try to protect their department.
As for Apple, yeah they are one of the most successful of the planet, but the feedback I have, is that developers would love to have PM to work with.
The issue is not to have PM or not. Anyone company in the world understand the benefit of having a good PM. But a lot of PMs are shit and just make things worse.
As for Apple, yeah they are one of the most successful of the planet, but the feedback I have, is that developers would love to have PM to work with.
The issue is not to have PM or not. Anyone company in the world understand the benefit of having a good PM. But a lot of PMs are shit and just make things worse.
It's a little more nuanced. Apple doesn't just throw away the PMs and tell eng leaders "You just have to do that work". Their culture has baked in the whole "DRI" concept where a single individual is directly responsible for all aspects of the product, and has corresponding decision-making responsibility and accountability for its success or failure. In typical companies, when eng and PM disagree, the decision is often escalated up the management chain, to someone even less involved and clued in. With the "DRI" model, any conflict between eng and product needs is purely in the mind of one person, and gets resolved right there.
The tough part about doing this is when you hire engineers, you need to also interview for good product sense and have more emphasis on soft skills. Not easy to find.
The tough part about doing this is when you hire engineers, you need to also interview for good product sense and have more emphasis on soft skills. Not easy to find.
Huh? If you go to the apple jobs page and search for "product manager" it comes back with 600+ results in the US: https://jobs.apple.com/en-us/search?search=product%20manager...
An example, Apple Pay Product Manager: https://jobs.apple.com/en-us/details/200185069/apple-pay-pro...
An example, Apple Pay Product Manager: https://jobs.apple.com/en-us/details/200185069/apple-pay-pro...
The problem is that PM responsibilities require a vastly different skillset than engineers usually need. I completely agree with you, but these people are extremely rare. Also, technically this doesn't eliminate the role but it does eliminate the position.
There's tons of stuff i do as a product manager that neither tech nor ux will do:
* Finding new customer needs that are not yet covered by the product (new products, so not existing product),
* determining how a product might address that need,
* determining the alternatives, competing products, customers may choose,
* the (financial) risk of not addressing the need,
* the business case of creating a new team to implement this need product/capability,
* the pricing of said new product,
* determining what the key product features of the competition are that we need to address to be able to win deals when in competition,
* and what features are relevant according to gartner, to ensure we're part of the short-list of potential customers
* determine how to prioritize product releases and features to ensure we can win markets (think crossing the chasm).
* ...
* Finding new customer needs that are not yet covered by the product (new products, so not existing product),
* determining how a product might address that need,
* determining the alternatives, competing products, customers may choose,
* the (financial) risk of not addressing the need,
* the business case of creating a new team to implement this need product/capability,
* the pricing of said new product,
* determining what the key product features of the competition are that we need to address to be able to win deals when in competition,
* and what features are relevant according to gartner, to ensure we're part of the short-list of potential customers
* determine how to prioritize product releases and features to ensure we can win markets (think crossing the chasm).
* ...
I hate to say it, but "empowering tech" is usually an anti-pattern. Technical work is done in service to business needs. The role of Product is to bridge that gap. Both pushing the tech team to focus on the most valuable work and explaining outwardly why a tech team might need to focus on quality or refactors instead of delivering features. It could be the same person the same way someone can be a doctor and a pilot, you'd just have a very hard time finding enough people who can do it all.
How do 100 empowered tech and UX people build a coherent product?
Why do movies need a director? Screenwriters and actors and cinematographers and effects teams and all the rest are brilliant at their jobs.
Why do movies need a director? Screenwriters and actors and cinematographers and effects teams and all the rest are brilliant at their jobs.
Totally agree. I feel that product managers are the emperor’s new clothes.
Don't want to be mean but this is honestly a very simple article. This can be easily summarized as :
- A product manager's job is to decide how to build the product
- a PMM is to market it
- a PO is just a role inside a scrum team
I don't really agree with that, things are much more complex in reality, the PM and the PMM jobs is very different depending on the company you are working at.
If you want good content on the topic, there are these two blogs :
- https://www.lennyrachitsky.com/
- https://svpg.com/articles/
But they are very oriented toward B2C and B2B smb product management. If you want insights and are working in B2B enterprise, there is still not good resources on the topic, (I blog a bit about it, but not enough to be a reference)
- A product manager's job is to decide how to build the product
- a PMM is to market it
- a PO is just a role inside a scrum team
I don't really agree with that, things are much more complex in reality, the PM and the PMM jobs is very different depending on the company you are working at.
If you want good content on the topic, there are these two blogs :
- https://www.lennyrachitsky.com/
- https://svpg.com/articles/
But they are very oriented toward B2C and B2B smb product management. If you want insights and are working in B2B enterprise, there is still not good resources on the topic, (I blog a bit about it, but not enough to be a reference)
Capital equipment is even more barren in information.
It might be better said that there are sales, development, and operational aspects to product management. You can split this into a product owner, sales interface, and engineering interface. Or not.
Even b2b is very different depending on what the market is. If you have 10 customers, the marketing path is different than if you have 1000, or 100,000. The roles shift dramatically.
It might be better said that there are sales, development, and operational aspects to product management. You can split this into a product owner, sales interface, and engineering interface. Or not.
Even b2b is very different depending on what the market is. If you have 10 customers, the marketing path is different than if you have 1000, or 100,000. The roles shift dramatically.
All of that to transform developers and "software engineers" into stupid micro-managed monkeys, just good to write code.
The worse is the product owner. Sadly the management world did profite of the hype of scrum to add this bullshit job but just a reminder:. It goes against the original concepts of Agile!
In the original Agile the product owner is the customer, and the goal was to have the devs in direct contact with the customer. It is not supposed to be an employee, with some management level, that tell you what and in which orders things have to be done, because he or she knows better...
Now, the devs are more than even isolated from the customer by bullshit jobs in between. This is very sad...
The worse is the product owner. Sadly the management world did profite of the hype of scrum to add this bullshit job but just a reminder:. It goes against the original concepts of Agile!
In the original Agile the product owner is the customer, and the goal was to have the devs in direct contact with the customer. It is not supposed to be an employee, with some management level, that tell you what and in which orders things have to be done, because he or she knows better...
Now, the devs are more than even isolated from the customer by bullshit jobs in between. This is very sad...
Usually when I hear this sentiment from a developer, it's not because the developer has a burning desire to run customer surveys, analyze top support requests, document byzantine business process, sit in 100 meetings, etc, themselves. It's because the imagined alternative is that the developer just does whatever they feel like, which is not the reality.
I personnally appreciate someone making the rounds around all the stakeholders, booking meetings for me, finding who do I need to talk to to get a domain-specific answer, reporting to stakeholders on the progress, and more generally navigating the organization on my behalf. This stuff is just too time consuming to tackle on top of a development role, especially in a larger org.
note: we are a product organization, not consultants.
note: we are a product organization, not consultants.
I suspect customer as product owner works really well for consulting, imagine all the billable hours
Only if customer is someone like a government who doesn't care about getting a result.
If the customer cares, letting them flail and fail is recipe for heartbreak, unpaid bills, and lawsuits.
If the customer cares, letting them flail and fail is recipe for heartbreak, unpaid bills, and lawsuits.
Also, if I'm right, even in current Agile definitions, Product Manager is a customer facing role (Unlike the article comparison chart reads)
I don't agree that PO is a necessarily "bullshit job", because "the customer" is often a complex group with demands that need to be unified and prioritized. So there needs to be a standin for the that group in the dev team - that's the PO. As dev, I much rather have that be one person than a "comittee" of all the different customer aspects.
This was what I thought when I was an angsty engineer in early 20's, and I guess what motivated me to become a PM, where I realized it wasn't true.
Doing the PM job well -- being rigorous about the product, its goals, its strategy, customers, how it interfaces with the external world, and figuring out how to distill that down internally to empower your team -- takes as much intellectual horsepower as engineering. I had to stop writing code every day to realize how deeply complex and interesting the non-code world can actually be. A good example is the passage in "Superpumped" about how Travis Kalanik validated the idea for Uber with deep research. It's not just bullshitting through meetings.
I think the issue though is that, unlike eng, there is no obvious intellectual "floor" for PMs (equivalent of fizzbuzz for programming), so you've probably dealt with lots of bad, lazy, incapable ones.
Doing the PM job well -- being rigorous about the product, its goals, its strategy, customers, how it interfaces with the external world, and figuring out how to distill that down internally to empower your team -- takes as much intellectual horsepower as engineering. I had to stop writing code every day to realize how deeply complex and interesting the non-code world can actually be. A good example is the passage in "Superpumped" about how Travis Kalanik validated the idea for Uber with deep research. It's not just bullshitting through meetings.
I think the issue though is that, unlike eng, there is no obvious intellectual "floor" for PMs (equivalent of fizzbuzz for programming), so you've probably dealt with lots of bad, lazy, incapable ones.
There are so many messed up implementations of Product roles/jobs.
Agile/Scrum Alliance just has the concept of a Product Owner (it is the same thing as a Product Manager). This is OK.
SAFe breaks up the role in terms of PM and PO. This is not OK. SAFe is fake Agile and simply the application of 'agile' labels to top-down, waterfall ways of working.
If you have both a PM and a PO in your organisation, I'm afraid they've had a drink of the SAFe cool-aid.
One last thing... a Product Manager/Owner is NOT a Delivery Manager.
Product should be responsible for the What and Why, delivery/tech for the How, When, Who.
Agile/Scrum Alliance just has the concept of a Product Owner (it is the same thing as a Product Manager). This is OK.
SAFe breaks up the role in terms of PM and PO. This is not OK. SAFe is fake Agile and simply the application of 'agile' labels to top-down, waterfall ways of working.
If you have both a PM and a PO in your organisation, I'm afraid they've had a drink of the SAFe cool-aid.
One last thing... a Product Manager/Owner is NOT a Delivery Manager.
Product should be responsible for the What and Why, delivery/tech for the How, When, Who.
> Agile/Scrum Alliance just has the concept of a Product Owner (it is the same thing as a Product Manager).
It's not, really because, Scrum doesn't deal with product design.
It's not, really because, Scrum doesn't deal with product design.
As a PM at a large tech company, I often describe the value of my role as this: we pay engineers a lot of money for their specialized skills. It is great if they can meet with customers, but that can't be 50% of their time, or even 25%. Even worse, they should not be spending their time communicating to executives via slide decks, writing documents for the sales teams, meeting with lawyers, meeting with other teams to negotiate turf battles -- etc., etc. Big companies need PMs because someone has to do all the "stuff." Yes, in the course of doing it, the PM gains some power to set the product strategy and roadmap -- by virtue of being the nexus of all the information -- but this is almost always done in close collaboration with the engineering team anyway. It makes no sense to compete with other companies for valuable engineers who can actually create software and then use up their time doing things that I can do for them. Someone who used to write code but now manages all of the business isn't an engineer anymore, he or she is a former engineer who is now a PM (or an executive perhaps), regardless of the job title.
The difference between product manager and product owner is subtle enough that it doesn’t make too much difference in my experience. What’s a product owner at one company is a product manager at another and visa-versa.
The one with marketing in the title is about marketing rather than product management.
The one with marketing in the title is about marketing rather than product management.
For me the difference is stark.
At my last three companies it worked like this:
Product Manager is responsible for the product strategy and feature roadmap. They spend most of their focus on internal and external customers. They report up through Product leadership.
Product Owner is part of the engineering squad. They spend most of their focus on the engineers building the product. The PO works on refinement, prioritizes the backlog, runs the sprint planning and retros, and is the one who can decide if a sprint should be broken. They also keep stakeholders up to date on the progress of the squad. They report up through Technical leadership.
In my experience it is a rare person who can do both of these at the same time.
At my last three companies it worked like this:
Product Manager is responsible for the product strategy and feature roadmap. They spend most of their focus on internal and external customers. They report up through Product leadership.
Product Owner is part of the engineering squad. They spend most of their focus on the engineers building the product. The PO works on refinement, prioritizes the backlog, runs the sprint planning and retros, and is the one who can decide if a sprint should be broken. They also keep stakeholders up to date on the progress of the squad. They report up through Technical leadership.
In my experience it is a rare person who can do both of these at the same time.
I've been a Product Owner and been responsible for the product strategy, feature roadmap, backlog refinement and management of external stakeholders, reporting up through product leadership.
I've also been in a company that had "Product Managers" and "Product Owners", where "Product Manager" was just a more senior Product Owner, and the "Product Owners" reported into the "Product Managers".
All I mean is that - it's different things in different organisations, and what one company calls Product Owner another company will call Product Manager. If someone takes a job title saying "Product Owner" and expects that to mean they will definitely be reporting up through technical leadership, in the real world I think they will be surprised to find that's quite often not true :)
I've also been in a company that had "Product Managers" and "Product Owners", where "Product Manager" was just a more senior Product Owner, and the "Product Owners" reported into the "Product Managers".
All I mean is that - it's different things in different organisations, and what one company calls Product Owner another company will call Product Manager. If someone takes a job title saying "Product Owner" and expects that to mean they will definitely be reporting up through technical leadership, in the real world I think they will be surprised to find that's quite often not true :)
This is my experience as well. You must always ask for a detailed description for these roles.
I've even seen companies that have a role called "Product Manager Owner" with a vague enough description that it could be either or both.
I've even seen companies that have a role called "Product Manager Owner" with a vague enough description that it could be either or both.
> In my experience it is a rare person who can do both of these at the same time.
I'm one of those rare people. I do not recommend it.
While I love my product and believe in the company I work for, I've seriously considered leaving so I can actually focus on one thing or the other.
For what it's worth, I'm a former full stack developer who transitioned into the product role. This means I have the technical skillset to translate for my dev teams. This is a blessing and a curse while wearing both hats.
I'm one of those rare people. I do not recommend it.
While I love my product and believe in the company I work for, I've seriously considered leaving so I can actually focus on one thing or the other.
For what it's worth, I'm a former full stack developer who transitioned into the product role. This means I have the technical skillset to translate for my dev teams. This is a blessing and a curse while wearing both hats.
Threads on this topic pop up on HN every few months. To me seems pretty clear that in most companies the structure of the product team seems fundamentally broken. I feel very sad for people who do not see the value in having a PO or a PM on their team.
To use buzzywordy language, a PO is not supposed to micro manage the developers but to give them a framework and the freedom to move within it and to make sure the product is moving in a cohesive direction that makes it objectively "better", whether that is more sales or better customer satisfaction or whatever.
IMO The PM's role is to find that out and communicate the value of the product to the market and figure out how to do that.
I've worked at places where neither role existed and the developers led the show, this always resulted in actual customer needs getting ignored, massive misunderstandings on what issues were critical and which weren't, believing the customer was a high-income tech-savy 30 year old with a 15" MacBook Pro running Chrome.
If the companies customer is that, then great! But for most companies in the world that isn't the case.
To use buzzywordy language, a PO is not supposed to micro manage the developers but to give them a framework and the freedom to move within it and to make sure the product is moving in a cohesive direction that makes it objectively "better", whether that is more sales or better customer satisfaction or whatever.
IMO The PM's role is to find that out and communicate the value of the product to the market and figure out how to do that.
I've worked at places where neither role existed and the developers led the show, this always resulted in actual customer needs getting ignored, massive misunderstandings on what issues were critical and which weren't, believing the customer was a high-income tech-savy 30 year old with a 15" MacBook Pro running Chrome.
If the companies customer is that, then great! But for most companies in the world that isn't the case.
Product Marketing -> communicate to the market the value of the product built
Product Management -> determine from the market what product should be created, with what priorities, what releases
Pricing could be either Product Marketing, or Product Management, or both.
Product Management -> determine from the market what product should be created, with what priorities, what releases
Pricing could be either Product Marketing, or Product Management, or both.
Yeah. This is similar to my experience.
In my company we use product owner and PO as it’s less likely to be confused with project manager and PM.
There's manager in these tittles, but if any of them has any number of direct reports (or worst, if the devs are managed by any of these 'managers') you are doing something wrong.
A product manager is like a category manager in supply chain. It's not a people management position.
Depending on where your product is in its lifecycle, you need to rotate between all 3 activities. You shouldn't be doing the same thing all the time.
After a big build, I'll tell the engineering team, hey, the requirements are going to be fuzzy for a while. look the the engineering manager while I work on launching this thing w commercial teams, and figuring out what we should build next. when that's done, I'll tell the commercial team the same thing about my commercial support
After a big build, I'll tell the engineering team, hey, the requirements are going to be fuzzy for a while. look the the engineering manager while I work on launching this thing w commercial teams, and figuring out what we should build next. when that's done, I'll tell the commercial team the same thing about my commercial support
I served in all three roles, under many job titles. Every company uses these titles and roles differently, often based on the politics of the organization and whatever blog the hiring managers read this month. I won't miss it.
Sounds like a recipe for bureaucracy and ambiguous leadership. I can't imagine this ever working outside of a tech company with fat enough margins to keep 3 separate leads on an individual team.
Not really. I work in a device development company. We have a technical product manager (understand what the market and customers want), commercial product manager (aid sales to sell what we have and introduce new products commercially) and product development lead for each new product. Dev lead is typically full time on 1 product being developed. Product managers are typically cover a product line. All three roles are full time jobs and operate distinctly.
[deleted]
A very related difference is "Product Manager vs Project Manager". It may sound obvious to some, but I still encounter many people in the industry referring to Software Products as Software Projects, even though there are relevant ramifications when thinking in terms of Projects vs in term of Products.
I recently decided to dig into that discussion in my post: "Software Projects vs Software Products": https://www.romenrg.com/blog/2020/12/30/software-projects-vs...
I recently decided to dig into that discussion in my post: "Software Projects vs Software Products": https://www.romenrg.com/blog/2020/12/30/software-projects-vs...
ihmo
pm: "watch this" po: "this over that" pjm: "predict this"
I haven't much experience with pmms. What are they like?
For those who are interested in what I observed in working with these roles: https://dev.to/solidi/what-is-a-product-manager-anyway-3pc4
pm: "watch this" po: "this over that" pjm: "predict this"
I haven't much experience with pmms. What are they like?
For those who are interested in what I observed in working with these roles: https://dev.to/solidi/what-is-a-product-manager-anyway-3pc4
Product Management is a total joke, it's just MBAs trying to be relevant in the world of tech. They're nothing but middlemen that don't understand technology and impose administrative overhead on engineers.
I hate the co-opting of Product Owner as an actual organizational role. It makes no sense.
The idea within SCRUM is literal - PO is the owner of the product. His function is to prioritize features and user stories, bridging the gap between business and the development team to ensure value is being delivered. They don’t write stories. They don’t estimate tasks or manage the team at all. There is no need for tech-savvyness, and it’s not a full time job.
The “PO” role in tech has become a dysfunctional amalgamation of an engineering manager and a product manager, who can’t do either very well.
The idea within SCRUM is literal - PO is the owner of the product. His function is to prioritize features and user stories, bridging the gap between business and the development team to ensure value is being delivered. They don’t write stories. They don’t estimate tasks or manage the team at all. There is no need for tech-savvyness, and it’s not a full time job.
The “PO” role in tech has become a dysfunctional amalgamation of an engineering manager and a product manager, who can’t do either very well.
A possible extension to the article would be to also include the project manager and compare to the product owner. For many people, they are the same. For me, the focus of the two is completely different (process vs product).
Oh dear. Yet another article that reinforces conflicting messages and gives ammunition to whoever wants to be "in charge" of a product.
No. This is not the authoritative model. It's written like this is what the industry has settled on. But you can design whatever model that you want as long as you're clear on "who actually has buck stops here decision making and accountability over those decisions".
For Scrum adherants...
If you are using Scrum (many claim to be using it but are actually using some variant of ScrumFall), there is a Product Owner role who has "buck stops here" responsibility in the team. The PO does a lot of the "Product Manager" (with revenue/KPI responsibility) and "Product Marketing Manager" (positioning/value based on customers) also. If you are going to have separated out people (Prod Mgr, Prod Mkr, PO), you must designate that the PO has the "buck stops here responsibility" in the Scrum team, and relegate the others to stakeholder roles who hold the PO accountable.
For us, we've done away with the separate roles and said that Product Owners are Product Managers. They have "buck stops here" responsibility. Stakeholders hold them to principles by asking challenging questions: "Are you maximizing value?" -> show us the empirical evidence, etc.
>> The Product Manager >> "These individuals are often referred to as mini CEOs of a product. They conduct customer surveys to figure out the customer’s pain and build solutions to address it. The PM also prioritizes what features are to be built next and prepares and manages a cohesive and digital product roadmap and strategy."
This is the Product Owner role essentially. If you have a separate Product Manager from a Product Owner, they should definitely not prioritize what features should be built next. Maybe at a very high level they are identifying a market need and saying "Hey there's something here, team - next quarter please figure this out". The PO is responsible for the roadmap, backlog and maximizing the value of the work from the Scrum team. All the Prod Mgr can really do is to be a good stakeholder, do the research, give lots of good external market inputs to the PO and hold the PO accountable for delivering value.
>> The Product Marketing Manager >> "The PMM communicates vital product value — the “why”, “what” and “when” of a product to intending buyers. He manages the go-to-market strategy/roadmap and also oversees the pricing model of the product. The primary goal of a PMM is to create demand for the products through effective messaging and marketing programs so that the product has a shorter sales cycle and higher revenue."
Yes and no. Because the PO is so close to the product, speaking to customers, getting feedback from customers from rapidly delivering iterations (again, assuming you are using Scrum(TM) correctly, and not the bastardized "scrum" where devs are relegated to code monkeys), the product positioning/messaging/value propositions and pricing model will naturally emerge from the Scrum team. The PMM as a stakeholder is helping to figure out the go to market strategy, etc, and execute on it in their own agile team.
Again, I stress that each organization can do whatever it wants. I just don't enjoy it when articles like this are referenced to as evidence for why X person's role should have Y responsibility, etc. It's teamwork. Everyone takes responsibility.
No. This is not the authoritative model. It's written like this is what the industry has settled on. But you can design whatever model that you want as long as you're clear on "who actually has buck stops here decision making and accountability over those decisions".
For Scrum adherants...
If you are using Scrum (many claim to be using it but are actually using some variant of ScrumFall), there is a Product Owner role who has "buck stops here" responsibility in the team. The PO does a lot of the "Product Manager" (with revenue/KPI responsibility) and "Product Marketing Manager" (positioning/value based on customers) also. If you are going to have separated out people (Prod Mgr, Prod Mkr, PO), you must designate that the PO has the "buck stops here responsibility" in the Scrum team, and relegate the others to stakeholder roles who hold the PO accountable.
For us, we've done away with the separate roles and said that Product Owners are Product Managers. They have "buck stops here" responsibility. Stakeholders hold them to principles by asking challenging questions: "Are you maximizing value?" -> show us the empirical evidence, etc.
>> The Product Manager >> "These individuals are often referred to as mini CEOs of a product. They conduct customer surveys to figure out the customer’s pain and build solutions to address it. The PM also prioritizes what features are to be built next and prepares and manages a cohesive and digital product roadmap and strategy."
This is the Product Owner role essentially. If you have a separate Product Manager from a Product Owner, they should definitely not prioritize what features should be built next. Maybe at a very high level they are identifying a market need and saying "Hey there's something here, team - next quarter please figure this out". The PO is responsible for the roadmap, backlog and maximizing the value of the work from the Scrum team. All the Prod Mgr can really do is to be a good stakeholder, do the research, give lots of good external market inputs to the PO and hold the PO accountable for delivering value.
>> The Product Marketing Manager >> "The PMM communicates vital product value — the “why”, “what” and “when” of a product to intending buyers. He manages the go-to-market strategy/roadmap and also oversees the pricing model of the product. The primary goal of a PMM is to create demand for the products through effective messaging and marketing programs so that the product has a shorter sales cycle and higher revenue."
Yes and no. Because the PO is so close to the product, speaking to customers, getting feedback from customers from rapidly delivering iterations (again, assuming you are using Scrum(TM) correctly, and not the bastardized "scrum" where devs are relegated to code monkeys), the product positioning/messaging/value propositions and pricing model will naturally emerge from the Scrum team. The PMM as a stakeholder is helping to figure out the go to market strategy, etc, and execute on it in their own agile team.
Again, I stress that each organization can do whatever it wants. I just don't enjoy it when articles like this are referenced to as evidence for why X person's role should have Y responsibility, etc. It's teamwork. Everyone takes responsibility.
What will be the difference with a CTO?
They’re really all just different ways to say “sales person”.
sounds like your org doesn't understand what product really does
I don't want to be picky, but the job descriptions could be improved if they removed the gendered text. E.g. "PMMM: he manages the ..." --> "PMMM: they manage the..."
Project Manager is a manager, it's a role from a formal process (waterfall). Product Owner is not a manager, it's an agile role.
You can't compare them directly.
P.S. In real life PM/PO are almost the same -- as people usually don't care about following metodology. PM/PO is just a kind of team's boss.
P.S. In real life PM/PO are almost the same -- as people usually don't care about following metodology. PM/PO is just a kind of team's boss.
I'd say PO isn't so much involved in determining the "what" to build, they are moreso executing on it. engineering manager is more of the team's boss
I support 4 different software solutions each part of a different product team and each having their own product manager. PM is definitely not my boss, just an unnecessary middle man making the total cost of tech more expensive.
OK not in times of COVID but there has to be someone who actually talks to customers or potential customers in person and builds _qualitative_ opinions / insight into what really needs to be built and where the real opportunities are. And that’s not to knock analytics, surveys and various other forms of customer feedback ... it’s just if you’re not directly talking to customers product development becomes an echo chamber of unvalidated opinions about how the world works. And there’s always huge and surprising insights to be gained from direct communication with customers...
From there you have to sift out signal from noise and create product vision and priorities.
Doing this PM function well quickly becomes full time and conflicts with the job of being a PO and working closely with developers.