Persönliche Diskussionsgrundlage · nach dem PM-Workshop
Nach dem PM-Workshop habe ich versucht, meine Gedanken einmal zusammenzubringen. Nicht als fertige Strategie, sondern als Diskussionsgrundlage.
Frage 1
Wissen wir als Unternehmen wirklich gemeinsam, wo wir Ende 2027 stehen wollen?
Frage 2
Können alle Bereiche erklären, welchen Beitrag sie zu diesen Zielen leisten?
Frage 3
Arbeiten wir an den wichtigsten Problemen – oder reagieren wir zu oft auf einzelne Impulse?
Kapitel 02
Keine Anklage, sondern Beobachtungen als Ausgangspunkt für die Diskussion. Wo aus meiner Sicht die größten Hebel liegen.
Es gibt viele gute Initiativen und viele engagierte Teams, aber aus meiner Sicht fehlt eine einfache Unternehmensvision, aus der sich für alle Bereiche klare Ziele ableiten lassen.
Dadurch optimieren Produktmanagement, Infrastruktur, Produktentwicklung, Vertrieb, Kundenservice, Marketing, Finance usw. teilweise jeweils ihre eigenen Themen.
Arbeiten wir wirklich alle am gleichen Unternehmensziel?
Aus dem Kompass bzw. aus der Unternehmensleitung kommen regelmäßig neue Impulse. Das ist grundsätzlich richtig und wichtig.
Wenn aber ein klarer gemeinsamer Zielrahmen fehlt, wirken solche Impulse schnell wie neue Richtungswechsel: Arbeiten wir an den falschen Dingen? Müssen wir umpriorisieren? Ist das vorherige Thema noch wichtig? Wer entscheidet eigentlich?
Wenn Unternehmensziele klar sind, lassen sich Impulse einordnen: Zahlt das auf Ziel 1, 2 oder 3 ein – oder nicht?
Unsere Vision kann nur funktionieren, wenn die technische Plattform zuverlässig funktioniert.
Wir sprechen aber seit langer Zeit über Stabilität, Wartungen, Performance, Ausfälle, technische Schulden, Legacy und Auswirkungen auf Kunden.
Ist Reliability bei uns wirklich ein Unternehmensziel – oder immer wieder ein technisches Unterthema?
Bei einigen wichtigen Themen ist nicht klar: Wer hält den Hut? Wer verantwortet den Zielzustand? Wer darf Entscheidungen treffen?
Wer bringt verschiedene Teams zusammen? Wer sorgt dafür, dass ein Thema nicht zwischen Abteilungen hängen bleibt?
Ein wichtiges Thema ohne klaren Hutmensch ist noch keine echte Priorität.
Neue Produkte, AI, Marketplace, Lead-Produkte, Agenturhelfer, Hosting, Migration, Compute, Developer Experience, neue Geschäftsmodelle.
Das Problem ist nicht Ideenmangel. Das Problem ist Fokus.
Strategie bedeutet nicht nur zu entscheiden, was wir machen. Strategie bedeutet vor allem zu entscheiden, was wir nicht machen.
Kapitel 03 · Vorschlag
mittwald macht Web- und Digitalagenturen technologisch zukunftsfähig.
mittwald ist der souveräne, zuverlässige und nahbare Technologiepartner hinter dem Geschäft unserer Agenturkunden.
Agenturen sollen den Großteil ihrer Kundenprojekte auf mittwald entwickeln, deployen und betreiben können:
Unser Job ist nicht, jedes Problem einer Agentur zu lösen. Unser Job ist:
Die technischen Probleme hinter ihren Kundenprojekten zu lösen.
Die Agentur schafft den differenzierenden Mehrwert für ihren Kunden. mittwald übernimmt möglichst viel von:
Leitmotiv
Ihr baut die Lösung.
Wir kümmern uns um alles dahinter.
Vorschlag zur Diskussion – keine beschlossene Vision.
Kapitel 04
Wenige gemeinsame Ziele statt vieler paralleler Prioritätenlisten. Als Vorschlag zur Diskussion.
ZIEL 01
mittwald soll die zuverlässige technische Basis für den Großteil des Agenturgeschäfts sein.
North Star
80–90 % der typischen Projekte einer Web- und Digitalagentur können selbstverständlich auf mittwald betrieben werden.
ZIEL 02
Agenturen sollen bestehendes Geschäft zuverlässig betreiben, neue Technologien ausprobieren, AI-Angebote entwickeln und schneller live gehen – mit weniger eigener Ops-Kompetenz.
North Star
Nicht: „Wie verkaufen wir noch ein weiteres Produkt?“ Sondern: „Wie werden wir für das Kerngeschäft unserer Agenturen so relevant, dass sie immer mehr ihrer Projekte mit uns machen?“
ZIEL 03
mittwald soll nicht nur gekauft werden. mittwald soll freiwillig empfohlen werden – in Communities, Pipelines und auf Konferenzen.
North Star
Developer Advocacy entsteht aus einem guten Produkt – nicht nur aus Marketing.
Kapitel 05
Gleiche Ziele, unterschiedliche Beiträge. Die Matrix ist ein Diskussionsangebot – kein fertiges Zielbild pro Bereich.
Tabelle horizontal scrollbar – auf schmalen Screens seitlich wischen oder mit Tastatur scrollen.
| Bereich | Ziel 1 · Plattform funktioniert | Ziel 2 · Agenturen erfolgreicher | Ziel 3 · Liebe & Empfehlung |
|---|---|---|---|
| Produktmanagement |
|
|
|
| Infrastruktur |
|
|
|
| Produktentwicklung |
|
|
|
| Developer Experience |
|
|
|
| Kundenservice |
|
|
|
| Vertrieb |
|
|
|
| Marketing |
|
|
|
| Finance / Buchhaltung |
|
|
|
| People |
|
|
|
| Security |
|
|
|
Kapitel 06
mittwald wird zum unsichtbaren Technologiepartner hinter den Projekten von Web- und Digitalagenturen.
North Star
Die Agentur baut und deployed. mittwald läuft zuverlässig im Hintergrund.
01
Von Code zu mittwald muss extrem einfach werden.
02
Was deployed wurde, läuft stabil, performant und kann für typische Agenturprojekte wachsen.
03
Kunden kommen einfach aus alter und externer Welt in die neue mittwald Welt.
04
AI wird zu einem normalen Plattformbaustein.
05
mittwald integriert sich in den Workflow des Entwicklers.
Kapitel 07
Fokus heißt auch: bewusst entscheiden, was wir nicht pushen. Zum PM-Plattform-Blick →
PUSH
Hier investieren wir bewusst.
ENABLE
Muss hervorragend funktionieren, ist aber nicht zwingend eigenes Wachstumsfeld.
MAINTAIN
Relevant und wirtschaftlich, aber kein großer Innovationsfokus.
EXIT / NO PUSH
Themen, die nicht mehr auf den Kern einzahlen.
Wir bauen nicht alles, was Agenturen gebrauchen könnten.
Wir bauen die Plattform, auf der Agenturen fast alles für ihre Kunden bauen können.
Kapitel 08
Wie sollten wir Produktmanagement 2027 organisieren, wenn unser Ziel nicht mehr primär lautet: „Wir entwickeln viele einzelne Hosting-Produkte weiter“ – sondern eine Plattform, auf der Agenturen 80–90 % ihrer Kundenprojekte einfach deployen, verwalten und zuverlässig betreiben können?
Passt unsere heutige Aufteilung nach einzelnen Produkten noch zu der Plattform, die wir 2027 bauen wollen?
Viele Produkte wurden stark weiterentwickelt und sind wirtschaftlich wichtig. Die Frage ist nicht, ob die Arbeit gut war – sondern ob die Aufteilung noch zur Plattform passt.
Heute: Container Hosting
Aus einem konkreten Produkt entsteht zunehmend die Frage: Wie kommen Anwendungen generell möglichst einfach auf mittwald?
Heute: AI Hosting
Aus einem konkreten Produkt entsteht zunehmend: Wie wird AI zu einem normalen Bestandteil der mittwald Plattform?
Heute: Domains, SSL und Mail
Wichtige Basisdienste – das Ziel sollte sein: Domain dran. DNS funktioniert. SSL ist da. Mail läuft. Fertig.
Heute: Agenturprodukte & Discovery
Sollte die Rolle weniger Sammlung kleiner Produkte sein und stärker Discovery, Adoption und neue Kundenbedürfnisse?
Vertiefung: Customer Lifecycle →Heute: Software-Stack & PHP ES
Brot-und-Butter-Geschäft: Aktualität, Stabilität, Sicherheit, Lifecycle, Wiederholbarkeit, Wirtschaftlichkeit.
Heute: Marketplace → mStudio
Strategisch wichtiger Wechsel: vom Marketplace hin zur zentralen Plattform-Oberfläche.
Heute: Migration + Hosting
Sehr große Themen gleichzeitig. Braucht Migration und Hosting-Plattform einen eigenen klaren Hut?
mStudio ist kein weiteres Produkt
Accounts, Projekte, Berechtigungen, Container, Hosting, AI – und künftig weitere Dienste. Nicht ein Produkt neben anderen, sondern die zentrale Management- und Control-Ebene.
mStudio
Zentrales Control Panel
│
┌────────────────┼────────────────┐
│ │ │
Deploy Hosting AI
│ │ │
Container Compute Inference
Templates Scale Modelle
Apps Runtime Gateway
│ │ │
└────────────────┴────────────────┘
│
Domains / DNS / SSL / Mail / Storage / DBsWenn mittwald eine Plattform statt vieler Produkte sein soll – wer sorgt dafür, dass sich das im mStudio wie EINE Plattform anfühlt?
Nicht: „Produktmanager für eine Oberfläche.“
Sondern: Wie erlebt und verwaltet der Kunde die gesamte mittwald Plattform?
Historisch logisch – für die Plattformstrategie aber mit Grenzen.
HEUTE · PRODUKTE
ZUKÜNFTIG · PLATTFORM
Agenturen sollen Projekte entwickeln, deployen, verwalten und betreiben – mittwald übernimmt die technische Komplexität dahinter. Dafür brauchen wir gemeinsame Plattformfähigkeiten, nicht nur einzelne Produktverantwortliche.
HEUTE
Produktmanager besitzt Produkt
ZUKÜNFTIG
Produktmanager verantwortet Plattformfähigkeit
Weniger: „Wer besitzt welches Produkt?“
Mehr: „Wer sorgt dafür, dass diese Fähigkeit unserer Plattform richtig gut wird?“
Diskussionsvorschlag – keine Rollenverteilung.
| Person | Möglicher Bereich 2027 | Produkte / Themen | Einfach gesagt |
|---|---|---|---|
| Tobias | Application Platform & Deploy | Container Hosting, Docker Compose, Templates, Deployment, Git/API/CLI, SiteDraft als Wette | Wie kommen Anwendungen möglichst einfach auf mittwald? |
| Mareen | Domains, Mail & Trust | Domains, DNS, SSL, Mail, Archivierung | Wie funktionieren die wichtigen Basisdienste zuverlässig und möglichst automatisch? |
| Sina | Customer Lifecycle, Churn & Growth | Churn, Lifecycle, Adoption, eventgesteuerte Kommunikation, AV Manager / Barriere-Checker prüfen, LeadFyndr Exit | Warum kündigen Kunden, wo verlieren wir sie – und wie machen wir sie gezielter erfolgreicher? |
| Hannes | Application Runtime & Lifecycle | WordPress, TYPO3, PHP, PHP ES, Software Lifecycle | Wie bleibt unser Brot-und-Butter-Geschäft stabil, aktuell und wirtschaftlich? |
| Basti | mStudio & Platform Experience | mStudio, Projekte, Organisationen, Benutzer, Buchung, produktübergreifende Journeys | Wie fühlt sich mittwald für Kunden wie eine einzige Plattform an? |
| Volkmar | Migration & Transition | externe Migration, Kundencenter → mStudio, alte → neue Plattform | Wie kommen bestehende Kunden und Projekte möglichst einfach in die neue mittwald Welt? |
| Maik | AI Platform | Shared/Dedicated AI, Inference, Modelle, Gateway, Embeddings, Speech, Templates | Wie wird AI zu einer normalen Plattformfähigkeit? |
| Niklas | UX Research / Continuous Discovery | kein eigenes Produkt | Lösen wir überhaupt die richtigen Kundenprobleme? |
| Offen | Hosting Platform & Scale | Webhosting, vServer, Dedicated, E-Commerce, gemeinsame Kubernetes-Plattform | Wie wird unsere gemeinsame Hosting-Plattform stabiler, flexibler und skalierbarer? |
OFFENE VERANTWORTUNG
Webhosting, vServer, Dedicated und E-Commerce basieren auf derselben Kubernetes-Infrastruktur. Die Frage ist nicht „Wer entwickelt den vServer weiter?“ sondern:
Wie entwickeln wir unsere gemeinsame Hosting-Plattform so, dass sie stabil, zuverlässig und flexibel genug für 80–90 % der typischen Agenturprojekte wird?
Dafür scheint aktuell ein klarer PM-Hut zu fehlen.
Ausfälle, Wartungen, Performance, technische Schulden – seit längerer Zeit Thema. Brauchen wir einen eigenen „Produktmanager Reliability“ – oder gehört Stabilität direkt zur Hosting Platform?
VARIANTE A · EIGENER HUT
Vorteile
Nachteile
VARIANTE B · TEIL DER HOSTING PLATFORM
Vorteile
Nachteile
Hypothese: Für eine Plattform, deren Versprechen „Es läuft einfach“ lautet, sollte Reliability kein nachgelagerter Reparaturprozess sein – sondern Kernbestandteil der Plattformverantwortung.
BEISPIEL · NEUE ARBEITSWEISE
Wette: Hilft SiteDraft Agenturen, schneller eine Idee in eine laufende Anwendung auf mittwald zu verwandeln?
WENN JA
weiterentwickeln · stärker in Application Platform & Deploy integrieren
WENN NEIN / EXTERNE TOOLS BESSER
Replit, Lovable, Claude Code … → SiteDraft Exit · dafür extrem gute Integration zu mittwald
Wir müssen nicht jedes Werkzeug selbst besitzen. Entscheidend ist, dass mittwald der beste Ort wird, an dem das Ergebnis läuft.
mStudio gehört nicht in PUSH/ENABLE wie ein normales Produkt – es ist die horizontale Management-Ebene darüber.
PUSH
ENABLE
MAINTAIN
EXIT / NO PUSH
mStudio
Platform Experience / Control Plane
Basti
│
┌──────────────────┼───────────────────┐
│ │ │
APPLICATION PLATFORM HOSTING PLATFORM AI
& DEPLOY & SCALE PLATFORM
Tobi Offen Maik
│ │ │
Container Webhosting Inference
Compose vServer Modelle
Templates Dedicated Gateway
Git/API/CLI E-Commerce Speech
SiteDraft-Wette Reliability Embeddings
│ │
└────────── APPLICATION RUNTIME ───────┘
Hannes
WordPress / TYPO3 / PHP
MIGRATION & TRANSITION DOMAINS / MAIL / TRUST
Volkmar Mareen
DISCOVERY & ADOPTION UX RESEARCH
Sina NiklasmStudio ist die zentrale Management-Ebene. Darunter liegen Plattformfähigkeiten – PM-Rollen arbeiten an Teilen derselben Plattform, nicht isoliert an Einzelprodukten.
Vielleicht brauchen wir 2027 nicht für jedes heutige Produkt einen eigenen strategischen Produktmanager.
Vielleicht brauchen wir klare Verantwortliche für die wenigen Fähigkeiten, die unsere Plattform wirklich ausmachen.
Application Platform & Deploy
Wie kommt etwas zu mittwald?
Hosting Platform & Scale
Worauf läuft es – und wie zuverlässig?
Application Runtime
Welche Standardsoftware läuft darauf?
AI Platform
Welche AI-Fähigkeiten nutzt die Anwendung?
mStudio & Platform Experience
Wie verwaltet der Kunde alles?
Migration
Wie kommt der Kunde in die neue Welt?
Domains, Mail & Trust
Welche Basisdienste laufen automatisch?
Discovery & Research
Lösen wir die richtigen Probleme?
Produkte können sich verändern oder verschwinden.
Die Kundenprobleme und Plattformfähigkeiten bleiben.
Persönliche Diskussionsgrundlage nach dem PM-Workshop. Keine beschlossene Rollen- oder Organisationsstruktur.
Kapitel 09
Ein möglicher, klarer Hut – statt einer Sammlung sehr unterschiedlicher Einzelprodukte.
HEUTE
MÖGLICHER ZUKÜNFTIGER HUT
Warum kündigen Kunden, wo verlieren wir sie im Lifecycle und wie können wir sie gezielt erfolgreicher machen?
Fokus: bestehende Kunden und deren Entwicklung – nicht der Aufbau immer neuer Einzelprodukte.
Wo und warum verlieren wir Kunden – und was machen wir daraus?
Nicht nur dokumentieren, warum jemand gekündigt hat – daraus konkrete Maßnahmen ableiten und Wirkung messen.
Für jede Phase: Was soll der Kunde tun? Wo bricht er ab? Welche Signale zeigen Risiko oder Potenzial?
Nicht Newsletter an alle – sondern Hilfe aus dem tatsächlichen Kundenverhalten.
Der Kunde steckt an einer bestimmten Stelle fest – wie helfen wir ihm weiter?
ONBOARDING
Kunde ist seit fünf Tagen registriert, hat aber noch kein erstes Projekt.
→ automatisierte Hilfestellung oder Mail
PRODUKT NICHT AKTIVIERT
Kunde nutzt Hosting, hat eine wichtige Funktion noch nicht eingerichtet.
→ gezielte Information
MIGRATION
Account vorhanden, aber noch kein bestehendes Projekt migriert.
→ passender Migrationshinweis
AI
Agentur nutzt Container intensiv, aber noch kein AI Hosting.
→ relevanter AI-Use-Case oder Template – keine generische Werbung
INAKTIVITÄT
Kunde zeigt typische Churn-Signale.
→ frühzeitig Hilfe, Servicekontakt oder passendes Angebot
Nicht: „Wie verkaufen wir möglichst viele Zusatzprodukte?“ Sondern:
Welche zusätzlichen Plattformbausteine helfen einem bestehenden Kunden bei seinem aktuellen Geschäft?
Mehr mittwald nutzen, weil es für die Projekte sinnvoll ist – nicht weil wir aggressiv bespielen.
Die Rolle arbeitet stark bereichsübergreifend.
PRODUKTMANAGEMENT
Welche Produktprobleme verursachen Churn oder verhindern Adoption?
KUNDENSERVICE
Welche Probleme tauchen immer wieder auf?
VERTRIEB
Welche Bestandskunden haben Potenzial für weitere passende Lösungen?
MARKETING
Welche eventgesteuerten Inhalte und Journeys brauchen wir?
DATA / ANALYTICS
Welche Signale zeigen Churn-Risiko oder Cross-Selling-Potenzial?
MSTUDIO
Welche Aktionen können direkt im Produkt ausgelöst oder unterstützt werden?
PUSH · AKTIVER FOKUS
MAINTAIN / ENTSCHEIDEN
Bewusst: standardisieren, wenig Aufwand, integrieren, Partner oder abkündigen?
EXIT
Bereits als Exit entschieden – gehört nicht mehr zur zukünftigen Rollenlogik.
Beispiele zur Diskussion – keine festgelegten OKRs.
CHURN
ACTIVATION
ADOPTION
CROSS-SELLING
LIFECYCLE-KOMMUNIKATION
Nicht nur Öffnungsraten messen. Outcome: Hat sich das Kundenverhalten positiv verändert?
Sina sorgt dafür, dass wir verstehen, warum Kunden bleiben oder gehen – und dass wir ihnen zum richtigen Zeitpunkt den richtigen nächsten Schritt anbieten.
Mehr Kunden erfolgreich machen, weniger verlieren und bestehende sinnvoll weiterentwickeln.
DIE ROLLE IST NICHT
DIE ROLLE IST
Customer Lifecycle systematisch verstehen und verbessern.
Unsere Plattform funktioniert einfach
Sina zeigt, wo Kunden im Produkt scheitern und welche Probleme Churn verursachen.
Unsere Agenturen werden mit mittwald erfolgreicher
Sina verbessert Onboarding, Adoption und sinnvolles Cross-Selling.
Agenturen und Entwickler lieben und empfehlen mittwald
Sina hilft, Reibung im gesamten Kundenlebenszyklus zu reduzieren.
Nicht mehr möglichst viele kleine Produkte betreuen.
Sondern den gesamten Weg des Kunden verstehen und gezielt besser machen.
Persönliche Diskussionsgrundlage – keine beschlossene Rollenverteilung.
Kapitel 10
Jedes strategische Push-Thema braucht genau einen klaren Hutmensch. Beispiel: Managed PostgreSQL →
EIN HUTMENSCH …
Ownership bedeutet nicht: „Ich mache alles.“
Ownership bedeutet: „Ich sorge dafür, dass wir das Ziel erreichen.“
Beispielhafte PM-Bereiche zur Diskussion
Kapitel 11
Wie bekommen wir strategisch wichtige Plattformbausteine schneller auf die Straße?
Managed PostgreSQL als konkretes Beispiel für ein organisatorisches Muster – nicht als Kritik an einzelnen Teams oder Personen.
Wie organisieren wir strategische Plattformthemen so, dass sie trotz bestehender Infrastrukturprobleme nicht immer wieder nach hinten geschoben werden?
Agenturen entwickeln zunehmend individuelle Apps, AI/RAG, Chat, SaaS, CRM, Tools – oft mit Claude Code, Replit oder Lovable. Der typische Stack:
┌─────────────────────────┐
│ Anwendung │
│ Container / Compute │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Managed PostgreSQL │
└─────────────────────────┘Bei Replit, Vercel, Render, Railway, Fly.io, Supabase, Neon …
Ich deploye meine Anwendung und daneben bekomme ich mit wenigen Klicks eine Datenbank.
PostgreSQL ist grundsätzlich möglich – oft als Container. Der Kunde trägt dann selbst Verantwortung für Updates, Backups, Restore, Monitoring, Failover, Recovery, Konfiguration.
Managed bieten wir heute insbesondere MySQL. Für moderne Application- und AI-Workloads fehlt ein zentraler Baustein:
Managed PostgreSQL.
DAS EIGENTLICHE PROBLEM
Wahrscheinlich nicht „Wir wissen nicht, was PostgreSQL ist“ – und auch nicht „Es gibt keine technische Möglichkeit.“
Aus „Das brauchen unsere Kunden“ wird „Ja, aber vorher Problem X … Y … Z.“ – Monate später kein Service.
Ein strategisches PUSH-Thema darf nicht permanent gegen das gesamte Tagesgeschäft verlieren.
Managed PostgreSQL ist nur ein Beispiel. Das gleiche Muster bei Redis, Object Storage, Vector DBs, Queues, AI-Infrastruktur, Compute, Storage …
Wie entwickeln wir neue Managed Services, obwohl die bestehende Plattform parallel stabilisiert werden muss?
Wer hält den Hut dafür, dass Managed PostgreSQL am Ende wirklich live geht – nicht nur ein Ticket erstellt?
NICHT
Perfekte Managed-Database-Plattform für zehn Jahre planen.
SONDERN
Strategische Plattform-Wette mit klar begrenztem Scope: Managed PostgreSQL v1 produktiv auf bestehender Plattform.
Nicht die komplette Zukunftsarchitektur – sondern: Was ist die kleinste Architektur, die wir guten Gewissens produktiv anbieten können?
KUNDE KANN (v1)
MANAGED DURCH MITTWALD
NOCH NICHT v1
Beliebige Versionen, dutzende Extensions, Cross-Region-HA, komplexes Autoscaling, freie postgresql.conf, Replica-Topologien, vollautomatische Major-Upgrades …
Erst einen guten Managed PostgreSQL Service bauen. Danach eine perfekte Database Platform.
Nicht sechs Technologien monatelang vergleichen. Default definieren – Abweichung braucht konkreten Grund. Architektur ist Hypothese, keine Religion.
Mission: Managed PostgreSQL produktionsreif machen.
PRODUCT / PM
Scope, Kundennutzen, Priorität
PLATFORM / K8S ENG
technische Integration
POSTGRESQL-KOMPETENZ
fachlich sauberer Betrieb
SRE / RELIABILITY
Failure-, Recovery-, Maintenance-Anforderungen
EXTERNER SPEZIALIST (OPTIONAL)
Review & Failure-Tests – nicht Monate Architektur-Strategie
Beispielzeiten – keine beschlossene Planung.
Woche 1–2
Architektur & erster Cluster
Woche 3–4
Backup, PITR, Monitoring, Provisionierung
Woche 5–6
Failure & Performance Tests
Woche 7–8
mStudio/API & interne Beta
Woche 9–10
Pilotkunden
Danach
Go / Change / Stop
Mission, Team und Timebox – nicht nur Platz im Infra-Backlog.
Nicht: „Fühlt sich die Architektur theoretisch perfekt an?“ Sondern: Besteht sie unsere Failure-, Recovery- und Performance-Tests?
„Deployment funktioniert“ reicht nicht.
Managed bedeutet Verantwortung für den Betrieb – nicht nur Installation.
Hutmensch (z. B. PM Hosting Platform & Scale)
Ziel, Scope, Priorisierung, Go-Live – sorgt dafür, dass wir das Ziel erreichen
Engineering Owner
technische Implementierung
SRE / Platform Owner
Betriebsfähigkeit & Reliability
PostgreSQL Owner
DB-spezifische Standards
Blockiert eine strategische Wette länger als zwei Wochen, muss sichtbar eskaliert werden:
Nicht: „Wir schauen nächsten Monat nochmal.“
NICHT
„Entwerft unsere zukünftige Managed-Database-Strategie.“
SONDERN
Managed PostgreSQL ist ENABLE – aber strategisch entscheidend für Deploy, AI, Hosting Platform, Developer Experience.
Ein ENABLE-Thema kann für mehrere PUSH-Themen entscheidend sein.
Neues Projekt
→ Anwendung deployen (Container / Git / Template)
→ Datenbank hinzufügen [ PostgreSQL ]
Größe: Small / Medium / Large
Backups aktiv · PITR 7 Tage
→ Connection String: postgresql://...
→ fertig.Der Kunde soll K8s, Operators, WAL und Storage nicht sehen müssen.
Plattform funktioniert einfach
Schließt Lücke in der Application Platform.
Agenturen erfolgreicher
Mehr moderne Apps komplett bei mittwald.
Entwickler empfehlen mittwald
Moderner Developer Workflow braucht Managed Services.
PostgreSQL → Redis → Object Storage → Queues …
Plattform noch nicht stabil genug
Welche konkreten Probleme verhindern PostgreSQL wirklich – messbar, nicht pauschal?
Stateful = hohe Komplexität
Kleiner Scope, dedizierte Nodes, Failure Tests, externe Expertise.
Zusätzlicher Betriebsaufwand
Vor Go-Live: Wer betreibt? Rufbereitschaft? SLOs? Runbooks?
Wirtschaftlich nicht relevant
Früh mit echten Kunden validieren, Kosten pro Instanz messen.
Externer Partner schneller
Build vs. Partner vs. Buy explizit vergleichen.
BUILD
Vorteile
Integration, Souveränität, Kontrolle, Plattformkompetenz
Nachteile
Betriebs- & Engineering-Aufwand, Reliability-Verantwortung
PARTNER
Vorteile
schneller, weniger Betrieb
Nachteile
Abhängigkeit, Margen, Integration, Souveränität
BUY / MANAGED TECH
Vorteile
Operator + Enterprise Support als Mittelweg
Nachteile
Abstimmung mit eigener Plattform
Bewerten nach: Time to Market, Reliability, Kosten, Souveränität, Integration, Betriebsaufwand, Differenzierung.
Managed PostgreSQL ist vielleicht weniger ein Datenbankproblem als ein Test dafür, ob wir strategisch wichtige Plattformfähigkeiten schnell genug umsetzen können.
Klare Priorität · Klarer Hutmensch · Kleiner Scope · Golden Path · Dediziertes Team · Harte Failure Tests · Schnelle Entscheidung
Wenn wir wissen, dass Kunden Managed PostgreSQL brauchen: Was muss konkret passieren, damit es in zehn Wochen statt in zehn Monaten live geht?
Persönliche Diskussionsgrundlage – keine beschlossene technische Architektur oder Organisationsentscheidung.
Kapitel 12
44 offene Themen aus dem aktuellen GitLab-Quartalsboard – bewertet nach Vision, Unternehmenszielen und zukünftigen Hüten. Nicht nach heutigem Autor.
44
Themen
3.4
Ø Fit
14
PUSH
11
Hut prüfen
9
Stop/Park/Exit
44 von 44 Themen · PUSH · ENABLE · MAINTAIN · EXIT
Plattformweite AuthZ/Token-Fähigkeit – mit QP!127 zusammenführen. Deploy nutzt sie, besitzt sie nicht allein.
Kern von Customer Lifecycle & Growth. Frühe Signale schlagen reaktive Einzelmaßnahmen.
Direktes Reliability- und DX-Outcome: Deploy darf nicht jedes Mal spürbar stören.
Grundlage für echte Application Platform: Build → Registry → Deploy. Eng mit Zero-Config und Tokens.
Usage/Control/Trust – Voraussetzung für produktive Agentur-Workloads und Weiterverrechnung an Endkunden.
Agenturen arbeiten in Teams – ohne saubere Rechte skaliert die Plattform nicht für 80–90 % der Projekte.
Mit QP!69 zu einer Token-/Scopes-Initiative bündeln. Kern für API-first Developer Experience.
Herzstück der Produktvision: Was Agenturen bauen, landet einfach auf mittwald. Eng mit DX und mStudio.
Direkter Fit zur Agenturpositionierung: Endkunden trennen, resellen, skalieren. Must-Win für AI-Wachstum.
Staging ist eine Application-/Deployment-Fähigkeit, kein Lifecycle-Thema. Gehört zu Deploy; mStudio liefert die UX.
Vom Einzelprojekt zum Produkt. Hoher Umsatzhebel, braucht klare Produktisierung statt Manufaktur.
Teil des Container-/Registry-Workflows. Eng mit Registry/Dockerfile-Themen koppeln.
Developer Experience im Betrieb von Apps/Containern. Enabler für Debugging und Vertrauen – kein eigenes Wachstumsprodukt.
Ressourcen-/Kapazitätstransparenz ist Hosting-Plattform, nicht Domains/Mail. UX in mStudio mit Basti.
Gleiche Capability wie QP!121 – Hosting/Compute-Transparenz. Mit QP!121 mergen; Hut nicht Domains.
Kern der Runtime-Verantwortung: CMS/PHP sicher und aktuell halten. Wirtschaftlich relevant, Innovationsfokus eher niedrig.
Transparenz bei Incidents ist Plattformvertrauen. Eng mit Notifications und Reliability koppeln.
Strategische Option für Souveränität und Modellvielfalt – noch Discovery, nicht monatelang Architektur ohne Pilot.
Wichtiges Trust-Signal – Scope klein halten (v1 Scan), nicht Security-Plattform für alles.
Hardware-/Compute-Architektur der gemeinsamen Hosting-Plattform – nicht Container-Produkt-PM allein.
SSO/moderne Auth ist Agency-Expectation. Nach 2FA priorisieren, nicht parallel verzetteln.
Monetarisierung und Tariflogik sind Voraussetzung, damit Dedicated und Shared skalieren – kein Selbstzweck, aber Wachstumshebel.
Querschnitt für Status, Auslastung, AI-Limits, Incidents. Platform Experience, kein Einzelprodukt.
Trust-Fundament der gesamten Plattform. Kein Wachstumsfeature, aber Pflicht für seriöse Agency-Plattform.
Praktischer Deploy-/Data-Workflow. Kleiner Scope, hoher Reibungsabbau – Enable, nicht eigene Wette.
Sinnvoll nur mit klarer Hypothese zum Kundennutzen. Sonst Feature-Fläche ohne Adoption.
Reduziert Reibung bei Domain-/DNS-Übernahmen – typischer ENABLE-Hygienefaktor, kein PUSH.
Operative Domain-Stabilität und Prozessklarheit. ENABLE, nicht Wachstumsprodukt.
Kann Reibung senken – oder Komplexität erzeugen. Erst Job-to-be-done prüfen; nicht als Ersatz für klare UX.
Passt zum Trust-/Mail-Hut. Erst prüfen, wie häufig Agenturen das wirklich brauchen und ob es 2027 Fokus verdient.
Strategische Wette: Hilft SiteDraft, Idee → laufende App auf mittwald? Sonst eher EXIT zugunsten Deployment-Ziel für externe Builder.
Interessanter DX-Hack, aber Marketplace-Ökosystem ist kein PUSH. Besser: Skills für Deploy/API der Kernplattform.
Sales-/Onboarding-Hilfe, kein strategischer Plattformbaustein für 2027.
Betriebs-/Pricing-Prozess, kein Produktbau. Erledigt halten, nicht als Quartals-PUSH führen.
Hilfreich, aber Content-/Support-Arbeit – sollte Plattform-PUSH nicht verdrängen.
Hilft Agenturen sichtbar zu werden, löst aber kein technisches Plattformproblem hinter Kundenprojekten. Bindet AI-PM-Fokus.
Abhängig von SiteDraft-Entscheidung und Marketplace-NO-PUSH. Nicht separat pushen – in SiteDraft-Validate oder stoppen.
Nur sinnvoll, wenn SiteDraft weitergeführt wird – dann Enablement durch Maik, Hut bei Deploy-Wette.
Marketplace als Geschäftsmodell ist aktuell NO PUSH. Feinjustierung der Sortierung kostet Fokus.
Gleiches Muster wie QP!109 – Marketplace-Nebenkriegsschauplatz.
Marketplace-Geschäftsmodell = NO PUSH. Prozessautomation lohnt sich erst bei klarer Marketplace-Strategie.
Marketplace-Wachstumshebel ohne Marketplace-PUSH – Fokus kostet echte Platform Experience.
Exit bereits strategisch entschieden. Weitere Pflege bindet Lifecycle-Kapazität ohne Plattformbeitrag.
Großes Marketplace-Investment ohne strategischen PUSH. Energy besser in Platform Experience Kern.
Kapitel 13
Wir brauchen nicht überall denselben Typ Mensch.
EXPLORER
Eher bei Zukunftsthemen wie AI, Deploy, neue Hosting Platform.
SCALER
Eher bei Runtime, Domains/Mail, Migration, Lifecycle.
Rollen nach der Aufgabe besetzen. Teams nach komplementären Stärken bauen.
Kapitel 14
Antwort: Resilienz, Reliability, weniger Abhängigkeiten.
Antwort: klarer Nordstern und Fokus.
Antwort: kleine Wetten, kurze Feedback-Loops, Experimente.
Antwort: beobachten, messen, lernen, anpassen.
Klar im Ziel. Flexibel im Weg. Stabil im Betrieb.
Kapitel 15
Keine komplette Jahres-Feature-Roadmap. Die Richtung bleibt stabil. Der konkrete Weg darf sich ändern.
Kapitel 16
Drei Frameworks kombiniert – Alignment, Quartalsziele und operative Frühindikatoren. Zur ehrlichen Bewertung →
HOSHIN KANRI
Unternehmensziele werden nicht einfach herunterdiktiert, sondern über einen Catchball-Prozess mit den Bereichen konkretisiert.
OKRs
Unternehmensziel: „Unsere Plattform funktioniert einfach.“
4DX / LEAD MEASURES
Nicht nur Ergebniskennzahlen messen, sondern beeinflussbare Frühindikatoren.
Lag Measure
50 % weniger Supportkontakte wegen Performance.
Lead Measures
Kapitel 17
Keine Managementreligion. Drei Werkzeuge – einzeln und ehrlich bewertet. Wir sollten passende Elemente auswählen, nicht drei komplette Systeme gleichzeitig einführen.
01 · HOSHIN KANRI
Wenige strategische Ziele – über Catchball mit den Bereichen konkretisiert.
Hoshin Kanri ist ein strategisches Steuerungsmodell aus dem Lean-Umfeld. Die Unternehmensleitung formuliert wenige strategische Ziele – die aber nicht einfach top-down verteilt werden. Stattdessen diskutieren die Bereiche im Catchball: Was bedeutet das Ziel für uns? Welchen Beitrag können wir leisten? Welche Abhängigkeiten und Kennzahlen gibt es? Wer übernimmt Verantwortung? Ziel: Unternehmensstrategie und operative Arbeit verbinden.
Es trifft unser Alignment-Problem
Viele Bereiche arbeiten an guten Themen – aber die Verbindung zu gemeinsamen Unternehmenszielen ist oft unklar. Hoshin macht sichtbar: Unternehmensziel → Bereich → konkreter Beitrag.
Weniger Gefühl von Richtungswechseln
Impulse aus Kompass oder GF lassen sich einordnen: Zahlt das auf unsere Ziele ein – und wenn nein, warum priorisieren wir es trotzdem?
Verantwortung wird sichtbar
Wer hält den Hut? Welche Bereiche müssen zusammenarbeiten? Welche Kennzahl zeigt Erfolg?
Bereiche gestalten mit
Catchball verhindert das Gefühl „drei Ziele von oben, jetzt erfüllt sie“. Dialog erhöht Akzeptanz und Eigenverantwortung.
Stark bei bereichsübergreifenden Themen
„Unsere Plattform funktioniert einfach“ betrifft Infra, Dev, PM, Service, DevEx, Finance und Security – Hoshin macht gemeinsame Beiträge sichtbar.
Hohe Komplexität
Zu viele Ziele, Kennzahlen und Abhängigkeiten erzeugen schnell ein Steuerungsmodell, das niemand mehr versteht.
Catchball kann langsam werden
Zu viele Abstimmungsebenen kosten Geschwindigkeit – gerade bei AI- und Technologie-Themen problematisch.
Nur mit echter Priorisierung wirksam
Zehn Unternehmensziele und zwanzig Initiativen lassen sich auch mit Hoshin nicht retten.
Neue Management-Bürokratie
X-Matrix, Reviews und Reports dürfen nicht zum Selbstzweck werden.
Führung muss entscheiden
Catchball heißt nicht Konsenspflicht. Am Ende: Was machen wir? Was nicht? Wer entscheidet bei Konflikten?
Jahresstrategie und Unternehmens-Alignment
Hoshin Kanri könnte sehr gut unser Alignment-Problem lösen. Wir sollten eher die Logik und den Catchball übernehmen als ein komplettes Lean-Steuerungssystem.
02 · OKRs
Objectives motivieren. Key Results machen Fortschritt objektiv sichtbar.
„Unsere Plattform funktioniert einfach.“
PM
Von Code zu mittwald wird selbstverständlich.
Infra
Wartungen haben deutlich weniger Auswirkungen auf Kunden.
Service
Die häufigsten wiederkehrenden Plattformprobleme werden strukturell beseitigt.
OBJECTIVE
Was wollen wir erreichen? Qualitativ, motivierend, verständlich.
KEY RESULTS
Woran erkennen wir objektiv, ob wir es erreicht haben? Messbar und ergebnisorientiert.
Strategie in Quartale übersetzen
Vision bleibt stabil. Die konkrete Arbeit darunter darf sich alle drei Monate ändern – passend zu einer volatilen Tech-Welt.
Ergebnisse statt Featurelisten
Nicht „Feature X, Y, Z“, sondern „Von Code zu mittwald wird deutlich einfacher.“ Teams behalten Freiheit bei der Lösung.
Transparenz
Sichtbar: woran andere arbeiten, warum, und wie Erfolg gemessen wird.
Passt zu unserem BANI-Ansatz
Ziel stabil, Weg flexibel. Quartalsweise neue Erkenntnisse einbauen.
Unterstützt Ownership
Ein Objective kann einen klaren Owner haben.
OKR-Theater
50 unverbundene Objectives – dasselbe Problem wie vorher, nur strukturierter aufgeschrieben.
Key Results als Aufgabenlisten
„GitHub Integration bauen“ ist Output, kein Ergebnis.
Messbarkeit als falsche Sicherheit
Nicht alles Wichtige lässt sich sinnvoll in eine Zahl pressen.
Lokale Optimierung
Service, Infra und Sales optimieren lokal – das Gesamterlebnis leidet trotzdem.
Künstliche Quartale
Nicht jedes strategische Problem ist in drei Monaten lösbar.
Quartalsweise Bereichs- und Teamsteuerung
Unternehmensziel: Unsere Plattform funktioniert einfach.
PM Objective: Von Code zu mittwald wird selbstverständlich.
OKRs passen gut zu mittwald, wenn sie unter wenigen gemeinsamen Unternehmenszielen hängen. Ohne diese obere Ebene optimiert jedes Team nur seine eigenen OKRs.
03 · 4DX / LEAD MEASURES
Nicht nur das Ergebnis messen – sondern was wir im Alltag beeinflussen können.
LAG MEASURE
50 % weniger Supportkontakte wegen Performance
Das Ergebnis – oft erst spät sichtbar.
LEAD MEASURES
Focus on the Wildly Important
Wenige wirklich wichtige Ziele
Act on Lead Measures
Beeinflussbare Frühindikatoren
Keep a Compelling Scoreboard
Sichtbarer Fortschritt
Create a Cadence of Accountability
Regelmäßige kurze Verbindlichkeit
Tagesgeschäft frisst Strategie
Tickets und Störungen verdrängen bekannte strategische Ziele. 4DX hält wenige Ziele dauerhaft sichtbar.
Besonders stark bei Reliability
Nur Uptime messen reicht nicht. Monitoring, Root Causes, Automatisierung, Wartungsqualität und Recovery sind beeinflussbar.
Konkrete Verantwortung
Jede Woche: Was können wir tun, um die Kennzahl zu bewegen?
Fortschritt wird sichtbar
Einfache Scoreboards motivieren und machen Probleme früh sichtbar.
Gut unterhalb von OKRs
OKR = Was dieses Quartal? 4DX = Was jede Woche dafür?
Kennzahlen-Fetisch
Teams optimieren nur noch die Lead Measures – nicht das eigentliche Ziel.
Nicht für jede Arbeit
Bei frühen AI-Wetten wissen wir oft noch nicht, welche Lead Measures sinnvoll sind.
Mikromanagement-Gefahr
Falsch gelebt wird Accountability zu „Warum hast du deine Zahl nicht geschafft?“
Falsche Lead Measures
Gut messbar ≠ gut. Falsche KPIs führen in die falsche Richtung.
Kann Innovation hemmen
Wenn alles über operative Kennzahlen läuft, bleibt zu wenig Raum für Exploration.
BESONDERS GEEIGNET
WENIGER GEEIGNET
4DX ist wahrscheinlich kein gutes Framework für unsere komplette Unternehmensstrategie. Für Reliability, Migration und andere wiederholbare operative Themen könnte es extrem wirkungsvoll sein.
Drei Fragen, drei Zeithorizonte – nicht drei Religionen.
| Hoshin Kanri | OKRs | 4DX | |
|---|---|---|---|
| Hauptfrage | Arbeiten wir alle an der gleichen Strategie? | Was wollen wir dieses Quartal erreichen? | Was müssen wir jede Woche tun, damit es passiert? |
| Zeithorizont | Jahr / mehrere Jahre | Quartal | Woche / laufend |
| Stärke | Alignment | Fokus & Outcomes | Execution |
| Schwäche | Komplexität | OKR-Theater | KPI-Fixierung |
| Top-down vs. Bottom-up | beides / Catchball | beides | eher Team |
| Exploration | mittel | hoch | niedrig |
| Scale / Operate | hoch | hoch | sehr hoch |
| Für mittwald | sehr interessant | sehr interessant | gezielt einsetzen |
Nicht drei Frameworks komplett gleichzeitig einführen. Elemente gezielt auswählen.
HOSHIN · LOGIK
Welche drei Unternehmensziele haben wir und wie trägt jeder Bereich dazu bei?
Nutzen
Nicht übernehmen
OKRs · QUARTAL
Welche messbaren Ergebnisse wollen wir in den nächsten drei Monaten erreichen?
Jedes Bereichs-OKR muss sichtbar auf ein Unternehmensziel einzahlen.
4DX · SELEKTIV
Welche wenigen beeinflussbaren Dinge müssen wir jede Woche tun?
Besonders
Reliability, Migration, Churn, Betrieb, Support, wiederholbare Prozesse
Nicht zwanghaft
Exploration und frühe Produktwetten
Wir brauchen wahrscheinlich kein neues Management-Framework.
Wir brauchen ein einfaches System, das drei Probleme löst:
1 · ALIGNMENT
Arbeiten wir alle an den gleichen Unternehmenszielen?
2 · FOKUS
Welche wenigen Ergebnisse wollen wir jetzt erreichen?
3 · EXECUTION
Tun wir im Alltag die Dinge, die diese Ergebnisse wahrscheinlicher machen?
Hoshin Kanri kann uns beim Alignment helfen. OKRs können uns beim Fokus helfen. 4DX kann uns bei der Umsetzung helfen.
Nicht das Framework ist das Ziel.
Das Ziel ist, dass alle wissen:
Wo wollen wir hin? Was ist mein Beitrag?
Woran erkennen wir Fortschritt?
Und was machen wir deshalb heute anders?
Kapitel 18
JÄHRLICH
Unternehmensvision + 3 Unternehmensziele
QUARTALSWEISE
Bereichs-OKRs und wenige strategische Wetten
MONATLICH
Fortschritt und Kennzahlen
WÖCHENTLICH
operative Lead Measures / Blockaden
Für jede strategische Wette
Kapitel 19
Wenn jeder Bereich seine eigene Prioritätenliste optimiert, entsteht daraus nicht automatisch eine Unternehmensstrategie.
Ein gemeinsamer Nordstern.
Wenige gemeinsame Ziele.
Klare Verantwortung.
Unterschiedliche Beiträge.
Messbarer Fortschritt.
Klar im Ziel. Flexibel im Weg. Stabil im Betrieb.
Alles auf dieser Seite ist als persönliche Diskussionsgrundlage nach dem PM-Workshop gedacht – nicht als beschlossene Strategie.