Product Manager vs. Product Marketing Manager vs. Product Owner
damilolaa.xyz
damilolaa.xyz
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.
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.
This reflects a lot my experience: People actions >>>> People words.
while there are problems with that assertion, hiring is largely serendipity. as an extrovert, serendipity for me is found while out and about.
- 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...
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)
Running A/B tests is IMO, a good proxy, to understand customers unbiased binary views on feature changes, and objectively better.
A/B tests let you know if you've solved the problem.
There is a use case for both.
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...
You can’t trust a salesperson to think about the broader good when half their comp is tied to specific deals.
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.
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.
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 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.
(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.
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!
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.
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.
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.
Thanks for writing this post and generating this discussion.
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.
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.
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 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.
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).
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.
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.
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.
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.
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'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.
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'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.
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)
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?
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.
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.
An example, Apple Pay Product Manager: https://jobs.apple.com/en-us/details/200185069/apple-pay-pro...
* 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).
* ...
Why do movies need a director? Screenwriters and actors and cinematographers and effects teams and all the rest are brilliant at their jobs.
- 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/
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)
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.
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...
note: we are a product organization, not consultants.
If the customer cares, letting them flail and fail is recipe for heartbreak, unpaid bills, and lawsuits.
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.
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.
It's not, really because, Scrum doesn't deal with product design.
The one with marketing in the title is about marketing rather than product management.
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 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 even seen companies that have a role called "Product Manager Owner" with a vague enough description that it could be either or both.
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.
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 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.
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 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...
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
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.
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.
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.