Vom ersten Gespräch bis zur skalierten Plattform.
Product-Engineering ist kein UI-Design. Es ist Systemdenken. Die Verbindung zwischen dem, was Nutzer wirklich tun, und dem, was das System tragfähig abbilden kann. Discovery findet, was gebaut werden soll. Design entscheidet, wie es sich anfühlt. Build setzt es zuverlässig um. Scale sorgt dafür, dass es unter Last hält. Vier Phasen, ein integriertes Vorgehen. Für DACH-Founder und Product-Manager.
Discovery macht die Frage klarer.
Discovery ist keine Anforderungserhebung, sondern Hypothesenbildung. Ziel: die richtige Frage präzise stellen, bevor die Antwort gebaut wird. Wer entwickelt, bevor die Frage klar ist, baut eine Antwort auf die falsche Frage.
Discovery startet mit Nutzer-Interviews, die echte Jobs-to-be-Done aufdecken. Nicht Wunschlisten. Aus den Interviews entstehen Hypothesen, die priorisiert und validiert werden, bevor eine Zeile Code entsteht.
Design-Phase ist Systemdenken.
Product-Engineering-Design ist kein klassisches UI-Design. Es entscheidet, wie das System konzeptionell aufgebaut ist. Welche Entitäten existieren, wie sie sich zueinander verhalten, welche Aktionen möglich sind, wie Nutzer durch komplexe Abläufe geführt werden. UI ist die letzte Schicht, nicht die erste.
Informations-Architektur
Welche Entitäten existieren, welche Beziehungen haben sie, welche Operationen sind erlaubt. Das konzeptionelle Modell entscheidet, ob das System für Nutzer erklärbar ist.
Interaction-Design
Wie werden Nutzer durch komplexe Abläufe geführt. Nicht jede Aktion passt auf einen Bildschirm. Schrittweise Prozesse, Fehlerzustände und Edge-Cases sind Designproblem, nicht Implementierungsdetail.
Prototyping
Klickbare Prototypen testen Interaction-Hypothesen, bevor Engineering-Zeit fliesst. Ein Prototyp kostet einen Tag. Eine falsch gebaute Funktion kostet Wochen. Der Unterschied zählt.
Build-Phase ist Engineering, qualitätsgesichert.
Schnelligkeit und Qualität sind kein Widerspruch, sondern Ergebnis guter Engineering-Praktiken. Eingebaut von Anfang an, nicht nachträglich als Refactoring-Projekt.
CI/CD ab Tag 1
Automatisiertes Build, Test und Deploy für jeden Pull Request. Kein manuelles Deployment, keine Deployment-Angst.
Testing-Strategie
Unit-Tests für Kern-Logik, Integration-Tests für kritische Pfade, End-to-End-Tests für Haupt-Workflows. Kein Test-Overkill, keine Test-Lücke.
Code-Reviews
Jede nicht-triviale Änderung wird reviewed. Reviews sind Wissenstransfer, nicht Fehlerkontrolle. Der Reviewer lernt, nicht nur der Autor.
Dokumentation
Architekturentscheidungen werden als Architecture-Decision-Records festgehalten. Warum eine Entscheidung getroffen wurde, ist oft wichtiger als das Was.
Scale ist eine Architektur-Eigenschaft.
Skalierbarkeit ist kein Feature, das nachträglich eingefuegt wird. Die Architektur bestimmt, wie weit ein System skaliert ohne fundamentalen Umbau. Die Scale-Phase systematisiert, was die Build-Phase begonnen hat: Messung, Haertung, Kostenoptimierung und Team-Fähigkeit als fortlaufender Prozess.
Performance
Datenbankabfragen profilen, N+1-Queries eliminieren, Caching validieren, CDN für statische Assets. Performance-Arbeit beginnt mit Messung, nicht mit Vermutung.
Observability
Metriken, Logs und Traces als Trio. Distributed-Tracing für Microservice-Abhängigkeiten. Alerting auf SLOs, nicht auf willkürliche Schwellenwerte.
Reliability
Chaos-Engineering für kritische Pfade. Incident-Runbooks vor dem ersten Incident. Backup-Strategie mit getesteten Recovery-Zeiten, nicht mit theoretischen RPO/RTO.
Cost-Optimierung
Cloud-Kosten wachsen mit Traffic, aber nicht linear, wenn die Architektur stimmt. Idle-Resource-Bereinigung, Reserved-Instance-Planung, Query-Kosten-Analyse als regelmässiger Prozess.
Team-Skalierung
Wie neue Entwickler produktiv werden. Onboarding-Dokumentation, lokale Entwicklungsumgebung, Codebase-Mental-Map. Das erste Jahr eines Engineers ist teuer. Gute Strukturen verkürzen es.
Security-Härtung
OWASP-Checks als Teil des Release-Prozesses, nicht als jährliches Audit. Dependency-Scanning, Secret-Rotation-Automatisierung, Least-Privilege gelebt statt proklamiert.
Product-Engineering im Studio, strukturiert.
Interviews mit Founder, Product-Manager und repräsentativen Nutzern. Systemanalyse, wenn ein Produkt schon läuft. Ergebnis: ein Hypothesen-Backlog mit Priorisierung nach Validierungsaufwand und Lernwert.
Informations-Architektur, Interaktionsmodell und technisches Blueprint entstehen parallel. Scope-Entscheidung für den ersten Build-Zyklus mit explizitem Nicht-Scope. Prototyp für kritische Interaktions-Hypothesen.
Iterative Entwicklung. Jede Iteration endet am Review-Gate. Funktioniert es. Ist es testbar. Ist die Entscheidung dokumentiert. Deployment in Staging nach jeder Iteration, kein langer Entwicklungs-Tunnel.
Vollständige Dokumentation. Architecture-Decision-Records, Runbooks, lokale Entwicklungsumgebung, KPI-Dashboards. Dein Team soll das System nach der Übergabe selbständig weiterentwickeln können.
Arbeit, die sich zeigt.
Unsere Kundenprojekte sind in anderen Disziplinen gebaut, aber nach denselben Product-Engineering-Prinzipien. Diagnose-First, Discovery vor Build, Übergabe mit Dokumentation.
Fragen, die vor dem Gespräch gestellt.
Was ist Product-Engineering und wie unterscheidet es sich von Softwareentwicklung?
Softwareentwicklung implementiert definierte Anforderungen. Product-Engineering setzt früher an. Es befragt die Anforderungen, bevor sie implementiert werden. Discovery (Nutzerforschung, Hypothesen), Design (Informationsarchitektur, Interaktionsmodell) und Engineering (Build, Test, Deploy) als integriertes Vorgehen. Reine Softwareentwicklung beginnt am dritten Schritt.
Wie läuft eine Discovery-Phase konkret ab?
Typischer Ablauf: qualitative Nutzer-Interviews mit fünf bis zehn Personen, Auswertung nach Jobs-to-be-Done, Hypothesen als priorisierter Backlog, Prototyping für die zwei bis drei wichtigsten Hypothesen, Validierungsplan mit Messpunkten. Die Phase endet mit einer Scope-Entscheidung. Was wird im nächsten Build-Zyklus getestet. Dauer meist ein Sprintzyklus.
Wann macht eine Discovery-Phase keinen Sinn?
Wenn die Anforderungen vollständig bekannt und stabil sind, etwa bei internen Tools oder Migrationen bestehender Systeme. Discovery als Selbstzweck ist auch falsch. Wenn die Grundhypothese durch Marktdaten oder eigene Nutzung bereits stark validiert ist, geht es direkt in den Aufriss.
Wie wird Design in Product-Engineering gedacht, versus klassisches UI-Design?
Klassisches UI-Design startet mit Farben, Typografie, Layout. Product-Engineering-Design startet mit konzeptionellen Entscheidungen. Welche Entitäten existieren, wie verhalten sie sich zueinander, welche Operationen sind erlaubt. Das UI kommt am Ende, nicht am Anfang. Informationsarchitektur und Interaktionsmodell entscheiden, ob ein System für Nutzer erklärbar ist, nicht ob es schön aussieht.
Wie viel Testing ist genug?
Genug heisst: die Fälle, die geschäftskritisch sind, sind automatisch getestet. Typisch: Kern-Geschäftslogik mit hoher Unit-Test-Abdeckung. Kritische Integrationspunkte wie Payment-Flows und Auth mit Integration-Tests. Wichtigste User-Journeys mit End-to-End-Tests. 100 Prozent Coverage kostet mehr als sie bringt. Unter 30 Prozent in kritischen Modulen ist riskant.
Was bedeutet Observability konkret?
Du kannst Fragen über das Systemverhalten beantworten, ohne neue Logging-Statements zu deployen. Drei Säulen: Logs für Events (was ist passiert), Metrics für Kennzahlen (wie oft, wie schnell, wie viel), Traces für Ablaufverfolgung (welcher Pfad lief durch welche Services). Ein System ohne Observability verstehst du erst, wenn es ausfällt.
Wie skaliert man ein bestehendes Produkt, ohne es neu zu bauen?
Selten muss alles neu gebaut werden. Strangler-Fig: neue Komponenten ersetzen das Alte schrittweise, während das System weiterläuft. Prioritäten für Umbau: Engstellen mit Performance-Problemen, Sicherheitsrisiken und Module, die Weiterentwicklung blockieren. Stabile Module bleiben unangetastet, auch wenn der Code nicht schön ist.
Wie lang dauert ein typisches Product-Engineering-Engagement?
Discovery, Aufriss, Build-Iteration, Scale-Phase. Jede Phase hat ein klar definiertes Ergebnis und eine Phasenentscheidung. Nach jeder Phase entscheidest du, ob und wie es weitergeht. Zeitrahmen je nach Umfang und Systemkomplexität.
