CADS GmbH

Etablierte Firma

Alle Videos anzeigen

Building Products with Purpose

Lukas Reinauer von CADS spricht in seinem devjobs.at TechTalk wie das Unternehmen das Thema der Produktentwicklung organisatorisch angeht.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In Building Products with Purpose zeigt Lukas Reinauer, wie sich Purpose aus Meaning und Rationalität ableitet und wie Teams über Produkt, Menschen und Prozesse hinweg mit einem praxistauglichen Fragen-Set arbeiten. Er erklärt, wie man mit dem „Warum“ startet, Problem und Risiken sauber fasst, ein fokussiertes MVP baut, die Ziel‑Lücke mit Requirements Engineering sowie wahlweise UX‑Prototypen oder Code‑Proof‑of‑Concepts schließt und früh wie oft via Verifikation und Validierung testet. Auf Team‑ und Prozessebene empfiehlt er, Entwickler und Designer direkt in Kundengespräche einzubinden, Kunden auf Probleme statt Lösungen zu lenken, Tech Debt gegen Features und Architekturentscheidungen bewusst abzuwägen und Regulatorik als Stakeholder mit eigenem MVP zu behandeln; zur Priorisierung dient die Heuristik aus heutigem Kundennutzen und Umsetzungseffizienz.

Produkte mit Purpose bauen: Ein praxisnahes Playbook aus der Medizintechnik von CADS GmbH

Einordnung der Session und zentrale These

In „Building Products with Purpose“ von Lukas Reinauer (CADS GmbH) haben wir eine dichte, pragmatische Anleitung für Teams gesehen, die Technologie nicht nur liefern, sondern echten Nutzen stiften wollen. Der Sprecher legte ein klares Versprechen auf den Tisch: Am Ende steht ein Toolset, mit dem sich Alltagsentscheidungen und strategische Weichenstellungen gleichermaßen strukturieren lassen – vom Feature über das Produkt bis hin zu Prozessen, Teams und ganzen Organisationen.

Der Kern dieses Toolsets ist die bewusste Verzahnung von Bedeutung (Meaning) und Rationalität: Purpose entsteht nicht zufällig, sondern aus einer geklärten Antwort auf das „Warum?“ und aus der Fähigkeit, daraus konsequente, überprüfbare Handlungen abzuleiten. Gerade in der Medizintechnik – Reinauers täglichem Kontext – ist das kein Luxus, sondern Sicherheits- und Qualitätsvoraussetzung.

Purpose auf zwei Beinen: Meaning und Rationalität

Reinauer unterscheidet zwei Dimensionen, die zusammen Purpose formen:

Meaning: die zugrunde liegende Bedeutung, das „Wertversprechen an mich, an Nutzer:innen und an die Gesellschaft“. Es beantwortet, warum es die Arbeit geben sollte und woran wir als Menschen mit Stolz und Freude arbeiten wollen.
Rationalität: die abgeleitete Kette an Kausalitäten und Handlungsplänen, die uns vom Wunsch „die Welt besser zu machen“ zu einem konkret machbaren nächsten Schritt führen. Rationalität ist das Werkzeug, mit dem wir Meaning in Aktion übersetzen.

Diese Zweiteilung schützt Teams vor zwei Extremen: dem blinden Aktionismus ohne Sinnanker und der reinen Sinnrhetorik ohne Umsetzungsplan. Aus unserer Sicht ist sie der rote Faden, der sich durch alle praktischen Empfehlungen der Session zieht.

Vom Problemraum zur Lösung: Das Gap-Problem in der Produktentwicklung

Warum fühlt sich Produktentwicklung oft so viel komplexer an, als das Whiteboard am ersten Tag verspricht? Reinauer greift das klassische Gap-Modell auf: Zu Beginn kennen wir unseren Ausgangspunkt nur grob, der Zielraum ist unscharf, der „Zielkreis“ liegt irgendwo in der Ferne. Während wir mit Kund:innen sprechen und iterieren, präzisiert sich der Zielbereich – meistens nicht dort, wo wir initial hingesteuert sind. Daraus entstehen Lernschleifen, Kurskorrekturen und mitunter aufwändige Umwege.

Die Praxisantwort darauf kennt die Branche seit Jahren: Requirements Engineering, Usability/UX-Engineering mit Click-Dummies, Proof-of-Concepts in Code. Doch jedes Werkzeug hat Grenzen:

Reines Requirements-Fragen hilft, bleibt aber hypothetisch, wenn Kund:innen ihr eigenes Problem noch nicht operationalisiert haben.
UX-Prototypen erhöhen das Verständnis, liefern aber noch keine Wirkung im Feld.
PoCs in Code erzeugen frühe Wirkung und echtes Lernsignal, bringen dafür technische Schulden mit, die später nachgezogen werden müssen.

Reinauers Punkt: Nutzt die Werkzeuge bewusst entlang eines rationalen Plans, der aus dem Meaning abgeleitet ist. Nicht jedes Feature braucht einen vollausgebauten UX-Prozess, nicht jedes PoC muss produktionsreif sein. Wählt das Leichteste, das die Informationslücke schließt, die ihr wirklich adressieren wollt.

Das Produkt-Playbook: Vom „Warum?“ bis zum Nachweis

1) Start with Why: Problem klären, nicht Lösung vordenken

Die wichtigste Frage ist das „Warum?“ – wozu soll es dieses Produkt geben? Welches konkrete Problem lösen wir, und ist es wirklich dringend? Reinauer warnte eindrücklich davor, zu früh in „Wie lösen wir es?“ abzurutschen und sich dann Requirements zurechtzulegen, die nur die bereits vorgedachte Lösung rechtfertigen.

Pragmatischer Tipp aus der Session: Erst auf Papier lösen. Wer das Problem skizziert, strukturiert und gegen Papier-Workflows denkt, behält Distanz zu Technologiepräferenzen. Entscheidungen sind so leichter reversibel, bevor Code Pfadabhängigkeiten erzeugt.

2) Risiko früh adressieren

Gerade in der Medizintechnik trägt jedes User-Requirement inhärente Risiken. Was passiert, wenn Ladezeiten zu lang sind? Was, wenn Berechnungen falsch sind? Diese Fragen gehören an den Anfang, nicht ans Ende. Die technische Umsetzung folgt dann einer rationalen Reihenfolge, die Risiken systematisch reduziert.

3) Das richtige MVP: Ein Problem wirklich lösen

Das Minimal Viable Product zielt nicht auf „alles irgendwie“, sondern auf „das eine Dringende wirklich“. Ein Kernzitat aus dem Tenor der Session: Für Nutzer:innen ist es oft wichtiger, dass die eine zentrale Berechnung oder Funktion zuverlässig tut, als dass im Hintergrund Identitäts- oder Data-Storage-Systeme in Perfektion glänzen. MVP heißt: Das Problem lösen – nicht die vollständige Produktlandschaft beim ersten Wurf fertigstellen.

4) Prototypen bewusst wählen: UX-Click-Dummy oder Code-PoC?

Reinauer machte klar, dass die Wahl des Prototypentyps eine Frage der Informationslücke und der Komplexität ist:

Wenn das Nutzerproblem vage ist, helfen schnelle UX-Prototypen, um Sprache, Flows und Erwartungshaltungen zu klären.
Wenn die Frage lautet, ob das Engineering-Team ein bestimmtes Framework oder eine Berechnung tragfähig umsetzen kann, liefert ein Proof-of-Concept in Code das belastbarere Signal.

Entscheidend ist die Zielklarheit: Welches Risiko wollt ihr mit minimalem Aufwand aus dem Weg räumen?

5) So früh wie möglich testen: Verifikation vs. Validierung

In der Medizintechnik sind zwei Testachsen nicht verhandelbar – und sie sind in Wahrheit universell nutzbar:

Verifikation: Hat das Produkt die eigenen Spezifikationen erfüllt? Beispiel: Ist der Haken mit der vorgesehenen Kraft befestigt?
Validierung: Löst das Produkt wirklich das Zielproblem beim Menschen? Beispiel: Hält der Haken, wenn ich mich dranhänge?

„Das kann ich für jedes Produkt tun – Software, Hardware, Medizintechnik.“

Die Empfehlung aus der Session: Diese Tests so früh wie möglich, so oft wie möglich und am besten mit echten Nutzer:innen durchführen. Nur so verschwinden blinde Flecken in Anforderung, Architektur und Interaktion.

6) Iteration als Dauerzustand anerkennen

Teams machen Fehler. Nutzer:innen machen Fehler. Umfelder ändern sich. Genau deshalb existiert agile Entwicklung: um Annahmen kontinuierlich zu prüfen, Entscheidungen zu korrigieren und auf neue Realitäten zu reagieren – ohne den Purpose aus dem Blick zu verlieren.

Menschen als Beschleuniger: Zusammenarbeit, die Verständnis erzeugt

Entwickler:innen und Designer:innen in Kundengespräche holen

Ein starkes Kulturmerkmal bei CADS – und eine der wirkungsvollsten Empfehlungen aus der Session – ist die direkte Einbindung von Engineering und Design in Kundendialoge. Nicht nur Product-Rollen verstehen das Problem, auch die Umsetzer:innen hören Nuancen, stellen Rückfragen und internalisieren das „Warum?“.

Reinauer formulierte einen persönlichen Qualitätsmaßstab: Er ist stolz, wenn Entwickler:innen mit Argumenten aus dem Nutzerkontext seine Lösungsvorschläge in Frage stellen – „weil der User das und das braucht“. Das ist gelebtes Purpose: kollektives Produktverständnis schlägt Hierarchie.

Das MVP-Mantra: Wichtigkeit und Dringlichkeit prüfen

Ein Satz, der bei CADS offenbar schon Running Gag-Status erreicht hat, lautet: „Ist das wirklich MVP?“ Dahinter steckt die Disziplin, Wichtigkeit und Dringlichkeit jedes Features konsequent zu prüfen. Nicht alles muss jetzt passieren. Manche Dinge kann man bewusst später lernen und erst dann bauen.

Kund:innen auf der Problembeschreibungsebene halten

Kund:innen bringen häufig Lösungsideen, Designwünsche oder konkrete Implementierungsvorschläge mit. Das ist wertvoll – aber gefährlich, wenn daraus implizite Spezifikationen werden. Reinauers Empfehlung: Wertschätzen, zuhören, aber die Freiheit bewahren, das Problem mit dem eigenen UX- und Engineering-Know-how zu lösen. Kollaboration ja, Design-by-Committee nein.

Technische Schulden vs. neue Features: Eine geteilte Priorisierung

Die Gewichtung zwischen Tech Debt und Neuerungen lebt bei CADS von Vertrauen in erfahrene Entwickler:innen – und vom gemeinsamen Blick mit dem Kunden: Welche Funktionen werden bald wichtiger, welche können (noch) schlank bleiben? Diese Transparenz hilft, nicht jede Ecke „future-proof“ zu überdesignen, wenn der Wert nicht jetzt entsteht.

Architektur hinterfragen – auch wenn’s weh tut

Architektur ist verführerisch stabil. Besonders in regulierten Umfeldern, in denen Dokumentationslasten hoch sind, neigt man dazu, bestehende Entscheidungen zu zementieren. Reinauers Warnung: Regelmäßig prüfen, ob alte Architekturannahmen noch tragen. Der Preis für späte Korrekturen ist oft höher als die Kosten eines bewussten Re-Cuts.

Embrace: Erfolge zeigen, Eigentum stärken

Ein praktisches Ritual mit hoher Rendite: Entwickler:innen präsentieren wöchentlich Fortschritte direkt beim Kunden und holen live Feedback. Das steigert Stolz, Sichtbarkeit und Vorfreude auf kommende Funktionen. Ebenso wichtig: Tester:innen auf Kundenseite feiern. Wer je eine Beta gespielt hat, kennt das Gefühl, „früher dran“ zu sein – es stiftet Bindung und Motivation, die Qualität zu heben.

Prozess ohne Dogma: Agil planen, regulatorisch denken

Dokumentation ist kein Feind – sie schützt Menschenleben

In der Medizintechnik ist Dokumentation unverzichtbar; sie ist Sicherheitsnetz und Rechenschaft. Reinauer bringt es nüchtern auf den Punkt: Manchmal produzieren Teams so viel Papier wie Code – und das ist richtig so. Gleichzeitige Warnung vor Scheinschlüssen: Nur weil ein Team in Sprints arbeitet, ist es nicht automatisch agil; nur weil Dokumente gut sind, ist es nicht Waterfall.

„So viel planen wie nötig“ – abhängig von Produkt, Regulierung, Organisation

Die sinnvolle Planungsdichte ergibt sich aus drei Faktoren:

Produkttyp und Risikoprofil
Regulatorische Anforderungen
Team- und Organisationsmodus

Was auch immer ihr plant: Stakeholder sauber mitnehmen. Neue Timelines ohne breite Kommunikation erzeugen sonst Missverständnisse und Friktion.

Regulatorik als Stakeholder behandeln – MVP inklusive

Ein starker, entlastender Gedanke aus der Session: Behandelt Regulatorik und Prozesse wie einen weiteren Stakeholder – mit eigenen Anforderungen, Risiken und einem definierten MVP. So wie CI/CD-Pipelines automatisierte Prozessanforderungen erfüllen, können wir auch regulatorische Artefakte in kleinsten, wertstiftenden Inkrementen liefern. Das macht Arbeitspakete greifbar und verhindert, dass „Dokumentation“ zu einem monolithischen Endgegner wird.

Entscheidungen mit Gründen: Zwei Achsen optimieren

Reinauer empfiehlt, Produktentscheidungen entlang zweier Achsen zu rationalisieren:

Welchen unmittelbaren Wert stiftet das Feature für Nutzer:innen – jetzt und heute?
Wie effizient lässt sich dieses Feature in der Entwicklungsabteilung realisieren?

Wer entlang beider Dimensionen priorisiert, minimiert die Gefahr, wertarmes, teures Scope-Wachstum in Releases zu schieben. Das ist besonders wichtig, wenn Releases nicht im strikten Zwei-Wochen-Takt erfolgen und Fenster größer werden.

Ein kompaktes Praxis-Playbook

Zum Mitnehmen haben wir die Kernelemente aus „Building Products with Purpose“ von Lukas Reinauer (CADS GmbH) in operative Checklisten verdichtet.

Produkt: Vom Purpose zur Wirkung

Why klären: Welches Problem, für wen, wie dringend?
Auf Papier lösen: Erst skizzieren, dann implementieren – vermeidet frühe Pfadabhängigkeiten.
Risiken listen: Welche Schäden entstehen bei Nichteinhaltung eines Requirements?
MVP definieren: Ein zentrales Problem zuverlässig lösen – Backendschönheit später.
Prototypwahl treffen: UX-Click-Dummy, wenn Verständnis fehlt; Code-PoC, wenn technische Tragfähigkeit fraglich ist.
Testen früh/oft: Verifikation (gegen Spezifikationen), Validierung (gegen Nutzerproblem) – ideal mit echten Nutzer:innen.
Iterieren: Annahmen fortlaufend überprüfen, Kurs halten, aber Kurs korrigieren.

Menschen: Verständnis verbreiten, Stolz fördern

Entwickler:innen/Designer:innen in Kundengespräche einladen – kollektives Verständnis entsteht im Dialog.
MVP-Frage stellen: Brauchen wir dieses Feature jetzt? Oder später – nach mehr Erkenntnis?
Kunden auf Problembeschreibungsebene moderieren – Lösungskompetenz im Team belassen.
Tech Debt bewusst balancieren – mit Blick auf zukünftige Wichtigkeit.
Architekturentscheidungen regelmäßig challengen.
Fortschritte zeigen, Tester:innen feiern – Ownership und Motivation vermehren.

Prozess: Agil ohne Etikett, regulatorisch ohne Ballast

Planungstiefe nach Risiko, Regulatorik und Organisation bemessen.
Stakeholder aktiv synchronisieren – Timelines transparent machen.
Regulatorik als Stakeholder behandeln – inkl. MVP für Artefakte/Prozesse.
Entscheidungen entlang „Kundenwert jetzt“ und „Engineering-Effizienz“ treffen.

Lessons Learned für Engineering-Teams

Purpose ist zweidimensional: Ohne Meaning fehlt Richtung, ohne Rationalität fehlt Umsetzung. Beides zusammen macht Produkte wirksam.
Das Gap ist normal – Instrumente wie Requirements, UX-Prototypen und PoCs schließen es jeweils auf ihre Weise. Wählt das Minimum, das die gesuchte Antwort liefert.
V&V sind kein MedTech-Exot, sondern universelle Disziplinen. Prüft, ob ihr gebaut habt, was ihr euch vorgenommen habt – und ob es beim Menschen das Problem wirklich löst.
Kultur ist Produktkraft: Direkter Nutzerkontakt fürs Team und das Recht, Annahmen zu hinterfragen, erhöhen die Qualität der Entscheidungen dramatisch.
Dokumentation ist Prozesswert – nicht Bürokratie um ihrer selbst willen. Wer Regulatorik wie einen Stakeholder managt, bleibt lieferfähig und sicher.
Gute Priorisierung folgt zwei Achsen: Nutzerwert heute und Umsetzungseffizienz. So vermeidet ihr kostspielige Scope-Drift.

Fazit

„Building Products with Purpose“ von Lukas Reinauer (CADS GmbH) liefert kein weiteres Buzzword-Feuerwerk, sondern ein anwendungsreifes Set an Denk- und Arbeitswerkzeugen. Der Leitgedanke – Meaning und Rationalität konsequent zu koppeln – macht den Unterschied zwischen Aktivität und Wirkung. Wer dieses Playbook beherzigt, entscheidet klarer, entwickelt gezielter und testet so, dass am Ende zählt, was zählt: Probleme von Menschen tatsächlich zu lösen – verifiziert, validiert und mit einem Team, das Purpose nicht nur benennt, sondern lebt.

Weitere Tech Talks

Weitere Tech Lead Stories

Weitere Dev Stories