

How to be a program manager - twampss
http://www.joelonsoftware.com/items/2009/03/09.html

======
JoelSutherland
I don't understand why Joel calls out Fried on functional specs and describes
the exact same 2 step process:

\-----------

Joel Step 1:

 _You start at the highest level: a vision statement, no more than one page
explaining the gist of the new feature._

Fried Step 1:

 _So what do we do in place of a functional spec? We write a one page story
about what the app should do. If it takes more than a page to explain it, then
it’s too complex._

\-----------

Joel Step 2:

 _Once that’s nailed down, you can develop storyboards… mockups of the screens
showing the user’s progression through the application, with detailed notes
showing how they work._

Fried Step 2:

 _Then we begin building the interface — the interface is the functional spec.
First with some quick and simple paper sketches, then directly into HTML.
Unlike paragraphs of text that are open to alternate interpretations,
interface designs are common ground._

\-----------

~~~
spolsky
Because Fried makes a big deal out of "not doing functional specs' when he's,
essentially, doing functional specs, just not calling them that.

He's opposed to BAD functional specs, which is fine, but too many people read
his title and decide it's OK to skip to writing the code first.

~~~
akeefer
One important distinction that a lot of agile people make is more around
writing down the specs; as the PM you still do work up front to think about
what to do, make mockups, do your homework, etc., but when it comes time to
communicate to developers it's done as stories (much less detailed than specs)
and with in-person communication for clarification (or, under less ideal
circumstances, over the phone or e-mail or chat). The process of getting to
the story in the first place ought to involve plenty of back-and-forth, design
vetting, and mockups, but once you get there you don't build something based
on a spec of any kind.

The theory there is that written documents will always be out of date,
incomplete, stale, and open to multiple interpretations, so we might as well
just accept that the face-to-face communication is infinitely higher bandwidth
and will have to happen anyway and not waste the time trying to write it all
down up front.

So if the PM needs to spec for their own edification, that's fine: do whatever
works for you. But I, as the developer, will trust the PM themselves as the
source of truth as to what the feature should do, and it's the PM's job to
know what they want well enough to answer my questions real-time as I'm
building.

~~~
ams6110
As a developer on the receiving end of "stories" I find that a few sentences
on an index card are, in most cases, woefully inadequate at describing the
desired functionality. So what happens is you end up going back and forth to
the PM with your questions, which is inefficient, OR you make assumptions to
fill in the gaps, which sometimes works out well and sometimes does not.

On the other hand I've also had the unhappy experience of wading through
dense, arcane specification documents written in stilted language ("the system
shall...." ad nauseum) that are ultimately not much better.

In the end I think what this illustrates is that writing a good, concise,
clear, complete functional specification is not easy. It requires a talented
PM and no formulaic approach, whether it is agile or anything else, can get
around that.

~~~
akeefer
The solution to that in our case, at least, is that the stories aren't just
handed down with no explanation from a product manager. Instead, there's a
team-wide "estimation session" every week where everyone (dev, PM, and QA)
attends and we take the higher-level feature ideas, including any initial
supporting documents (market research, mockups, desired use cases) and break
them out into smaller, estimated stories. At that point everyone has a chance
to ask for more detail and clarify any concerns they have, point out potential
difficulties, suggest alternatives, etc. So stories are only scheduled for
work once they've passed that initial stage where everyone was involved; if
things are too vague, or technically impossible, or otherwise unready for
development, they don't make it out of the estimation session.

It definitely still requires good product managers, but again the idea is that
no matter how good the spec or whatever is you'll still always have questions,
and it's better to just build that fact into the process and get people used
to asking questions rather than having people make assumptions. And the best
way I've seen to make sure that the PM has the answer to those questions is
the estimation session, since if the PM doesn't know what they want well
enough to answer the questions quickly as you develop, you'll find that out in
the estimation session before anyone is tasked with working on the feature.
That at least largely avoids the situation where a developer starts working on
something and finds out the PM really didn't have a great idea of what they
wanted after all, or that it's technically infeasible, which (in my
experience) is just a really bad situation to be in.

The story approach still presents endless ways to screw up, but it's far
better than any other approach we've tried over the last 7 or so years.

------
rayvega
The distinction between _functional_ design and _technical_ design is very
important and often overlooked. Some developers tend to miss it or mix it up.

I have worked with programmers who felt they lost all control because they
were not driving the functional design. However, they did truly have control,
as Joel points out, because at the end of the day they still own and decide
the technical design which is generally better aligned with their unique
skills.

Good functional design tends to be technology ignorant by being more focused
on _what_ something is going to do from a user's perspective versus _how_ it
is going to do that something behind the scenes in code (as defined by the
technical design).

While a functional design can be written out as a spec, the technical design
can be developed and evolve as you write actual code if you follow an agile,
iterative style of development. I think writing a technical spec (not to be
confused with the functional spec) and handing it off to junior developers is
why people get turned off by the idea of creating documentation on how
something is going to work by someone who is not going to be the one actually
implementing it. (In Joel's article, it is what Charles Simonyi was trying to
define as program manager.) Once again, this is not the same as someone who
provides a functional design spec.

Alan Cooper's The Inmates Are Running the Asylum does a really good job
drawing out and describing that distinction between the areas of functional vs
technical design (although if I recall he uses different terminology to
describe the two but the same concept nonetheless).

------
notauser
Joel's definition of Programmer Manager is closer to what I know as a Product
Manager (except for the co-ordinating teams bit).

The APM definition of Program Manager (which covers a lot more than the
software field) is someone who manages a portfolio of projects, balancing
resources to deliver results. This is also roughly the definition that
Wikipedia agrees with.

I agree with a lot of the rest though, especially: "It helps, as a program
manager, to be pretty good at coding yourself. This is unfair. Program
managers aren’t supposed to write code. But programmers tend to respect
programmers a lot more than non-programmers, no matter how smart they are. It
is possible to be an effective program manager without being a coder, but the
burden of earning the respect of the programming team will be higher." That
goes for Project/Program managers as well as Product managers.

------
10ren
I found it incongruous how Joel seemed to be in charge of the whole operation,
with all these long-established gurus reporting to him - a guy fresh out of
college, who (modesty?) didn't know anything.

This setup drove home his point for me, that _The program manager and the
developers have to be peers._

Joel _wasn't_ their boss. He was just the spec guy ("program manager"). Still,
he must have some serious smarts to land such a job - possibly great coding
chops _plus_ being able to communicate well. Rare.

~~~
endtime
From what I've seen, becoming a PM does indeed require serious breadth of
smarts. I don't know about MSFT, but at Google being a PM requires technical
skills, communication skills, design skills, and market insight. I interviewed
for a associate product manager internship at Google, which is extremely
selective (I was told they only take 10-15 APM interns a year). I had two on
campus interviews with PMs, then an interview with a PM _at_ Google (most
people have a technical interview at this point too, with a Google engineer,
but I had interviewed for engineering in parallel so I had effectively had
that one already), and then the final step was to write a three page essay to
be reviewed by a hiring committee. I didn't get the internship, but they had
told me that the essay was the final round either way. Four interviews and an
essay might not sound like a lot, but keep in mind this was just for an
internship.

The APM interviews and the essay were very nontechnical. They mostly focused
on product design and consumer experience (not limited to web/tech stuff), as
well as one or two about industry in general (which I was pretty crap at
answering). The most technical APM interview question I had involved coming up
with strategies for improving AdSense performance and helping suggest keywords
to advertisers. However (if the technical interview that regular APM
candidates get were like the ones I got as first-round engineering
interviews), the technical interview is pretty tough. Not impossible, but
harder than MSFT or Amazon first-round...probably on par with MSFT second-
round. And as a CS student I found the APM interviews the hardest of all.

------
joshwa
The rest of the world calls this role a Product Manager (happens to be what I
do, too).

cf. Marissa Mayer, Ev Williams, Joe Kraus, Steve Jobs (on a high level), etc.

In Fortune 500 hell we call it 'Business Analyst' (because in bizarro
enterprise software world, users and what they do with your software is called
'the business').

In Agile/Scrum they call it the 'Product Owner'.

Point is that someone needs to keep the big picture in mind and serve the
interests of the end-user, all while sweating the details from their
perspective as well.

~~~
simplegeek
I've been a part of Scrum teams and I can tell you from a personal experience
that Product Owner cannot do this much in a , say, 4-week sprint. I doubt it.
At least, during my stay, I never say Product Owners creating specs, talking
to QA and etc.

------
peterb
... and this explains, in detail, why Microsoft products are so much more
difficult to use compared to Apple (designed by industrial designers) and less
functional than FOSS (designed by programmers and domain experts). They are
designed by committee and program managers who are smart, but fresh out of
school with no real world experience.

~~~
jimbokun
I have enjoyed Microsoft bashing a lot over the years, but a lot of real
people have managed to do a lot of real things over the years with Microsoft
software.

Maybe it is just as legitimate to say "Microsoft products are more functional
than Apple products (designed by industrial designers) and more usable than
FOSS (designed by programmers and domain experts)," and that is a better sweet
spot for software design? For example, what software is better overall than
Excel and Word in their categories, when both functionality and user interface
is considered?

~~~
peterb
Agreed. Microsoft has released best of breed products. But Microsoft's product
decisions are largely driven by "PMs", whereas open source is driven by
technical merit and Apple is driven by industrial design. Microsoft occupies
this weird middle ground, call it "pragmatism" (or even MBA-driven design :-).

This middle ground results in weak consumer products like Vista and Microsoft
Mobile. They aren't bad products, but lack the polish an industrial design-
driven process could have produced. They also lack the technical depth that
open source is producing. As a result Microsoft is getting squeezed from both
ends.

Joel's products are similar: a good middle ground. Neither awe-inspiring
(technical) or fun to use (design).

~~~
lunchbox
This post contains lots of oversimplifications that don't do justice to
Microsoft, Apple, or FOSS.

First, why do you think pragmatism is weird? As jimbokun pointed out, you're
framing it as if it's OK to focus on either design or technical merit, but
that trying to do well on both (which is what users actually need) is somehow
undesirable.

I think your comment about "MBA-driven design" gets to the heart of your
misunderstanding about what a PM is. Neither MBAs nor industrial designers are
a substitute for PMs (most of whom are software engineers by training). Tell
an industrial designer or an MBA to design Exchange's system for handling the
million special cases that come up when handling calendar synchronization.
What do you do when two appointments are modified concurrently? What happens
on the server when someone deletes their local Outlook data file by accident?
When do you treat two similar calendar events as duplicates, when do you treat
them as separate, and what's the most logical way to let users resolve
duplicates/triplicates? How do you handle the many confusions that arise from
people traveling across time zones? Which attributes of a person's calendar
should be stored on the server, and which should be customizable on each
specific device? I know industrial designers and MBAs who work in the software
industry, and they would tell you that this isn't their job.

You also say that the middle ground results in weak consumer products like
Vista and Windows Mobile. These two data points are cherry-picked. I could
equally say that this middle ground results in _great_ products like Office
2007, SharePoint, Exchange, .NET, Visual Studio, SQL Server, and so on (not
fair to limit this to consumer products, since Microsoft's biggest focus is on
productivity applications. I could point out Apple's lack of success among
business users, but I understand that this is not their strong suit and that's
OK. Their ability to deliver for a growing set of high-end consumers makes
them a huge success in my eyes.)

~~~
ryanwaggoner
MBA is a degree, not a job title. There are tons of MBA product managers and
tons of MBAs who can code.

~~~
lunchbox
Sure, that's true; I should have said "MBAs who are not software engineers". I
think, however, that peterb was using "MBA-driven design" to imply "design by
someone who knows business but not software engineering", and I replied by
using it in the same colloquial sense.

------
carterschonwald
So the conciser version is the program manager is someone who understands
software design, usability issues and can communicate with every role in the
company?

~~~
raganwald
You must have been daydreaming about Sally in 11th grade. You forgot that _The
program manager and the developers have to be peers._

I had this experience at KL Group with the marketing department, who owned the
requirements and the UI. Marketing and development were peers, which reflected
the company's structure: Greg Kiessling and Ed Lyclama (K & L) were co-owners.
Greg ran the business while Ed ran the technology. Steve Rosenberg, the VP of
Development, used to echo another of Joel's sentiments: Whenever we were
depressed, he would remind us that _We own the compiler,_ meaning that nothing
could happen with convincing, cajoling, or otherwise making Development a deal
they couldn't refuse. Marketing and Development fought like wild dogs over the
specs and shipping priorities, and we ended up taking over our market and
making Ed and Greg wealthy men when they sold out.

A while later I worked for another company where marketing owned the
requirements and UI, and the VP of Marketing executed a coup and got
Development to report to him. The company failed shortly thereafter.

~~~
jimbokun
Yea, Sally. I wonder whatever happened to her.

------
simplegeek
So isn't it really hard to interview Program Managers? This essay should have
been more insightful had Joel included some information on how to hire Program
Managers? I'm wondering how do Microsoft hire Program Managers?

------
snowytigger
I never had much use for the PMs at Microsoft. On the other hand, every PM I
knew there had a... let's say "large" sense of their own worth. Guess it was
in the job description. Since leaving I have encountered PM-like roles doing
everything from just documenting whatever crazy requests the users made, to
ignoring the users and pushing for whatever they personally wanted.
Occaisionally I have encountered someone who really added to the process, but
it takes just the right person, and sadly that's been the exception rather
than the rule.

------
Longhorn213
If you haven't taken the time yet you should read the Copilot spec. It caused
me to rethink how specs should be written, and what is the right level of
detail.

------
albemuth
Totally off-topic, that picture of the "Cemetery for soldiers' dogs" is from
the Edinburgh castle right? It gave me a weird childhood flashback

~~~
spolsky
Yes, good catch

------
mattyfo
Thoughts on how I can move towards becoming a program manager? I have the
communication skills, I'm learning to program (ruby) and I'm learning to
design webpages.

I'm not very interested in becoming a full on hacker but I want to help build
programs and webapps because I feel I'm good at getting 'the big picture' and
advocating for users/customers.

------
dmoney
Beware of hidden command structure. If you want to be "peers" with the
developers, make sure they understand they don't have to do what you say.
After all, most commands in corporate America are framed as questions, and
many developers will assume that the burden of proof is on them, since you
have "Manager" in your job title.

------
cake
_"Lacking a program manager, your garden-variety super-smart programmer is
going to come up with a completely baffling user interface that makes perfect
sense IF YOU’RE A VULCAN (cf. git)."_

Glad I'm not the only one who isn't a Vulcan.

------
sarvesh
Joel, in case you are lurking around here, link for the book Don’t Make Me
Think is broken.

