This document summarizes learnings from product management that we would like to apply in the developer-facing Arch and SRE teams. It also includes a standardized set of practices that we propose to externalize our work.

References

Outcomes over Output

The goal of any user-facing feature/deliverable is to change the user’s behavior in a measurable and positive way. What matters is whether the deliverables are impacting user behavior, which in turn impacts product indicators, which in turn impacts business indicators.

Outcome Hierarchy

A hierarchy of outcomes allows a team to connect their team’s outcomes to an overall business impact: business outcome, product outcomes, traction metrics.

Example

A. Business outcome: reduce time-to-market, via developer efficiency

B. Product outcome: reduce developer context-switching while working on a developer task

C. Traction metrics: feature usage and performance

Product outcome

Product outcome:

• connects to the business outcome

• connects to the human behavioral change, and to a moment in time of the user’s journey

• a metric that the team is able to move on their own

• is negotiated with the leader - is it aggressive enough?

Anti-Patterns

Anti-pattern: Feature Factory

Many software teams struggle to deliver value to users. More often than not, it’s because:

1. product and engineering teams stopped talking to users

2. they don’t measure whether what they delivered (features) had the desired impact

   1. they don’t measure at all

   2. they measure the wrong thing

They are stuck in a feature factory, just “building stuff” and churning out features — and hoping that someone will use it.

Shipping a feature does not equal success. Changing users’ behavior in measurable and positive ways is what leads to success.

Anti-pattern: Project-mindset

To foster an outcomes-based flow of value, teams need to move away from thinking about delivering projects, to instead having long-term user-centric:

1. ownership of a product or

2. support of a platform as a service.

Anti-pattern: Push Adoption of unneeded solutions

“If I had an hour to solve a problem, I’d spend 55mns thinking about the problem and 5mns thinking about solutions.” - Einstein

By emphasizing the prioritization of problems instead of the prioritization of technical solutions, teams can focus energy on continual learning of the user’s problem space. This shift in mindset from delivering solutions to solving problems enables the team to discover users' needs, desires, and delights, which can also evolve over time.

This is different from a solutions-first approach, where a solution is chosen before fully understanding the problem space, and then pushed to be adopted by users.

Anti-pattern: Metrics that don’t connect to business outcomes

The following measures, by themselves, tell us little about the business impact of the work. They need to be connected to the higher-level business outcome.

• Feature metrics: Performance of a feature (How many people are using it? Is it quicker or easier for a user to do X now than it was before?)

• Product metrics: Performance of specific product objectives (Because of feature X, more people are using functionality Y)

• Team metrics: How many story points/features were launched at the end of the month/quarter? (This will only lead to — at best — success theatre, and at worse, the wrong behaviors from all parties)

A more business-centric way to build and manage a product is by measuring our efforts in terms of outcomes, not output. When we measure outcomes, we measure the impact the new features had on the activity of the users AND the success of the company.

Continuous Learning via User-centricity & User-first

• Using data that is regularly gathered from users, we build user insights, which inform our hypotheses.

• Being user-first, we ask questions and actively listen in order to form hypotheses, without making assumptions and jumping to conclusions/solutions on behalf of our users.

• Being user-centric, we keep the voice and perspective of the user in mind as we prioritize, design, develop, validate → and continuously learn and iterate.

Opportunity trees and Product Katas (see below) are tools to enable continuous learning and refining of the user-problem space. We continue to discover opportunities through regular user touchpoints.

To ensure user-centricity, opportunities are phrased from the user’s point of view. Tie the opportunity to a specific moment in time.

Opportunity Tree Example

Open

Process & Externalizing Work

Rituals

Org-wide

We will externalize our work as part of the following organization-standard rituals:

1. Quarterly Strategy Reviews (folder)

2. Consumer Reviews (overview, folder)

3. Engineering Operating Reviews (overview, folder)

4. Squad Demos (arch, sre)

With Director(s)

In addition to the above org-wide rituals, work with your engineering director to establish a cadence of regular review of the squad’s process and artifacts. For example, the director may request a weekly touchpoint to review the squad’s WIP and artifacts from steps 3-5 below.

Process & Artifacts

This section lists standard ways for our teams to explore the problem space, prioritize, externalize, and iterate.

1. MAP: User Journey

Starting with the user journey gives a high-level understanding of our user’s needs and a user-centric perspective of the high-level touchpoints with the products and services that we provide.