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?
For more on the changing role of test, read Test don’t get no respect and “Undisciplined” (chapter 4).
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.
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.
So what makes a great PM? Much has been written about this inside and outside of Microsoft. There are three core skills.
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.
“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.
Why are there so many bad PMs? There are several PM pitfalls.
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.
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.
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.
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.