

What does a product manager do? - sudonim
http://iamnotaprogrammer.com/2010/08/what-does-a-product-manager-do/
A lot of founders don't understand what a product manager does and when to bring one in. This is an attempt at an explanation.
======
tptacek
These are indeed things that product managers do. However, in a software
startup, the product manager's portfolio _is_ the founder's portfolio; in
other words: you'd better be a good product manager (or be ready to become
one).

Read Steve Blank and Eric Ries. Don't think about hiring someone into this
role until you've done it successfully for your company first.

~~~
torrenegra
I agree. As I commented in the orignal post:

"For over five years I've hired four product developers for three different
startups I've co-founded. None of them has delivered satisfactory results. I
am a perfectionist and that may be part of the issue. I've decided to stick to
product development and, instead, hire others to take care of sales, business
development, operations, etc. Also, doing product development is what I love
the most. I am not that good at interacting face-to-face with others."

------
rwhitman
Interesting, this week I'm in the interview loop for a PM position at a
notable company.

I come from a background as a botched startup founder & 'jack of all trades'
consultant (developer / designer / project manager / team lead). Anyone have
any advice? What challenges would I face in transition?

~~~
ruff
I'm a PM at a large, well known software company. In fact, I lead a team of
PMs and have been in a PM role for several years after running a failed
software startup during university and a stint as a sales and marketing guy at
a solar start-up.

This article does a great job summing it-up: the PM role is about taking the
vision, converting it to execution of a strong product, and facilitating a
feedback loop that helps drive the vision forward.

A lot of times the PM is denigrated as an excess or waste, particularly in
start-ups. It's true that a lot of PMs are taxes to their teams. But good PMs
will bring a lot of clarity and absolute focus. I'm sure strong founders are
also very capable of this but it's likely a matter of time and focus for those
founders relative to other competing objectives.

Tips on doing PM well:

\- Live. Eat. Breathe your product. I've spent years working on a product that
I secretly detested but used that frustration with the product as a motivation
to learn the product space inside-out and established myself into a position
to remake the product what it needs to succeed (rebranding, significant
technical overhaul, slash/dash legacy feature weights, etc.). Our customers
are going from constant complaining to singing praises—that's hugely rewarding
personally.

\- Squash out all forms of inefficiency in the team. Every aspect of
development that reduces your ability to deliver the best product is a
concern. I'm engaged in everything from the architecture, feature
prioritization and scheduling, end user usability and aesthetics, support
workflows, license agreements, and key customer account discussions. I
coordinated the entire team's shift to agile development practices including
deciding the structure of each sub-team (our dev team is quite large and split
across different countries)--as the PM for a large team you are in a unique
role to see all sorts of opportunities for improvement. But be very careful--
don't be shallow in identifying something as inefficient. For example, driving
out prototyping time from devs reduces both their morale and creativity, two
valuable resources. Another common mistake, seeing process as efficient…
Creating checklists that engineers spend more time checking-off than
delivering value to customers. Bad PMs excel at this.

\- Software is the output of people and your ability to drive, motivate, and
coordinate people is key to their ability to deliver the product. Process and
schedules are mere tools for organizing people, don't let them dominate you,
the team, or the product. The best PMs are really good with people and care
about the team's success more so than their own because they know that a
product and team's success will ultimately be good for their own career. The
role often puts you in a leadership position with the team—don't be afraid to
lead.

\- You will constantly straddle the expectations of upper management, peer
managers, and the individuals on your team. Knowing how to balance all of that
and communicating appropriately to each set is a really important skill. Also,
be prepared to be honest when the news isn't good--bad PMs will hide things
and hope for miracles. Your job is to help people make the right decisions
even if it means you get ripped apart in a couple meetings.

\- The most important thing to deliver to the team is focus. Get the
distractions out of the way and point the direction to the what needs to get
done today. If you're nuanced, you can do this without making it feel
burdensome or dictatorial. The best is building a team and process where the
team can answer focus questions themselves.

Here's what day:day job entails (these will often change based on the size of
the company and the scope of your influence—as mentioned, I drive a team of
PMs for a software product that straddles the consumer/enterprise space:

\- Meeting with key customers and getting requests/appeasing them around
product direction (and knowing when to ignore them or probe deeper about what
they really need vs what they are saying)

\- Working with or sifting through market research about the space to try and
forecast the demand for certain features

\- Driving these requirements into a schedule and managing that schedule with
development, often a negotiation between you, development, and management—this
bullet really underestimates this as often this is what more junior PMs spend
a lot of time doing

\- Bubbling up engineering opportunities that need prioritization and/or could
save costs and/or better align your team to future customer opportunities

\- In larger orgs, coordinating across teams about aligning bigger customer
bets and scenarios

\- Drafting functional specs that range from whiteboard drawings to many-paged
docs describing how things will work (totally depends on your ability to
communicate, the team you work with, etc)

\- Driving the overall look-and-feel of your product in alignment with
usability, branding, and revenue concerns \- Making the calls about what hits
the quality bar to go in/out a version of the product

If you want a good start at understanding some aspects, see Making Things
Happen by Scott Berkun (<http://www.scottberkun.com/books/making-things-
happen/>).

~~~
baddspellar
A number of these PM tasks go deeply into the development world: defining
development processes, architecture, and managing developer checklists.

I've worked with a number of product managers who've grossly overestimated
their competence in these areas, and who've been mocked and ignored as much as
possible by the development team as a result. I'm familiar with a large, well
known software company that uses such a job description. I worked with a
product manager who left that company for mine. He was awful. He never gave
customer-focused requirements. Instead he'd define implementations as if he
knew what he was talking about, and I'd have to play 20 questions to figure
out what problems he was trying to solve.

The _best_ product managers I've worked with have leveraged their strengths
and trusted others on their team to do what they're best at. In my experience,
these product managers have always had a very strong customer/user focus. My
favorite product manager was at a medical imaging company. He had been a tech
before he moved into product management, so he knew deeply what our users
needed from our product, he had many connections in the user community, and he
knew how to listen. We'd challenge and ask questions, but at the end of the
day we deferred to him in his area of expertise, just as he challenged and
asked questions but deferred to us in our area of expertise.

~~~
ruff
This is a good point and something I should have made clearer. As PM, you ar
first and foremost the customer advocate. Drop the ball here and you fail.

Engaging at a more technical level needs to be about ensuring focus, not
meddling where you don't understand. For example, cootdinating architectural
decisions does not mean designing the solutions (your senior devs do that) but
it does mean infusing those discussions with customer centric decision making.
The worst thing a PM can do is act like they know something without actually
doing so--as others have noted, you need to listen and learn.

My experience may be a bit different; when I started, my boss was checked-out
and looking for a career change. To learn the role, I got to know our
developers really well (in the end, they have lots of power) and asked them
what the PMs did well and didn't do well.

~~~
joezydeco
Well put. I'm currently in a situation where my PM has started to believe he
knows more than he does (thanks to the assistance of me and the developers in
the office).

Then PM made the mistake of talking within earshot about how he was going to
decide the timeline and budget for my team without talking to me. My attitude
toward the guy instantly went from "whatever it takes" to "do your own
homework next time, buddy".

This is a small startup. We need every win possible to succeed. And I just
don't give two shits about the guy anymore. Am I wrong to think this way?

~~~
ruff
The bozo bit is starting to flip... Give the PM the benefit of doubt; I'd be
direct with him about why you don't think his actions are right--tell him what
you expect from him and why the way he's behaving isn't constructive. If he
doesn't listen, do your job, watch your back, and communicate to your boss how
this guy isn't healthy for your team.

~~~
joezydeco
Yeah, I'm trying, but unfortunately politics are getting in the way...the PM
and CEO are best friends from way back at previous companies. PM was laid off
from his last job and sometimes I wonder if he got the job only because he
needed one. It's tricker than it looks.

------
ashbrahma
As a Product manager, I like what Gmail's Todd Jackson said at SXSW about
PM's: "You can either be a shit funnel or a shit umbrella..."

~~~
megablast
Not sure which is better form that quote. Someone who protects the company
from shit, or someone who funnels the shit away from everybody else in the
company?

~~~
brown9-2
I think you're looking at the quote backwards. It's about protecting (or not)
the _team_ working on the product, not the company.

------
sbov
I would imagine its hard to hire a good external product manager.

I once worked at a small company where the product manager was a new hire, but
most of the developers had been around for a long time (4-5 years). In the
"food chain" the manager was higher, but after years of experience working on
the project and under the founder the developers had a better eye for what
worked when it came to implementation.

~~~
btilly
The job of product managers is not to know, it is to learn. Far too many
people have that backwards, including product managers. The best ideas rarely
come from the product manager. But the best product managers do a good job of
finding ideas that are out there in the users, QA department, developers, etc,
and figuring out which ones deserve to be tried, how to integrate them into
the product, and how to judge their success.

I remember one product manager. Her first time being a product manager in
software. I handled reporting. Within 3 days I knew she was good. She knew
absolutely nothing, but she asked the right questions, and put the answers
together in good ways to come up with insights other people hadn't had. I was
on my way out the door, but I kept in touch with the company. I was entirely
unsurprised that 6 months later she had emerged as a superstar.

Still there is always a challenge in telling the difference in an interview
between people who are good, and are good at BS. This seems to be particularly
true with product managers. But I suspect (never having hired for the position
I can only suspect) that digging into their willingness and ability at asking
questions is revealing.

~~~
bfung
Why did you know she was good after 3 days? Do you remember any specifics?
What were those "right questions"?

~~~
btilly
Yes, I remember specifics of how Jenny Kaplan (then Roosa) impressed me. (No
need to hide the name of someone I'm complimenting. :-)

She was asked to look at our lease reporting process. That was a process that
was somewhat complex, under documented, and which nobody had been in charge of
for some time.

Less than a day later she knew that I was a useful resource. She asked me for
any information I had on lease statuses. I sent her a copy of the standard
documentation we had on tables, and pointed to where in that there was a list
of all statuses you could wind up in during the lease reporting page. She
asked me for information about transitions from state to state. I sent her the
source code that controlled the set of all possible lease transitions, and
included brief descriptions on how to tell when that would trigger emails,
etc. (There was no other documentation. Seriously.) She came to me, and said
she was trying to prioritize the logic, and we had a brief back and forth
discussion about what was available. Perhaps 15 minutes later I had a report
for her that listed for each lease transition, how many people had made that
transition in some previous time period.

The next day she had a diagram that listed the major lease states, the
important lease transitions, gave volumes for how people flowed through, and
gave how many people's leases ended at each status. She had also prioritized
which ones she thought had the most room for improvement. This was by far the
best view I'd ever seen on the lease report process in several years at the
company.

I was impressed with how quickly she had come up with that, and I mentioned
this in a conversation with the person who ran QA. Who said, "You're not the
first to compliment her. Monica (who handled customer support) has been saying
how happy she is to have a product manager who comes and asks questions about
what problems people are asking customer support about. I'll be very
interested to see what she does with her spec."

Jenny started 3 days earlier. Within 3 days of being handed a big hairball of
a project, she had managed to impress 2 people in 2 other departments. And
when said spec arrived, the comment I got from the head of QA was, "Now THIS
is what I wish every spec looked like. Clear. Simple. Too the point. And it
looks like it will work."

------
16s
Reminds me of a rhetorical question Ted Nugent once asked which he then
answered himself, "What does the National Guard do? They _guard_ the nation."

------
known
A product manager should _manage the gap_ between his product and competing
product.

------
korch
I don't recall what article about startup valuations it was, but it was posted
here a few months ago, and one of the pieces of advice was: when valuing a
fresh, new startup(< 10 employees), deduct -$200,000 for every product/project
manager on the payroll who doesn't also hack code.

~~~
kenjackson
So if Steve Jobs started a new company with no employees, you'd valuate it
-$200,000?

~~~
forgottenpaswrd
I will. Steve Jobs had Wozniak partnership , without him he would be not what
he is today, he wouldn't had the experience he has(he started very young),
either the money and fame. He wouldn't had the opportunity to work with(and
learn) from extraordinary people he has.

It was a symbiosis because odds are that Woz without Jobs will not be in a
very good position. Jobs is an extraordinary seller(distortion field).

So yes, if I find a young Jobs without training and even more if it has no
employees is at least -$200,000.

~~~
kenjackson
I not asking if you had a young Steve Jobs.

I'm saying if Steve Jobs today said, "I'm leaving Apple and starting my own
company. As of today, I'm the only employee of this new company."

He comes to you and says, "I'll give you 50% share for $20" you'd say, "No.
Since you don't write code, the company is only worth -$200k".

Let me cut to the chase. Valuating companies with stupid formulas, leads to
stupid valuations. IMO.

~~~
brianlash
Jobs is a terrible example. If he founded a company he'd be a finger snap from
surrounding himself with an A-List tech team, the likes of which SV VCs only
dream about. It's the fact that he _could_ find the talent if he needed it
that the valuation would obviously be greater than 0. Your point is moot.

~~~
kenjackson
No, that's exactly my point.

You don't say, "non-programmer equals -200k". You say, "What do they bring to
the table? Oh, you have Bill Clinton on your team and you're trying to do a
government services startup -- that's a pretty big plus, even if Bill isn't
coding". "You're doing a Clicker like company and you have the ex-CEO of
Comcast. Maybe a plus". "Doing financial services software, and you have the
ex-head of IT from BofA... maybe useful, even if he is 'just' IT".

In fact, I'll say if you have a startup company in front of you who doesn't
know how to judge each individual, pass on them. They'll fail.

------
bluishgreen
Anyone looking to hire an awesome product manager? Please leave a note here,
lets talk!

