
The Product Manager's Lament - Brajeshwar
http://www.linkedin.com/today/post/article/20121211155158-2157554-the-product-manager-s-lament
======
ajsharp
All too typical of a tale. Too many people working on too many things, where
the only person who has ownership is the guy not building any of the things
(the PM).

Simple solution: Small teams that own what they're working on, soup to nuts.
This probably means 1-2 devs on a team, a designer spread across 1-2 teams
(depending on the scope of the team), and the PM helping all of them, where
necessary, but not giving them _exact specs_ of what to build. Product manager
in an agile-ish organization is an extremely poorly named title, as their
primary function is _not_ to manage, but to communicate and facilitate things
that are otherwise difficult or inefficient for designers and engineers to get
at.

If the PM is giving the designers and devs exact specs on the product to
build, he or she is failing in their role. The PM should be focusing on
communicating succinctly the business problems to solve, and the software
solutions evolve naturally from the small teams. The product manager, as a
member of a team that builds software, should be expected to have some insight
as to the general design of the software (maybe in the form of wireframes or
whatever). But providing exact specs for what to build is a battle-tested
Recipe for Failure™.

~~~
zaidf
_The PM should be focusing on communicating succinctly the business problems
to solve, and the software solutions evolve naturally from the small teams_

This may work with top x% of programmers/designers but the fact remains,
majority of the programmers and designers are _not_ equipped to take a
business problem and come up with a solution. Their core job never was to
think deeply about a problem in a niche domain. Now I understand at startups
it is common for multiple of these roles to fall under one person but I am yet
to see that system scale, especially at an enterprise level where the customer
may have very peculiar requirements the product manager can really help think
through before it even goes to the devs/designers.

~~~
arohner
> the product manager can really help think through before it even goes to the
> devs/designers.

I'm not convinced it's more likely that the PM can think through the issues
better than anyone else on the team.

In any decision, in any industry, in any profession, _the only way to make a
good decision is to understand the cost and benefit at the same time_.

IMO, almost all corporate software disfunction comes from that failure. The
decider understands the cost, but not the benefit, or the benefit, but not the
cost. Sales teams that don't understand the product, developers that never
talk to customers, managers that don't understand how to code are all trivial
examples of this.

If the PM designs the feature incorrectly without understanding how to code or
understanding the current codebase, there could easily be a 10x cost
difference, in terms of implementation and QA. If the developer writes a
feature that no customer will accept, all implementation time is wasted.

How to fix that failure depends on the relative costs for the PM to learn the
codebase, vs. the developer learning the business domain. Though both are
nearly essential to a successful company.

~~~
zaidf
Sure, and thus the rise of the developer-product manager. I'd consider myself
to be one and I know plenty of others out there. My primary focus is to make
sure what we build is what the clients want but when communicating with the
developer, I will talk in terms of primary key and other technical concepts.

The same terminology would no make sense to the client and a client's
terminology("I just want feature x") leaves out bunch of implementation
details which a good product person should be able to clarify and fill in
instead of leaving it up to the developer to guess.

------
yonasb
I'm really surprised that he didn't just recommend that they do away with
Product Managers altogether.

This is probably the best Product Management approach I've heard of for early
startups: [http://www.quora.com/Stripe-company/Does-Stripe-have-
product...](http://www.quora.com/Stripe-company/Does-Stripe-have-product-
managers-or-do-engineers-manage-the-products-themselves/answer/Patrick-
Collison/quote/201417)

~~~
prostoalex
I also like GitHub's approach <http://warpspire.com/posts/product-design/>
(they refer to the role as product designer) but I wonder how long it's going
to work for them.

~~~
S4M
Github is a very special company in that respect as the developers are
building a product they are using for themselves. Github's model couldn't be
replicated in a field where this wouldn't be the case.

------
RyanZAG
Feels like that PM is trying to micromanage and failing to keep his troops
working in their box.

If you're going to make a spec that defines 'how' as a PM, then you need to
make sure your designers, coders and QA do exactly what you tell them. This
can actually work if you're an incredible genius and know the details of what
you're trying to do incredibly well.

Most PMs don't fall anywhere near there, and so the solution is simple: spec
the 'what' very broadly. Delegate protocol specs to the programmer(s) who will
be dealing with that protocol the most. Make sure the programmers create a
product that the designer can 'skin' afterwards - such as moving elements
around the screen without programmer assistance. Have the QA work with the
actual product and not a spec - the users will be using the product after all,
not the spec.

Standard stuff...

~~~
pacala
What about spec the "why", then engage with the team to figure out the "what",
then let the team figure out the "how" by themselves. Believe it or not, the
PM is not the only one with problem-solving skills on the team to tackle the
mapping between "why" into "what".

~~~
gyardley
Sometimes this is true. It depends on the developers.

Sometimes the developers don't have product skills but _know_ they don't have
product skills. This is also fine.

Sometimes the developers think they have product skills when they don't, and
this is always a complete disaster.

I can't tell what situation the company described in the article is in.
Perhaps the product manager is incompetent (there's lots of incompetent
product managers out there), and the developers are correcting for this.
Perhaps the developers have good product sense that the product manager is
underutilizing.

But if the developers don't have the product skills they need, skills you get
by spending lots and lots of time talking with customers instead of (or in
addition to) writing code, no amount of process tweaking is going to fix the
real problem - individuals assuming that their technical skill translates into
product skills, and insisting on also doing something they're not good at.

I've often wondered why the subset of developers who lack product skills
and/or the relevant domain knowledge frequently insist on getting involved
with product anyway. After all, the head of human resources rarely insists on
committing code.

------
seiji
I'm slightly confused. Is LinkedIn pulling a Tumblr? Is Eric employed by
LinkedIn now? Can anybody post posts on linkedin.com/today? Is a link at
linkedin.com/today a stable URL or only good for today? Today when/where?
What's going on?!

~~~
pspeter3
LinkedIn is allowing a few business leaders to write long form articles and
have members follow them. Go to
<http://www.linkedin.com/today/post/whoToFollow>

------
jlgray
"So the product manager winds up actually having to use the software, by
hand..."

maybe this is startup-land naivete speaking, but I pity the company whose
product manager doesn't routinely use their own product.

~~~
seiji
<real-world-gripes>

What if your product is creating giant networked ovens for Nabisco assembly
lines?

What if the product is an Enterprise Firewall Spam Detector IDS Bad Guy
Defeater Gateway Proxy with more feature check boxes than atoms in the human
body and the PM (who is a PMP, obviously) has a BA in English with a minor in
interpretive dance?

What if the product is a series of experimental HIV vaccines?

Not every product in the world is a consumer webapp.

</real-world-gripes>

~~~
jlgray
Good points. You definitely got me on the HIV vaccines, although that would be
one quality-conscious product manager!

The number one skill a good product manager should have is being able to
understand what the users need (not always the same as what the user wants, of
course). Using the product, when possible, is a great shortcut. When it isn't
possible, customer understanding is going to require phenomenal communication
and imagination. That said, I would still be very wary of putting someone
without some domain knowledge in charge of speccing out a super complicated
product.

------
dmarble
I was a PM at a bigger company (~350) before jumping into startup land. After
being the CTO and de-facto PM for a couple startups, I've had an idea that
probably needs some vetting:

I think when you're still small, most typical PM functions should be
distributed instead of centralized, with a manager getting in the mindset of
managing people who are 10-20% PM / 80-90% engineer or designer.

While the overall product/business strategy and business requirements should
be owned by one or a few founders/officers, I think as many people as possible
in an early stage web/mobile product company should have most of the general
skillset of a PM. Highly specialized talent might be an exception if you're
creating a sophisticated product or have unique interface goals. But the
general PM skills -- mockups, basic design principles, writing stories,
writing requirements, managing a story/requirement from creation to deployment
-- should be universal while you're small.

The inflection point goal at web/mobile startups is getting MVP after MVP out
the door until you've pivoted or iterated your way to a good-enough product
for a good-enough market. (Or good-enough product for a specific customer.)
It's an all-hands-on-product affair.

With this in mind, I think the early CTO should be a hybrid of engineering
talent and director of product management. Or perhaps depending on skillset a
separate person (another co-founder or the person you thought should be the
first PM) is that director of PM and the CTO is more like a lead architect.
The point is that rather than doing all the product management or all the VP
Engineering stuff, this person (or two) manages a team of hybrid
engineers/PMs, retaining some important overall product and architecture
decision-making responsibilities, but empowering and helping designers and
engineers employ basic PM skills individually or split among a small group
such that the person or small group owns more process for a feature.

~~~
johnbellone
This makes sense to me, but at a startup assuming that the CEO is the
lifeblood of the idea for the company (as s/he should be) aren't they
essentially the PM manager that you describe here? I guess this is a moot
point, but we're obviously only focusing on a startup that is heavily
technology focused.

What about one where the pudding is actually a process or physical commodity
and the technology portion is merely an extension of this?

------
debacle
Having designers develop wireframes and designs without the input of software
engineers is like having a product designer design the dashboard of a car
without the input of automotive engineers.

Wireframes should be signed off on by engineers before design starts, and
design should be signed off on by engineers before it is approved.

------
garagemc2
Sounds like this is the root of the problem:

"When the programmers get it (the specs), they often start negotiating with
him about what's going to be built. They exchange countless emails, and he's
being constantly interrupted and being asked to clarify exactly what the spec
means. "

A simple solution is: speaking about the project/product feature with your
developers first. Understand what will take long, what won't, what can be
stripped out in the first iteration. Once this is done, work with designers to
push something out.

Another super simple solution is videos.

Writing takes time. Wherever possible I try to make videos for the designers
or even better have live calls.

In terms of idle time, there should be always a backlog of specced out work or
bug fixes that the developers can focus on. Failing that, they can work on
optimising past projects, refactoring or reading about new things.

~~~
danso
Writing takes more time than producing videos? Are these videos largely
unedited? And if so, how do you measure the time lost in the inefficiency of
interpreting the video?

~~~
garagemc2
Unedited videos, remember, this is for design briefs. For developers, videos
may not be the best form.

I can imagine on some very complex projects videos being a difficult medium.
But for me it's great: I just record the things I want to get done, bring up
examples from other websites, use the mouse as a pointer to direct the viewers
focus. I summarise what I want to be done at the end.

Usually I send over the video and checklist of things to do.

------
hising
I have been working both as a product manager and as a lead developer. I think
both roles are designs of companies where hierarchy are more important than
the outcome. A healthy company probably lacks Product Managers, Lead
Developers and System Architects and those roles are filled by loosely formed
teams based on interest in the problems and products people are
solving/building. Where I come from, it is called taking responsibility.

------
ellbeaux
I think the article shows correctly the common problems at most organizations
today. Many organizations don't have engineers who really care about usability
over functionality, so simply "handing off high level wants" just doesn't work
outside of a couple of rehabbed buildings in Frisco.

It's easy to have a reference to the Stripe article, where there are no PMs.
But, this environment is the exception rather than the rule. After working in
a few medium sized places, the ratio of engineers who place an equal level of
detail on usability & functionality vs those that place a higher value on
functionality/architecture is easily 1:6. And you can guess which ones are
usually the Sr members. To their line of thinking, usability isn't something
they have ever had to worry about.

I do agree with a previous poster that this is something that the startup
culture is starting to change, but I would bet that this change won't be
visible at most organizations until at least 5 - 8 years out as the engineer
talent changes.

Now, I would say this problem is something that can be changed with some UX
standards. The PM creates flowcharts and/or wireframes of the proposed
solution > hands it over to the agile team > dev + ux discuss any flows that
fall outside of established standards. As a PM myself, I would love this. To
be required to only provide more end user/market requirements as needed would
be ideal.

One issue with this is that usually with organizations that have these issues,
the investment just isn't there in the area of UX (I sit here reflecting on my
current situation).

I will bet that the product team disfunction mentioned in the article is
directly reflected in said team's products. :)

------
dchichkov
In the early stage startup a Founder/CEO should also play a PM role.

It might be not obvious, but the main problem having a dedicated PM on the
team, is that unless PM has very strong engineering or business experience
[and in this case that person should either code or bring in money], the _PM
would fill very insecure_ , surrounded by highly experienced people, who can
actually do things. Cost of somebody on the team, feeling very insecure and
trying to bullshit/manoeuvre/bully his way around outweighs any potential
benefit to the team.

From my personal experience, I've seen projects fail solely because of PMs
protecting their turf.

------
aioprisan
That's what happens when you don't involve engineers in the project spec part
of the process, they need to be consulted much earlier and be partners in
helping define the feature-set and timeline, not impose it from above with an
arbitrary set of features.

