PM at Microsoft

While at Stanford this week I was asked by a number of PM (program manager) candidates to talk about the PM role at Microsoft.  The PM role is unique to Microsoft and was actually created in response to developing software that is more usable and at the same time pushes the state of the art of technology.  So when we talk about PM at Microsoft, we're talking from a perspective of creating and evolving the role over the lifetime of the PC industry.

I have been both a PM and an SDE (software design engineer) during my career at Microsoft.  When I was recruited I started off as an SDE candidate and then I learned about PM during the course of my interviews and I thought "COOL!" that has to be a job for me--after all it sure sounds like an incredibly cool role, since it has the title "manager" in it and if you read/hear the description it sure sounds like you're running the show. The job title "program manager" is a bit of a misnomer, since program managers do not program nor do they manage--go figure.  I went with SDE because I wanted to write code in my job.  After being an SDE for 4 years I moved to program management.  I think that was a good move for me because while I like to think I was competent at development, I was probably never going to hit it out of the park with my ability to write code, but I think what I wasn’t able to do in writing code I made up for with the skills required of a program manager 🙂

What follows is a description of program management from a PM perspective -- that means through the lens of a PM.  It is also an analytical description based on my experience.  I'm not trying to hype the job or make it seem too over the top.  In fact, I've recently talked with an number of candidates who have been told of PM roles at other companies and my feeling is that they are not being told the whole story.  So with my blog I try to be a bit more complete and not "sell".  This might make it seem like there's no room for change or to impact the definition of the role, but that is not the case.  What I'm describing is in constant evolution and it is the members of the team that are constantly evolving the role.  PM is a role that has a lot of responsibility but you also define it--working in partnership with expert designers, clever developers, super smart testers, etc. you all work together to define the product AND the responsibilities each of you have.  PM is one equal part of a whole system. 

Program managers got started at Microsoft while developing Excel for the Macintosh.  The challenge the company saw was that we were stretched thin trying to push the state of the art in technology (in this case develop for a brand new OS using brand new Graphical User Interface concepts) and so the developers were very busy just trying to make things like printing, display, graphics, etc. work as well as trying to develop new algorithms for spreadsheets and modeling.  That meant that the place where we were not focusing enough attention was on the usability or the scenarios for how people would use the software.  In a very classic sense the high order bit of our development was the code--this is pretty classic in most organizations today where you really only see development and test (sometimes called QA) and to the degree that there is input from users/customers this is usually done by the demand generation or marketing team (called product managers in Silicon Valley).  So at Microsoft a new role was created in Program Management with the explicit goal of partnering with development and working through the entire product cycle as the advocate for end-users and customers. 

The challenge of trying to write code using the latest technologies and bringing ever more complex scenarios to end-users in a simple way continues today as we build web sites (OfficeOnline), server products like SharePoint, and entirely new products like OneNote, as well as build whole new user experiences to replace the aging menus/toolbar paradigm.

Up front I would say that the PM role at Microsoft is both unique and one that has unlimited potential -- it is PMs that can bring together a team and rally them around a new idea and bring it to market (like OneNote, InfoPath).  It is PMs that can tackle a business problem and work with marketing and sales to really solve a big customer issue with unique and innovative software (like SharePoint Portal Server).  It is PMs that can take a technology like XML or graphics and turn it into an end-user feature benefitting 400 million people (Office Open XML format or the new graphics functionality in Office12).  I could go on and paint a very emotional picture, but let's spend some time digging into the more analytical aspects of the job.

Where developers were focused on code, architecture, performance, and engineering, the PM would focus on the big picture of "what are we trying to do" and on the details of the user experience, the feature set, the way the product will get used.  In fact the job has matured significantly and it is almost impossible to document a complete list of the responsibilities of program management.  One way to do that is to list the sections of a specification for features in Office that a PM would complete before the code gets written which includes nailing the scenario you are solving for, the worldwide implications (will your work make sense to customers in China, India, Estonia), how will developer customers extend the product (object models, programmability), is the product secure and is privacy maintained, what are the other features your work interacts with, will the feature be responsive and performant, and more.  These are critical parts of the design of any product, and when you will have 400 million potential customers thinking these through before you start the work is critical.

As an aside a lot has been said lately about "agile development".  A key benefit of program management is that we are far more agile because we have program management.  That can be counter-intuitive (even for many developers at Microsoft who might be waiting for their PM to iron out the spec).  But the idea that you can just start writing code without having a clear view of the details and specification is a recipe for a poorly architected features.  A great PM knows when the details are thought through enough to begin and a great developer knows when they can start coding even without the details for sure.  But like building a house--you don't start without the plans.  While software is "soft" the cost of remodeling or rebuilding is no different than if you decide the walls are in the wrong place or you forgot to leave room for the HVAC system--sometimes because we don't have material costs in software we think that "rewriting" is perfectly ok.  That generally works super well in two cases.  First, if the program is small then of course you can rewrite it.  In the commercial software world most software projects are not the work of one or two people--in fact one way to think of it is that if a project is only the work of one or two people (or is only a 100KLOC) then the economic value (and thus the impact) of that product is probably pretty finite (at the very least a competitor is likely to catch up very quickly).  And second, rewriting works well when you are looking backwards and re-doing what has been done (like cloning an existing product, implementing something for the n-th time).  When you're doing innovative work, the time spent on design and analysis pays off handsomely in the ability to develop a complete program and to have something of lasting economic value.  AND when you have a process that embraces design and up front thinking you also find your development much more agile because when you do get the code in the hands of customers--after 2 months or 2 years--there is time to respond and react with changes because you are not overwhelmed with the basics.

The last point is worth re-emphasizing.  There's a school of thought that just getting your software out in beta and then "reacting" to the feedback is the best way to get the product done.  Again, this tends to work for products that already have a definition you are chasing of if you're interested in incremental feedback.  So if you're building an email experience and release it in beta, your customers/users can help you to prioritize which features in the universe of email to add next assuming you did not have all of them up front.  But if you're doing something new and innovative or more importantly if you want more than incremental feedback then you need to have much more sophisticated mechanisms than just beta feedback from power users.  Most importantly, the role of PM is to represent all customers, not just the ones who do beta tests or the ones who take the time to send in feedback or use early products.  A key skill of program management is to have empathy with a broad range of customers.  Often when you are just getting started you will see how easy it is to over-emphasize early power user feedback or anecdotes over broad based feedback.  Don't get me wrong, power users are great but they are just one type of user.  A great advocate for the "little guy" is Walt Mossberg and he really does point out when you're missing the mark on a product and too focused on "techies" as he calls them.  The bottom line is that most people are not techies, but most beta customers and most early adopters are so you as a PM have to do the leg work to validate your work with a broader audience. 

Before talking about what PM does specifically it is important to look at PM in the context of the relationships with the others that contribute to building products.  A PM serves as the coordinating point where all the disciplines come together--this is why you can think of the PM as being the hub.  What is critical about the Microsoft PM role is that all the different people serve as a "virtual team" building the product--the PM does not have to go pull them together but rather has to help get everyone aligned.  The resources for a project are dedicated to the project--these resources include development, test, product planning, usability, and product design.  Each role brings a unique perspective a unique set of skills to the product development process.  While you can often be someone who has an affinity for another discipline, rarely can any one person bring all of these skills and experiences.  And I can promise that any project of significance really needs the specialized skills to do a world class job and build a sustainable and uniquely innovative product.  I should probably write a blog like this on each role--maybe after the holidays!

  • Development -- developers write the code.  They are in charge of the code's architecture, the performance, the reliability, the security, and getting the functionality into the product. Of course development is at the core of what we do as a software company, but it cannot stand on its own.
  • Test -- software design engineers in test insure the quality of the product but more importantly that the product ultimately meets the needs of the customer we set out to meet.  SDETs will review all specifications as first class members of the team and use their perspective and experience in working with PM and SDEs to insure that the product is not going to be fragile and that it will be possible to insure a successful implementation.
  • Usability -- usability engineers validate the designs of our software and incorporate the statistical understanding of customers into the process. Microsoft was an early pioneer in integrating usability in the product development process (though some might say how in the world we released the Hot Dog Stand theme if we had usability).  Many usability team members have PhDs in HCI or related research areas such as anthropology, and many are undergraduates with a HCI or psychology background.  These team members design mechanisms to test and validate designs and design assumptions.
  • Product Design -- Design work in partnership with PM to develop the interaction model for our products and also own the overall product look and feel.  While many companies use design for "graphical design" (which we do) our designers are expert in computer interaction--many have studied at programs like Delft's or CMU.  When you look at the new user interface in Office12 what you see is a strong collaboration between the PM experts and the Design and Usability experts.
  • Product Planning -- our planners are experts in understanding the market place and understanding what our customers need from software.  Planners own research and communicating that research to the product team PMs and to the executives deciding the overall goals of a release.  Planners are assigned to broad technology and business areas (collaboration, business intelligence) where they become expert in all the products and solutions on the market and how Microsoft can offer customers improvements over what is in the market.  Many planners have business background and have worked in marketing before.

Many companies will "sell" you on being able to do many of these different things from one job.  This is just not a reality that exists and I always feel a bit bad for folks who believe this.  There are two times I hear this a bunch.  First is at startups you hear "come join us from college and you can own all of this".  Of course at a startup the real experience is that you are the college hire, which means you will do the grunt work while the founders and the venture people do all the strategic work--so you might find yourself setting up the build machines rather than interacting with customers.  Second, I hear this a lot when companies are selling against Microsoft and point out that "at our company we do not specialize and everyone does everything".  This is another "well in reality..." situation, since of course even when I have seen companies that claim to do the specifications or customer research and up front planning they do that work from Product Management, and those people are just as specialized, they just report to the marketing team.  And we know what that means, which is when push comes to shove the marketing team will need to use every hand to get out there and generate the business and sell--so even if there is a single group that does the work, those roles are specialized, and rarely dedicated specifically to the role.  These are my experiences and of course your specific situation might be different.  I've just seen these patterns repeat themselves over many years of hiring students and having them come back to Microsoft after a short experience with something like that.

It is worth talking about the size of the PM team for a bit.  In Office our PM teams are small (our dev teams are usually about 20-30 developers as talked about previously).  The entire user interface for Office12 was developed by a team of about 12 program managers--imagine that 12 program managers did all the work to totally define the new interaction model for 400M customers of Office.  But along with the fact that the team is small is the fact that a team like this is also one where even the newest members of the team receive significant mentorship and training from a very senior member of Microsoft (you can watch this video to meet the head of the user interface PM team).  So you have the biggest impact you could have in designing software while receiving a very high level of management attention.  And then of course each PM has developers they are responsible to equip with features and specs -- the whole user interface development team was less than 30 people (so about 2 devs for each PM).  A critical part about PM (also one that is unique for Microsoft) is that as a PM you have dedicated developers for your feature area--your job is to get the most out of those developers in terms of bang for the buck by having great feature ideas and great specs to get them done. 

So what does a program manager do?  Well there are three phases to program management: learn, convince, spec, refine.  These roughly mirror the product development timeline written about previously.  Do keep in mind that the timeline is not fixed--rather the phases of the timeline are.  So if we're doing a 12 month project then the time is divided accordingly, same as if the project is 24 or 30 months.

Learn --> Output of learning is a prototype

During the learn phase, program managers spend their time learning about customer problems and learning about the products and technologies out there that are relevant to these problems.  There is a lot of work with planning to understand competitive products or new products in the marketplace.  As you can imagine, customers have huge challenges in getting their computing systems to do what they need.  So often we will spend days at a customer's place of business learning from them and watching them trying to get their work done.  A great example of this is the work we did to understand how customers manage documents in an organization.  It is easy to see that organizations like law firms or pharmaceuticals are heavily dependent on the flow of documents in an organization (contracts, drug approval and research) and so the systems are both mission critical and elaborate.  Companies really want to automate more and to make things more usable and reliable.  The work of program management was to deeply understand how to model the flow of documents in an organization--spending time at big drug companies, small startups, big law firms, local law firms, Public Relations agencies that produce press releases, or government offices that produce legislation to name a few.  Out of this work PM and Planning developed a conceptual model called the "document lifecycle" (DLC).  This helped us to frame the way that customers would like features to work.  So for this work the PM needs to be really good at working directly with customers, learning from them, listening, being open minded to different ways of working, etc.  When you're hired from college you will participate in this work for your area.

At the same time there are deep technical problems to solve.  We need to solve the control and access to information (drug test results and contracts need a high degree of security, yet they need to be collaboratively authored).  PMs spent a lot of time working with the Windows platform team who develop platform technologies like our Rights Management Server or the Windows Workflow Foundation (WinWF).  These technologies are critical to enabling a robust and extensible implementation of the DLC. So in this phase of learning, the PM has to become well-versed in new platform technologies or in how to apply existing technologies.  Often this is where some people say "it would be easier to roll our own" -- which of course in the immediate term it is (just build your own linked list and event source/sink) but what you miss out on is the expertise and leverage that comes from a deep platform technology.  For example, by learning the WinWF and being an ISV of that technology we can take advantage of advances in workflow, integration with Visual Studio, and a very robust and scalable server without us doing any work--just like when developers reuse the process model of Windows, or the client side drawing code of GDI.

With this information at hand the role of the PM is to synthesize this learning into a series of prototypes.  These prototypes are of varying fidelity.  This is where the analogy to architecture holds--sometimes you do a drawing, sometimes you do a high fidelity diagram, and sometimes you build a model.  In software we sometimes build static screen shots, we sometimes prototype in tools like VB.NET, sometimes we prototype in a series of static bitmaps that illustrate a scenario.  For our new user experience in Office12 we went through a series of high fidelity prototypes development first in PowerPoint (you'd be amazed at the depth of interaction you can do) and then in more high-end design oriented tools.  By the time we were ready to exit the learning phase, we had a full mockup of the user interface (which I have shown at my campus tech talks this year).

The output of this phase is a prototype upon which we will author specifications.

Convince --> Output of convince phase is a plan and goals

Once you've learned a lot you have to go out and convince your peers, your manager, and the dev team that your ideas are worth pursuing.  This is where being a solid communicator and someone who is able to bring together customer needs, technologies, and scenarios really comes together. 

As an aside, a lot of companies will tell you that you can come and pursue your ideas.  That is probably not a good plan -- that is a recipe for chaos.  But more importantly, if you can do whatever you want there is a good chance someone else in the company has the right to come in and tell you to change.  If there is this level of empowerment it means the management team is empowered as well 🙂  The ability to just start at a company and pursue your own agenda is much more of a lore than any reality--all companies have a strategy and a business framework that the work needs to fit within.  At the very least, eventually shareholders will want a return on your R&D investment.

So at Microsoft the convince phase is really where your entrepreneurial skills come to play.  While you will always have work to do, during this phase you are working to expand your vision and get as many lined up behind your area as you can handle.  Your ability to convince people of your ideas is a lot like trying to get funding from venture capital folks.  That is why if you have a great conviction of your ideas and a lot of energy you probably have the makings of a great PM.

The best part about this is that the teams you work with are all working in unison on the vision and everyone is on board trying to make sure the ideas come together super well.  In particular your mentor is there to work with you.  But ultimately, the ideas will succeed based on your own initiative and ability to convince the team of the chances for success and the high priority nature of the work. 

The output of this phase is the set of objectives for the project area.  What follows is developing things at the next level of detail.

Spec --> Output of spec phase are a series of written specifications

The first thing people always think of is "specs are for bureaucrats".  That drives me a bit crazy.  I know as Americans we have a tendency to use new products without reading the instructions, but it is lunacy to develop a new product without first writing down the goals.  The mere process of writing is thinking, and the thinking will always push you to uncover more issues sooner before it is way too expensive to change things.  For all the talk about agile development, few ever talk about specifications as being the most important step in agility.  It is way easier to change a bitmap or do some editing of English in Word than it is to move around and rearchitect code. 

Yet at the same time we do not sell our specifications, we only sell our code.  So while we work to be very hardcore about having up front planning we do not develop our specifications to the point that they are the full documentation of the product.  It is too much work and not enough of a pay off.  So if you make a late breaking design change we might document the change in the change log but we don't go back and redo all the words in the spec.  Another fun one for reading specs from a long time ago is that the actual feature name used in the product is never what we named it during development--the Office Assistant was famously named TFC during development.  The "C" stood for clown.  I will let your active imagination figure out what the TF stood for.

So in writing a specification, the PM that worked on the learn phase now has to turn that learning into an experience that customers will have.  This is where the entire series of features, user interactions, boundary conditions, localization, ISV opportunity, and all the details are filled in.  A specification is how a developer will estimate the amount of time it will take to write the code.  So if your spec omits a lot of details and developers need to guess, then there is a good chance you will end up not being able to realize all of your dreams because too many things needed to get filled in a the last minute, plus your developers will not be very happy working with you.  So doing a good job on the spec is important. 

A great program manager will take their whole feature area and divide it up into specifications that match the developers or break the feature up into workable "chunks".  On average a PM writes about 8-10 specs for their area, and each one can be 30-50 pages depending on how visual (how many pictures).  Some specs are significantly longer and some PMs choose to write a larger number of smaller specs. 

Specs are not just for developers.  But the usability, product designers, and testers are all contributors to and refiners of the specifications.  In fact while the output of the Spec phase is the document, the final output is an "inspected specification".  If you've ever gone through a code review with a professor or mentor (as an intern) a spec inspection is like a code review.  During this time testers might push on you about boundary conditions or compatibility with existing products.  Product designers might work with you to improve the way the spec describes the overall interaction.  Usability might research the instrumentation from in-market products and use that to refine the priorities for the feature.  In fact the role of data is critical to Office PMs--if you run a web site you have click streams and logs, and Office through the Office Customer Experience Program has exactly the same--usage information for millions of volunteers (anonymous and private of course) and that educates us immensely on how to design features (Jensen's blog describes this as well).  So the spec, while owned by PM, is a work product of many contributors.

It is worth noting that many times along with a spec is a more detailed prototype.  This is particularly true for heavily interactive features.  In this case product design and PM work together to develop detailed prototypes of the work (often these will be tested in the labs with customers as well).

When the spec is complete the core part of development begins.  PM then transitions to refining the product.

Refine --> Output is the product

During the development of the product, PMs are constantly refining the details, working with development and test to determine what needs more clarity and what is working better than expected (that can happen) and what is going less well (that happens more).  PMs are on call to answer questions and "unblock" development.

More importantly as the real code becomes available, PM is anxious to try it out and make sure it is meeting their own design expectations.  Once the real code creeps along we will bring that into our usability labs to further understand how the product works.  A famous story of this phase of developing the PM role was that the first PMs were trying to improve a feature under development and ran some usability tests.  The feature bombed.  The PMs tried to explain this to the developers, but the developers insisted that the PM just picked "dumb users" because the feature was great.  So after a few rounds of this the PM dragged the Dev to the tests to watch 10 out of 10 users fail to use the feature.  The developer finally relented and the feature was fixed.  Today, developers can watch tests via streams or go downstairs to our usability labs and watch the tests in person.  Almost all developers I know are keenly interested in how their features are doing (and how the PMs are doing designing those features!) 

Another aspect of refinement is working with customers who use the early code.  While it is cool to throw a product out to beta and get some instrumentation and maybe get some qualitative input via mail, the only true way to understand how the product is doing is by deep engagement with real world users.  We do this this through a number of mechanisms that gradually expand the number of customers involved.

Early in the process we meet with a very small number (10-20) customers who spend days with us here on campus and learn about the product.  We walk them through all the details and solicit their feedback and input.  We did this for Office12 last summer and it was critical to our ability to get to Beta1 with a product that reflects real world usage and learning.  As a PM you will be responsible for getting together with these customers and learning from them.  We often follow up on site.

Another group we learn from that is a bit larger are our MVPs -- the most valued professionals.  These folks are the power users of Office. Our PMs all got involved with the MVP summit on campus and again worked with the MVPs in small groups to get their feedback and expertise into Office12.  The MVPs know more about Office than any other customers on earth--they are a wealth of information.

We're currently in the phase of learning from a broad set of beta1 customers.  We are doing this through newsgroups and through direct communication. 

You might also notice that many of our PMs are blogging (see the links to the right).  This is new for us (well for everyone) and also a great source of information and a great way that PMs are connecting with the web community.

Of course our senior program managers are also responsible for working with the press and product management.  So a lot of time is spent on communicating Office12.  There are a lot of reporters interested in Office and a lot of information to get out there. 

All of this Refine work feeds back into the developers where we prioritize and make sure that the very best product is built.  Of course that doesn't end with RTM since we're always refining and listening to customers (even though we're not "Web 2.0").  As I mentioned previously, we make over 100 changes every month to Office based on customer input -- so the product is always improving, and we're always learning!

PM Attributes

So those are the phases of program management and what you do as a PM in Office.  I would say that there are many unique elements to the role of PM in Office that are not emulated by other companies who have tried to create this role.  A good book that describes the uniqueness of PM at Microsoft is Michael Cussumano's book "Microsoft Secrets" or his new book, "The Business of Software".  If you're considering a PM role at Microsoft (or Office), from my perspective a couple of things you will get:

  • A small team dedicated to solving customer problems and bringing the best technologies to the table
  • Access to dedicated developers who are there to implement your ideas if you can live up to creating a great idea and making sure the details are thought through
  • A very strong mentor who as part of small team will be there for you on a daily basis

If I had to think of the qualities that make a great PM I might list a few, but your recruiter and the interviews will help out a lot so don't let these discourage you from applying:

  • Strong interest in what computing can do -- a great interest in technology and how to apply that to problems people have in life and work
  • Great communication skills -- you do a lot of writing, presenting, and convincing
  • Strong views on what is right, but very open to new ideas -- the best PMs are not necessarily those with the best ideas, but those that insure the best ideas get done
  • Selfless -- PM is about making sure the best work gets done by the team, not that your ideas get done. 
  • Empathy -- As a PM you are the voice of the customer so you have to really understand their point of view and context 
  • Entrepreneur -- as a PM you need to get out there and convince others of your ideas, so being able to is a good skill

PM is unique to Microsoft and I think it is fair to say this is a role that is often copied but never duplicated.


Comments (95)

  1. Doug Mahugh says:

    Thanks for taking the time to write that up — the historical perspective helps the role make more sense.

    As an MS new hire, I’ve found roles/titles a bit confusing at times, and PMs in particular can be found doing a pretty wide variety of things around here.

  2. steven_sinofsky says:

    Doug that is definitely the case. As always this is from my perspective and describes the PM role in Office (where it started).

    Happy Holidays!


  3. Roberto Islas says:

    Thanks for the explanation of what exactly the job and responsabilites of being a PM in Microsoft. It could be a good idea to include some of your points to the The information about PM in there is very incomplete. Happy Holidays.

  4. This is one of the best articles that I’re read amout the PM position. Thanks for all the details and it definitely helps my preparation for a PM interview with MS in January. Meanwhile thanks for leaving comments in my blog.

  5. Oops sorry about those typos. If the PM role has so many responsibilities, then how does a good Manager draw the line between being authoritative and not being tough enough to make a decision for the feature team?

  6. steven_sinofsky says:


    Of course in any job there is always a balance in exhibiting too much authority and being a team player. I think program management is much more about being a team player. At the end of the day the PM does not write the code or test it, so being able to be convincing and work collaboratively is the most important skill.


    PS: I only delete comments deemed inappropriate or unrelated. I sort of think of them as "letters to the editor".

  7. Thanks for the writeup, Steven!

    Friends and family are constantly asking me what exactly a PM is – now I have something great to point them to!

  8. PM @ MS says:

    This is an awesome write-up on what the PM does at Microsoft, and I am one. But this only reflects what a PM does in Office I guess and the other groups are vastly different and I mean a day and night.

    I am a PM, and probably perform the role of a dev manager (as I lead a dev team of 30) and 4 PMs working offshore..but none of them report to me!!

    To make things clear:

    The "manager" in Program Manager is a misnomer as it means managing your own deliverables and not managing people like in other organizations. The PM title is common in the industry but the MS role matches closely to what a Business Analyst generally performs in the industry.(

    And clearly, most PM roles are 8 to 10 levels below the management roles in the org hierarchy – so there is little chance of a PM to middle management growth in less than a decade given the size of each group.

    my real 2c

  9. Steve,

    I have often heard MS employees talk about the different flavors to the PM role like Design PM, Security PM, Release PM and so on.. Can u talk about these variants and are they exclusive to certain groups in MS?

    – Sriram

  10. steven_sinofsky says:

    b0rgbasher (deleted comment)

    I’m sorry you don’t like the way I try to keep things focused on what I’d like to discuss 🙂

    FWIW, I actually wrote this post on a machine running all alternatives to Office and Microsoft software which I often do. I don’t think that is in poor taste, nor is it the topic of this blog.


  11. steven_sinofsky says:


    A PM plays many different roles throughout his/her career and sometimes during the course of one project he/she might be focused on one aspect of the project (Release or Security) but that would just be for hte project and overall even within those areas of focus a PM needs to be responsible for the full range of activities.

    On our team we generally do not use modifiers on the title as you indicate above (with the general exception of localization where the job responsibilities are generally different).


  12. steven_sinofsky says:

    PM @ MS,

    The link to your description is down, but I’m pretty sure that what I describe would not be a Business Analyst. The closest used at other companies would be a Product Manager, but not working on the demand generation or communications side but might work on "market requirements". Almost universally though these folks do not see the features from inception through to working with development and test (at least in my experience).

    On the Office team a line program manager working on Office12 has either 3 or 4 managers between me and them, not 8 or 10 (and my manager reports to the CEO).

    You are correct as this post describes the PM role in Office where the role originated. It has taken on other responsibilities and job definitions as appropriate to other products and technologies at Microsoft.

    It definitely sounds like you have a unique role that I probably wouldn’t characterize as a PM, at least by this description.


  13. PM @ MS says:


    Also, Product Managers in my opinion, control the product lifecycle in many ways and are more empowered than a Program Manager at MS. Typically Product Managers are also higher up the food chain at MS 🙂


    Definition of a Business Analyst:

    Business Analysts are responsible for identifying the business needs of their clients and stakeholders, to determine solutions to business problems.

    The Business Analyst is responsible for requirements development and requirements management. Specifically, the Business Analyst elicits, analyzes, validates and documents business, organizational and/or operational requirements. Solutions are not predetermined by the Business Analyst, but are driven solely by the requirements of the business. Solutions often include a systems development component, but may also consist of process improvement or organizational change.

    The Business Analyst is a key facilitator within an organization, acting as a bridge between the client, stakeholders and the solution team.

    Business analysis is distinct from financial analysis, project management, quality assurance, organizational development, testing, training and documentation development. However, depending on an organization, an individual Business Analyst may perform some or all of these related functions

  14. steven_sinofsky says:

    PM @ MS I think your experience at MS is not typical (based on the reporting structure you outlined and your responsibilities). I am speaking from my experience at Microsoft of course (and so are you). To be clear, it would not make sense for a PM to manage developers (any more than it makes sense for dev to manage test, or for that matter sales to manage marketing — an important organizational princple is having consistent rules where different disciplines come together in general management).

    Typically in a "silcon valley" organization product managers report to the VP of Marketing and are not dedicated to the product per se or the developers. There is usually a product manager (managers) who write a "market requirements document" which is then handed off to "engineering" (typically in the VP of Engineering org). At that point the feedback loop is usually not well-defined.

    Business Analyst is just not a title I have run across before. But the description you outline sounds very much like a valley product manager. The description sounds very "academic" and not like any structure I think could really work ("solutions driven solely by the requirements of the business" — isn’t that a tautology?)

    At Microsoft a product planner most certainly is responsible for "identifying business needs" where "business" can be Microsoft’s or the customers (i.e. strategy or solutions).

    The key is that at Microsoft, the program manager is not only empowered but responsible for making sure the product is well-defined and well-executed in terms of the market and customers.

    Often people want to define the "single person" responsible. That is another thing that works well when you have no scale or small things, but in general any product of substance is unlikely to have such a single point of failure or accountability. Even for Office, I work closely with my peers and my manager on issues that impact the broader Microsoft.

    My experience has been that if you are sold in your job on "control" then you need to look carefully at what the actual scope is and not get too hung up on total control. More often than not, having a broad say in technology (that requires cooperation and consensus building on your bpart) is much more interesting, rewarding, and higher impact than having final say in every detail of a very small area.


  15. Mike says:

    Thanks for the post. I think this description explains a lot about the history of a PM. I think it also helps clarify some of how Microsoft needs to change.

    As you aptly described, the PM role was initially created to better capture customer requirements and broad interdependencies when building software back in the early 1990s. The model you describe still may be necessary when projects are large. But times are a-changing!

    In 1990, PMs were necessary. Technology was not in a position to help the flow of information sufficiently that a development team could be close to it’s customers for large projects. There just wasn’t enough time in the day to manage the information flow, communicate new plans, and get code written. However, since that time, the world has changed significantly. Thanks to technology improvements (email, web sites, automated support, scalability improvements, broadband, etc), developers can be involved in the design and development of a product, as well as in the deployment, operations, and support of their product. Why shouldn’t data collection from customers be an automated process and part of every application? Why do we need to question which parts of the product are working well and which are not? Microsoft’s crash-detection tools are a great example of this automation. Easy-to-build websites and customer feedback/FAQs/etc also ease this communication burden. Remember that back in 1990 the internet didn’t exist and few had email. Communicating between groups was a difficult, paper-dominated world.

    If a company were highly efficient, there would only be two groups in the company: those that build the product and those that sell it. In reality, all companies have overhead, which comes in the form of administration, payroll, marketing, etc. Improvement in any company is an exercise in never-ending optimizations and removing overhead. Technology is often the key to these optimizations. As such, the role of a PM as you’ve defined is one of these jobs which is being optimized out. Microsoft’s competitors, like Google, are well aware of this, and you’ll find few PM roles there, and only minimal overhead in their development teams. Granted, the Google model has yet to be proven over a 30 year history, but none can argue that their results so far have far out-paced the development speed of Microsoft’s PM based model.

    In my opinion, the role of a PM will eventually go the way of the dinosaur as software development becomes more efficient. Those companies which can’t keep up with this change, will die out. I hope that Microsoft will not hang onto its past ways for the sake of posterity. Microsoft needs to evolve too.

    Lastly, I’m definitely not arguing that the development process won’t have planning in the future. It’s just that the tools to do the planning and incorporate customer feedback are much simpler than they were 15 years ago, and they are getting easier with each passing day. As a result, these tasks will be folded increasingly into the developer’s job, with supervision of fewer and fewer PM-type roles. A developer of the future will need to be able to do far more than a developer of 1990. In 1990, the developer just needed to write code. Today, and in the future, the developer needs to be able to understand business requirements, forsee future developments, communicate well in specifications, and write code.

  16. steven_sinofsky says:


    Thanks so much for the thoughtful comments.

    We actually do all the things you talk about and find that they provide very good input on the current product and on how to incrementally improve products. Mechanisms like you describe are not necessarily representative of all customers and over-represent technical users quite a bit. Our customers are usually people that worry much more about their business or their products and do not have time to be experts on the technology direction of software and so their "solution space" is limited, which is why qualitative methods or things like surveys or asking for opinions are limited in the ability to uncover new and innovative things.

    Our developers have access to all the data like Watson as well as our customer experience data (which you can think of as click streams for client applications) as well as all of our support incidents and of course all the newsgroups, blogs, press, and other activity regarding out beta tests.

    I think that with even more data like this widely available I would draw the opposite conclusion and that is that even more planning and up front work is required and that a higher specialization will develop. If history is any indication, most of the times roles evolve to be more specialized and not less as more technology is developed that requires even more expertise to understand the information that comes from data.

    I appreciate for sure that developers should be much more involved in the data and for us that is critically important. I know some program managers have a tough time when developers feel like the PM is not really justified in the decision and push PM back to uncover the data that drives a specific direction. There is plenty of data out there to make the right decisions.

    You might check the job listings at some of our competitors for the title "associate product manager" and I think you’ll see the beginings of our PM role though without the career framework I think we have at Microsoft. Just as with us, the role becomes more important as the number of decisions to make and amount of data to absorb increases 🙂


  17. Mike says:

    Actually, I think history shows that you are wrong. Companies get more efficient, not less, and the barrier to entry on software development is decreasing, not increasing. This has been steadily shown over time. The new generation of companies is outpacing Microsoft with far less overhead.

    For applications that want to be big and global, some of what you say is true, and these roles will expand. As a given product grows, it needs more people to track the details. Unfortunately, this necessitates that the project also slow down.

    There is no doubt that the most impacting innovation and fundamental change will be done by much smaller teams where as much of the overhead has been removed as possible. When we’ve removed all of the overhead, the team can iterate much more quickly, and I believe the most important facilitator of change is the ability to iterate.

    I doubt you and I will come to agreement on this. While you think that broadening of skills will yield more PMs, I think broadening of skills will yield fewer PMs because the work is replaceable.

    The reason I see this is because large groups lend themselves to political issues – it is just human nature. To ignore it, or pretend that a company like Microsoft doesn’t have it is being naive. Because of politics, PMs usually end up becoming filters of data rather than aggregators of data. And once the data has been filtered before getting to development, well, you’ve lost all chance of speedy innovation.

  18. c says:


    As a developer in Office, I see where you’re coming from, but I disagree with you.

    I’m a developer. I specialize in writing code. I do some customer research and look at their data streams (like Watson, SQM, and newsgroup posts), but that’s to understand the customer enough to make good narrow-focus design decisions. For broader "we should add feature foo" or "changing bar would make people more efficient" I leave those up to the PM. I’ve got my own ideas, which I share with them (at length!), but I spend the majority of my time on semicolons, not business requirements.

    On the other hand, a PM specializes in knowing the customer and knowing their requirements. The time that I spend focused on feature implementation they spend focused on feature design. Meeting after meeting where they meet with everyone who matters to the feature so they can figure out what the right design is.

    When you talk about removing overhead, you’re really talking about limiting scope. We can design and implement faster if, for example, we’re only concerned about shipping in English. If we limit our target audience – say, focus only on the home user, or the student, or the guy at Boeing. If we don’t worry about instrumenting with SQM and with group policy settings and with making sure everything works if all your drives are network drives.

    By shrinking your scope, you reduce the need for a PM – targeting a smaller market means that it’s easier for a developer to know enough about their customer space to be able to learn that in their spare time. And it reduces implementation time for the feature, so you can push products and features out the door sooner.

    For better or worse, Microsoft won’t do ANYTHING unless it covers every scenario for every market and customer. Everything is figured out up front so that we can meet all of these requirements while avoiding a late "oh crap, how can this work in a right-to-left reading language?" Well, in theory 🙂

    It hurts us and it helps us. Joe Sixpack or Joe Blogs don’t care if it works in Turkish, they just want to see a shiny web UI with a novel DHTML trick. But Joe Corporate does care if he can’t standardize their Turkish offices on the same software they use in the rest of their worldwide company. We’re late-to-market in many areas because we try to solve every problem at once.

    Maybe if we limited our focus we could keep churning out shiny two-years-beta products, but I think one of our strengths is that when we get around to shipping something it does work for almost everyone in almost every scenario. It takes longer, but it also saves time – it’s more efficient to do it right the first time than it is to ship something, then tear out the rendering code and start again because you can’t make it work in RTL.

  19. Mike, I’m a manager of PMs in Office and in addition to what "c" writes I would emphasize something that Steven referred to briefly in a reply to you: "We actually do all the things you talk about and find that they provide very good input on the current product and on how to incrementally improve products."

    Note the "incremental improvements to current products". Automated data collection is going to tell you how to make small changes to your product to drive it toward optimal execution of what it already is designed to do. If your product is a database, you will get faster, more stable, and may even be able to optimize controls for reporting better based on automated feedback from users. But none of that will tell you that your customer is going to need to follow Sarbanes-Oxley reporting rules, and has to be able to provide an audit trail for their accounting that is linked to their document review systems. And what does that even mean in terms of changes or additions to your product, some potentially moving it into a different category altogether? Developers don’t have the time or inclination or in some cases the aptitude to work out with the customer and other technology partners you need to integrate with exactly what capabilities need to be developed and what the user experience is going to be. That sort of thing is what PMs do.

    I think "c" and Steven also made good points about how the increasing complexity of solutions being attempted and the simultaneous expectation from customers of increasing simplicity means the PM role is in even more need now than in the past. In the 80s and some of the 90s products were pretty simplistic and limited in capability compared to what customers expect now, plus you could design software for "geeks" and everyone else had to deal with it. Now, well, that doesn’t cut it, and no amount of incremental improvement from automated data collection is going to fix that.

    As "c" notes, if your product just does a single thing, like "search", then maybe incremental improvements are all that is needed if you just want to get better at that. But you might get blindsided by a competitor that is able to use PMs to change the rules. (e.g. maybe connecting people with answers is actually what customers want rather than just more relevant results?) That requires insight and collation of diverse types of data.

    BTW, I think you can *easily* argue that Google has not outpaced Microsoft’s model. Both companies have done great things, but you shouldn’t confuse dribbling out a feature at a time with developing faster. Office 12 collectively delivers more functionality across a broader array of customer needs than what Google has done in 3 years of their own development. Don’t forget that most of Google’s properties were acquired (blogger, picasa, etc.) or are basic tools that merely match functionality offered by others (Froogle, blog search, etc) and differentiate by using the Google search tech. If we released each single capability of Office 12 one at a time we’d have a cool new shiny thing to talk about every week of the past three years. And the feedback on Office12 so far has been tremendously positive…radical improvements that come (in part) from PMs listening to customers and thinking deeply about the root customer needs – driving us to major overhauls and entire sets of new products as part of the Office system (SharePoint, OneNote, InfoPath, new Office server products, etc.)

  20. a says:

    Chris and Steven: your commentary tends to be based around a large, mature, product like Office. what about markets where all the entrants are v1/ground floor? the comments above, and some of the comments on certain other blogs point towards the model of developing and shipping new ideas rapidly, and seeing if they stick in the market. in this model you would not need test or program management – but rather direct user feedback by using metrics such as instrumentation, downloads, buzz. can (should?) a startup mentality like that exist at Microsoft?

  21. Mike says:

    Thanks for all the thoughtful comments. I am not quite sure what we are arguing about, though.

    My point is that technology makes overhead easier, not harder. And as we move forward, although our markets are bigger and our scope is bigger, it is still overall easier to communicate and innovate than it was in 1990. If you don’t agree that a company should have less overhead with better technology, then I’m not sure what to say.

    My second point is that PMs are overhead. I’m not trying to belittle the role here, but I think it is important for everyone to understand. They don’t sell product, and they don’t build product. It is a role in the middle- managing process and facilitating communications. In all companies, some amount of overhead is required, absolutely. But over time, the goal for all companies is also to minimize overhead. That is just business, and so it will happen for the PM role as well.

  22. Rick Watson says:


    I’m a PM here, and as someone who’s familiar with corporate discussions, I can say that if you’re not selling, then you are overhead. This includes PM.

    Development is not selling, ergo, they are in the same boat as PM. Just like the rest of Marketing.

  23. a: I worked on OneNote from the very beginning (see link to my blog under my name), so that was a v.1 effort. You can read from the early posts in my blog about how we approached our v.1. I think one thing you are missing is that PMs are the ones who figure out "what" to build in order to get the feedback you are talking about. So they aren’t unnecessary at the beginning – far from it. It sounds nice in theory to just have some "stuff" that you "put out there", but where does the stuff come from? It comes from some humans who dream it up and design the initial idea. We call them program managers (of course devs aso participate when they want to). And who interprets that automated data you mention to figure out what to improve? Program managers.

    As for test, if you have a relatively trivial project (such as a mash-up) you can make a workable "beta" version without testers (using dev as initial testers), but nearly everything we make in Office and nearly all the rest of the company is not trivial even in "v.1". Products that do more than one thing have a large set of permutations that quickly outstrips the sort of casual testing a dev can do unless they basically become a tester. Beyond Office, there are lots of teams that follow a more rapid development model (and even a few less rapid) since they are working on projects that work better that way. MSN search is an example of something that is getting better every month (at least) due to incremental improvements. This is true of basically all of our web properties that are under active development. For a very different example, you can look at the flexwiki ( project – something a few MS developers put together as an example of a very different sort of development.

    Mike, I think you can define overhead many different ways. You’re choosing one, but it seems arbitrary to me – and in any case I would include PMs in the "build the product" part, since if they weren’t around developers would have to do the same work of defining what to build, meaning they couldn’t write code. But all the roles are needed to maintain an organization that can exist over time in a healthy way. Is your spleen overhead? Your stomach? After all, you can survive without these organs if absolutely necessary – they neither operate your body nor move it to new places so they are overhead, right?

    To your first point, I agree that a company that has not added any complexity to its operation and does exactly what it did in 1990 at the same pace should need less in terms of what you call "overhead" thanks to technological improvements. But work looks very little like 1990 anymore. Just about every company has had to speed up the pace of its operations, has had to customize its offerings to meet more specific customer needs, has had to optimize its processes to squeeze every cent out of its operation. All these tasks mean more "overhead", not less. But honestly, talking about Program management at this high theoretical level is not too meaningful IMHO.

  24. Silicon Valley Product Manager says:

    I am curious why "program manager" is unique to Microsoft? This position doesnt exist in Silicon Valley.

    What you described as roles and responsibilities for ‘program managers’ are covered here by ‘product managers’. Usually product managers are primarily ‘inbound’ while ‘product marketing managers’ are ‘outbound’, but a company’s particular culture will put a bit of spin on each. So what do ‘product managers’ at Microsoft do? I know they exist, I’ve met them. (And they are different again from product marketing in each region across the globe.) It would seem that Microsoft Product Managers are squeezed out? Or do they do the largely outbound tasks of ‘product marketing’? And why does Microsoft also create positions called ‘product planners’? Again a task owned by ‘product managers’ here. (I realize you will respond from your experiences at the company and may not generalize to all orgs in Microsoft).


  25. steven_sinofsky says:

    Silicon Valley Product Manager,

    Good question! I don’t know why the specialization does not exist in the valley in "title" though it does sometimes exist under the Marketing organization. As I mentioned, based on my experience I believe that the role (at least the way we define it) cannot be successful if it is subsumed by marketing (any more than test could be successful if subsumed by development, though both of those happen in valley companies quite a bit).

    Product Managers (in Office) at Microsoft are focused on the brand, positioning, pricing and licensing, demand generation, press relations, corporate briefings, and a whole host of pre/post sales and marketing activities, not the least of which is coordinating our global sales force and how they sell and support Office.

    Product Planners are a learning and research function. More on that later.

    I think that as an organization matures it makes things that are implicit more implicit. Program management was a decisive step in that direction as we realized we were not being efficient with our developers (they were writing and rewriting the same code, they were not able to spend the time to make things usable, they were not in touch with customer but yet were responsible for being so and writing the code, etc.).

    You might check out "Microsoft Secrets" or "Business of Software" by M. Cussumano that explain the role as compared to valley companies.


  26. Silicon Valley Product Manager says:


    Thank you for your considered response.

    But it has not slacked my thirst for an understanding of why Microsoft (at least Office)appears to have ‘sliced the salami’ of a Silicon Valley Product Manager into at least three components spread across the org: "program managers" handle the ‘inbound’ of customer requirements, dev decisions, etc.; "product planners" have some role in trend/issue identification with customer needs and product definition; "product managers" are mostly ‘outbound’ on pricing, positioning, and messaging. (Leaving aside the product marketing roles of demand generation etc. in specific regions around the world.)

    Your response leaves me still hungry since it is empty fodder: it is based on logical errors of induction, deduction, and syllogisms:

    Induction error:

    "Observations at Microsoft show QA-Test reporting to Dev fail"

    "QA-Test is a subordinated organization when reporting to Dev."

    "Therefore all subordinated organizations fail"

    Yet this induction is proven wrong by the deduction fueled by an existence proof that "both of those happen in valley companies quite a bit." One would expect that even by the law of large numbers, there are examples where QA-Test reporting to Dev is not a failure but is a success.

    Categorical Syllogism:

    "If Prog M reports to Marketing, it is subordinated to Marketing:

    "All subordinated orgs fail"

    "Therefore Prog M reporting to Marketing will fail."

    Since the inducted categorical proposition is proven wrong by the deduced existence proof, the categorical syllogism that Prog M reporting to Marketing will fail is also false.

    In fact, the established & proven successful model for Marketing is ownership of the "4Ps: product/packaging, pricing, promotion, and place." (Regis McKenna, Bill Davidow, Jeffrey Moore, etc.) There has to be one-spot where there is the "soul" of the new machine–market trends, issues, customer requirements, product planning, feature-functional rationalization with dev, critical decisions about feature cuts as the bug regression trend collides with launch timelines, outbound tactics, in general the responsibility of making sure the product meets expections, delivers, and is successful, etc."

    I am concerned that Office-Microsoft’s chopping up of the responsibilities, authority, and accountability only sets up a machine that is suboptimal by risk-aversion and incrementalist since the balkanized org optimizes decisions for local maximums rather than a global maximum.

    Surely your point of program management being a "decisive step to make the dev side of the org more efficient" is just such a potential example: the global maximum of increasing shareholder value by taking some risks with new products and services is sacrificed for "dev efficiency"? False idols! Advancements in high tech are messy, hardwork, and need lots of good luck. "Dev efficiency" seems a third-order issue at best.

    I am aware of Jon DeVaan’s efforts to better integrate marketing with engineering to reduce the impedience mismatches and reduce the local optimizations at the expense of increasing shareholder value. Where has that work gone in Office?


    An Even Hungrier Silicon Valley Product Manager

  27. steven_sinofsky says:

    SVC PM,

    Sounds like you have some misinterpretations of what I’m saying and also that you work at Microsoft, so how about asking more directly internally so we can have a conversation made up of more context since it sounds like you have more issues than just how I’m describing the job.

    To be clear, this is not about slicing things up–you make this sound like a zero sum game and that there is only so much work to go around. Nothing could be further from the truth.

    Rather this is about growing the amount of specialized work we can do. While you might claim data points to the contrary, the benefits model of having these roles be specialized is not just one I am asserting, nor are the challenges and risks that a lack of specilization assertions, but rather the data does support these. That is why I pointed you to a third party resource rather than have me just keep on trying 🙂

    But again, as a Microsoft employee you have a much easier time contacting your managers and executives directly where you can get much richer answers to your questions based on specifics that neither of us can share in a blog. That is why I always encourage people who already work at Microsoft to use the tools and people you have available to you.


  28. Hey everybody, I’m Dr. Nicholas Allen, and I’m a Program Manager at Microsoft on the Windows Communication…

  29. Well, the other day I was minding my business, being a Program Manager, when I realized I had not chatted…

  30. kabir_khanna says:

    While it may seem like an overhead , the role of a PM is definitely one. It is a more specialized role which has evolved over a period of time as the scope of software to solve problems has become larger and larger.  While a college graduate can single handedly do his/her  final year software project work the approach is not scalable when you have to design software for a much larger audience and when the cost of error is large. It is unrealistic to say that is the PM neither develops software nor sells it , it is an overhead. Consider for example the role of a movie director or that of a music orchestrator. While neither of them actually act of play the music their role is extremely important for the movie to succeed or the music to not sound like noise. Yes, you can say that all the super talented actors are mature individuals who should also understand not only how to enact a scene, but rather in what sequence things happen, get everyone to agree on common creiteria, etc. Do you think that can work ? Has the role of a director been phased out over the years in order to reduce the overhead. This is the age of specialization. Specialized roles as these pay up many times over for the cost/time overhead you might suspect they may be adding.

  31. kabir_khanna says:

    Minor correction, in my previous post I meant Role of PM if "NOT" an overhead and not that it is. Sorry for the typo.

  32. Student says:

    Thank you for your detailed description of what a PM does. As a graduate student who likes to become a PM I have the following questions:

    1. Do PM’s get to choose their mentor and bond with them, or are they assigned one at the beginning that shall remain with them till the life of the project?

    2. You mentioned that an in-depth knowledge of technologies is needed to enhance the projects performance rather than re-invent the wheel. How do PM’s acquire this knowledge?

    3. Some companies want a percentage of your time to be spent on pet projects; Do PM’s have this opportunity as well?

    4. Can PM’s work flexible hours like developers?

    5. What are the growth potentials and career advancements for a PM?



  33. Today I present guest writer Brad Weed, Product Design Manager of the Office Design Group. He leads the…

  34. Steve,

    I just came across your entry (thanks for providing this insight into the PM role, by the way), and as a new Sr. PM hire (starting in 2 weeks) I was found the comments interesting. I wanted to comment on the difference between the PM and Business Analyst roles.

    At my last company, I managed a team of PMs and Business Analysts. While there does seem to be some overlap in the roles, the primary difference is that PM’s manage execution, while the traditional BA role is around definition. Also, BAs move vertically — usually working with specific business units or technologies — while PMs work across many teams and technologies, focused on getting a solution out the door. It’s process vs. project-centric roles.

    Some view the BA role as junior to the PM, but more often than not I’ve seen BA’s move into data analyst or other technical roles. It’s a different mindset. Very few BAs make good PM candidates, in my experience.

  35. kayte says:

    Wow this was a fantastic entry.  I’m actually considering a PM role at the moment and got some really good insight and flavour on the role of a PM.

    I’m bookmarking this one.


  36. TexBlog says:

    Pardon the delay in blogging.  It wasn’t lack of love, I assure you, but I just had to go dark for…

  37. Background I was a dev and a dev lead for a few years and although I still enjoyed doing it, I felt that

  38. We have some job openings on the Storage Engine Program Management team – if you’re looking for a great

  39. It was a very hectic week for me. I had been on one of the recruiting trips to a school on east coast.

  40. The reason that I’ve created this blog is to share some of the things that we do on the PM team with

  41. The reason that I've created this blog is to share some of the things that we do on the PM team with

  42. Here’s what Sumeet has to say about the PM role at Microsoft: Thanks to all students who visited Microsoft

  43. On JobsBlog, we’ve written about Program Managers before – but Steven Sinofsky just posted the granddaddy

  44. Recently several external people have asked me what Program Manager in Microsoft do and what I do. And

  45. Eytan Seidman, Program Management Director over core relevance for Microsoft Live Search, is leaving Microsoft (and Seattle) after six and a half years and heading to New York to work on a travel-related start up with his brother. I talked to him about

  46. If you love the web and are passionate about the developer experience building web applications we’d

  47. Weddings says:

    While at Stanford this week I was asked by a number of PM (program manager) candidates to talk about the PM role at Microsoft. The PM role is unique to Microsoft and was actually created in response to developing software that is more usable and at th

  48. evolvingWe says:

    Don’t tell my dev team’s but today is the first day I’ve felt like I could catch my breath since taking on the challenge of building up a Program Manager foundation at Telligent. That means that it’s a good time to talk about what I’ve been working on

  49. evolvingWe says:

    Don’t tell my dev team’s but today is the first day I’ve felt like I could catch my breath since taking on the challenge of building up a Program Manager foundation at Telligent. That means that it’s a good time to talk about what I’ve been working on

  50. Republished from Steven Sinofsky’s PM at Microsoft , TechTalk, Dec 2005 While at Stanford this week I

  51. A few months ago, we asked you for feedback on what are some of the things you would like to see improved

  52. Спасибо всем за ваши комментарии и электронные сообщения. Я действительно рад тому диалогу, который мы

  53. 感谢所有发表评论和给我发送邮件的人们。我非常欣赏我们所开始的讨论。当这个博客开博的时候,在我们的走廊里大家都摩拳擦掌。介绍Windows开发团队看起来会是一个不错的开头。本篇日志就将提供这个团队的概况

  54. The Program Manager position: Check out Steven Sinofsky’s PM at Microsoft post on TechTalk, Dec 2005 The Interview Process : The goal of the Microsoft interview process is twofold: It’s not only an opportunity for us to get to know you, but also

  55. 댓글을 남겨주시고 메일을 보내주신 분들께 감사드립니다 . 이러한 토론을 시작할 수 있게 되어서 대단히 기쁩니다 . 블로그를 시작한 뒤로 저희 사무실 주변은 활기가 넘치고 있습니다 .

  56. 먼저 Windows Customer Engineering Feature 팀의 고객 데이터 수집을 담당하고 있는 Christina Storm 이 쓴 글입니다. 이전 블로그에서 Steven

  57. Dear JobsBlog: After working for 9+ years as a technical lead, I am now considering a change in career path and am seriously considering the Program Manager role. I work at a start-up and wear multiple hats like meeting customers, working with development

  58. QS says:

    Interesting.  After six years,  when I look back the discussion,  I tend to agree on Mike on his opinion.  I am not saying the we shouldn't have PM role.  It is just that technique changes the way we are doing software and service.  Today, if you are running service, you can get a lot of feedback from user, and the data is the only truth.  What we need is to be more agile and response to user faster.  Also,  I saw many cases that we have too many PMs in the org.  Whenever we do something, we always start from PM to write specs, and every feature will have a PM no matter how big or small it is.

  59. ST says:

    So, six years after making this blog post, how much do you think the role have evolved or changed?

  60. Kim Harley says:

    How To Turn windows7 features on or off in the control panel to install or configure Mircosoft .NET Framework  3.5 SP1?

  61. uma says:

    That was a very good description…

    Could any of you please tell me what is the overall experience expected in terms of years..

    I am very much interested in this role and I believe there are not many companies which support such profiles.

Skip to main content