Neben dem Tagesgeschäft Produkte bauen: für etablierte Unternehmen

Das Dilemma: die Idee ist da, die freie Hand fehlt

Fast jedes etablierte Unternehmen hat eine Schublade voller Produktideen. Eine Erweiterung des Kerngeschäfts. Ein digitaler Service rund um ein bestehendes Angebot. Ein Werkzeug, das ihr seit Jahren intern nutzt und das auch anderen helfen würde. Diese Ideen sind meist gut durchdacht, denn sie kommen aus echter Branchenerfahrung. Was fehlt, ist nicht die Einsicht. Es ist die freie Hand, die sie umsetzt.

Genau das ist der Kern des Innovationsdilemmas. Eine Organisation, die ein laufendes Geschäft betreibt, ist darauf optimiert, dieses Geschäft am Laufen zu halten. Jede Stunde, jedes Budget, jede gute Fachkraft ist verplant. Das ist kein Versagen, sondern die normale Physik eines funktionierenden Betriebs. Clayton Christensen hat es vor Jahrzehnten beschrieben: Die Fähigkeiten, die eine Firma im Kerngeschäft stark machen, bremsen sie beim Aufbau von etwas Neuem aus. Wer auf Effizienz und Verlässlichkeit getrimmt ist, tut sich schwer mit der Unsicherheit, die jedes neue Produkt mitbringt.

In diesem Artikel geht es darum, warum gute Produktideen intern so zuverlässig untergehen, warum ausgelagerte Entwicklung als Pilot ein gangbarer Weg ist, wie du das aufsetzt, ohne die Kontrolle abzugeben, und wann du besser die Finger davon lässt.

Warum Produktideen im Tagesgeschäft sterben

Wenn ein Produkt intern nicht vorankommt, liegt das selten an mangelndem Willen. Es liegt an vier Mechaniken, die sich kaum aushebeln lassen, solange das Tagesgeschäft im selben Topf liegt wie das neue Vorhaben.

Dringlichkeit verdrängt Wichtigkeit. Das Tagesgeschäft hat immer einen Kunden, der heute eine Antwort braucht, eine Rechnung, die heute raus muss, eine Störung, die jetzt behoben gehört. Das neue Produkt hat das nicht. Es ist wichtig, aber nie dringend. Jede Woche, in der jemand zwischen dem Kundenanruf und der Produktarbeit wählen muss, gewinnt der Anruf. Nach einem halben Jahr ist am Produkt fast nichts passiert, obwohl alle es wollten.

Es fehlt die Spezialisierung. Ein digitales Produkt zu bauen ist ein eigenes Handwerk. Software-Architektur, Nutzerführung, Datenmodelle, Betrieb. Eure besten Leute sind exzellent in eurem Geschäft, aber selten genau in diesem. Wer nebenbei lernt, ein Produkt zu bauen, baut langsamer und macht Fehler, die ein eingespieltes Team längst hinter sich hat.

Die Erwartung an Sicherheit passt nicht. Im Kerngeschäft kennt ihr eure Zahlen und wisst, was eine Massnahme bringt. Ein neues Produkt ist eine Wette. Die ersten Versionen werden falsch sein, und das ist normal. Eine Organisation, die auf Planbarkeit gebaut ist, liest diese Unsicherheit als Risiko und bremst, statt sie als Lernschritt einzuplanen. So wird das Produkt totgeprüft, bevor es seine ersten falschen Annahmen korrigieren durfte.

Das Budget kommt aus dem laufenden Betrieb. Zahlt ihr die Produktentwicklung aus demselben Topf wie das Kerngeschäft, konkurriert sie direkt mit allem, was heute Umsatz bringt. In jedem Quartalsgespräch steht sie zur Disposition. Was man jederzeit pausieren kann, wird irgendwann pausiert.

Pilot heisst Kapazität auslagern, nicht Verantwortung abgeben

Die naheliegende Antwort: die Produktentwicklung aus dem Tagesgeschäft herauslösen und einem spezialisierten Team geben. Entscheidend ist, was das genau bedeutet. Du lagerst nicht die Verantwortung für das Produkt aus, sondern die Kapazität und das Handwerk, es zu bauen. Richtung, Branchenwissen und die Entscheidung, ob das Produkt eine Zukunft hat, bleiben bei dir.

Der tragende Begriff ist Pilot. Ein Pilot ist ein bewusst begrenzter erster Lauf mit einem klaren Lernziel. Du baust nicht das fertige Produkt mit allen Funktionen, sondern die kleinste Version, mit der sich die wichtigste offene Frage beantworten lässt. Diese kleinste sinnvolle Version heisst MVP, Minimum Viable Product. Es geht nicht darum, wenig zu bauen, sondern genau das, was eine echte Annahme testet: Nutzen echte Anwender das? Löst es ein Problem, für das jemand zahlt? Wie du den Umfang eines solchen Aufbaus sinnvoll schneidest und was ihn teuer oder günstig macht, steht in was kostet ein MVP.

Ein Pilot mit einem externen Team hat drei Vorteile gegenüber dem internen Versuch. Er ist vom Tagesgeschäft getrennt, niemand muss mehr zwischen Kundenanruf und Produktarbeit wählen, weil andere Leute die Produktarbeit machen. Er ist planbar begrenzt, mit Anfang, Ende und festem Rahmen, statt als offenes Dauerprojekt am Budget zu nagen. Und das Team bringt das Handwerk schon mit, es muss das Produktebauen nicht nebenher lernen.

Dann lohnt der Blick darauf, wer dieses externe Team ist. Eine klassische Agentur baut, was im Pflichtenheft steht, und übergibt danach. Das Risiko liegt im Was-danach: ein Produkt, das niemand betreibt und das nach Projektende langsam zerfällt. Wir bei Wertstifter bauen Produkte nicht nur, wir betreiben sie selbst. Wortfreunde und Reazon laufen im echten Einsatz, mit echten Nutzern, mit allem, was Betrieb, Wartung und Weiterentwicklung an Realität mit sich bringen. Das verändert, wie man baut. Wer ein Produkt später selbst betreiben muss, trifft andere Entscheidungen als jemand, der nach der Übergabe nie wieder hineinschaut. Die Wege selbst bauen, Agentur beauftragen oder mit einem Produktstudio arbeiten haben wir in selbst bauen vs. Agentur vs. No-Code vs. Produktstudio nebeneinandergestellt.

Governance: Kontrolle behalten, ohne selbst zu bauen

Auslagern heisst nicht loslassen. Damit ein Pilot funktioniert und du am Ende eine belastbare Entscheidung treffen kannst, braucht es Steuerung. Governance klingt schwerfällig, meint hier aber etwas Schlichtes: ein paar Festlegungen, die verhindern, dass das Vorhaben entgleitet oder in eine Sackgasse läuft. Fünf davon zählen.

Du brauchst einen benannten Verantwortlichen auf eurer Seite. Eine Person, die das Produkt will, die entscheiden darf und die dem externen Team als Gegenüber dient. Ohne sie versandet jeder Pilot, weil niemand bei euch die Fäden in der Hand hält. Das ist kein Vollzeitjob, aber es braucht echte Entscheidungsbefugnis.

Du brauchst Lernziele statt Funktionslisten. Leg vor dem Start fest, welche Frage der Pilot beantworten soll. Nicht: Das Produkt braucht diese zwanzig Funktionen. Sondern: Wir wollen wissen, ob unsere bestehenden Kunden ein digitales Werkzeug für Aufgabe X annehmen. Aus dieser Frage leitet sich ab, was gebaut wird, und nicht umgekehrt. Das hält den Umfang klein und das Ziel scharf.

Du brauchst einen getrennten Budgetrahmen. Gib dem Piloten ein eigenes, begrenztes Budget, das nicht jede Woche neu mit dem Tagesgeschäft konkurriert. Ein fester Rahmen schützt vor der ständigen Verdrängung und zwingt zugleich zur Disziplin, denn unbegrenzte Budgets laden zum Ausufern ein.

Du brauchst einen kurzen, regelmässigen Takt. Keinen monatlichen Lenkungsausschuss, sondern einen verlässlichen Rhythmus, in dem das Team zeigt, was entstanden ist, und du entscheidest, ob die Richtung stimmt. Dieser Takt ist deine eigentliche Kontrolle. Er erlaubt dir, früh gegenzusteuern, statt am Ende vor einem fertigen Produkt zu stehen, das in die falsche Richtung gebaut wurde.

Und du brauchst geklärte Eigentums- und Betriebsfragen, von Anfang an. Wem gehört der Code? Wo laufen die Daten? Wer betreibt das Produkt, wenn der Pilot aufgeht? Viele Vorhaben scheitern nicht am Bauen, sondern an genau diesen ungeklärten Fragen rund um Betrieb und Verantwortung. Welche Muster hier typischerweise schieflaufen, zeigt warum SaaS-Projekte scheitern.

Wann der externe Pilot der falsche Weg ist

Damit das nicht nach Verkaufsprospekt klingt: Es gibt Fälle, in denen du den externen Pilot lieber sein lässt.

Wenn das Produkt euer Kerngeschäft selbst ist, gehört die Kompetenz langfristig ins Haus, nicht zu einem Dienstleister. Ein externer Pilot kann dann den Start beschleunigen, aber ihr müsst von Beginn an planen, das Team aufzubauen und das Wissen zu übernehmen. Wenn ihr noch nicht einmal die eine Frage formulieren könnt, die der Pilot beantworten soll, ist es zu früh fürs Bauen, dann braucht ihr erst Klarheit über das Problem. Und wenn niemand bei euch die Verantwortlichen-Rolle übernehmen kann oder will, lasst es lieber ganz. Ein Pilot ohne Gegenüber auf eurer Seite produziert ein Produkt, das niemand weiterträgt, und das ist teurer als gar nicht anzufangen. Ob sich ein eigenes Produkt für euch überhaupt rechnet, ordnet lohnt sich eigenes SaaS für KMU ein.

Klein starten ist die stärkere Strategie

Die Versuchung bei etablierten Firmen ist gross, ein neues Produkt gleich richtig aufzuziehen. Ihr habt Ressourcen, ihr habt einen Namen, ihr könnt es euch leisten. Genau das ist die Falle. Je grösser ihr startet, desto mehr Annahmen baut ihr ein, bevor ihr eine einzige davon überprüfen konntet.

Klein starten hält die Lernkosten niedrig. Jede Annahme, die ihr vor dem ersten echten Nutzerkontakt fest verbaut, kann falsch sein. Sie später zu korrigieren kostet ein Vielfaches dessen, was es gekostet hätte, sie früh zu testen. Ein kleiner Pilot bringt euch in Wochen statt Monaten in den Kontakt mit echten Nutzern, und dieser Kontakt ist die wertvollste Information überhaupt.

Klein starten hält auch die Optionen offen. Nach einem Piloten habt ihr drei Wege: ausbauen, weil es funktioniert. Nachschärfen, weil ihr etwas Wichtiges gelernt habt. Oder bleiben lassen, weil die Annahme nicht trug. Alle drei sind gute Ergebnisse, weil ihr in jedem Fall für wenig Einsatz viel gelernt habt. Ein gross aufgezogenes Produkt nimmt euch diese Freiheit. Wenn erst genug investiert ist, scheint Aufhören keine Option mehr, selbst wenn es die richtige wäre.

Und dann habt ihr etwas, das Startups fehlt. Bestehende Kunden, eine Marke, Vertriebswege, Branchenwissen. Ein neues Produkt aus eurem Haus startet nicht bei null. Baut ihr klein und kontrolliert, könnt ihr diese Stärken gezielt einsetzen, statt sie in einem grossen, unsicheren Wurf aufs Spiel zu setzen.

Der erste Schritt

Wenn ihr eine Produktidee habt, die seit Monaten im Tagesgeschäft feststeckt, fangt nicht mit einem grossen Plan an, sondern mit drei Klärungen. Formuliert die eine Frage, die der Pilot beantworten soll. Benennt die Person, die das Vorhaben führt und entscheidet. Steckt einen begrenzten Rahmen ab, in Wochen gedacht, nicht in Jahren.

Dann braucht es ein Team, das das Produkt nicht nur baut, sondern den Betrieb mitdenkt, weil daraus die besseren Entscheidungen entstehen. Genau dafür gibt es die ausgelagerte SaaS-Produktentwicklung: ein Pilot, der euch in Wochen zu einer belastbaren Antwort bringt, mit Governance, die euch die Kontrolle lässt, und mit dem Blick von Leuten, die ihre eigenen Produkte selbst betreiben. Eure Branchenkenntnis und die richtige Bauhand zusammenzubringen ist der Moment, in dem aus einer Idee in der Schublade ein Produkt im Markt wird.