Principles for great product managers(reeve.blog)
reeve.blog
Principles for great product managers
http://reeve.blog/blog/principles/
91 comments
Hey folks, author here. I'd love feedback – I'm also happy to answer any questions and/or debate!
One of the hard things to get right when writing one of these "Tips for being a great X" is that they're usually written from the point of view of someone who is a clear leader in their field.
With some exceptions, the people who write this sort of article have the confidence (or presumption) to see themselves as ahead of the pack. It is rare to see articles like this written by teams of people who, in cooperation, balance tasks like product management, architecture, engineering, operations and customer success between them. And yet that is, imo, the best way to do it.
When I read and article like this advising the reader to do X to "their team" (in this case let your team get on with work), it falls into this category where the "how to be a great X" applies to a particular structure - where "X" is somehow in control of the rest of the team, rather than an equal participant.
With some exceptions, the people who write this sort of article have the confidence (or presumption) to see themselves as ahead of the pack. It is rare to see articles like this written by teams of people who, in cooperation, balance tasks like product management, architecture, engineering, operations and customer success between them. And yet that is, imo, the best way to do it.
When I read and article like this advising the reader to do X to "their team" (in this case let your team get on with work), it falls into this category where the "how to be a great X" applies to a particular structure - where "X" is somehow in control of the rest of the team, rather than an equal participant.
Have a mirror? Looks like site is already down.
Ugh, I'm on it!
I love Cloudflare for this kind of thing - it's free (at least for blog-sized sites), it's reasonably easy to configure and it automatically takes effect when you get an unexpected surge in traffic.
Thanks for the suggestion! I'm on Digital Ocean; I had to do a quick droplet upgrade to avoid the "hug of death" – I'll keep Cloudflare in mind!
Funny, I happen to have this open in another tab.
https://a16z.com/2012/06/15/good-product-managerbad-product-...
https://a16z.com/2012/06/15/good-product-managerbad-product-...
One of the greats! It's amazing how well "Good PM/Bad PM" has aged. =)
Wait, what aged poorly about it? I don't know if you meant that but the disclaimer at the top says it did:
>>Warning: This document was written 15 years ago and is probably not relevant for today’s product managers. I present it here merely as an example of a useful training document.
>>Warning: This document was written 15 years ago and is probably not relevant for today’s product managers. I present it here merely as an example of a useful training document.
I'm saying it's aged well! Despite the author's caveat, I think it's still accurate in a lot of ways.
Thanks for confirming. I skimmed it and I couldn't tell what he meant was no longer relevant; nothing seemed obsolete (in any obvious way to a non-PM like me). To his credit, it seems like he wrote the principles in a very general, abstract manner that didn't become dated with changing technology.
Love that post, although the "CEO of the product" title has never really resonated with me. A large difference between being a PM and an actual CEO is that both CEO lead via influence but the CEO has final authority. Day-to-day that's not a big distinction, but when sh*t really hits the fan it is a BIG difference :)
Sadly less applicable now with the explosion in the number of PMs accompanied by the responsibilities that developers haves ceded away to them.
Early in my career (~20 yr, and obviously ymmv maybe I just had good ones) product folks knew their business, customers, market, and the capabilities of the business as well or better than anyone else in the building. They could pull off the “ceo of the product” role well. Some of them were hard driving, others had more of a mr Rogers vibe and somehow always had on a sweater and a big mug of coffee in hand, but they made sure people around them understood what was to be built, why it was to be built, and had a “player coach” feel. These days every sub-project has a PM and there just isn’t the need for the PM of old anymore.
I see a lot of problems popping up in organizations that have someone trying to be the type of PM that their coworkers don’t expect them to be.
Early in my career (~20 yr, and obviously ymmv maybe I just had good ones) product folks knew their business, customers, market, and the capabilities of the business as well or better than anyone else in the building. They could pull off the “ceo of the product” role well. Some of them were hard driving, others had more of a mr Rogers vibe and somehow always had on a sweater and a big mug of coffee in hand, but they made sure people around them understood what was to be built, why it was to be built, and had a “player coach” feel. These days every sub-project has a PM and there just isn’t the need for the PM of old anymore.
I see a lot of problems popping up in organizations that have someone trying to be the type of PM that their coworkers don’t expect them to be.
dead
Getting: ‘Error establishing a database connection’
Here's the google cached version: http://webcache.googleusercontent.com/search?q=cache:z3YxCz4...
Back online, sorry about that, folks!
Partially covered under others but as someone who has worked with PMs as an engineer: be a power user. If you are working on a technical product you should be an expert end user of the product. You don’t necessarily need to know how the entire product works under the hood, but if you don’t understand the product well enough to be an expert you’re probably not going to make good product decisions
That only applies to certain types of products though. Many years ago I was a longtime product manager for mostly large computer systems. I was very familiar with how they worked at an architectural level. But other than getting a cast-off Unix workstation on my desk at one point, I wasn't a user of the systems at all--and being so wouldn't have been practical.
I guess I have a hard time understanding how you would answer “what” questions in that position other than simply doing what customers asked. If you really didn’t need to add any new features other than what customers directly asked for I can kinda see how it would work. But how would you know how to advise customers on workarounds/that they are using the product wrong, or a future product roadmap, if you can’t see the product from a customer standpoint?
I’m sure you could be an effective project manager in that position but to lead a product’s development without fully understanding how it’s used is a bit suspect to me.
>but to lead a product’s development
My guess is--haven't really been a PM for other types of products--is that the relationship between the PM and engineering is probably different. I would certainly never have considered that I "led product development." And, yes, I did bring in requirements both from customers directly and from sales and I worked closely with engineering on defining the product. But actually--remember that product development cycles of big hardware were relatively long--after the initial requirements and basic design were worked out for a given system model--there often wasn't a huge amount for me to do until closer to launch when a lot of selling/marketing/pricing/etc. tasks had to get done. (I tried to plan my longer vacations during the quiet periods.)
To be clear, I wasn't just sitting around for months at a time as I was usually handling multiple products and involved in exploring new areas.
>if you can’t see the product from a customer standpoint?
As far as customers are concerned, big systems have a lot to do with specs, features, pricing, upgradability, etc. (And the availability of software.) They're not even maintaining them themselves.
My guess is--haven't really been a PM for other types of products--is that the relationship between the PM and engineering is probably different. I would certainly never have considered that I "led product development." And, yes, I did bring in requirements both from customers directly and from sales and I worked closely with engineering on defining the product. But actually--remember that product development cycles of big hardware were relatively long--after the initial requirements and basic design were worked out for a given system model--there often wasn't a huge amount for me to do until closer to launch when a lot of selling/marketing/pricing/etc. tasks had to get done. (I tried to plan my longer vacations during the quiet periods.)
To be clear, I wasn't just sitting around for months at a time as I was usually handling multiple products and involved in exploring new areas.
>if you can’t see the product from a customer standpoint?
As far as customers are concerned, big systems have a lot to do with specs, features, pricing, upgradability, etc. (And the availability of software.) They're not even maintaining them themselves.
You brought up good points where for B2B and big corp type of product development requires different best practices. Also the politics from big corps or in B2B environments are very different than B2C. As simple as reviewing if you product via Google Analytics funnel can work for B2C, that may not apply vis-a-vis to B2B products. You can still use analytics to review, but usually the corporations are already focusing on another features and there is never enough time to revisit past products nor the budget to improve existing ones. Then, what does a PM should do?
Open source is also a somewhat different situation that I'm familiar with but not as a PM. Obviously it varies depending upon the degree to which the project overlaps the product, but a company may be more in the position of influencing a community than dictating a product roadmap.
Completely agree. The PM is there to help the team figure out what to build, and help them succeed in building it. They can do this in a number of ways: Being an expert on the product is "must have", but they also need to know the market, the needs of users/customers, the metrics, and more.
problem i have with PMs as an engineer is that very often they are both clueless about domain knowledge and about technology (or the state of the system they are working with). this is a very horrendous situation to be in both as PM and as an engineer working with a PM.
>5. Decisions, and what you prioritize, need evidence
This. In my experience PMs' features are driven by not evidence but "lets try this stuff out" and "hypothesis" causing a ball of mud on the engineering side to ship stuff fast to impress the stakeholders.
I don't generalise and I also have seen PMs to be brilliant - but is more an exception than the rule - some PMs I've worked with they had very strong analytical skills, engineering knowledge and domain knowledge + skin in the game - if a feature has turned out to be crap they have the guts to kill it
>5. Decisions, and what you prioritize, need evidence
This. In my experience PMs' features are driven by not evidence but "lets try this stuff out" and "hypothesis" causing a ball of mud on the engineering side to ship stuff fast to impress the stakeholders.
I don't generalise and I also have seen PMs to be brilliant - but is more an exception than the rule - some PMs I've worked with they had very strong analytical skills, engineering knowledge and domain knowledge + skin in the game - if a feature has turned out to be crap they have the guts to kill it
I think biggest problem is: not killing enough features. It goes let's try that stuff or some customer "really really needs this" but then no one uses that feature for 2 years. If I would have some PM that looks into stats and kills not used stuff it would be better.
Unfortunately mostly it looks that removing feature is negative value, firstly you already spend time/money building it, second removing is not free where leaving feature there seems like it is free. It is hard to explain that application maintenance costs more when we have bs features in code.
Unfortunately mostly it looks that removing feature is negative value, firstly you already spend time/money building it, second removing is not free where leaving feature there seems like it is free. It is hard to explain that application maintenance costs more when we have bs features in code.
Removing a feature can be a really negative experience for the users. If literally no one uses it, then that's ok, but if even just 0.01% use it, then removing it can break their faith in the product.
If instead you can spin the feature out into a plug-in/extension and possibly even open-source it, you'll do much better by your users.
If instead you can spin the feature out into a plug-in/extension and possibly even open-source it, you'll do much better by your users.
> problem i have with PMs as an engineer is that very often they are both clueless about domain knowledge and about technology (or the state of the system they are working with). this is a very horrendous situation to be in both as PM and as an engineer working with a PM.
I don't think the PM needs to be particularly knowledgeable about technology so long as they sanity check their ideas with engineering first. The roadmap needs to be the result of a conversation.
> >5. Decisions, and what you prioritize, need evidence
This is all I really want from a PM. When they set a certain priority to tasks, I want to see market research data, usability studies, customer testimony, a list of sales leads, revenue projections, etc.
I don't think the PM needs to be particularly knowledgeable about technology so long as they sanity check their ideas with engineering first. The roadmap needs to be the result of a conversation.
> >5. Decisions, and what you prioritize, need evidence
This is all I really want from a PM. When they set a certain priority to tasks, I want to see market research data, usability studies, customer testimony, a list of sales leads, revenue projections, etc.
Personally, I haven't got the time or energy to question the decisions or expertise of fellow team members. Nor do I have the interest to wade though sales projections and market research any more than they would want to wade through our codebase. An efficient organization is based on trust. I should trust in my PM's skills and diligence to do their research, and they should trust me to build what is needed. When it comes to prioritizing tasks, we can have an adult conversation about what should come first based on technical and non-technical considerations. If you don't trust your peers to do their job, the end result is micromanagement - which can work both ways.
> When it comes to prioritizing tasks, we can have an adult conversation about what should come first based on technical and non-technical considerations. If you don't trust your peers to do their job, the end result is micromanagement - which can work both ways.
Expecting people to be able to justify their decisions isn't micro-management. It's a perfectly adult, rational way to work together. If I want to (for example) change the underlying technology used to build a product or set aside some time to clean up technical debt, I need to justify (or at least be prepared to justify) that decision to my colleagues.
Expecting that I can rely on my positional authority over "technical" decisions to deflect questions or criticisms of my decision is a sign of a low-trust organization.
Expecting people to be able to justify their decisions isn't micro-management. It's a perfectly adult, rational way to work together. If I want to (for example) change the underlying technology used to build a product or set aside some time to clean up technical debt, I need to justify (or at least be prepared to justify) that decision to my colleagues.
Expecting that I can rely on my positional authority over "technical" decisions to deflect questions or criticisms of my decision is a sign of a low-trust organization.
> This is all I really want from a PM. When they set a certain priority to tasks, I want to see market research data, usability studies, customer testimony, a list of sales leads, revenue projections, etc.
Ok, I take it you're not a developer then!
Ok, I take it you're not a developer then!
Au contraire! I am a developer. As a developer, one of the biggest issues I've seen with product management is a constant shifting in product direction. Each time there are great power point slides defining a new product vision, but rarely ever is any justification for this new vision, nor do I often see evidence that the change increased revenue.
By requiring evidence for a particular prioritization, not only does that increase my confidence that what I'm working on will actually matter, but it makes changing the prioritization harder, and hopefully means that it will happen less often, and that perhaps I can actually ship something before the PM changes the vision (again).
By requiring evidence for a particular prioritization, not only does that increase my confidence that what I'm working on will actually matter, but it makes changing the prioritization harder, and hopefully means that it will happen less often, and that perhaps I can actually ship something before the PM changes the vision (again).
I think if you are building something extremely technical such as products for devs, or Fintech stuff, you have to understand some APIs just to know enough that you know what you are able to deliver.
Some level of technical competence is necessary, but not always as much as you might expect. For example, in designing an API, sequence diagrams and data payload definitions are things you can use to communicate the essential aspects of an API to less-technical PMs.
You're doing the Product Manager's job, in my opinion. They're the ones who have to justify to senior management why something is being done, and when. The devs really should just get on and do it once it's been agreed.
Nope, I'm not doing the PM's job. I'm not doing the market research or coming up with the product roadmap. I want the PM to justify to me the work they are asking me to do. I also want to have a productive conversation about the cost of what they are asking me to do (which I can articulate to some extent) and the value they expect it to return.
Involving devs after the roadmap has been decided is too late.
Involving devs after the roadmap has been decided is too late.
Why do you expect justifications? This is not the role of the dev.
I would say that as the PM role is one without actual power, you need to convince those who will be working on a problem to be convinced that what you're doing makes sense. With data backing them up, this makes your assumptions more trusted, and the team easier to convince.
I'm curious as to know what your PM's roadmaps look like, because really they shouldn't be listing features/implementation, but objectives and goals.
I agree though with what you're saying, regardless of the technical capacity of the PM, it's not really up for him to decide the capability of the teams, or the proposed technical solution. He should be managing those with the engineering teams, and their thoughts should be reflected on the roadmap.
I agree though with what you're saying, regardless of the technical capacity of the PM, it's not really up for him to decide the capability of the teams, or the proposed technical solution. He should be managing those with the engineering teams, and their thoughts should be reflected on the roadmap.
> 7. There is no such thing as over-communication
> Constant communication might feel like “fluff,”
if it feels like "fluff" it is fluff imo. And that's something that most incompetent PMs suffer from.
if it feels like "fluff" it is fluff imo. And that's something that most incompetent PMs suffer from.
Yup. Cover up your own lack of utility by talking non-stop, holding numerous meetings, and 'following up'.
hankchinaski(1)
Absolutely... but the best PMs I know absolutely hate meetings, and are constantly trying to clear them off of their plates. I've actually had PMs on my team specifically petition to remove meetings and replace them with emails, Slack checkins, or (my favorite) nothing.
It's all about aligning incentives. You need to reward PMs for getting stuff done, rather than looking busy.
It's all about aligning incentives. You need to reward PMs for getting stuff done, rather than looking busy.
We shouldn't mistake "communication" with "meetings" or "talking a lot." But, communicating more through the right channels is indeed very helpful. Maybe through more documentation, maybe on Slack, maybe through weekly/monthly updates emails that one can easily ignore, if needed, or maybe through more listening.
The reason I think communication is very important is that limited or incorrect / stale information is a very big problem for medium-large organizations (the kind of organizations that have PMs). Many times, poor or lack of sufficient communication is the foundational reason for other issues that we see regarding seemingly always changing priorities, decisions being made out of nowhere, etc.
The reason I think communication is very important is that limited or incorrect / stale information is a very big problem for medium-large organizations (the kind of organizations that have PMs). Many times, poor or lack of sufficient communication is the foundational reason for other issues that we see regarding seemingly always changing priorities, decisions being made out of nowhere, etc.
A good portion of people respond to overcommunication by simply tuning out all communication on that topic or from that source.
I think there are many different types of PM and the "Great Product Manager" you are referring to is the PM who owns an ongoing Product and who is responsible for some of the business goals.
I think most cases, including my own, the PM owns a sub feature of a major product, or they are somewhat like a mix of Project Manager. That is also different when you consider if you are dealing with B2C or B2B.
In B2B, the problem may be "automate this process" and there is not a lot to discuss or vision to communicate in that case.
Finally, your recommendations will change what is the best if you are dealing with organizations that are more engineering focus or marketing focus.
For example, leading your team suggestions may not apply if you don't have the control of the devs. They are just outsource team and your company's budget is limited. So keep pushing for vision and values may not work.
Another example, if a PM works in a Dev/Product shop, the decisions are usually decided by the client, not the PM; so in that case, what is the best may not apply. The PM can recommend and back it up, but then the final decisions are under the scope of the client.
Finally, I think the other sections such as Communicating Effectively, Being good operator and Running Effective Meetings are definitely good for every type of work, not only for PMs but I'd say any job.
I think most cases, including my own, the PM owns a sub feature of a major product, or they are somewhat like a mix of Project Manager. That is also different when you consider if you are dealing with B2C or B2B.
In B2B, the problem may be "automate this process" and there is not a lot to discuss or vision to communicate in that case.
Finally, your recommendations will change what is the best if you are dealing with organizations that are more engineering focus or marketing focus.
For example, leading your team suggestions may not apply if you don't have the control of the devs. They are just outsource team and your company's budget is limited. So keep pushing for vision and values may not work.
Another example, if a PM works in a Dev/Product shop, the decisions are usually decided by the client, not the PM; so in that case, what is the best may not apply. The PM can recommend and back it up, but then the final decisions are under the scope of the client.
Finally, I think the other sections such as Communicating Effectively, Being good operator and Running Effective Meetings are definitely good for every type of work, not only for PMs but I'd say any job.
I've been a PM for 25 years. All the principles in the article can be applied to all of the items you mention, when I'm the PM. I don't consider myself great, just experienced and willing to learn more all the time. In the past when I've seen things like this, if I don't agree with them I have gone to someone more experienced to see what they have to say about it.
> and there is not a lot to discuss or vision to communicate in that case.
Agreed. In those cases, I explicitly say as much when writing up the card. I say "We have no specs or mockups, but here is the need - make it happen." We typically start from there and have a few discussions to work through details, but I have zero problem letting my engineers be free to do their own jobs.
Agreed. In those cases, I explicitly say as much when writing up the card. I say "We have no specs or mockups, but here is the need - make it happen." We typically start from there and have a few discussions to work through details, but I have zero problem letting my engineers be free to do their own jobs.
I do exactly what you do. I write up the cards in Jira and then the devs will have further discussions from that point and beyond. They also feel validated and they do bring good ideas.
This is a great list of things product managers should do. Especially around managing time and how to do that effectively.
One of the things that makes this less overwhelming is flipping it on its head and thinking about what a product manager shouldn't do. Warren Buffett talks about this idea of "The Institutional Imperative" and what happens when you aren't aware of it and allow the defaults to run your work. It's a great complement to this article, I am sending out a post on Wednesday applying his idea to product management. productsolving.substack.com
One of the things that makes this less overwhelming is flipping it on its head and thinking about what a product manager shouldn't do. Warren Buffett talks about this idea of "The Institutional Imperative" and what happens when you aren't aware of it and allow the defaults to run your work. It's a great complement to this article, I am sending out a post on Wednesday applying his idea to product management. productsolving.substack.com
I look forward to reading that
I decided to push this one out a week and am publishing a piece on what we can learn about priming problems from GPT-3. Hope you like that one as well.
I became a PM last year only months after learning what a PM actually is. I did not have a software or product background, but I did have a significant technical background in the product domain for which I was hired.
I have found the entire experience both incredibly rewarding and incredibly humbling. I've never worked in a position that is so broad - from technical expert to support to tech writer to customer success to management.. every day is different. I do think this sums it up well:
> 14. Be on top of your shit. Until I figure out how to better articulate this, I’ll say it ineloquently as “just be on it.” Know your business, your product, your team, be responsive, communicate relentlessly, make good decisions, own your results, get 1% better every day.
If you're not constantly on top of everything, it becomes chaotic and obvious very quickly.
I have found the entire experience both incredibly rewarding and incredibly humbling. I've never worked in a position that is so broad - from technical expert to support to tech writer to customer success to management.. every day is different. I do think this sums it up well:
> 14. Be on top of your shit. Until I figure out how to better articulate this, I’ll say it ineloquently as “just be on it.” Know your business, your product, your team, be responsive, communicate relentlessly, make good decisions, own your results, get 1% better every day.
If you're not constantly on top of everything, it becomes chaotic and obvious very quickly.
I've worked with only one truly effective 'does everything' product manager, and I'd look forward to working with him again. It's rare to find natural executives that haven't gravitated into more straightforward executive roles. Perhaps you're leaning in that direction yourself!
What has been consistently effective at the team level is to divide the various functions discussed here between a 'product scientist' and a 'project manager' who both collaborate with engineering (plus UX, QA, etc). These roles may employ different titles, but I think my terminology more or less captures what they do well.
What has been consistently effective at the team level is to divide the various functions discussed here between a 'product scientist' and a 'project manager' who both collaborate with engineering (plus UX, QA, etc). These roles may employ different titles, but I think my terminology more or less captures what they do well.
I like to think I am leaning in that direction! I have no real desire at this point in my career to be an executive unless it's an executive with a close association to the technical problems/decisions facing a company. I feel like product gives me a chance to strike that balance, whereas my original career path (sysadmin --> project manager/consulting engineer --> technical manager) had me dedicating a lot more time to business decisions and people management that I preferred.
Awesome article, Alex!
An FYI: your link to the book Inspired is broken. You might want to put an Amazon affiliate link :)
An FYI: your link to the book Inspired is broken. You might want to put an Amazon affiliate link :)
Thanks! Principle #23, triple-check your links! ;)
Lots of what's written here doesn't just apply to PMs.
As someone on the more revenue-focused side of business, having concise comms and definition of responsibilities is the only way we can effectively keep the business running. There's plenty to takeaway here for all types of professionals.
As someone on the more revenue-focused side of business, having concise comms and definition of responsibilities is the only way we can effectively keep the business running. There's plenty to takeaway here for all types of professionals.
This list jibes with my experience (been a software PM for 19 years, coach lots of PMs as a service[1]).
But I find it incredibly surprising that the word "customer" appears only once in this post in the "Leader your Team" section:
> The game you’re playing: Your vision for the product, your product’s value to the customer, your competitive advantage, and how you’ll win.
In my experience a PM's job #1 is to know their customer. Specifically things like:
- Their pain points
- Their workflow (and how your product fits into it)
- Why they love your product
- What could be better about your product (and why)
- Who the buyer, user, and champions are
- What types of customers/pains your solution is best for (and who it's NOT best for)
Basically, a great PM can't be great without being the best-informed person in their organization about their customer.
There are two ways to do this:
1. Set up systems to funnel customer insights to the PM[2]
2. Set up systems to schedule customer calls, ideally automatically[3]
It's still surprising to me how many PMs have "talk to customers" buried somewhere on their list instead of it being at the very top.
[1] https://www.reemer.com/consulting/product-management-coach
[2] like https://www.savio.io (disclaimer: I run this)
[3] great example here: https://www.danwolch.com/2019/04/being-the-closest-to-the-cu...
But I find it incredibly surprising that the word "customer" appears only once in this post in the "Leader your Team" section:
> The game you’re playing: Your vision for the product, your product’s value to the customer, your competitive advantage, and how you’ll win.
In my experience a PM's job #1 is to know their customer. Specifically things like:
- Their pain points
- Their workflow (and how your product fits into it)
- Why they love your product
- What could be better about your product (and why)
- Who the buyer, user, and champions are
- What types of customers/pains your solution is best for (and who it's NOT best for)
Basically, a great PM can't be great without being the best-informed person in their organization about their customer.
There are two ways to do this:
1. Set up systems to funnel customer insights to the PM[2]
2. Set up systems to schedule customer calls, ideally automatically[3]
It's still surprising to me how many PMs have "talk to customers" buried somewhere on their list instead of it being at the very top.
[1] https://www.reemer.com/consulting/product-management-coach
[2] like https://www.savio.io (disclaimer: I run this)
[3] great example here: https://www.danwolch.com/2019/04/being-the-closest-to-the-cu...
I'd also give a suggestion that if you're working on a B2B product (especially one with "Enterprise Sales"), you might be CEO of your product, but you're not gonna be able to boss around the COO/VP of sales and the field. You need to understand how the field works, who the decision makers are, which folks cover which areas, how can you enable them, etc. You should be talking to your field at least as often as you talk to individual customers - it's an easy way to scale feedback/etc. and if something is wrong between your product and the field, you need to fix it ASAP.
I haven't heard of this kind of experience and I haven't exactly seen it either. So I'm curious to hear more. To me it seemed like the biggest thing the field needs support in is messaging and positioning. There wasn't really an aspect of bossing around.
I agree. Most of the "best PM advices" are usually related to B2C facing products. How about PMs who develop tools for internal use? I think the recommendations also changes - not from the point of "know your customers" but the nuances and what to pay attention and even measuring results are different than B2C consumers in general.
> PMs who develop tools for internal use.
You're thinking of a TPM, not a PM.
https://blog.tryexponent.com/pm-vs-tpm/
You're thinking of a TPM, not a PM.
https://blog.tryexponent.com/pm-vs-tpm/
I'm pretty sure the delineation of the PM and TPM roles is not internal vs. external customer facing, but where your main skills lie in terms of what you're handling.
PMs are usually more upfront in understanding the customer and the business needs. Whereas a TPM, is more behind, understanding the customer but moreso managing the tech teams and solution architects to deliver the proposed solution.
However, the PM role is fickle, and seemingly no company does it the same as another.
PMs are usually more upfront in understanding the customer and the business needs. Whereas a TPM, is more behind, understanding the customer but moreso managing the tech teams and solution architects to deliver the proposed solution.
However, the PM role is fickle, and seemingly no company does it the same as another.
If the field just needs messaging and positioning info, you're good. In my business, customers usually assemble a bunch of our products (and potentially competitors) together into a solution. We usually have 3-4 different options for each flavor because folks want to optimize for different things or have different opinions/skillsets in their org. It's effectively impossible to be clear 100% of the time for all those permutations, so you really have to be accessible to the field to help clarify when it matters. 99% of the time they handle it, but that 1% that they can't are often because it's a complex, demanding customer that also usually means $$$. In my business, the top 10% of customers can easily drive 80% of your revenue, so it can really matter in the end that the field WANTS to work with you, and not pursue a more accessible alternative.
Posit: an engineer with healthy business appreciation makes brilliant product manager.
That space, where same person can directly bring product imperatives into engineering, is where magic happens.
That space, where same person can directly bring product imperatives into engineering, is where magic happens.
Somewhat interesting article, I normally find these sorts of things a bit tedious. I do think there are some contradictions in some of the points regarding the honouring of the 'manager's schedule', 'maker's schedule' (that phrase made me wince) and communication, and the (incorrect) belief that there's no such thing as over-communication.
Maybe it was hinted at in the article, but while someone's job title may be Product Manager, they'll most likely be working with engineers who know far more about the product - it's capabilities and limitations - far more than the PM. Don't take it personally if something gets shot down, or if something you didn't know about is inserted into the monthly plan.
Maybe it was hinted at in the article, but while someone's job title may be Product Manager, they'll most likely be working with engineers who know far more about the product - it's capabilities and limitations - far more than the PM. Don't take it personally if something gets shot down, or if something you didn't know about is inserted into the monthly plan.
Thanks for reading! PG has a great article on "maker" vs. "manager" (I borrowed the framing from him and linked it in the article).
http://www.paulgraham.com/makersschedule.html
To your second point: Ultimately, the PM and the people they work with (engineering, design, PMM, research, etc.), are a cross-functional team. The PM shouldn't just provide a list of what to build; the PM should help lead them towards figuring out what to build, collaboratively, together.
http://www.paulgraham.com/makersschedule.html
To your second point: Ultimately, the PM and the people they work with (engineering, design, PMM, research, etc.), are a cross-functional team. The PM shouldn't just provide a list of what to build; the PM should help lead them towards figuring out what to build, collaboratively, together.
While PGs essay talks about maker's and manager's schedule (emphasis), I find it being mis-framed here.
PG doesn't assign PM to manager's schedule. You can see engineers themselves running in buckets of maker's and manager's schedules.
Mindset of PMs being "managers", who must "lead" and unblock engineers & designers is deeply flawed and creates silos, turfs and dysfunction. Reality is that the notion of product is continuum between engineering and product management functions. One hardly need to manage other. One definitively need to partner with other.
PG doesn't assign PM to manager's schedule. You can see engineers themselves running in buckets of maker's and manager's schedules.
Mindset of PMs being "managers", who must "lead" and unblock engineers & designers is deeply flawed and creates silos, turfs and dysfunction. Reality is that the notion of product is continuum between engineering and product management functions. One hardly need to manage other. One definitively need to partner with other.
Nice post! Personally, I like to describe the output of a PM team, broadly, as Great Decisions. This goes a bit beyond just communication – it's the role of PMs to force great decisions to be made, in addition to communicating the output. This is also distinct from "Correct Decisions" since a pretty good decision right now might be better than the perfect one in a week.
Thank you, and great point — another way I've heard it said by a friend/mentor is that "80% of PM is prioritization and communication". Where prioritization basically means "making good decisions on what gets prioritized".
Yup, I agree with that characterization. I also think that this is why a lot of people feel like PMs do nothing. Ironically it most frequently appears that PM isn't doing much when things are going really well (effortless execution) or really badly ("wtf are all of these meetings?").
I like the blog a lot, my biz partner and I have been writing on similar topics (link in profile if you're interested). Look forward to reading more of your stuff!
I like the blog a lot, my biz partner and I have been writing on similar topics (link in profile if you're interested). Look forward to reading more of your stuff!
Be on top of your shit.
I agree with this one wholeheartedly. One of my biggest gripes about PM's are when they produce half-baked things, like half-baked metrics, or half-baked external communications, or half-baked documentation. I'd rather they just didn't send it out in the first place. It's one thing to intentionally scope down the work. It's another to deliver something that is half of what you promised. This holds for engineers too, but in context we're talking about PM's.
At best you get confused managers/coworkers/users. At worst it makes your team look incompetent regardless of the work you actually did. That's how as a PM you get cut out of the loop.
Also, I think somewhere in should be a meta-principle:
Figure out what skills your team needs, and focus on providing those.
Specifically, depending on the company, team, culture, problem domain, product, etc. A team with an established, tight UX/engineering iteration cycle needs the PM to define the problems and get out of the way. A team that is starved of UX skills will need a PM to pinch hit on occasion. A team working on highly technical products (such as in security) might need a PM who is almost an engineer themselves in terms of technical expertise. A team working on a CRUD app doesn't need that much technical expertise, in favor of more time spent on UX and interfacing with other functions in the company.
As a PM, you have to understand these dynamics and how you can best fit into it. Otherwise you just get in people's way and lose the trust of the people you depend on.
(For context, I was a PM for several years, am an engineer now.)
I agree with this one wholeheartedly. One of my biggest gripes about PM's are when they produce half-baked things, like half-baked metrics, or half-baked external communications, or half-baked documentation. I'd rather they just didn't send it out in the first place. It's one thing to intentionally scope down the work. It's another to deliver something that is half of what you promised. This holds for engineers too, but in context we're talking about PM's.
At best you get confused managers/coworkers/users. At worst it makes your team look incompetent regardless of the work you actually did. That's how as a PM you get cut out of the loop.
Also, I think somewhere in should be a meta-principle:
Figure out what skills your team needs, and focus on providing those.
Specifically, depending on the company, team, culture, problem domain, product, etc. A team with an established, tight UX/engineering iteration cycle needs the PM to define the problems and get out of the way. A team that is starved of UX skills will need a PM to pinch hit on occasion. A team working on highly technical products (such as in security) might need a PM who is almost an engineer themselves in terms of technical expertise. A team working on a CRUD app doesn't need that much technical expertise, in favor of more time spent on UX and interfacing with other functions in the company.
As a PM, you have to understand these dynamics and how you can best fit into it. Otherwise you just get in people's way and lose the trust of the people you depend on.
(For context, I was a PM for several years, am an engineer now.)
> Leading Your Team
I am growing more and more allergic to the words "lead" "leader" "leadership"...
In all the high-productivity team I personally experienced, the so-called manager/leader are doing work that support the team. They never lead the team in any concrete fashion, i.e., they often clear barriers for the team to do what they always wanted to do, and most of the activities are often proven to be the correct things later.
I think most of the useful leadership training actually state the same idea.
But I see often times that many such "leaders" are mentally forced into what the name suggests, and trying really hard to "actually lead" the team members. That immediately turned down the collective creativity and gel between the team members.
That, is why I am allergic to these words...
I am growing more and more allergic to the words "lead" "leader" "leadership"...
In all the high-productivity team I personally experienced, the so-called manager/leader are doing work that support the team. They never lead the team in any concrete fashion, i.e., they often clear barriers for the team to do what they always wanted to do, and most of the activities are often proven to be the correct things later.
I think most of the useful leadership training actually state the same idea.
But I see often times that many such "leaders" are mentally forced into what the name suggests, and trying really hard to "actually lead" the team members. That immediately turned down the collective creativity and gel between the team members.
That, is why I am allergic to these words...
What you're describing as a "so-called" leader is in fact what a good leader should do, in my opinion. It's a fine balance!
I'm a web developer with 5+ years direct professional experience (and probably closer to a decade with freelancing) and my past two roles have been senior level, though the title doesn't mean much other than that I do projects start to finish by myself.
I've been interested in moving into a PM role for the past couple years and it seems like a very difficult transition unless it's done internally at a company big enough to both need the role and for there to be reasonably frequent openings for the role. I've never worked at a company that large before, and I am so so sick of software development that I don't think I can stomach another couple years of it at a new, bigger employer to make that internal transition.
My strategy right now is to find a project management role and then transition from that to product management. But boy this is a difficult job market to find entry level project management roles. I advertise myself as being experienced with project management, which is true - it's been a part of my dev job for years and in freelancing. But after 20+ applications I haven't had a single response. I would have hoped so many years as an engineer would count for more on a resume but I guess not when applying to project or product management roles.
Any advice welcome.
I've been interested in moving into a PM role for the past couple years and it seems like a very difficult transition unless it's done internally at a company big enough to both need the role and for there to be reasonably frequent openings for the role. I've never worked at a company that large before, and I am so so sick of software development that I don't think I can stomach another couple years of it at a new, bigger employer to make that internal transition.
My strategy right now is to find a project management role and then transition from that to product management. But boy this is a difficult job market to find entry level project management roles. I advertise myself as being experienced with project management, which is true - it's been a part of my dev job for years and in freelancing. But after 20+ applications I haven't had a single response. I would have hoped so many years as an engineer would count for more on a resume but I guess not when applying to project or product management roles.
Any advice welcome.
i can't provide any advice, but could you share what makes you sick of software development?
btw maybe not having a masters degree is an impediment in your pm job search. most devs don't have one nor need one but i suspect as with other management roles, there's a higher perceived need for an advanced degree.
btw maybe not having a masters degree is an impediment in your pm job search. most devs don't have one nor need one but i suspect as with other management roles, there's a higher perceived need for an advanced degree.
Replying from different account:
I'm specifically sick of web development, which is really all I know. I think my extreme distaste for it has also jaded my view on all programming. I recently tried to branch out into ML and AI stuff but the motivation to learn more is simply not there.
I'm tired of (web) development probably because I'm not growing in it anymore. I feel like I've done everything a million times. I always work at small places which means I'm also constantly having to deal with infrastructure and deployment problems as part of my job too. I really cannot force myself to give a shit about the thousandth configuration error message that takes an hour to fix just to get back to where I was before it popped up. Working at smaller places also means maintaining legacy projects that have really obscure technology choices that make it impossible to find resources or other people posting with similar problems. So I wind up having to become familiar with a technology that is dead and no one uses and I will never use again and does nothing to advance my career. I resent every second I spend learning it because of that.
Overwhelmingly my projects are for people who don't really know much about business, technology, or what constitutes a good idea for a project. So my projects are often just death marches where I'm spending months of my life on something that ultimately fails and sits in a repo never to be touched or deployed ever again. This is very demoralizing, as is taking direction from people who have no idea what they're doing - but they're the client and they're the ones paying us, so we gotta do what they want.
As I get older I think I just have less patience for things I find meaningless. I want to find something that I can actually grow in (like a new career direction with PMing) or work in an environment that I feel like has some sort of net positive change for society. It is difficult to find non-profits that are hiring right now, however, and overwhelmingly they want you to have previous non-profit experience too.
The advanced degree option is a good one, but I cannot in good faith spend two years of my life and tens of thousands of dollars (and hundreds of thousands in lost wages) just to get an entry level project management job that pays $50k.
I'm specifically sick of web development, which is really all I know. I think my extreme distaste for it has also jaded my view on all programming. I recently tried to branch out into ML and AI stuff but the motivation to learn more is simply not there.
I'm tired of (web) development probably because I'm not growing in it anymore. I feel like I've done everything a million times. I always work at small places which means I'm also constantly having to deal with infrastructure and deployment problems as part of my job too. I really cannot force myself to give a shit about the thousandth configuration error message that takes an hour to fix just to get back to where I was before it popped up. Working at smaller places also means maintaining legacy projects that have really obscure technology choices that make it impossible to find resources or other people posting with similar problems. So I wind up having to become familiar with a technology that is dead and no one uses and I will never use again and does nothing to advance my career. I resent every second I spend learning it because of that.
Overwhelmingly my projects are for people who don't really know much about business, technology, or what constitutes a good idea for a project. So my projects are often just death marches where I'm spending months of my life on something that ultimately fails and sits in a repo never to be touched or deployed ever again. This is very demoralizing, as is taking direction from people who have no idea what they're doing - but they're the client and they're the ones paying us, so we gotta do what they want.
As I get older I think I just have less patience for things I find meaningless. I want to find something that I can actually grow in (like a new career direction with PMing) or work in an environment that I feel like has some sort of net positive change for society. It is difficult to find non-profits that are hiring right now, however, and overwhelmingly they want you to have previous non-profit experience too.
The advanced degree option is a good one, but I cannot in good faith spend two years of my life and tens of thousands of dollars (and hundreds of thousands in lost wages) just to get an entry level project management job that pays $50k.
[deleted]
if you can not produce great product, you are not a great product manager.
For me Product is a conversation between a constructed thing and its environment.
The environment includes its users, its creators, the market, the people who believe in it, the people paying for it...
This conversation happens over time, and the thing evolves (both growing and shrinking) in response to its environment - but it also has an effect on its environment. A more successful product will have a larger effect - and indeed harsher environments may produce more focused products. The most successful products will create their own futures, that is when Product becomes really fun.
The environment includes its users, its creators, the market, the people who believe in it, the people paying for it...
This conversation happens over time, and the thing evolves (both growing and shrinking) in response to its environment - but it also has an effect on its environment. A more successful product will have a larger effect - and indeed harsher environments may produce more focused products. The most successful products will create their own futures, that is when Product becomes really fun.