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. 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—What’s so special about specialization?.

We’re on a mission

Years ago, Borland’s Turbo suite of compilers dominated Microsoft’s compilers, until Visual Studio (now in its 15^th 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?.

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.