...
...
Outcomes over Output
...
An outcome is a measurable change in user behavior.
The goal of any feature you ship to a user should be to change the user’s behavior in a measurable and positive way.
User behavior <A> changes from <x> to <y> over timeframe <t>. |
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.
A. Business outcome: reduce time-to-market, via developer efficiency
The average amount of time for a developer to start a task to merge the changes into version control is reduced by 30%. (Developer value stream prior to SRE’s Accelerate metrics.) |
B. Product outcomes: reduce developer context-switching while working on a developer task
The average number of times that a developer context switches to another task on a daily basis is reduced by 30%. |
C. Traction metrics (: feature usage and performance)
The 95% duration that a developer waits on the most frequently used command in their local development is reduced by 30%. |
When developers have a question on local development, they discover the answer 3x faster than before. |
Developers run 3x more local development commands in a week. |
Developers post 3x less frequently in the devstack-questions slack channel. |
Product outcomes
Product outcomes:
...
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.
...
To ensure user-centricity, opportunities are phrased from the user’s point of view. Tie the opportunity to a specific moment in time.
...
Opportunities = user needs, user pain points, user desires, or user questions, at a moment in time.
Opportunity Tree Example
...
Externalize work
...
Visualizes the team’s mental model of the problem space
Promotes the idea of many bets or multi-tracking towards the business outcome
Binds solutions in groupings (opportunities) that are themed, contextual and most importantly, aligned to the outcome
The trees can also be used in reverse; if you have a lot of ideas (or a backlog you’ve just taken over), you can work backward to the outcome and discard ideas that don’t align
Allows measuring at many levels — business outcome, opportunities, solutions, experiments
Ensures opportunities are exposed through generative research (like the Kata Table)
Note: we need to find a standard way to link opportunities to user insights.
Idea: The top-level depth of the opportunity tree can be taken from the developer journey described above. This allows the team to ideate against the desired outcome across each part of the developer journey.
Arch example (link)
...
SRE example (link)
...
HPS: Hypothesized Problem Statements (reference)
We believe that <this capability> |
RICE (reference)
|
CD3: Cost-of-delay over Duration (reference)
Incorporate the values from the RICE model into the CD3 equation, as follows:
Weekly Impact = (Weekly frequency of issue) * (# of hours lost each time) Cost-of-delay (hours lost weekly) = (Reach of developers) * (Weekly Impact) CD3 = Cost-of-delay / Effort |
👩🎓 CONTINUOUSLY LEARN: Kata Table
...