Principles for great product managers
reeve.blog
reeve.blog
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...
You're thinking of a TPM, not a PM.
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.
>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
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.
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.
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.
Ok, I take it you're not a developer then!
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).
Involving devs after the roadmap has been decided is too late.
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.
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.
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.
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.
if it feels like "fluff" it is fluff imo. And that's something that most incompetent PMs suffer from.
It's all about aligning incentives. You need to reward PMs for getting stuff done, rather than looking busy.
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.
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.)
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.
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.
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.
https://a16z.com/2012/06/15/good-product-managerbad-product-...
>>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.
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.
That space, where same person can directly bring product imperatives into engineering, is where magic happens.
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.
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.
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.
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.
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.
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.
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.
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...
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 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!
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.
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.
An FYI: your link to the book Inspired is broken. You might want to put an Amazon affiliate link :)