ℹ️ This site is no longer maintained and may be taken offline in the future. When available, CDS Learning Resources will link to updated documents.

Guide for product teams

Français

Product team member responsibilities

Purpose of this document: Clarify who, by default, is responsible for key elements of building a product. Why? Because we often have subtly different understandings.

These responsibilities are not exhaustive. These responsibilities focus on your role as embedded on a product team. A team member may have broader responsibilities to their community, or the organization, that isn’t described here. There may be other important things to do to help your product succeed. We trust team members to do what needs to be done.

If there are multiple team members from a community on a team, they share the responsibilities for their discipline. For example, if there are multiple developers on a product, they divide up the responsibilities amongst themselves.

Others can (and should) support other team’s responsibilities. This document describes who’s ultimately accountable. It doesn’t limit who can be involved. Many responsibilities touch many members of a product team.

Responsibilities each discipline has for their respective expertise

  • Documenting their activities, decisions and outputs for fellow and future team members and others in the government to learn from
  • Raising opportunities to tell compelling stories about their work to the Outreach team
  • Being able to demonstrate the working service, and explain the reasoning behind key product decisions.
  • For partnership products: Coaching their “pair” from the partner on how to adapt their expertise to our way of working.

Product manager

  • Defining the need(s) and vision for the product, and ensuring the team’s aligned with it, given the goals and timeline of the partnership or platform play
  • Describing the users and their needs, and advocating for these in product decisions, with particular input from the researcher
  • Balancing user needs with organisation needs and technical constraints when negotiating product decisions
  • Setting a roadmap for meeting the need and accomplishing the vision
  • Defining the features of the product that meet the need(s)
  • Writing user stories to guide feature development and tracking these on the backlog, based on input from the team and stakeholders
  • Continuously prioritizing the product backlog based on input from the users, the team and stakeholders
  • Facilitating key team rituals, including sprint planning, standups, review, and retros
  • Determining when things are “done” based on input from involved team members
  • Advocating for timeline, goal and people matching changes to the product
  • Setting timelines and ensuring all the other things on this list get done
  • Setting and sharing metrics for the product, with particular input from the policy analyst, researcher and service owner
  • Ensuring the sprint load is properly scoped to team members’ capacity
  • Monitoring the team’s health and advocating for action to improve it
  • Preparing proposals to continue or end a partnership or product, in partnership with a partnership advisor or delivery manager, as applicable
  • Creating strategies to wind down work, transfer ownership, or sunset a product after OCEO has determined work will stop

For platform products:

  • Conducting business analysis for platform products
  • Supporting the engagement and onboarding of early users

Partnership advisor

For partnership engagements.

  • Establish goals and timeline of the partnership engagement
  • Develop partnership structure and agreement, with particular input from the product manager and tech lead
  • Secure necessary agreements for elements of the partner department for our work (including access to people, resources and other work), with help from product team experts in a given area.
  • Develop an approach for engaging and communicating with the partner department, including stakeholder mapping, with help from service designers and policy analysts. Stakeholder engagement to support project success (ie alignment workshops)
  • Communicate team plans, progress and blockers to the Director of Partnerships
  • Work with service owner to set roles and responsibilities (and facilitate coaching as required)
  • Provide support to the service owner as they establish a team within department during the beta phase to take on the service as our work on it ends
  • Coordinate briefings, with help from the product manager (internal, to the partner assistant deputy minister monthly, ministerial)
  • Update website to reflect new partnerships, with outreach’s help
  • Monitor the health of the partnership
  • Prepare proposals to continue or end a partnership or product, in partnership with the product manager and team. (The decision to end partnerships is ultimately made by the CEO.)

Service owner

For partnership engagements

  • Accountable for service outcomes
  • Lead efforts to define service outcomes with guidance and support from the CDS delivery team and ensure baseline data is provided where it is available.
  • Assemble an interdisciplinary team to work alongside CDS, so they can continuously improve the service during and after beta
  • Ensure team members have access and are connected with people within the partner department
  • Remove blockers to delivery by advocating for the needs of the delivery team across groups and levels within the department
  • Communicate team plans and progress to the partner department
  • Raise awareness of the partnership and service iteration within the department, across government, and with the public
  • Lead, with support from CDS, all monthly meetings with Signing Authorities.
  • Attend twice monthly touch base meetings with the delivery team.

For platform products

(At the moment, the Director of Platforms is the service owner for all platform products.)

  • Evaluate needs for the product and the product’s capacity to meet the needs
  • Ensuring an interdisciplinary team is assembled to develop and continuously improve the product incrementally over several product lifecycles
  • Find departments to work with to pilot and use products
  • Help other team members access and connect with people within the departments
  • Communicate team plans and progress to stakeholders
  • Remove blockers to delivery by advocating for the needs of the delivery team across groups and levels within departments
  • Raise awareness of the product across government, and with the public
  • Attend all biweekly sprint reviews to understand progress and help remove blockers to delivery

Researcher

  • Identifying and describing the people who will use the service, their needs, and goals to the product team or other stakeholders, with particular input from the product manager
  • Planning research (participant recruitment, scheduling, travel, user compensation, preparing material etc) including both quantitative and qualitative methods.
  • Conducting interviews, usability tests and other research methods with the people who will use (or be affected by) the service
  • Conducting quantitative experiments on prototypes and production tools that bear on product metrics
  • Summarize the results of research for the product team, partners or other stakeholders
  • Triaging research findings and playing them back to relevant team members (including representatives from design, dev, PM, policy)
  • Suggesting changes to the product roadmap, features or backlog based on research findings
  • Working with designers and developers to integrate changes based off of research.
  • Preparing materials that explain how the product meets user needs, with particular input from product designers and managers. Coordinating how best to share research findings
  • Suggesting relevant metrics to the product manager based on discovery research.
  • Tracking product metrics in research activities and reviewing the product evaluation framework.
  • Documenting research activities, and high-level insights for future team members and stakeholders.

Designer

  • Charting the current state of the service (i.e., service blueprints) and future journey of all users involved in the service (service designers), with particular input from research.
  • Working closely with researchers to help define questions, identify gaps, plan research activities, and conduct analysis/synthesis after research has taken place.
  • Designing wireframes for prototypes or production features (interaction designers).
  • Writing content for wireframes or product features (content designers).
  • Linking design decisions back to research, and tracking whether ongoing issues surfaced in research have been addressed in design, in collaboration with research.
  • Proposing design solutions or changes in response to research findings, in collaboration with developers and with help prioritizing with product managers.
  • Conducting workshops and collaborative activities (i.e., ideation sessions), with support from researchers (service design led).
  • Defining how might we questions, insight statements, etc (taken outside of a workshop setting) and connecting them back to ideation goals and design decisions.
  • Ensuring the team is following CDS Design Principles, common design patterns, standards, and guidelines consistently.
  • Ensuring everything is being designed inclusively and accessibility, from the start, and at every step of the way.

Developer

  • Create simple prototypes to better understand service/user needs
  • Develop software that meets service/user needs
  • Test software continuously to ensure it’s functional, secure, and accessible and enable others to change it with confidence
  • Write clear, concise and well documented software
  • Provide high quality, timely code reviews to fellow developers as requested
  • Assign open source license to all CDS written source code, except under specific circumstances
  • Understand our partner’s current development environment, pain points, and roadmap.
  • Use and expand on continuous delivery pipeline
  • Adhere to CDS Software delivery best practices
  • Make use of ‘infrastructure as code’ and ensure there is an automated and repeatable release process
  • Ensure the service generates sufficient logs to enable debugging, monitoring, and incident response
  • Implement sufficient monitoring and alerting to ensure secure and reliable operations
  • Define service level objectives and design system accordingly
  • Create shared understanding of software delivery practices that will be used for the product (languages, framework, deployment target, etc)
  • Get buy-in for technology decisions and practices from key decision makers
  • Create architecture diagrams that incorporate our service and how it interacts with existing systems
  • Conduct security accreditation process with security teams (CDS and/or Partners) to acquire Authority to Operate
  • Work with team members to create an iterative change approval process that includes relevant members from other disciplines
  • Get buy in on how to release service changes early and often, to enable rapid improvement based on feedback and policy changes
  • Learn from software and process failures, through the use of incident reviews, and share learnings with your team, partner, and community

Product Tech Lead

This is not a permanent role, but an additional set of responsibilities for the chosen developer. Think of it as a developer “add-on”.

  • Spokesperson for the development team with a good understanding of overall product decisions. The Product tech lead is the touch point for client communication and demos; advocates on behalf of the development team in product, design or research meetings.
  • Helps bring forth and table issues such as product tech debt, technical skills gap, training needed.
  • Helps resolve technical conflicts (i.e tie breaker) and manage the technical quality of team deliverables
  • Main point of contact for incidents during business hours
  • Coordinate the release management requirements
  • Responsible for onboarding new developers
  • Works with line managers in providing feedback on developers’s performance

What this role is not about

  • Review all technical decisions
  • Define system architectures

Policy advisor

  • Researching and documenting organizational structures, legislation, regulations and program policies, and existing funding and investments, and identifying areas that may impact delivery.
  • Researching and identifying GC-wide rules, and identifying and planning for potential blockers.
  • Identifying and securing policy changes and approvals required for CDS services to operate over the long-term, with the help of subject matter experts.
  • Working with developers to ensure documentation is completed to support an Authority to Operate a service.
  • Working with researchers to ensure research is enabled and is carried out in accordance with relevant legislation and policies.
  • Working with designers and developers to ensure content and code considers and reflects relevant legislative or policy requirements
  • Suggesting relevant metrics to the product manager based on CDS-wide measurement priorities
  • Conveying CDS-wide standards and frameworks for metrics-setting.
  • Gathering relevant baseline data from partner departments, with assistance from service owner and partnership advisor

Outreach advisor

  • Providing translations and translation reviews of product content and research materials.
  • Working with all product team members to identify and develop storytelling opportunities for the duration of the product development period.
  • Working with partner communications teams to facilitate storytelling work and overall communications about the product within the department, across government and with the public.
  • Developing and executing a go-to-market strategy for the product with the team PM