
The Black Box of Product Management - saadatq
https://medium.com/@brandonmchu/the-black-box-of-product-management-3feb65db6ddb
======
kyllo
I don't see why people think of a Software Product Manager's job as amorphous
or poorly defined. The job description is straightforward: you manage
features. You gather information from users/customers and/or sales & marketing
about what new features and feature enhancements are wanted, define what
criteria satisfy the features, get estimates on what the features will cost to
build, and you make decisions about how to prioritize and schedule the
development of features, to make the product as successful as possible.

~~~
alexhaar
Creating value != managing features. In many cases the opposite is actually
true.

~~~
sanderjd
Creating value != _creating_ features, but it might equal _managing_ them.
Determining which ones to not create or to remove is also "managing".

~~~
alexhaar
Fair point, I should have left out the second part. My point is that creating
value shouldn't be associated at all with features. Creating value might be 1)
striking a deal with a partner, 2) tweaking an operational process, 3)
improving a customer support script, etc etc etc.

~~~
kyllo
_1) striking a deal with a partner, 2) tweaking an operational process, 3)
improving a customer support script, etc etc etc._

Yes these tasks add value, but that doesn't necessarily mean they are, or
should be, part of the Product Manager's job description. They may get done by
Product Managers in some cases, but they could also be done by people in
various other roles.

------
RyanZAG
_> One day, there may be graduate degrees and definite career paths to product
management, but not today._

What he has described is a multi disciplinary generalist with knowledge of
each business sector and training in how to manage organizational goals and
people. There is actually a current post graduate degree for that exact task -
the MBA.

~~~
sologoub
Unfortunately, many MBAs are still looking at the world through a
manufacturing lens. Software sector is fairly different in that you don't have
a conveyor belt and "plant size" is only marginally useful in that you cannot
replicate productiveness exactly.

For product marketing aspects of that job, an MBA is useful, but again, one
needs very solid grounding in the subject matter itself. MBA is more of a way
of thinking, as opposed to a blueprint in how to do X.

~~~
jeffjose
I go to Wharton, and can weigh in from an inside perspective. There's a lot of
interest for tech generally, and PM role is probably the most coveted one.
This is because most companies favor people with a background in technology
(or at the very least a passion for technology). You might be able to get a
job/internship in a tech company in Ops, BizDev, Corporate Strategy or Finance
with a whole lot of background in tech, but PM roles definitely require one.

~~~
stvswn
Also went to Wharton, and I'm a PM. My background was only a CS minor as an
undergrad (8 years ago) and that I taught myself Rails in order to attempt a
startup. This demonstrated a propensity for software but is completely useless
practically. I've learned almost everything on the job.

I use my MBA for: statistics (I'm stronger here than most SWEs), marketing,
communication skills, and understanding business use cases. Watching very
effective PMs, I think soft skills (leadership, communications) are more
highly correlated with success than "technical prowess." The ability to grok
technical concepts is kind of table stakes, but being very technically
talented isn't necessary (and such talent would probably be wasted).

~~~
sologoub
Great perspective! From my own experience, having a strong grasp of the
overall architecture and implications thereof is very important, however,
thinking that you can do better than the Engineering team or that you know how
that system should be designed is a liability. Collaboration is the name of
the game.

~~~
stvswn
Right, I don't mean to imply that technical knowledge isn't central to the
job. It is. But it can be learned.

A lot of engineers on this thread might not realize that within MBA programs,
the word is out -- "don't even try to be a PM, you need a technical
background." As if "coding" is something ultra-intimidating and therefore if
you can't already do it, you can't be a PM.

My company has a reputation for this constraint, like we only hire people who
were full-time SWEs in a past life. It's simply not true.

Once you get here, though, you have to understand the technical architecture,
for sure. But being a PM isn't alone among careers, here -- most careers have
a steep learning curve when you're starting out.

------
mattzito
It's a really long article explaining and justifying what "Product" is.

I think a much simpler explanation is that product management is the hub that
connects all of the other groups together in a unified and consistent fashion.

Is marketing up to speed on exactly what is launching a month before it
launches, so they can prep content and PR people? Do sales people understand
exactly how we should or should not be selling a new feature? Do finance and
legal know how we're going to sunset that old piece of functionality without
violating contractual agreeements with customers?

Thats' all product management. And then you get into the roadmap side of
things, but even that is largely in service of the above goal.

I'm not one of those product people who thinks that all companies _need_
product managers. But I think in the end, someone ends up filling that need,
whether they have a formal title or not. It could be a sales exec, or a
presales engineer, or a head of engineering with good business sense, but
that's the job function they're stepping in to fulfill.

~~~
zzalpha
_It 's a really long article explaining and justifying what "Product" is._

TBH, I didn't think the article was justifying the role so much as justifying
the ambiguity that surrounds it.

The fact that PM touches so many areas without specializing in any one, and
ultimately involves mostly leadership and coordination, means it can be really
tough to put a finger on what, exactly, someone with that title is doing.

* But I think in the end, someone ends up filling that need, whether they have a formal title or not.*

And that really is the key.

In small organizations, it's not unusual for the lead of the technical group
to own these functions. That can be good, or it can be very very bad,
depending on the person and the market the company is operating in.

But as the organization scales, the complexity of the work grows
substantially. Often that means a few folks help pick up the ball in an ad hoc
fashion until someone realizes that maybe one person should own the
responsibility, and voila, a product manager is born.

------
zzalpha
Interesting piece...

As a relatively newly minted Product Manager, I struggle, every day, to figure
out what, exactly, my job is, other than to abuse commas (I'm in a rather odd
spot in that I have no mentor and weak senior leadership, so I'm largely
responsible for defining my own role in an organization that doesn't really
grok what product management involves).

One thing I've found is that I can't easily put my finger on what exactly I
do... "leadership + coordinator/facilitator" is the best I can come up with.
It's something that's troubled me for a while now, but this post makes me
realize that maybe that's just normal, which is rather nice to see.

Still doesn't mean I know what the hell I'm doing, but that's a different
problem...

~~~
gyardley
Honestly, your job is to get yourself into a product management role where
you'll be properly mentored by someone more experienced. I'd persuade your
company that they need to hire someone senior for you to learn from or move to
another company where there's already a bigger PM organization.

~~~
zzalpha
Unfortunately, you're 100% right about all of that...

This is getting afield, but I'm in a rather tough spot: late stage startup
that continues to grow, and one I've been involved with for a very long time,
so I've invested a lot of my career here. I want to see it succeed (not the
least because I have a not insubstantial option pool), and it seems we
probably will, though perhaps in spite of ourselves. :) Customer engagement is
high, we're seeing steadily growing revenues, and we've largely pushed aside
any competition in our space.

 _But_ , senior management is only borderline functional and business focus is
primarily customer acquisition rather than strategic product initiatives. Some
recent changes in that area have been positive, but not transformative, and we
continue to build a business on an original concept invented over a decade
ago, while failing to keep up with changes in the industry.

Meanwhile, my direct report is essentially absent (which means product has no
representation at the VP level), and the only other VP-level individual (who,
notably, is _not_ my direct report) with a strong product background is likely
on their way out for various political reasons.

Tricky.

Anyway, barring a career change, at minimum, I really need to reach out to my
network to find other folks in the role with whom I can share war stories and
coaching/advice...

~~~
mud_dauber
IMO: once you grok how PM is viewed by a management team, you need to make a
stay-or-bail decision. Don't waffle. It sounds like you've already made the
evaluation.

My 30 yrs of experience says that an idiotic mgmt team is going to stay that
way until they fail and/or are replaced. PM's squishy nature just makes it a
easy target for "oh, they're just marketing." And your particular direct
report circumstances just make the decision that much easier.

Do it. To stay just invites an ulcer.

------
mbesto
I wouldn't necessarily agree with the part about "why product management
exists".

Product management exists because customers need a clearly and concisely
communicated path to their benefits today and in the future. Product
developers need a clearly and concisely communicated path on what to build to
create value for customers.

Successfully marrying those two is not an easy endeavor, and the way at which
you do it isn't a one size fits all orchestration. Hence, why product
management is seen as something of a dark art.

Here's what I do know. Companies without strong product management risks
themselves to higher customer churn and longer development-to-value timelines.

~~~
mattzito
One exception that i'll say is that a lot of platform-y products where the
developers are relatively closer to the target audience tend to do better
without product management.

Not that it gets you out from some of the challenges I list elsewhere, but at
least from a persona/use case perspective it's comparatively easy to grok why
and how someone wants to use the tool if that "someone" is close to the person
who is writing the code.

On the flip side, anything with sophisticated non-technical business users or
niche industries absolutely depends on having product management to rep the
voice of the customer to R&D.

------
notacoward
From an engineer's perspective, the problem with product management is often
lack of a definable process. How do the PM's priorities correlate to actual
_user_ priorities? I've never had a PM who showed actual names and numbers or
anything quantitative to show this relationship. If I could see that, it might
be easier to understand why they're willing to tie up half of engineering for
a year to implement a feature that not one of those engineers believes will
actually matter, while other apparently low-hanging fruit have to go unpicked.
It's OK if they're wrong, so long as there seems to be a rational process
involved. I've worked with some pretty good PMs, but even they seemed to be
good primarily because they had good gut instincts and not because they
applied a rigorous process. In other cases, PM decisions seemed to be based on
pure personal bias unchangeable by facts. Anyone who has lost a year of their
life because of a PM's ten-second decision is going to be less keen on PMs as
a species for a long time.

~~~
zzalpha
_I 've worked with some pretty good PMs, but even they seemed to be good
primarily because they had good gut instincts and not because they applied a
rigorous process._

So have you provided a rigorous, data-driven defense of every decision you've
made as an engineer?

'cuz I've met a _lot_ of great engineers whio made great decisions primarily
because they had good gut instincts and not because they applied a rigorous
process.

I've also seen engineering teams suffer because of a ten-second decision made
by someone a year previously.

We're more similar than you think. :)

The sad reality is PM is fundamentally a dark art, even more so than
engineering, which is, let's face it, driven as much by instinct as true
engineering principles.

Now, that doesn't excuse a PM from not doing market research, not doing
cost/benefit analysis, not tracking KPIs, etc, etc. PMs should view themselves
like an entrepreneur, and should always be looking to back their decisions
with data like any other business owner.

But ultimately, good instincts have to be part of the skillset. And just like
an engineer, sometimes decisions are made based on a gut reaction,
particularly when decisions have to be made very quickly (which happens more
often than we'd all like).

~~~
notacoward
> So have you provided a rigorous, data-driven defense of every decision
> you've made as an engineer?

Not every one, no, but most of the time. What you're engaging in here is _tu
quoque_ , as if an occasional behavior in one group justifies a continual
behavior in another. Ain't so.

> I've met a lot of great engineers whio made great decisions primarily
> because they had good gut instinct

As have I. I've also met some PMs who were likewise, and said as much. All I'm
saying is that relying on that _all the time_ can cause resentment.

> The sad reality is PM is fundamentally a dark art

That's OK, though I believe it's probably less true than you or the OP seem to
believe. What's most injurious to the PM/engineering relationship is not the
lack of rigor but the lack of transparency that goes with it. Often PMs don't
even _try_ to explain where their priorities came from, and don't admit when
they're just guessing. We engineers can deal with guesses. As you point out,
we make them ourselves all the time, but we _acknowledge_ that they're guesses
and therefore inferior to any data that might come along. "Because I'm the PM"
is too often the only reason given, and _of course_ that leads to animosity.

~~~
zzalpha
_" Because I'm the PM" is too often the only reason given, and of course that
leads to animosity._

Ah, well, that's a different problem: PM arrogance.

Confidence + Humility is not contradictory to Leadership, but unfortunately
not everyone understands that.

'course, many also don't understand that Manager and Leader are two different
things... and a Product Manager has to be both.

------
jarjoura
I find here in the valley companies value engineers who want a say in product
direction. So we have companies filled with engineers who don't want to just
be shoved a task and relegated to coding monkey status. I think that's where
most of the ambiguity exists.

As I see it, a PM should be your team's CEO and the lead engineer should be
the CTO. Together the pair of you are delivering on a single vision, one
person outwardly and the other inwardly. Yet for the magic to work, the entire
team needs to be on the same page. No one person should be setting the goals
for everyone else. Simple put, the PM isn't the engineers bitch and
engineering is the PM's bitch.

~~~
eitally
The problem is with closed-minded PMs who refuse to accept reasonable input
from external stakeholders & experts. Not saying this is the rule, but it is
common.

~~~
zzalpha
Well, to be blunt: a closed-minded PM is, by definition, a crappy PM.
Listening to experts and external stakeholders is literally one of the core
parts of the job.

That's not to say a PM has to take their advice. But if they choose not to, it
should be for clearly defined reasons based on strong reasoning backed by
data.

------
martinflack
I think the author missed a biggie: In many companies, the Product Management
team owns P&L's and makes sure products are profitable. They have direct
delegation from the CEO for the "business side" of the product. If you're
charging for your product, that's super important!

~~~
zzalpha
Incidentally, if you wanted to identify one of the major pain points of a
company transitioning from no PM to having PM, this is one of them.

In a small company sans PM, this work is done by the CEO or CTO. Deferring
that to even a VP-level PM... that's no easy transition!

------
mgrennan
I work for a company with many product. This post explains why it is so hard
for the company to move forward in our fast moving tech world. It also
explains why so many startups today are "single trick ponies" that learn to
expand their from only one product.

------
angryPM
[https://www.youtube.com/watch?v=RAY27NU1Jog](https://www.youtube.com/watch?v=RAY27NU1Jog)
I have people skills - I am good at dealing with people!

