---
title: Tech Debt sichtbar und verhandelbar machen
author: Lars Decker
date: 2026-01-13
updated: 2026-01-13
description: So machen Product Owner technische Schulden sichtbar, verhandelbar und priorisierbar, damit Risiken und Business-Impact klar werden.
tags: product owner, tech debt, priorisierung, produktmanagement, stakeholder
canonical: https://lars-decker.eu/blog/tech-debt-sichtbar-machen
---

# Tech Debt sichtbar und verhandelbar machen


_Wie Product Owner technische Schulden aus der Nerd-Ecke holen und produktiv priorisieren._

Technische Schulden sind selten das eigentliche Problem.
Das Problem ist, dass niemand außerhalb des Entwicklungsteams versteht, **was sie bedeuten**, **warum sie gefährlich sind** und **wann sie relevant werden**.

Als Product Owner stehst du genau dazwischen. Und genau dort kannst du den Unterschied machen.

---

## Warum Tech Debt für Product Owner so schwer greifbar ist

Tech Debt fühlt sich oft abstrakt an:

- „Das müssten wir mal refactoren“
- „Das skaliert so nicht“
- „Das wird später richtig teuer“

Für Stakeholder klingt das nach:

> _„Nice to have, aber nicht dringend.“_

Und für viele Product Owner ehrlich gesagt auch. Nicht aus Ignoranz, sondern weil **Übersetzung fehlt**.

---

## Schritt 1: Tech Debt in Produkt-Sprache übersetzen

Solange Tech Debt technisch beschrieben wird, ist sie kaum verhandelbar. Der erste Hebel ist Sprache.

### Statt

- „Legacy-Code“
- „Unsaubere Architektur“
- „Hohe Komplexität“

### Besser

- **Erhöhte Time-to-Market**
- **Steigende Fehleranfälligkeit**
- **Eingeschränkte Erweiterbarkeit**
- **Abhängigkeit von Einzelpersonen**
- **Erhöhtes Ausfall- oder Sicherheitsrisiko**

👉 Frage dein Team aktiv:

> _„Was bedeutet diese technische Schuld konkret für Nutzer, Business oder Delivery?“_

---

## Schritt 2: Tech Debt sichtbar machen (nicht nur erwähnen)

Was nicht sichtbar ist, existiert in Priorisierungen faktisch nicht.

### Bewährte Visualisierungen

- **Tech-Debt-Backlog** als gleichwertiger Teil des Product Backlogs
- **Ampel-Logik** pro System oder Modul  
  Grün = unkritisch, Gelb = wachsend, Rot = produktgefährdend
- **Trend statt Einzelwert**  
  Wird es besser oder schlechter über Zeit? (z. B. mit einfachen [Metriken](/blog/data-metrics))

Wichtig: Nicht jede Schuld braucht sofort eine Story. Aber **jede relevante Schuld braucht Transparenz**.

---

## Schritt 3: Tech Debt priorisierbar machen

Tech Debt konkurriert immer mit Features. Also muss sie vergleichbar werden.

### Drei bewährte Fragen zur Einordnung

1. **Was passiert, wenn wir nichts tun?**  
   (Kosten, Risiken, Verzögerungen)
2. **Wann wird es spürbar?**  
   (Jetzt, in 3 Monaten, beim nächsten Skalierungsschritt)
3. **Was blockiert es konkret?**  
   (Feature X, Markt Y, SLA Z)

Erst wenn diese Fragen beantwortet sind, wird aus „technisch sinnvoll“ eine **produktstrategische Entscheidung**.

Wenn du dafür eine klare Priorisierungslogik brauchst, hilft das [Eisenhower-Prinzip](/blog/eisenhower) als schnelle Entscheidungshilfe.

---

## Schritt 4: Verhandeln statt Durchdrücken

Tech Debt ist kein Selbstzweck. Aber sie ist auch kein „Restposten für freie Kapazitäten“.

### Gute Muster

- **Debt-Tickets mit klarem Business-Kontext**
- **Fixe Capacity-Anteile** (z. B. 20 % pro Sprint)
- **Debt gekoppelt an Features**  
  „Feature X nur sinnvoll, wenn wir vorher Y aufräumen“

### Schlechte Muster

- Schuld „unter Feature-Stories verstecken“
- Vage Formulierungen ohne Impact
- Alles oder nichts fordern

---

## Die Rolle des Product Owners dabei

Du musst Tech Debt nicht selbst bewerten. Aber du bist verantwortlich dafür, dass sie **verstanden, eingeordnet und entschieden** wird.

Deine Kernaufgaben:

- Übersetzen
- Sichtbarkeit schaffen
- Priorisierung ermöglichen
- Entscheidungen moderieren

Nicht mehr. Aber auch nicht weniger.

---

## Fazit

Tech Debt verschwindet nicht, weil man sie ignoriert. Und sie wird nicht priorisiert, nur weil sie technisch sinnvoll ist.

Sie wird priorisiert, wenn sie:

- verständlich,
- sichtbar
- und vergleichbar ist.

Genau hier kann ein Product Owner enormen Wert liefern.

---

_Bonus-Frage zum Mitnehmen:_  
👉 **Welche technische Schuld in deinem Produkt würdest du heute nicht mehr erklären können?**