Analytics/ProductManagerDutiesHandover

Product Manager Duties

Our product manager has two complementary responsibilities. The first is to act as a Product Owner and Business Analyst and work with the development team to specify, design and ship software on a regular cadence that delights our customers.

The second is to work as a more conventional Product Manager, where in co-operation with the Director of Analytics, the Research and Data team lead and the Development team, help set the strategic direction for the work of the development team.

This is a lot of work and depending on the Product Owner responsibilities, it might be difficult to do the work associated with the Product Manager duties. The plan is to monitor this moving forward and have the Director assist here when necessary. An interesting comparison and commentary on PM versus PO responsibilities is here.

Additional Documentation

Our process is documented in this Google doc. It would be awesome to make it publicly available and/or convert it to a wiki. (It's a google doc for historical reasons) There are two other versions that we need to deprecate or delete: one and two

The document that the WMF uses as a reference for our scrum process is here. While I like this document, it should be considered aspirational -- we do not follow all or even most of its recommendations.

The mobile team has probably the best internal documentation. Again, we follow some but but not all of these principles.

Development Artifacts

We have a number of development artifacts that we use to manage our backlog and our sprints:

• Prioritization Hub where our current epics are listed along with links to requirements
• Planning Board (Mingle)
• 2014 Showcases

Status of Transitioning Activities

Frequency	Activity	Artifact	Responsibility
Daily	Standup		Kevin
	Bug Triage	Bugzilla	Toby
Weekly	Update to Public Lists (Friday)	Email Report	Toby
	Tasking	User Stories / Etherpad / Estimates	Kevin
	Backlog Grooming	User Stories / Backlog	Kevin
	Staff Meeting (Tuesday)
Biweekly	Sprint Planning	User Stories, Dan's Spreadsheet, Mingle	Kevin
	Showcase	Deck	Kevin / Dan
	Retrospective	Etherpad, Email	Kevin
Monthly	Dev Updates (WMF)	Text Report	Toby

Handover

Operational Handover (30-60 days)

Currently, the Director is performing the role of Product Owner. This has been generally sub-optimal and the development team has been doing a great job in executing and filling in the gaps. But this needs to end. This phase is focused on bringing the new PM up to speed with the team, how we work and all the idiosyncrasies of the Foundation and our stakeholders. Note that the team is a bit exhausted with discussion of process, so we should not try to implement any wholesale changes initially.

Goal: Product Owner responsibilities handled completely by the new PM.

Artifact: Documents updated to reflect how things really operate and shared publicly (let's replace old deck with wiki docs)

Specific Tasks:

1. Start rewriting the user stories to make them more directed and smaller
   1. Editor Engagement Vital Signs
      1. Follow up with R&D (Aaron) on Metric definitions
   2. Decide on scoping for #1227 (The browser report for mobile)
2. Expand requirements for new high priority Epics
   1. MVP for EEVS
   2. Dashboard Discoverability/Annotations
3. Update Mediawiki Epic page with new prioritization
4. Bugzilla triage (should we push this off to phase 2?)

Optimization (60 - 120 days)

It is likely that after spending some time with the team and the process that some optimizations will be needed. A particular sore spot is the tooling. This phase should be focused on working with the Scrum Master and the development team to make any necessary changes to the process. Another interesting area of improvement might be a shared definition of Done.

Goal: Product Development process solidified in co-operation with Scrum Master and Development Team. if necessary, migration to new tooling. New process steps documented.

Artifact: Epics and backlog in new tool (if required) and new process steps documented.

Sustainable Development (120 days onward)

It is desirable that we get the process where it needs to be and limit our changes to small tweaks as needed.

Goal: Operational excellence -- we are able to release software at a sustainable pace that meets the needs of our stakeholders.

Artifact: Documentation updated regularly, understood by our stakeholders.

Projects

This is a unordered list of projects that might be taken on during the first few months

• Tool selection