10 ms·

Principles for great product managers

226 points by AlexDReeve 6y ago

opportune 6y ago
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
- ghaff 6y ago
  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.
  - opportune 6y ago
    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.
    - ghaff 6y ago
      >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.
      - designium 6y ago
        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?
        ghaff 6y ago
        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.
- AlexDReeve 6y ago
  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.
AlexDReeve 6y ago
Hey folks, author here. I'd love feedback – I'm also happy to answer any questions and/or debate!
- jaksawesome 6y ago
  Have a mirror? Looks like site is already down.
  - AlexDReeve 6y ago
    Ugh, I'm on it!
    - simonw 6y ago
      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.
      - AlexDReeve 6y ago
        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!
  - timsneath 6y ago
    Principle #23: plan for unexpected scale :)
    - AlexDReeve 6y ago
      Too true! =(
- goofballlogic 6y ago
  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.
ryanmarr 6y ago
Funny, I happen to have this open in another tab. https://a16z.com/2012/06/15/good-product-managerbad-product-manager/ https://a16z.com/2012/06/15/good-product-managerbad-product-...
- AlexDReeve 6y ago
  One of the greats! It's amazing how well "Good PM/Bad PM" has aged. =)
  - SilasX 6y ago
    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.
    - AlexDReeve 6y ago
      I'm saying it's aged well! Despite the author's caveat, I think it's still accurate in a lot of ways.
      - SilasX 6y ago
        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.
- staysaasy 6y ago
  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 :)
- 6y ago
toisanji 6y ago
dead
sarajevo 6y ago
Getting: ‘Error establishing a database connection’
dchuk 6y ago
Here's the google cached version: http://webcache.googleusercontent.com/search?q=cache:z3YxCz4NvD4J:reeve.blog/blog/principles/+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:z3YxCz4...
AlexDReeve 6y ago
Back online, sorry about that, folks!
hankchinaski 6y ago
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
- ozim 6y ago
  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.
  - falcor84 6y ago
    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.
- lliamander 6y ago
  > 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.
hankchinaski 6y ago
> 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.
- jeffbee 6y ago
  Yup. Cover up your own lack of utility by talking non-stop, holding numerous meetings, and 'following up'.
  - hankchinaski 6y ago
    spot on.
    - AlexDReeve 6y ago
      I agree. In my opinion, over-communication is to help maintain alignment between people/teams/functions. It can't replace real, valuable work and results. Ideally, if the PM is a good communicator, execution is a lot smoother for every team (because the PM is carrying the alignment/communication burden).
      - secondcoming 6y ago
        Over-communication never helps. Well, maybe it helps a PM feel like they're doing something, but to the detriment of everyone else.
        alonmower 6y ago
        I've always interpreted this message as "don't assume that everyone you're interacting with has all of the same context as you" and be proactive about sharing relevant context whenever you communicate. Not "send people the same message over and over or annoy people to make it seem like you're staying busy"
designium 6y ago
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.
- bravoetch 6y ago
  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.
- codingdave 6y ago
  > 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.
  - designium 6y ago
tylerwince 6y ago
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
- FindMySocks 6y ago
  I look forward to reading that
  - tylerwince 6y ago
    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.
darrmit 6y ago
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.
- rch 6y ago
  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.
  - darrmit 6y ago
    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.
sidhanthp 6y ago
Awesome article, Alex! An FYI: your link to the book Inspired is broken. You might want to put an Amazon affiliate link :)
- AlexDReeve 6y ago
  Thanks! Principle #23, triple-check your links! ;)
MaximumMadness 6y ago
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.
kareemm 6y ago
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 https://www.reemer.com/consulting/product-management-coach [2] like https://www.savio.io https://www.savio.io (disclaimer: I run this) [3] great example here: https://www.danwolch.com/2019/04/being-the-closest-to-the-customer/ https://www.danwolch.com/2019/04/being-the-closest-to-the-cu...
- crandycodes 6y ago
  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.
  - eatonphil 6y ago
    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.
zxienin 6y ago
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.
secondcoming 6y ago
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.
- AlexDReeve 6y ago
  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 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.
  - zxienin 6y ago
    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.
staysaasy 6y ago
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.
- AlexDReeve 6y ago
  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".
  - staysaasy 6y ago
    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!
munchbunny 6y ago
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.)
justicezyx 6y ago
> 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...
- AlexDReeve 6y ago
  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!
vayeate 6y ago
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.
- dajohnson89 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - dencodev 6y ago
    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.
z61a 6y ago
if you can not produce great product, you are not a great product manager.
somewhereoutth 6y ago
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.

226 points by AlexDReeve 6y ago

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

ghaff 6y ago
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.
- opportune 6y ago
  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.
  - ghaff 6y ago
    >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.
    - designium 6y ago
      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?
      - ghaff 6y ago
        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.
AlexDReeve 6y ago
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.

AlexDReeve 6y ago

Hey folks, author here. I'd love feedback – I'm also happy to answer any questions and/or debate!

jaksawesome 6y ago
Have a mirror? Looks like site is already down.
- AlexDReeve 6y ago
  Ugh, I'm on it!
  - simonw 6y ago
    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.
    - AlexDReeve 6y ago
      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!
- timsneath 6y ago
  Principle #23: plan for unexpected scale :)
  - AlexDReeve 6y ago
    Too true! =(
goofballlogic 6y ago
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.

ryanmarr 6y ago

Funny, I happen to have this open in another tab. https://a16z.com/2012/06/15/good-product-managerbad-product-manager/ https://a16z.com/2012/06/15/good-product-managerbad-product-...

AlexDReeve 6y ago
One of the greats! It's amazing how well "Good PM/Bad PM" has aged. =)
- SilasX 6y ago
  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.
  - AlexDReeve 6y ago
    I'm saying it's aged well! Despite the author's caveat, I think it's still accurate in a lot of ways.
    - SilasX 6y ago
      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.
staysaasy 6y ago
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 :)
6y ago

toisanji 6y ago

dead

sarajevo 6y ago

Getting: ‘Error establishing a database connection’

dchuk 6y ago

Here's the google cached version: http://webcache.googleusercontent.com/search?q=cache:z3YxCz4NvD4J:reeve.blog/blog/principles/+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:z3YxCz4...

AlexDReeve 6y ago

Back online, sorry about that, folks!

hankchinaski 6y ago

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

ozim 6y ago
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.
- falcor84 6y ago
  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.
lliamander 6y ago
> 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.

hankchinaski 6y ago

> 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.

jeffbee 6y ago
Yup. Cover up your own lack of utility by talking non-stop, holding numerous meetings, and 'following up'.
- hankchinaski 6y ago
  spot on.
  - AlexDReeve 6y ago
    I agree. In my opinion, over-communication is to help maintain alignment between people/teams/functions. It can't replace real, valuable work and results. Ideally, if the PM is a good communicator, execution is a lot smoother for every team (because the PM is carrying the alignment/communication burden).
    - secondcoming 6y ago
      Over-communication never helps. Well, maybe it helps a PM feel like they're doing something, but to the detriment of everyone else.
      - alonmower 6y ago
        I've always interpreted this message as "don't assume that everyone you're interacting with has all of the same context as you" and be proactive about sharing relevant context whenever you communicate. Not "send people the same message over and over or annoy people to make it seem like you're staying busy"

designium 6y ago

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.

bravoetch 6y ago
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.
codingdave 6y ago
> 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.
- designium 6y ago

tylerwince 6y ago

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

FindMySocks 6y ago
I look forward to reading that
- tylerwince 6y ago
  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.

darrmit 6y ago

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.

rch 6y ago
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.
- darrmit 6y ago
  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.

sidhanthp 6y ago

Awesome article, Alex! An FYI: your link to the book Inspired is broken. You might want to put an Amazon affiliate link :)

AlexDReeve 6y ago
Thanks! Principle #23, triple-check your links! ;)

MaximumMadness 6y ago

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.

kareemm 6y ago

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 https://www.reemer.com/consulting/product-management-coach [2] like https://www.savio.io https://www.savio.io (disclaimer: I run this) [3] great example here: https://www.danwolch.com/2019/04/being-the-closest-to-the-customer/ https://www.danwolch.com/2019/04/being-the-closest-to-the-cu...

crandycodes 6y ago
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.
- eatonphil 6y ago
  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.

zxienin 6y ago

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.

secondcoming 6y ago

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.

AlexDReeve 6y ago
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 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.
- zxienin 6y ago
  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.

staysaasy 6y ago

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.

AlexDReeve 6y ago
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".
- staysaasy 6y ago
  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!

munchbunny 6y ago

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.)

justicezyx 6y ago

> 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...

AlexDReeve 6y ago
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!

vayeate 6y ago

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.

dajohnson89 6y ago
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.
- deleted 6y ago
  [deleted]
- dencodev 6y ago
  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.

z61a 6y ago

if you can not produce great product, you are not a great product manager.

somewhereoutth 6y ago

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.