If you are considering a job in program management (PM) or attempting to understand what program managers do, you should read this!
This paper will tell you everything and nothing about program management. It reveals the ‘zen’ of the program management discipline. It is not intended to be an interpretation of the Microsoft Career Stage Profiles for Program Management or an instruction manual for how to be an effective program manager. Instead, it expresses what is unique about program management, both in aptitude and role. Enjoy!
Version 1.0e: February 14, 2007
The ‘Zen’ of Program Management
Program managers are the champions of
the value proposition.
In early planning, we immerse ourselves in customer needs, competitive landscape, technological trends and businesses priorities, and from this cacophony we distill a clear and focused value proposition.
We articulate what the team is signing up to deliver, for whom they are delivering it, and the purpose it is intended to serve.
This articulation of the value proposition serves as a “frame” within which the team can make decisions about features, designs, timelines, and priorities.
As the project moves from planning into design, we paint the detailed picture of what the team will ship, through storyboards, prototypes, and most significantly through specs.
As the project moves from design into implementation and on to the endgame, we keep perspective to ensure that tactical implementation decisions fit within the frame of the value proposition.
Ultimately, we ensure that the feature or product presents a strong value proposition and that the implementation actually delivers the promised value.
The ‘zen’ of program management lies in connecting the customer and value proposition with an actual product or service. The program manager brings the team together to make this connection between aspirations and ends.
The goal of this paper is to provide deeper insight into the program management role and clearly identify what makes program managers unique and uniquely valuable. While this document focuses on the value of program management, this value is only realized within the context of the broader team. Teamwork is paramount, and no one role carries the team.
This paper covers the three major steps of the software product cycle, and the value that program managers bring to each step:
- Planning: Framing the Landscape
- Design: Defining the Solution
- Execution: Delivering on the Value Proposition
Planning: Framing the Landscape
The unlimited potential of software makes program management an incredibly exciting job. The unlimited potential of software also makes program management an incredibly important job. At every milestone of every product cycle, feature teams face an essentially infinite set of possibilities. They can build almost anything they dream up. But to succeed, the team has to make smart choices about where to focus and what to build. In the face of endless possibility, how do feature teams make these choices?
Framing is the art of identifying what is truly important and separating the “could” from the “should.” Early in the planning stages of a project, program managers work with customers, planners, and other team members to define this frame and ensure that every member of the team understands and internalizes it.
To create the frame, the program manager starts by asking some broad questions.
- Who are the customers and what are their needs and priorities?
- What is happening in the marketplace? What are competitors doing and what are our options for responding and differentiating?
- How is technology changing and what possibilities does it offer our customers?
- What are the priorities for our business?
The answers to these questions paint a landscape in which a product and its features will be built.
The purpose of a frame is to narrow the focus on a clear and compelling vision that fits within this landscape. This link between vision and landscape is critical. A vision without this context is fragile and fails to provide teams with the basis for making the myriad of day to day decisions they inevitably face.
So, how does a program manager go about creating such a frame? The three key elements are gathering information, grokking the space, and getting the team up to speed.
The first step is to ensure that you, the program manager, have access to the right information to understand the landscape in which your product or service exists or will exist. There is a wealth of information available to any program manager willing to make the effort to find it: customer studies and surveys, customer satisfaction indexes, personas, usability data, SQM/Watson data, online newsgroups, customer advisory boards, partner feedback, product support reports, industry analysis, competitive product reviews, focus group results, and more.
The need to ground your work and your team’s work in information holds true whether you are a group program manager responsible for defining a product vision or an individual contributor designing a specific feature.
Don’t forget your colleagues in Product Planning, Product Marketing, MSR, and outside the company. They are great allies in collecting and distilling this information. If, however, you don’t have a planner or marketer to turn to, you are still responsible for getting this information for your team. Program managers must be resourceful in finding ways to collect this information. You ensure that the team has access to this information early enough to provide the context necessary to frame the project.
A word of caution: There is an unlimited amount of information out there, but it can be tough to find the answers you are looking for. Don’t get frustrated. Remember that you aren’t really looking for specific answers. You are looking to understand the space and gain context. What you learn may even lead to more questions and conflicting priorities. Gathering information is not like hunting for Easter eggs. If you think of this as a search for answers, you may find yourself on an endless quest. Gathering information is just a starting point—your work isn’t done here, so take what you learn and move forward.
Grokking the Space
Now that you are immersed in information about customers, competitors and more, what does it tell you? Wouldn’t it be great if you could apply a simple formula to produce a provably correct roadmap for your product? You can stop searching the Internet for that formula and look in the mirror. Even with all the data in the world, you can’t prove what features to build or what design to pursue. These decisions are part art and part science and mastering that mix is an important part of being a program manager.
Get your head around the data; mull it over; talk to your teammates and others about what you’ve learned and where it should lead you. Some of this is about determining what information is noise and what is signal. Some is about finding connections between disconnected or seemingly disparate pieces of information. Ultimately, it’s about getting to the point where you can see what is meaningful and get ready to tell the story of where the real opportunities lie.
Don’t be surprised if you feel like you’re staring at a wealth of information and seeing no big patterns or deeper meaning. It takes time, iteration, and even conversation to coax direction out of data. Often, it is only after annoying your co-workers with drawn out whiteboard discussions with far too many little boxes and several abandoned slide decks that it all start to make sense to us.
Getting the Team Up to Speed
Once you understand the context and are ready to focus on a specific opportunity, your job is to share your understanding with your team. If you are going to be impactful, it is only through sharing your knowledge, ideas, and understanding with your co-workers. To do this successfully you have to create easily digestible ways for your team to understand the broad landscape and the frame that makes the opportunities clear, demonstrates their value, and provides clear priorities. Effectively communicating this is the key to helping your teammates understand how you got from “Our competitors are beating us and one of the biggest reasons is that they have a better three-year TCO” to “We need to enable customers to deploy our solution in four hours or less,” and why this leap makes sense.
A note of caution here. Do not fall into this classic program manager trap: You gather the information, grok the space, and come back to your team to report, “Hey team, I’ve figured it all out – here’s what we need to do.” Teams HATE that! Instead of following your well researched plan, they’ll probably end up tuning you out instead. We hire smart people and they want to share your understanding, not just hear your conclusions. To be effective, you have to share the context and the thinking that led you from the data to your conclusions before your team is going to get on board. In many cases, the process of sharing this information can actually help shape and refine your ideas… don’t miss out on this opportunity to learn from the collective brainpower of your teammates!
Recognizing this reality, great program managers take the time to review the information and sources they’ve gathered with their peers and feature teams, highlight key data points, and share their reasoning about how it all connects. Remember, the first role of the program manager is to frame the project in a way that the team can understand and use to set direction and priorities. Your role isn’t handing out decisions, it’s empowering the team with the understanding and shared framework to make these decisions throughout the lifecycle of the product.
Design: Defining the Solution
After the problem has been framed comes the hard work of finding a solution to the problem. For every problem there are usually dozens of potential solutions, and more often than not, the best solution is a tradeoff between many competing factors: cost, resources, elegance, robustness, features, technology constraints, compatibility requirements, etc. If the problem has been well framed, the framing can be used to guide the program manager and the feature team to the best set of tradeoffs.
Before you begin thinking about a concrete design, establish your feature’s value proposition. A value proposition is a clear and specific statement of the benefits that your feature will bring to its users. If your users can say things like “this feature helps me to get my job done,” or “this feature is fun to use,” or “this feature saves me lots of time,” then the feature has a value proposition. Now go one step further: recall the framing, and ask whether the value proposition lines up with the value you actually want to deliver. Many features (and products) have failed, not because they didn’t deliver some value, but because they delivered the wrong value.
To go from the frame and value proposition stage to the design stage, the three key steps are going from blank page to concept,iterating to a great design, and communicating the design.
Going From Blank Page to Concept
The key to getting away from the awful emptiness of the initial blank page (or blank whiteboard or empty slide deck) is to be willing to make a proposal, take a stand, or float an idea. Designing a solution is not like solving an algebra problem: there is no provable right answer that you can find all by yourself. Start with an idea for a solution – any idea – and see if you can explain it to your colleagues. Share your rough thoughts in e-mails, short documents, or whiteboard scribbles. Visit other team members in their offices to brainstorm.
You’ll probably discover right away that even you don’t understand your ideas well enough to explain them. Once you get over that first embarrassing hurdle, you’ll quickly find the good and bad stuff in your proposed solution, and the very smart people you work with every day will inundate you with ideas for getting to a better solution. (Remember, your job is to lead the effort to get to a great solution … not to be the one with all the great ideas.)
Iterating to a Great Design
Embrace iteration, but keep it under control. Getting your initial ideas into the open increases the amount of brainpower working on the design, which is a very good thing. It can also increase the amount of noise and confusion, so be the person who drives the process forward through discrete iterative cycles. Gather feedback from the previous cycle, hold onto the good ideas and let go of the bad ones, publish a new version of the proposed design, and then drive your team of collaborators to focus on the places in the design that still need attention. As you grow as a program manager, you will encounter lots of fun and useful design techniques (storyboarding, contextual inquiry, etc.), but managing and driving effective iteration is the most important skill of all.
With each iteration, check again that the feature delivers a value proposition that lines up with the original framing of the problem.
Expect dissent and disagreement as part of the process, and always remember that it’s not personal. When you are driving a feature team of smart people towards a design, you can be sure that lots of great ideas will emerge through debate and argument. But you will also be expected to make judgment calls. You won’t always have everybody agreeing with your judgments, but if a decision has to be made in order to keep the iterative design process moving forward, then you need to take a risk and make the call.
Getting good at exploiting iteration also means that you’ll get good at knowing which parts of the design need to be nailed down early, and which can be finalized later.
As you and your feature team iterate on the design, validate the emerging solution by soliciting feedback from stakeholders, and by pulling in specialists from other disciplines for their input. Usability engineers can determine whether the proposed interface is easy to use, including use by people with disabilities. Early customer feedback on a working prototype can provide invaluable confirmation whether your solution will work. Security specialists can spot potential vulnerabilities, even at early design stages. Other program managers – either peers or managers – can be a treasure trove of great ideas, or warnings of paths to avoid.
Communicating the Design
Once the design is fleshed out, it needs to be captured and communicated so that all members of the team share a common picture of what the team is building. In most cases, the final communicated form of the design will be a written specification document (“the spec”). Key benefits to capturing a design in a high-quality spec include:
- A feature is not testable unless there is a clear statement of its correct function. If there’s no spec to act as an “oracle”, or the spec is incomplete, incorrect, or ambiguous, then there’s no testing, only experimentation and argument.
- The spec records the version of the design that has the widest and most explicit buy-in from all concerned: the feature team, product team management, and other stakeholders.
- The details of the design affect far more people than just the developers who implement the feature and the testers who test it: there will also be translators, documentation authors, trainers, and sustaining engineers, to name a few.
- Regulatory compliance is an increasingly important fact of life for Microsoft, and compliance often involves making design and implementation details available for regulatory scrutiny.
Attention to detail and precision are the keys to writing quality specifications. The spec needs to be rich in detail, starting with the customer scenarios that motivate the design and progressing all the way to fully describing the interfaces and actions of every aspect of the feature. Draw every dialog. Describe every action. Consider every word that a user might see. If you don’t do these things, then somebody will make these design decisions for you, probably in haste and without the benefit of your understanding of the framing of the problem and the subtleties of the solution. The wrong solution will be implemented, and the documentary record will not reflect reality.
Execution: Delivering on the Value Proposition
Once you have framed the problem and designed a solution, it’s all about execution – that is, finishing what you’ve started. To make this happen, program managers immerse themselves in the details that make a product great. This includes the details of scenarios, designs and specifications, customer discussions, shiproom meetings, and a myriad of little tasks and deadlines that must be attended to. Maintaining the integrity between the big picture and the small details is a key part of the program management role and great program managers know how to transition back and forth between these roles as the context requires.
Not only must you help usher the bits out the door, but you must also be the guardian of the value proposition. You must ensure that what ships are the right experiences, the right features, and the right value proposition on the right schedule. To do this well, the best program managers adopt an “owner mentality” — they feel a strong drive to make sure that the right things happen. This drive can be critical to push through artificial barriers, to adapt to changing circumstances, and to drive the project to success.
Validating Your Product with Customers and Partners
Just because you completed all your homework to understand the customer and context and thoughtfully iterated on perfecting the design does not guarantee that your design will necessarily hit home with customers as you envisioned. As the product takes shape, program managers play a valuable role in validating the design with customers and partners. The sooner you obtain quality feedback, the sooner you can adjust your plan, if necessary. Even before a design is implemented, tools like slides and storyboards can be used to solicit early feedback. That said, there will always be lessons that can only be learned as the product is built. Validating early builds or betas with customers is essential and program managers play a vital role in engaging customers in feedback programs and consolidating feedback from betas, usability studies, and other sources. Once the feedback starts rolling in, it is also the program manager’s responsibility and role to guide the team in responding to feedback. What should be changed immediately? What can wait until the next version? How should the responses be compiled to respond to customers? Where could better documentation or a small design change make a major impact on the customer experience?
Speaking with a Clear Perspective and a Clear Voice
As designs transform into implementation, even the best plans and designs need to be refined. If left unattended, small design changes can result in big threats to the core value proposition you and your team set out to deliver. Program managers are vigilant advocates for the customer and value proposition throughout every stage in the project, including execution. The reality of software development is that compromises must be made, features cut, and bugs punted. To make the right compromises, however, program managers provide a clear perspective and a clear voice that keeps reframing the problem (or more accurately, reasserting the original frame).
As a project nears its end, things often become complicated and intense. Teams come under pressure to cut features, punt bugs, crises arise, and features may not live up to expectations. In most cases, when you’ve framed the problem correctly, you should be able to use this framework to prioritize tradeoffs and make endgame decisions. In some cases, however, the context that informed your initial framing may have shifted and you may have to go back and reframe the problem, recreate a solution, or even abandon the effort altogether. The strongest program managers know “when the patient cannot be saved” and they do not allow emotions or personal interests to cloud an objective perspective.
The program management perspective is also critical in assessing whether or not a product is ready to ship. Will it deliver enough customer value to win in the marketplace? Is the user experience right for customers? Will it delight or disappoint? Will it exceed, meet, or fall short of the marketing promise? Having spent many hours with customers, marketing, usability, and with the product itself, program managers are in an ideal position to guide the endgame and ensure that the team works not only toward delivering on time, but towards delivering the right product.
Myths of Program Management
Program management has something of a reputation around Microsoft. Depending on who you talk to, this reputation ranges from hero to houseboy, but there are a few common myths about the role of the program manager that we think it’s time to eliminate.
- Myth: The program manager’s job is to take notes and schedule meetings: Program managers often take notes and schedule meetings, but not because everyone else’s time is more valuable, but because they realize the value in documenting decisions and building consensus. They also use these activities to help set an agenda, focus decisions, and ensure that the outcome is clearly captured. Having a record of what decisions were made, and why, is an essential part of the solution process from a program management perspective and good engineering in aggregate. Often, you’ll see leaders in other disciplines playing these roles because they recognize the value. Note taking and scheduling meetings are not skills unique to program management.
- Myth: The program manager is primarily an evangelist: Program managers are generally good public speakers and can communicate well with a variety of audiences. That said, the primary role of program management is as part of the product development team, not as an internal or external marketing resource. The fact that program managers tend to be strong communicators does not mean that program managers should spend most of their time explaining the plan of record to customers or other groups at Microsoft. Nor does it mean that every speaking engagement should be assigned to a program manager. Overloading the program management role with presentations takes away time from their higher priority roles designing software, regularly engaging with feature teams to advocate for the customer and preserve the value proposition. Speaking engagements can be valuable for program managers, as well as people in other roles … as long as this doesn’t become the focus of the role.
- Myth: “PM” stands for “project manager”: The role of program management is fundamentally about shaping software, not just managing the processes by which software is shaped. While there may be a justification to have full time project managers for some projects, this is generally just a small part of the program manager role. Even if program managers do end up playing this role full time for some period of time, the Career Stage Profiles for Program Management require a broader skill set for long term success. A good program manager must be able to challenge developers and testers and suggest alternative courses of action and this can be done effectively only when the program manager has a deep understanding of the project and knowledge of the technologies and approaches being used in the solution. A program manager who can only comment on the number of outstanding tasks, who they are assigned to, and whether they are ahead of or behind schedule, fails to provide insight into the most important state of a project — whether the product is on track to deliver on the value proposition and meet customer needs. Furthermore, project management skills are not unique to program management and can often be shared by other disciplines. Who better to drive the schedule than the developers who are delivering the code? Who better to manage the release process than testers who are acutely aware of the current state of the product?
- Myth: Program managers should get coffee for developers: A program manager who gets coffee or lunch for a developer in the final hour of fixing the last gnarly bug before release is simply being a good teammate. This does not mean that program managers exist only to serve developers (literally or figuratively). Program managers exist, along with their counterparts in development and testing, to serve the customer. The best product teams view the roles of program management, development and testing as all having vital and necessary roles in the production of great software.
- Myth: The program manager is “in charge”: You are a single member of a team – a coequal team member. While it is true that the best program managers adopt an ownership mentality in driving to deliver features, it is also true that the best teams are comprised of team members that all adopt an ownership mentality for producing the right product. You will be most successful when you encourage all team members to feel like owners. Think of your development and testing partners as your business partners in a small business – all of you are owners and all of you make critical contributions to the success of the team. High performing teams naturally divide into differing roles based on personality strengths and preferences. However, no one grants “in charge” status to program managers or anyone else. (There are several variants of this myth. Some examples include “Program managers are responsible for strategy,” “Program managers write specification documents in isolation,” and “Only program managers talk with customers.” They are all wrong.)
Personality Traits of Successful Program Managers
How can you determine if you are a “natural” program manager — someone with the innate skills, aptitudes, and personality traits that exemplify the ‘zen’ of program management? If you spend time with successful program managers, you will find that some trends emerge. We’ve picked five natural tendencies and behaviors, illustrated by short sound-bites, that we believe are common among successful program managers at every level (and in many cases manifested themselves long before the individual became a program manager).
While we are not attempting to illustrate the full set of skills and abilities mapped by the Career Stage Profiles (CSPs) for Program Management, it should be easy to see the link between these personality traits and the progression of the CSPs. Does this mean that all program managers have similar personalities? No. Are program managers born or are they a product of their environment (trained)? The short answer is “both.” A significant portion of the skills in the program management CSPs can be learned. The personality traits and natural tendencies discussed below, however, appear to be factors in whether or not individuals progress from “good enough” program managers to “great” program managers.
- “Do we really have a plan?” Even in the midst of action, great program managers will step back and consider whether they (and their friends and colleagues) are really operating on a solid plan. If you are thinking about a career in program management, you should be comfortable challenging the plan of record, initiating action, and leading the development of a plan. In fact, program managers are often uncomfortable until their team (or outside work, their friend or family member) has a crisp coherent set of achievable and believable goals against which to execute.
- “If I were designing that <insert random everyday object>, I would …” Great program managers are instinctive designers who crave creativity, design, and problem solving as part of their daily lives. As compulsive problem solvers, they often find themselves in situations like examining the climate controls in a friend’s new car and questioning whether they adequately serve their purpose, and then coming up with potential enhancements for the next generation of the car.
- “Here’s a great movie we should go see.” Great program managers are often natural leaders even outside the workplace. You know those moments when a large group is making a decision about something as simple as picking a movie? There is no “right” answer, so building consensus can be tough. The natural program manager is likely to at least float a proposal or facilitate consensus to get the group moving. If you’re considering a future in program management, you should not be afraid of leading a discussion, taking charge of a meeting, or driving a team to consensus, even if you are not the best qualified to make a decision on your own. Rather than becoming paralyzed by a lack of direction, great program managers are energized and challenged by ambiguity and driven to move things forward.
- “Let me tell you a story…” Great program managers are comfortable and often passionate communicators, with the patience to explain the whole story. They tend to use analogies and stories to communicate, whether talking about politics, hobbies, or products. They are the people who send out detailed, but concise, directions when inviting someone to their house. This tendency toward inspiring and guiding communication often translates into energetic and motivating rallying cries capable of inspiring a team towards a common direction or initiative. If you take pleasure in making sense out of complexity and confusion, you may be a natural program manager.
- “Here’s what I think (though I may be wrong).” Great program managers are natural collaborators who listen to ideas, facilitate discussion, and collect alternate data or differing point of views. They tend to not to be afraid of dissent (giving or receiving) and are willing to take risks by putting their own ideas out there for feedback. These people will even try things where failure is a very real possibility because they intuitively know that even if they fail, they’ll learn something valuable from doing so. If you meet a great and well-established program manager, ask if they’ve ever failed spectacularly. You will likely be met with a good story and lessons learned. If you are inclined to explain away failed projects or pursuits or if you’re confident that you’ve never failed, you might think twice about pursuing a program management profession.
So, while there is no one type of person that makes a successful program manager, there are some common “symptoms” that suggest a tendency toward the discipline. If you see yourself in the descriptions above, you just may have the potential to become a great program manager!
PM Personality Traits & Attributes
Problem Solving and Ownership
Customers and Partners
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, any companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.
© 2007 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.