docs(day1): Added notes for first talk
This commit is contained in:
parent
84dad8b5a3
commit
7d3d55e58d
77
content/day1/01_product-thinking.md
Normal file
77
content/day1/01_product-thinking.md
Normal file
@ -0,0 +1,77 @@
|
||||
---
|
||||
title: Product Thinking for Cloud Native Engineers
|
||||
weight: 1
|
||||
tags:
|
||||
- platform
|
||||
- org
|
||||
- management
|
||||
---
|
||||
|
||||
<!-- {{% button href="https://youtu.be/rkteV6Mzjfs" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}} -->
|
||||
<!-- {{% button href="https://docs.google.com/presentation/d/1nEK0CVC_yQgIDqwsdh-PRihB6dc9RyT-" style="tip" icon="person-chalkboard" %}}Slides{{% /button %}} -->
|
||||
|
||||
This is a slightly updated version of the KubeCon EU 2025 Talk of the same name.
|
||||
Please check out [my notes of the KubeCon talk](https://kubecon25.nicolai-ort.com/day0/08_product-thinking) for additional details and the original recording + slides.
|
||||
|
||||
## But Why?
|
||||
|
||||
- Focus on user value and outcome
|
||||
- Create visibility for things that are usually not that visible (operatrions, planning, ...)
|
||||
|
||||
## And What
|
||||
|
||||
### Principles
|
||||
|
||||
- Problem > Solution
|
||||
- Outcome > Output
|
||||
- Product > Project
|
||||
|
||||
### For whom?
|
||||
|
||||
- Builders (Platform Dev, Product Dev)
|
||||
- Enablers (Platform Dev, Service Providers)
|
||||
- Regulators
|
||||
- Viewers (Controlling, Finance)
|
||||
|
||||
## Problems > Solutions
|
||||
|
||||
### First steps
|
||||
|
||||
1. Find the problem that is the most important (has the most value) to solve
|
||||
2. Understand the problem to figure out how to solve it
|
||||
|
||||

|
||||
|
||||
### Defining the problem space
|
||||
|
||||
Goals:
|
||||
- Identify opportunities
|
||||
- Prioritise
|
||||
- Gather insignts and data
|
||||
|
||||
Techniques:
|
||||
- Value stream mapping
|
||||
- RICE, Value vs Effort or ather cost benefit analysis
|
||||
- Analyse your exploration proces
|
||||
|
||||
## Metrics
|
||||
|
||||
- If you don't provide your own metrics, someone else will guesstimate some for you - this might result in metrics that don't represent the value you provide
|
||||
- Product metrics should measure outcome not output (or performance metrics)
|
||||
- Baseline: You need to know the desired outcome
|
||||
|
||||
## And how?
|
||||
|
||||
### With Frameworks
|
||||
|
||||
- DevEx: Balance Flow State, Feedback Loops and Cognitive Load
|
||||
- Internal Platform Scorecard (by Syntasso): Speed (Time to deploy), Safety (Policy compliance), Efficiency (mean time to upgrade), Scalabulity (Mean time to new service)
|
||||
- DORA
|
||||
- Space
|
||||
- DX Core 4
|
||||
|
||||
### At the engineer level
|
||||
|
||||
- Look at: Which outcomes do you want to reach
|
||||
- Side-Benefit: Easy to explain to management
|
||||
- You can do it yourself without a PO or PM
|
Loading…
x
Reference in New Issue
Block a user