
Principles for great product managers - AlexDReeve
http://reeve.blog/blog/principles/
======
kareemm
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-cu...](https://www.danwolch.com/2019/04/being-the-closest-to-the-
customer/)

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

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

~~~
hitekker
> PMs who develop tools for internal use.

You're thinking of a TPM, not a PM.

[https://blog.tryexponent.com/pm-vs-tpm/](https://blog.tryexponent.com/pm-vs-
tpm/)

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

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

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

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

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

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

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

------
hankchinaski
> 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
Yup. Cover up your own lack of utility by talking non-stop, holding numerous
meetings, and 'following up'.

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

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

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

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

------
ryanmarr
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-
manager/)

~~~
AlexDReeve
One of the greats! It's amazing how well "Good PM/Bad PM" has aged. =)

~~~
SilasX
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
I'm saying it's aged well! Despite the author's caveat, I think it's still
accurate in a lot of ways.

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

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

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

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

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

------
justicezyx
> 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
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!

------
tylerwince
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
I look forward to reading that

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

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

------
staysaasy
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
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
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!

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

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

~~~
jaksawesome
Have a mirror? Looks like site is already down.

~~~
timsneath
Principle #23: plan for unexpected scale :)

~~~
AlexDReeve
Too true! =(

------
sidhanthp
Awesome article, Alex!

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

~~~
AlexDReeve
Thanks! Principle #23, triple-check your links! ;)

------
sarajevo
Getting: ‘Error establishing a database connection’

------
AlexDReeve
Back online, sorry about that, folks!

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

------
toisanji
dead

