For most of my 10+ year's career at Microsoft, I've been in program management roles — from being a program manager responsible for a specific product feature to becoming a group program manager leading a team of program managers. It's a role that I really enjoy doing and over the years I have learned a lot about the program management discipline from a lot of smart people at Microsoft. This post focuses on the 'what' i.e. what do program managers do.
The first thing to note about the program manager role is that it's an unfortunate job title. As Steven Sinofsky wrote in his blog post PM at Microsoft back in 2005 "program managers do not program, nor do they manage". Well that isn't completely true – there are some PMs that write code (although that's not usually part of a PM's job) and there are PMs that manage other PMs (but not development and test teams). Also PMs play an important role in not only defining the software product, but also doing the project management.
I like to describe the PM role at Microsoft using the '3 Ds' – discover, design and deliver:
1) Discover (Framing the Landscape)
In order to understand and frame the landscape, the PM needs to gather as much data as possible about the market, customers, competitors, technology trends etc. There are lots of ways to accomplish this – market research reports, customer feedback, user surveys, usability studies, competitor product reviews, industry reports etc. The goal at this stage is to just gather data and start making some sense of the landscape.
The next step is to analyze this data and identify opportunities, gaps, trends in the market. One useful tool for distilling this data into key information is a SWOT analysis (strengths, weaknesses, opportunities & threats). In simplest terms you identify the strengths and weaknesses of your business/product (internal) and then identify the opportunities and threats in the market (external). Whatever tool you use, the goal at this stage is to develop a deeper understanding of the landscape.
Once the PM understands the landscape, it's time to clearly define the opportunity. Usually this doesn't just emerge once you've understood the landscape – it takes a little more work. One useful way to develop those ideas is to start discussing your findings with other members of the team i.e. other PMs, developers, testers, product planners, marketing, partners etc. This will eventually get you to a point where you feel good about a particular opportunity and are ready to tell a story.
Telling the story is really about answering the what, who & why questions i.e. what problem are you going to solve, who are you going to solve it for, why does this problem need to be solved etc. By now the PM can clearly describe the landscape and use data to backup key points. You'll know when you're onto something when people clearly understand what you're proposing and why. And when your story not only resonates with them but starts to get people excited.
2) Design (Defining What to Build)
Once the landscape has been framed, the PM must help define what to build. A good place to start is by clarifying the value proposition i.e. what problems will you solve for your customers. The PM will then work with the team to establish SMART goals including the non-goals i.e. what you will not try to do (in order to manage the project scope). And then work with key stakeholders to define and prioritize the requirements — which will eventually get translated into scenarios.
There's no silver-bullet for figuring out what to build — as they say, the best way to have great ideas is to have lots of ideas (good or bad). The PM must help foster the right environment for idea generation e.g. establishing brainstorming 'ground rules', involving the right people etc. Then these ideas need to be validated using relevant data, evaluating the trade-offs and by continuously asking 'will this solve our customers' problem?'. And then the PM must help the team get closure by selecting a concept or idea.
Getting to the right design takes multiple iterations and feedback loops. The PM needs to clearly communicate the early ideas (whiteboards, sketches, emails etc.) and gather lots of feedback on the proposed design. Both functionality and user experience (UX) need to be considered at this stage, so it's critical to involve UX designers early in the process. After several iterations, the PM should have enough information to start producing the detailed specifications (spec).
The spec is typically a document that provides very detailed information on how the final product should look and function. But in an agile world, it's sometimes more effective to write a shorter spec and communicate the details of the design with a prototype. In some cases, this could be a set of design comps and in other cases it could be a working mockup of the final product. There are lots of great prototyping tools available — a couple of my favorites are Balsamiq and iMockups for iPad.
3) Deliver (Shipping the Right Product On Time)
In this phase, the PM's job is to ensure that the product team ships the right product on time. This means working with the rest of the product team (development and test) to understand work item estimates, develop a schedule and make the right trade-offs e.g. cutting features if necessary. The PM must take on a leadership role in developing a solid plan with the rest of the product team and effectively anticipating and identifying potential issues.
The PM also spends a lot of time refining the plan during this phase e.g. clarifying requirements, working with developers to resolve feature design challenges etc. And with so much focus at this stage on how to build the product, it can be easy to sometimes forget why you're building it. So ensuring that everyone keeps the big picture in mind is critical. The PM needs to continuously remind the rest of the team about the value proposition and ensure that the final product will actually solve the customer's problems.
As early versions of the product become available, the PM can start to get real user feedback e.g. is the product intuitive to use, does it address the real world scenarios, do customers actually like what they see etc. This provides the product team with incredibly value information about the product they're building and it's an opportunity to refine the design and make additional improvements to ensure that the team ships the right product. It can also help to identify major customer issues that may require the team to go back to the drawing board.
And finally, the PM needs to provide effective communication across the board. There are always a lot of moving parts on any software development project and the PM is the key person to ensure that everyone on the team knows what's going on i.e. status of the project, issues, risks, dependencies, early customer feedback etc.
