
Things a Good Product Manager Should Think About   - jpuopolo
http://www.jpuopolo.com/2011/09/5-things-a-good-product-manager-should-think-about/
======
bane
"Keep an eye on what really matters...[a]It will help make money...[b]It will
improve the user experience..."

I've had considerable difficulty with PMs in the past regarding the paradox
between a&b. Lots of "wouldn’t it be cool if it could do this?" questions are
answered by b, but an overzealous PM might say no, justifying against a...and
it's easier to build justifications around feature bloat and that seems to be
where lots of dev cycles are spent in most companies.

Ref: see Microsoft vs. Apple's approaches.

------
throwaway111222
From a Product Management standpoint, this is good advice.

But what do you do when you're a software developer who sees these problems
but have your hands tied by management?

~~~
SoftwareMaven
It depends. I found myself in that situation and just started doing the job,
but this requires your boss' approval, since it will take time away from
coding and cost money. To do this, you have to have a current gap in product
management (as opposed to PMs making bad decisions). This was my path into
product management.

If you can't get your boss' approval or there is existing product management,
you can try sitting down informally with them. Explain your concerns, but be
tactful (this part is hard for many engineers who are completely data driven).
You have to be careful not to get people defensive. Go in with an attitude of
"I see this as suboptimal, teach me why I'm wrong" instead of "You're an
idiot, you should be doing this thing instead". Make sure you are being
objective, though. I've had engineers fight me on what "should" be done
because they were only looking at technology instead of the whole business.

If neither of those work, you are probably going to get frustrated quickly.
Few things did more damage to my team's morale than feeling like they were
working on something useless.

------
thesash
I agree with almost everything except point 1. A Minimum Viable Product is
exactly that-- the smallest possible product that will be viable in the
marketplace. Some startups and developers may take this thinking overboard and
put products on the market that are so stripped down as to not be viable, but
I think that the concept of a true MVP sums up the entire purpose and
challenge of Product Management.

A true MVP must strike the balance between feature bloat and watered down
junk, driven by a vision of what users need as opposed to what they think they
need. Such vision requires a lot of insight and a lot of courage. Imagine
being the PM that decided the iPhone was ready to ship without support for
copy and paste. Is copy and paste an important feature for a mobile phone?
Obviously. Was it necessary for the product to be viable in the marketplace?
Clearly, it wasn't, and that is why determining a feature set for and MVP is
such a challenge.

------
dangravell
"Well thought out features that deliver value, even if they take a bit longer
to come to market, will (in my opinion) deliver more ultimate value to the
product and to the user experience."

The important thing to notice there in the quote is that there are two steps
to "delivering more ultimate value".

The first step is more thought. Well obviously. No-one is saying slap any load
of crap down and expect someone to pay for it.

The second is "that deliver value". This appears to be the one most missed by
people, in my experience, and is the raison d'etre of MVP. If the market
doesn't exist and if you aren't solving a genuine problem that you can both
communicate and be delivered economically then it doesn't matter how much you
"think".

This is why MVPs are important: an empirical guide to work out what should be
done, not sitting at your desk pontificating with your wise-ass
rationalisations, abstractions and reductions of human behaviour and reality.

------
rfairfax
Do startups actually need product managers? A few months back, a job posting
for a designer at inDinero included a sidebar that asked this question.
Jessica suggested that the answer was "No".

It seems that product managers are not required when a company is relatively
small, and a co-founder has the bulk of his/her time to dedicate to product
development. In such a case, a team need be made up of only engineers and
designers.

Even when teams are larger, new-ish web application frameworks like Rails make
deployment incredibly easy/fast and all of the "strategic thinking" that a PM
might ordinarily contribute is done with live product. In these situations,
all of the activities listed in Joseph's blog post - focus, vision, avoiding
frankensteinism, customer-centricity - could be handled by a product designer
or product-minded engineer.

Are product managers a thing of the past? Seems increasingly likely.

~~~
gyardley
inDinero has what, five employees?

As teams grow and the scope of what they do grows, the need for specialization
also grows.

Let's assume a wonderful team of world-class engineers who all happen to have
the same skills as a world-class product manager, and who all like product
management work. (If you like, they can all also be world-class designers.)

In my experience, pure product management work grows pretty linearly with the
number of developers. (Providing they're organized, more developers means more
projects or increased velocity on existing projects. Either means more product
work.)

In this situation, each developer could spend X% of his time on product
management work. (Let's say X% = 10%, since in my experience one product
manager can keep ten developers busy.)

Great, you might think. Since every one of these developers can do and likes
to do product management work, they'll each devote 10% of their time to it,
and everything will work out fine.

There's only one problem with that - great products aren't built in small
isolated portions. In order to be an effective product manager, you've got to
know the whole product - so everyone doing any sort of product work has to
coordinate with each other. As the team grows, so does the coordination
overhead.

Even assuming a perfect central repository of knowledge (an uber-wiki?), so
each developer only has to do a knowledge dump once, just consuming and
synthesizing all the information created by all other people takes an
increasing amount of time. And then there's the need to reach consensus when
people's syntheses disagree, as they invariably do.

In these situations, as the team grows and/or the product gets more complex,
someone inevitably ends up spending an increasing amount of their time on
product, while others stop spending any. Someone becomes the guy who makes
product decisions, while others defer to that guy.

Perhaps, when the dev team is ten people or so, that product-focused person's
still spending a bit of time coding, and still calls himself a developer. But
as the team grows, it's inevitable - you will either hire external dedicated
product managers or you will grow them yourself from the inside.

------
ChristopherM
Grammatical errors aside, I like the ideas represented here.

However I think the post would have more impact if it was followed up with
concrete examples. Take MVP for instance, are there any known failure cases
that would demonstrate why it's important not to rush half-baked ideas out the
door? I certainly can understand how shipping bad functionality can create a
huge negative opinion of a company and it's products. However, how do you
convince others, especially your boss, that it's a bad idea? Explaining what
might happen usually gets you nowhere, pointing out other disasters sometimes
gets their attention.

This type of analysis could be performed on each of the 5 things and in doing
so would make for a far more interesting read. As previously said, I like the
ideas it just seems to be missing information that would make it feel
complete.

~~~
jpuopolo
Thanks for reminding me about the grammar, constant challenge :)

I have lots of examples, perhaps I will do a follow up on that. I will have to
talk about most of those examples with a beer in hand, that is a prerequisite.

Joseph

------
ericxtang
It's super difficult to find a startup PM at the beginning, partially because
it's super difficult to find another person who has the same product vision.
It's much easier for the founder with strong conviction to see the product
through, at least to a stage where it's been proven by the market.

------
rglover
I think a lot of these points can apply to founders, too, and not just product
managers. Especially in regard to the MVP concept, I think a great point is
made here a lot of people mistake an MVP for an incomplete/half-working thing.
This isn't always the case, though, it's more common to see that than it is to
see fairly polished work being released. One of my all time favorite
companies, Metalab, hosts a series of products that look and function like
apps that have gone through rigorous iteration but in reality are on their
first (sometimes beta) release.

~~~
BerislavLopac
Founders are, by definition, product managers, at least until they can hire a
dedicated one.

------
matusz13
I wish someone at Cisco systems would religiously enforces some of these
standards. They consistently approach products at a minimally viable level and
they almost always become frankensteins because of it. Just one of many
reasons they've been in some financial hot water in the past few years.

------
mathattack
The Frankenstein problem is huge. Look at the clutter on Yahoo versus Google.
Absolutely captures the difference in focus and culture.

Frankenproducts are a sign of a bloated middle management that isn't willing
to make a stand on win-lose tradeoffs.

------
sachinmonga
great post joseph, nice to get some perspective from the others side on the
huge MVP trend.

