Key Questions for a PM at patterns & practices

I was looking for some of my old job descriptions for PM positions in patterns & practices to help out a colleague.  While I didn’t find them, I did find some of the questions that I have used to evaluate PM effectiveness:

Project Management

  • ability to create a work breakdown structure (WBS)?
  • ability to manage a budget?
  • ability to organize scope in terms of incremental value?
  • ability to cut scope to manage quality, resources and effort?
  • ability to ship within short cycles? (1 month vs. 3 month vs. 6 month vs. 12 months)
  • ability to get budget support from another group/org?


  • ability to work effectively cross group?
  • how have you resolved design conflicts among a team?
  • how have you verified user experience?
  • lead a team through execution?

Technical Expertise

  • ability to identify emerging and future problems/trends?
  • ability to identify key technical challenges within a problem space?
  • ability to identify and evaluate solution candidates/options?
  • ability to identify appropriate guidance within a given domain for a broad audience?

Customer Focus

  • ability to vet design decisions with customers?
  • ability to build, organize and rationalize customer data?
  • ability to organize guidance against user experiences?


  • ability to sell an idea?
  • ability to communicate technical concepts to individuals outside the internal development team?


  • passion for working for Microsoft?
  • why Microsoft?
Comments (2)

  1. Anu_MSFT says:

    JD – great set of soft metrics! Do you have an insight on how you can measure PM effectiveness on an agile team? Given that most often PMs perform the roles of product owner and scrum master and the spec delivery is not as detailed as that in traditional models, it would be interesting to hear your take on how you evaluate performance in these situations.

    – Anu

  2. J.D. Meier says:

    @ Anu — Good question.  Here are some key shifts for a traditional PM moving to an agile team:

    – less specs, more user/tech stories

    – less documenting, more doing

    – less big-up-front-design, more spiking/testing

    – less top down, more team empowerment

    – the doers of the work, estimate the work

    – less fixed-scope and it's done-when-it's-done, more fixed-time and flex scope

    – less customer hypotheses, more customer validation

    – less big-bang, more flow as you go

    With that in mind, some key capabilities are:

    – ability to show velocity / progress?

    – ability to chunk down and ship value along the path?

    – ability to capture/share requirements in the form of stories?

    – ability to respond to changing plans?

    These are just some quick ideas to get you thinking.

Skip to main content