How to be a program manager | Hacker News Reader

How to be a program manager

joelonsoftware.com

161 pointstwampss43 comments

Open articleView on HN

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.

-----------

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.

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.

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.

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.

"In the end I think what this illustrates is that writing a good, concise, clear, complete functional specification is not easy."

A complete, unambiguous, and functional specification is called a program. May or may not be "good".

The going back and forth that you describe as inefficient is where the collaborative creative act occurs, where you work with the person that needs a custom system to define what you can build for them.

Not only writing the code first, but write with the idea that because they're "agile", their code is somehow easier to change 15 times as the complete understanding of the functionality emerges.

It would have been helpful for me to have read that context rather than the weird insult. That only seems to escalate the confusion caused by his title.

When the "functional spec" is the exact same thing as the html code, it is no longer recognized as a functional spec.

The functional spec usually comes before the html code.

Sure, Fried treats his html code as a functional spec, but others who work differently would not be able to find what they are used to calling a functional spec.

I think Fried is in general against shuffling papers (like BAD specs and business plans) instead of getting around to actually making decisions.

Though the processes sound similar, the scope and details each is emphasizing are different.

Spolsky: "feature"

Fried: "app"

Suppose either is designing GreenfieldGloryApp - he might start with a one-page vision statement. He might then make some very high level mock-ups of scenarios. Maybe they would even be done in HTML. This is where they diverge: At this point 37signals would start building. Fog Creek would iterate 'specs' many times further by drilling down to feature or feature-set level functional specs. Each feature-level spec would start with a vision statement and then be fleshed out with mocks and "detailed descriptions".

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).

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.

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.

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.

... 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.

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?

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).

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.)

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

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.

Take it easy dude...It's always easy to bash on any product..what is important is whether you are making money out of it or not and whether it's reaching a wider audience or not. Have fun making software :)

Sometimes decent solutions come from not being at one extreme or the other.

Not always, but sometimes.

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.

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.

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?

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.

Yea, Sally. I wonder whatever happened to her.

Yes, in other words, the proper definition of a "really good programmer". (As opposed to the flawed one Joel - and many others - use)

For me -- Seems to also fit the (albeit rarely found) definition of a "good architect" also.

I'll give you that. I've never seen a "good architect" that wasn't also a "good programmer" via my definition.

Indeed - For whatever reason, I've had the title architect for most of my career, so I hope that's true (as for the "good" part...).

The Program Manager also understands the timeline/schedule and improves the code without actually coding.

Yes, and the correcter version of your comment is 'So the more concise version...' ;)

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?

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.

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.

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

Yes, good catch

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.

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.

"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.

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

Reply on news.ycombinator.com