Fun of PM.4 … Advocate and evangelise

After covering Persona, Energise and Enable, we have reached the end of the series with this post focused on Advocate. We will also take a quick look at questions that were raised against recent posts and conclude with a snapshot of a week in Willy’s PM world.

image

evangelise

The Program Manager is the spokesperson, the voice, for the team and its solutions. A primary responsibility of a Program Manager is to understand the solution, with all its features, constraints and opportunities. Often seen in Channel 9 videos, events such as TechReady, TechEd and MVP Summit the Program Manager evangelises the solution, demonstrates its capabilities and future plans.

image

More importantly the Program Manager actively listens to the community and users of the (potential) solution to understand potential short-comings and potentials, the ordering of supported and planned features in terms of priority and impact, and the “vibe” the solution creates.

position

Similar to the Product Owner in a Scrum team, the Program Manager is responsible for maximizing the value of the solution. The Program Manager needs to continuously analyse in-house product strategies, market strategies and demands, user demands and metrics collected through the solution, surveys and research.

image

An important responsibility of the Program Manager is to ensure the solution is positioned for maximum value and optimal alignment with the rest of the organization. This requires on-going briefing of status, plans and impediments to all stakeholders, and once again active listening, as well as negotiation skills. It loops back to the B-X-T perspective we discussed in Fun of PM.1 … Persona within the ALM Rangers, which strives for maximum Business value, Good EXperience for all stakeholders, and a Technically sound solution. Typically a Program Manager is responsible for one or a few features of a bigger product. With the ALM Rangers, however, the Program Manager owns multiple solutions, which typically have a short development (1-4 months), but long-term service and maintenance lifetime. The result is that ALM Ranger PMs have to master frequent context switching, are often unable to drill down to the bits and bytes of all solutions, and rely on working with Project Leads and Subject Matter Experts to present a united front of expertise.

interesting questions

These are the latest questions we have collected from the community and our candid thoughts:

?-1 Defining future projects in VSAR have a community approach, where members propose and vote ideas to select the ones going FW. Nevertheless, I feel that the geek inside the PM will work its way up and try to get the influencer working towards some initiatives? Do you see that happening? If not, do you think it should?
A This is a core responsibility of a PM ... in my humble opinion. The community has a view on what's important, the stakeholders have a strategy and the PM needs to align the two. A greater challenge is that the PM has his/her own views and "geeky" inclinations, which interferes with the influencing ... which is why transparency is important, so that everyone can influence.

?-2 From what I've learned so far, a typical PM focus on a project at a time, while a VSAR PM has a whole menu of active projects. Do you feel an approach more project focused would improve results in this ecosystem? Why (not)?
A My personal opinion, after 5+ years as PM in this world is that I as a PM would be able to get involved more in-depth, focus and specialize ... but, the variety and context switching is what I feel makes every day exciting :) I often wish I had more time for every Ranger project, every Ranger and an ability to specialize, however, unless the community is unhappy, I am happy :D. From a Rangers program perspective more PMs would increase cost of program, expectations and probably turn the community into a feature team ... not sure that's what we want.

I like Rui’s comment: “Keeping the team bellow the radar (cost wise) and with a proactive + happy mood is certainly a proven formula Smile

a week in Willy’s PM world

Using a timesheet I created a few views to visualize the average allocation of bandwidth (time) to core responsibilities during two of my recent weeks. Happy to see that collaboration, planning, supporting teams, research, testing and contributing to projects dominates the percentages. It is great evidence that the ALM Ranger teams are self-organizing, self-sufficient and require very little people and process management.

image
imageimage
image

Do any of the percentages surprise or worry you? Thoughts? Comments?

Does anyone deal with a similar amount of context switches? If yes, how do you deal with it?

last but not least … a PM checklist by Anisha, Rui and Willy

We each created a checklist, with explanatory text, which resulted in the following visualisation once analysed by https://voyant-tools.org/tool/Cirrus/:
image

Realising that it is probably an ambitious checklist, we consolidated three pages into the following seven (7) points, which we feel strongly about:

  1. Build bridges between teams.
  2. Help align and understand user need with product strategy.
  3. Motivate, enable and energise team.
  4. Orchestrate and leverage resources, creating cross functional teams comprised of variety of skills, personalities and experience.
  5. Remove obstacles and impediments.
  6. Support B-X-T (business value, good experience and technically OK).
  7. SHIP-IT mentality.

image

what’s next!

This post concludes this series. Going forward, we are pondering over a “Scenarios of PM” series which presents PM scenarios we discuss during peer mentor sessions, share our perspective and invite everyone to share their experience and views. Interesting?

… call to action!

? Thoughts? Candid feedback?
! We need your feedback and questions to fuel these discussions and help us improve our mentoring program.

special thanks

Special thanks to Anisha Pindoria and Rui Melo, who help me improve these posts as part of our peer mentorship, and Bill Heys, who turns my gibberish into human readable content.

reference info