Mindset
Von Code zu Produkt
Der Perspektivwechsel
Der Perspektivwechsel
Als Entwickler denkst du: "Wie baue ich das?"
Als Product Engineer denkst du: "Warum bauen wir das?"
Der Unterschied ist fundamental. Es geht nicht darum, Code zu schreiben. Es geht darum, Probleme zu lösen.
Die drei Fragen
- Für wen? – Wer hat das Problem?
- Warum? – Warum ist es ein Problem?
- Was dann? – Was passiert, wenn wir es lösen?
Code ist ein Mittel, kein Zweck
Der beste Code ist der, den du nicht schreiben musst.
Manchmal ist die Lösung kein Feature, sondern bessere Dokumentation. Manchmal ist die Lösung kein Code, sondern ein Gespräch. Manchmal ist die Lösung, das Problem neu zu definieren.
"Lass mich das schnell bauen"
Schnell gebaut heißt nicht schnell gelöst. Versteh erst das Problem.
Vom Output zum Outcome
Output: Features shipped, Zeilen Code, PRs merged.
Outcome: User-Probleme gelöst, Business-Ziele erreicht, Value geliefert.
Output ist messbar. Outcome ist wichtig.
Tipp
Frag dich bei jedem Feature: Was ändert sich für den User, wenn das live ist? Wenn die Antwort unklar ist, verstehst du das Problem noch nicht.
Die praktische Übung
Nimm ein Feature, an dem du gerade arbeitest.
- Schreib auf: Für wen ist das? (Konkreter User, nicht "alle")
- Schreib auf: Welches Problem löst es? (In den Worten des Users)
- Schreib auf: Wie weiß ich, dass es funktioniert? (Messbares Outcome)
Wenn du eine Frage nicht beantworten kannst, bau das Feature noch nicht.
Der Mindset-Shift
| Entwickler-Denken | Product Engineer-Denken |
|---|---|
| Wie baue ich das? | Sollte ich das bauen? |
| Ist der Code sauber? | Löst das das Problem? |
| Wann bin ich fertig? | Wann ist der User happy? |
| Was ist technisch elegant? | Was ist für den User wertvoll? |
Zusammenfassung
- Die drei Fragen: Für wen? Warum? Was dann?
- Code ist ein Mittel, kein Zweck – der beste Code ist der, den du nicht schreibst
- Vom Output zum Outcome – nicht Features zählen, sondern gelöste Probleme
- Die Kernfrage: Was ändert sich für den User, wenn das live ist?
Was kommt als nächstes?
Du hast den Perspektivwechsel gemacht: Es geht um Probleme, nicht um Code. Die erste der drei Fragen war: "Für wen?"
Genau da geht es jetzt weiter. Wie verstehst du die Menschen, für die du baust? Wie lernst du ihre Probleme wirklich kennen? Das ist User Empathie – und ohne sie bleiben alle anderen Skills oberflächlich.