Team purpose

Smallish, cross-functional teams that work to a sequenced product backlog to improve existing products and services, deliver projects and implement complex change. Measured on effectiveness.

Product teams solve problems, problems that have never been solved before.

Most often, the topics that the teamwork on in the backlog come from, Product Strategy, user feedback, or the Objectives and Key Results (OKR) for the team.

‍

Remote Working Challenges

• Mission Teams to pass things gently to the Product Teams and help each other in that transition phase.

‍

Why the team is included in the remote:af?

Product Teams usually act as part of a Team of Teams that work together to create value. The Team of Teams collaboratively plans how to meet enterprise objectives and breaks objectives into independent pieces of work that collectively add value to the end-user (either a customer or a change stakeholder). Sometimes Product Teams will also operate their solutions (Dev/Ops) and sometimes they will handover solutions to Operations Teams.

‍

Team Configuration

Team composition

• Leaders
• Developers

Size

‍<= 9 people

Operating Model

• Organise around customer products
• Focus on effectiveness and  efficiency
• Customer/Stakeholder centric

Funding

‍Capacity based or Capex/Opex funded

Boundaries

• Clear boundaries, flexible responsibilities
• Evolving dependencies

Development programs

• Loosely structured development programs

Team profile

• Creative, curious, rigorous
• Quality focused
• Generalists with specifications
• Life long learners

Culture and leadership

• Collegiate
• Learning
• Developmental
• Curious

Team Launch Pattern

• Clarify System of work
• Visual Work
• Digital representation of work
• Centralise/create a backlog
• Customer input from surveys and feedback capability
• Regulatory from business projects
• Remote Team Alliance
• Similar to Mission and Product teams (not all are separate roles specifically).
• But need to include
• Support for projects and delivery

Team Events

Same as the other team types, but things to consider:

Planning/Replenishment

• Based on Kanban
• Usually from Production Incidents and Delivery requirements - see replenishment section for details
• From Analysis and Problems
• From Delivery
• From Customer Input
• From Regulation/Legal
• Change Demand
• System Demand

Daily Standup

• Not a status update.

Review

• Celebrate the work the team does
• Use data to show improvements.

Reflection

• Data metric based.
• Prod trends inform what/where to focus capacity towards production improvements

Key Metrics and Benchmarks

Product teams are measured on the effectiveness and success of implementing business products and processes which will drive for the customer and for the business.

The thing is, you can’t tell whether you’re driving value unless you have a way to measure the value that you’re creating! After all, you need an objective way of determining your impact outside of qualitative feedback from customers and stakeholders. That’s why it’s so valuable for product managers to be , and why it’s such a key skillset for any product manager. Although it’s difficult to align current product metrics to the targeted business value.

Measure what’s meaningful, not what’s easy, set the right metrics from the very beginning, even if they’re hard to implement.

It’s critical to first define what business value is. What are the key drivers of the business? Every business will have different key drivers, and even the same business will wind up having different key drivers over time.

Once you know what the various drivers of the business are, you select one of them to focus on. Remember, product management is all about tradeoffs — you can’t do everything at once.

Once you know the business value you want to target, then define the north star objective. What’s the core qualitative objective of your team?

Once you have an objective, you can then define a north star metric that moves you towards the objective. Remember, an objective is aspirational, whereas a metric is tangible.

Once you have the north star metric, you can then decompose the metric into distinct qualitative problem areas.

As you define a problem area, you can then ideate with business stakeholders and development teams to flesh out a constellation of metrics that you can track and improve.

To summarise:

1. Determine the key drivers of the business
2. Select the single driver you want to focus on
3. Define a qualitative north star objective
4. Define a north star metric
5. Decompose the north star metric into qualitative problem areas
6. Define product metrics that capture each problem area
7. Solve a problem area and measure progress

Human beings are naturally driven by stories, and the most robust stories are naturally driven by data.

The convenience of getting a metric isn’t correlated with how well-aligned that metric is to the business value.

Begin with the business value that you want to drive, then define a north star objective and metric, then break down into sub-metrics, and iteratively solve problems that will ladder back into the business value.