PM: Secret weapon or wasted headcount?

 Microsoft is one of the few software companies that uses program managers (PMs). PMs, developers, and testers form the infamous engineering triad. Together they prioritize and cost features, triage bugs, and make design decisions. Now that highly agile services teams are rethinking the test role, should we reconsider the PM role as well?

What the heck do PMs do anyway? Where is their value—aside from covering duties devs and testers despise? Is the value in PM specs? No, “stop writing specs” (chapter 3). Are they valuable for cross-team collaboration and driving issues to closure? Sure, but all engineers need to collaborate and drive issues to closure. Are they necessary for arranging meetings? Really, that’s what you’re going with—meeting creation?

Before throwing PMs under the proverbial bus, we should pause and consider why Microsoft has been so successful, particularly at developing product versions 3, 4, 5, 6, 7, and onward, while our competitors seem to lose momentum after versions 1 and 2. Could PMs be the secret weapon that allows us to catch and then crush our competitors, leaving them behind in the dust of our success, when conventional wisdom had considered us woefully lagging? If so, what’s the blueprint for that secret weapon? What makes a great PM?

Eric Aside

For more on the changing role of test, read Test don’t get no respect and “Undisciplined” (chapter 4).

We’re on a mission

Years ago, Borland’s Turbo suite of compilers dominated Microsoft’s compilers, until Visual Studio (now in its 15th version) won the market. The same can be said about WordPerfect and Word, Lotus and Excel, PageMaker and Publisher, Notes and Exchange, Netscape and IE, you name it and Windows, PlayStation and Xbox, and so forth. In a few years, we’ll be adding Google and Bing and iPhone and Windows Phone to the list.

Am I being arrogant? Darn right! Does a new or reinvigorated competitor (like Apple’s iPad) trounce Microsoft regularly, humbling the company and reigniting our focus? Heck yeah! What gives me the confidence to claim all comers will be conquered in due course? Our collection of PMs.

As I’ve written before, our competitors depend upon either 1) the one-smart-guy approach (Apple), which doesn’t scale or, unfortunately, last, or 2) the crapshoot approach (Google) of trying a slew of ideas, one of which occasionally hits, but doesn’t survive competition past the first few iterations. Microsoft depends upon an orchestrated hoard of smart and persistent people who tease out what customers really want and need and then drive and iterate that value into our products. We call those people PMs.

Some of my equally arrogant developer peers are saying, “Oh please! Most PMs are useless and clueless. It’s developers who build the products. They’re the ones who make the magic.” Not all PMs are great, that’s true. But if technology were sufficient, then Windows Mobile Phone and Windows Tablet PC would have dominated the market. After all, both released many years before iPhone and iPad. Technology isn’t enough. You need to deliver great design and great experiences. That’s what PMs are responsible for doing.

Eric Aside

Of course, Windows Mobile Phone and Windows Tablet PC did have PM teams. However, PMs at the time were focused on enhancing features instead of experiences. Neither technology nor features were sufficient. Apple focused on great experiences and then waited until the technology was available to support those experiences, including price point.

Microsoft has learned the lesson of focusing on the customer’s experience. We learn, we iterate, we improve. Sometimes it takes a few versions to get it right, but we are persistent.

One other point: When I talk about design in relation to PMs, I’m referring to the aspects of design that define what the customer experience should be. Engineering design remains in the hands developers, testers, and the other engineering disciplines.

The right stuff

So what makes a great PM? Much has been written about this inside and outside of Microsoft. There are three core skills.

  • Great PMs know the customer. I mean really know the customer. I mean they live, breath, swim inside, and wallow among the great depths of the customer. They don’t just read market research reports. They follow customers around for days, observing them in their natural habitats. They get into their heads through focus groups, anthropological studies, terabytes of usage data, and whatever else it takes to understand and appreciate the very souls of customers.
  • Great PMs facilitate design. Design is an iterative, collaborative, multidisciplinary process. Someone has to facilitate it—bring all the disciplines together (dev, test, user research, design, product planning, marketing, operations, leadership, customer support, and business development), coordinate brainstorming and prototyping, weed out and enhance concepts, capture the most promising solutions, test out those concepts with customers, and do these steps over and over again as the design converges on a truly compelling and delightful product.
  • Great PMs focus the team. There are always far too many ideas, features, and requirements, and far too little time on the schedule, when developing a product. Someone must prioritize and organize the product backlog and schedule, provide laser focus to the team, and drive the team through product development to meet the schedule commitment made to partners and customers.

A PM who deeply knows the customer, effectively facilitates design, and focuses the team to release a quality product on time is a great PM.

Depends on your point of view

“Sure, but developers and testers also need to know the customer, facilitate design, and focus the team. Why do we need PMs?” Developers implement and testers evaluate. Yes, there’s design involved in both, but it’s implementation design and evaluation design, not experience design. Developers’ and testers’ viewpoints and roles shape their approach.

When developers listen to customers, they imagine fixing things. When testers listen to customers, they imagine trying things. We need people who listen to customers purely to understand them—with no agenda other than to deeply know what customers care about and what they wish to accomplish, independent of implementation or evaluation. Yes, the product can’t be built or validated without developers and testers, but a compelling and delightful experience won’t blossom without PMs.

They could be miles off course

Why are there so many bad PMs? There are several PM pitfalls.

  • Possessing superficial knowledge of the customer. Lazy or cocky PMs read a market report or try a couple of competitive products and then think they understand the customer. Worse yet, they think, “I am the customer.” Their products are doomed to mediocrity. Provide these PMs the humbling experience of talking to real customers, and engage them with peers who do grok the customer.
  • Dictating the design. Arrogant, ignorant, and insecure PMs believe they author the experience design, rather than facilitate it. These PMs go off to a cave, write the requirements and specs, and then return proudly to have their brilliance reviewed. Their products are doomed to slip, stink, and eventually sink. Design is an iterative, collaborative, multidisciplinary process. Insist on giving early feedback to bad PMs until they learn that they should iterate and involve others from the beginning.
  • Focusing on process. Anal or dictatorial PMs concern themselves with process instead of priorities. They come up with elaborate schemes to control the flow of information and execution of the project. When the project gets bogged down or fails to converge, they add more process, which typically makes things worse. For these PMs, return to first principles: what are we trying to build, why do we think customers will want it, and when should customers have it? Now, cut, crop, and close out everything else. Define an achievable plan based on actual prior team performance. Then execute with laser focus on the prize, not the process.

Pathetic PMs will say, “But Steve Jobs claimed to be the customer. He dictated the design and was anal and dictatorial about process. Apple has been hugely successful.”  Yes, that’s true. The problem is that you aren’t Steve Jobs. If you were Steve Jobs, you’d be CEO. The one-smart-guy approach can work brilliantly, but it doesn’t scale and it doesn’t last. Microsoft’s approach wins in the end with great PMs.

Eric Aside

Saying great PMs focus on “the prize, not the process” is like saying great PMs focus on the what instead of the how. Who looks after the how? That would be management. Management should drive the strategic plan AND the operational plan, as I talked about in “Is your PUM a bum?” (chapter 10).

Personally, I like standard release management at the division level, tied to scenario-focused engineering and Kanban (or Scrum) at the team level. However, great PMs (as defined here), great devs, and great testers can succeed using a wide variety of methods. My favorites are the ones I’ve found to be the most effective and efficient.

That’s what I’m talking about

When your PMs deeply understand the customer, they become a touchstone for decisions and tradeoffs. They can lay out a clear vision of what the customer needs and why. Great PMs constantly go back to customers to validate and update their deep connection.

When your PMs facilitate the design in an iterative, collaborative, and multidisciplinary way, everyone contributes their best ideas to the product, and all constraints and tradeoffs are transparent. There isn’t one design idea, there are hundreds. Successive iteration and refinement whittles down solutions until the best stands out. Customers win, along with the business.

When your PMs focus the team on what’s important to the customer—what the customer is trying to achieve and how the customer benefits—then tradeoffs are easier to make, priorities are easier to set, and deadlines are easier to hit. The team isn’t confused about what it is trying to build or why. The project moves forward with purpose, responds clearly to changes and distractions, and meets its release criteria without ambiguity.

If that sounds like your project, thank your PMs. If it doesn’t, maybe it’s time you found some good ones.

Eric Aside

How many good PMs does a project need? (What should be the ratio of PMs to devs and testers?) There’s no one simple answer, but basically, you need one PM for every feature team (every cross-discipline team of 4 to 8 engineers), one PM per high-level scenario, a project-wide release manager, a small PM team for sustained engineering, and PM management.

The one PM per high-level scenario is the role that many teams miss. Instead, teams have all PMs drive cross-group coordination around every scenario. This leads to overburdened PMs, too many PMs, poor orchestration, poor focus, poor prioritization, or all the above. You want one experienced PM to know each high-level customer scenario, facilitate the end-to-end design, and focus the larger organization on delivering that scenario—kind of a meta PM.

0712 PM – secret weapon or wasted headcount.wma

Comments (9)

  1. Anonymous says:

    You raise very good points, and the customer-centric attention that the PM role provides does lead to good executions.

    Sadly, the majority of PMs I've met in my career add little value and are not really engineers. I truly believe we can lose 3/4 of the PM code and we'd do better. In fact, the PM should be a very agile customer-centric engineer, with clear sensibilities around practicality and trade-offs.

  2. Anonymous says:

    Really? soon we will add Google and Bing, iPhone and WP? PM are definitely useful if the dev to PM ratio is like 5-10:1 instead of 1-2:1. Really!

  3. Anonymous says:

    What a cheap pandering article, Eric disappointed in you.

    You are just copy pasting from a textbook, without putting any effort into what actually goes on in the compony.

    Not only have the PMs I have seen add no value, but they actually hurt the dev's career sometimes . During calibration , there is a rule in many dev orgs that pm and test has to give stellar feedback about the dev, else they will be screwed. Most PMs know this and  often don't do anything after writing the intial spec. Dev has to not only code, but also hold scrum meetings, colloborate with other teams, deal with breaking issues etc while coding. Most PMs know that very well and are assured dev will not tell anything bad about them to prevent getting labelled in the "cannot get along with Pm" bucket

    Pm I have asks what did I do every week, and then copy paste's my email into thier email and broadcasts to the whole team as "feature crew status" email.

  4. Anonymous says:

    Great article. (In full disclosuse, yes I am a PM)

    Above under "Great PMs facilitate design" you mention bringing "all the disciplines together" to focus on the design. How about PMs enabling the post-release experience that our users receive? Maybe this was implied as a "high-level scenario"?

    Personally, I bring in operations and customer support early into the release so they are aware of the changes and can prepare ahead of time to support it. In additon, this enables a 2-way communication channel since their feedback is instrumental preparing for the next release, whatever the release cadence may be.

  5. Anonymous says:

    I think one could construct a more compelling argument that Microsoft's triumph over competitors in the past was a function of a better business model, rather than a special 'secret weapon' job discipline that no other organization had.  Bundling (ala Office), undercutting, OEM licensing, and a long list of other business maneuvers masked Microsoft's product deficits and won markets.  From my career experience at Novell, the customer needs assessment (called contextual inquiry) processes in practice with the WordPerfect groups were far ahead of Microsoft's at the time.

    By the logic of this article, Microsoft's failures in the marketplace are to be attributed to the PM discipline, too. If true, then the role has been so grossly ineffective that it is a liability.  But I don't think it is true: I think that is as much a fallacy as ascribing domination over competition to the role.  Culture, missteps from leadership, marketing failures are more likely culprits.

  6. Anonymous says:

    This article is a great and thank you for teaching us the basic element of our industry. My only comments is about the post comments. I always get the sense when i read Microsoftees response with disloyalty and in-secure. Not sure why??

  7. Anonymous says:

    I love the, PMs are not even really engineers, comment. I am a PM. I've never called myself an engineer. I've never thought of myself as an engineer. Why is, not an engineer, positioned as a criticism of PMs?

  8. Anonymous says:


    This is so funny I'm not going to finish it today; instead, I will save some to perk me up tomorrow as well.

    In my longer than I care to admit career I have seen many driven, productive, customer-centric, team-uniting, USEFUL PMs. None of them have been at Microsoft. Yet, some of them have worked at Microsoft at one time or another, where I suspect they have been the same backstabbing, disruptive, meeting-scheduling, "bring-me-up-to-speed-so-I-can-claim-your-work-in-an-email" nuisance.

    People become PMs at Microsoft for two reasons – first and foremost, because they cannot cut it as developers, and second – because they think they have superior BS skills. Then they spend their time trying to prove that talking louder in meetings is a contribution of the highest level. And their "superior human skills" drive them to be the first to start gaming the visibility game.

    To be constructive, here is my suggestion – every 6 months the Dev/QA team should vote on which PMs they want to keep employed, if any, and how much they should be paid.

  9. Anonymous says:

    Agree totally with comments here.

    We have too many PMs. They are one of the prime reasons for politics in MS