--- title: "UX in der frühen Start-up-Phase: Interview mit Benjamin Wilms" description: "Der Mitgründer und CEO von steadybit erzählt uns, welche Rolle UX in den Anfangstagen gespielt hat und wie er die UX-Ressource im Unternehmen strategisch plant." url: "https://www.uxi.de/artikel/benjamin-wilms-steadybit" language: "de" translation: "https://www.uxi.de/en/articles/benjamin-wilms-steadybit" type: "Article" published: "2023-01-18" modified: "2025-05-26" breadcrumb: "Start › Wissen › Artikel › Wie wichtig es ist, UX in der frühen Start-up-Phase zu verankern, verrät Benjamin Wilms, Gründer von steadybit" --- Interview # Wie wichtig es ist, UX in der frühen Start-up-Phase zu verankern, verrät Benjamin Wilms, Gründer von steadybit **Von:** [Juliana Hirsing](https://www.uxi.de/expertinnen-und-experten/juliana-hirsing) & Benjamin Wilms **Lesedauer:** 6 Minuten **Aktualisiert:** 26.5.2025 2019 hat Benjamin Wilms [steadybit](https://steadybit.com/) gegründet, eine Plattform für Chaos Engineering und Resilience. Im Interview erzählt er uns, welche Rolle UX in den Anfangstagen des Start-ups gespielt hat und wie er die UX-Ressource im Unternehmen strategisch plant.  ![Benjamin Wilms](https://cdn.sanity.io/images/1gpva9gt/production/d03f89b4f98815c0e9276c2a0229589b10e7306d-1800x1800.jpg/benjamin-wilms.jpg?w=320&h=320&fit=crop&auto=format) Benjamin Wilms Mitgründer und CEO von steadybit Benjamin blickt auf über 20 Jahre Erfahrung als Entwickler und Software-Architekt zurück. Vor fünf Jahren hat er sich in das Thema Chaos Engineering verliebt und teilt seitdem sein Wissen als Speaker und Autor. Er hat beim Open Source Projekt CHAOS MONKEY für Spring Boot mitgemacht – diese hat 500 Sterne bei Github erhalten und wurde pro Monat über 800 mal heruntergeladen. Wenn er mal nicht seine Tastatur malträtiert, relaxt er beim Mountainbiken. ## Produktfokus ### Benjamin, was macht steadybit im Kern für dich aus? **\\ **_Du kannst nur über das Produkt gewinnen._ Das heißt, wir haben einen absoluten Produktfokus. Wir haben die große Chance, mit einer Handvoll Designpartnern zusammenzuarbeiten. Das sind Kunden, die Geld dafür bezahlen, um das unreife Produkt zu benutzen, und im Gegenzug nehmen wir sie mit in die Produktentwicklung. Wir sprechen regelmäßig miteinander und bekommen sehr detailreich geschildert, welche Probleme der Kunde vor Ort hat und wie wir das mit dem Produkt [steadybit ](https://steadybit.com/)für ihn lösen können. Daraus entstehen neue Features, die wir auch wieder direkt mit dem Kunden verproben, Interviews durchführen, aber auch direkt schauen, wie der Kunde unser Produkt nutzt. Wir sehen, wo es Schwachstellen gibt und wo man das Ganze verbessern kann. ## UX & Deep Tech ### Das klingt schon nach ausgeprägter UX-Methodik. **\\ **Ja, mir persönlich war es auch immer wichtig. Wir haben das von Tag 1 an mit UX&I gemacht. Man sieht einfach extrem deutlich, wenn Leute, die sich damit nicht beschäftigen, eine UI bauen, die andere benutzen wollen. Das ist wie ein Bruch. Es gibt Leute, die haben ein Gespür dafür, andere aber sagen ”Da ist doch der Knopf, drück den doch.” Daran erkennt man auch die Qualität der Software. Daher ist mir UX-Expertise sehr wichtig. Und unser Produkt soll sich auch nicht anfühlen wie ein Störenfried. Bitte erzieh mich nicht, lass mich auch nicht allein, sondern hilf mir, selber zu wachsen, selbst besser zu werden und mich selbst hochzuleveln durch die Nutzung der Software. ### Spielt UX eine besondere Rolle, wenn Software von Entwickler\*innen für Entwickler\*innen gemacht wird? **\\ **Ja. Denken wir an den finalen Endgegner: Wenn der Entwickler über die UI alles verstanden hat, möchte er Dinge über die API automatisieren. _Dafür muss er erstmal auf eine sehr spielerische Art beigebracht bekommen – ohne dabei erzogen zu werden – wie sich steadybit anfühlt und was man damit machen kann._ Wenn er diese Grundkonzepte über die UI kennengelernt hat, muss sich das in der API genauso widerspiegeln. Und: Entwickler wollen immer selber besser werden und etwas haben, worüber sie sprechen können: “Guck mal, ich hab das und das erreicht, das solltest du auch tun.” Das muss man ins Produkt einfließen lassen. ![Tablet mit dem Dashboard von steadybit: „Start experimenting right away and become more resilient“, Karten „Create Experiment“ und „Create Scenario“, Statistiken](https://cdn.sanity.io/images/1gpva9gt/production/bdbb2242f48d0e1da11a0e7047710d99f3fedc85-2083x1535.png/steadybit-dashboard-der-chaos-engineering-plattform.png?w=2240&fit=max&auto=format) User Interface von steadybit ## Team Setup ### Wie sah das Team Setup ganz zu Beginn bei euch aus? **\\ **Wir drei Gründer sind alle Entwickler. Das hatte am Anfang viele Vorteile. Wir waren extrem schnell in der Umsetzung und hatten keine technologische Hürde, die große grüne Wiese. Das Problem war: Wenn Entwickler eine UI bauen sollen, weiß keiner, wie man das bedienen soll. Da kamen UX&I ins Boot. Neben der konkreten Arbeit an der UI haben wir auch viele Workshops gemacht und Grundlegendes herausgefunden. Welche Stärken haben wir, welche Schwächen, was soll das Produkt können, was erwartet der Kunde und wie sieht der Kunde eigentlich aus. ### Warum sollte man, so wie ihr, von Anfang an UX mit einbeziehen? **\\ **Du hast keine laute Stimme als frühes Start-up. Du wirst nicht gehört, die Masse da draußen ist viel zu groß. _Du musst es schaffen, ein Produkt zu bauen, zu dem die Leute Wow sagen._ Dann tragen sie es für dich weiter. Du kannst dir das auch kaufen und ein riesiges Marketingbudget verbrauchen, aber damit ist noch kein Kundenproblem gelöst. Du kannst nur über dein Produkt gewinnen, das ist die Kernaussage. _Wenn das Produkt von den Kunden geliebt wird, verkauft es sich viel einfacher, vielleicht sogar von selbst._ Das ist auch die langfristige Strategie von steadybit: land and expand. Das hat schon zweimal bombig eingeschlagen. Wir haben zwei riesige Konzerne, die mit uns arbeiten. Sie haben uns gefunden, weil sie ein Problem hatten, das wir auf unserer Website beschrieben haben. Durch eine Demo waren sie dann überzeugt. In beiden Fällen waren die Kunden die Early Adopter in der Firma und haben das Problem als Erste erkannt. Nun haben sie steadybit gesehen und für nützlich befunden. Wir hatten plötzlich zwei Champions, die für uns kämpfen. Land and expand. Du musst kein Top Down Selling auf dem Golfplatz machen, das funktioniert nicht. ### Ist die UX-Denke bei euch im ganzen Team verankert? Nicht in allen Köpfen. Man erkennt die Leute schnell, da sie sich im Ideen- und Problemraum tummeln. Sie denken darüber nach, wie sich Firma und Produkt entwickeln sollen. Andere kommen nicht aus dem technischen Denken heraus. In Meetings müssen wir oft erst eine gemeinsame Sprache finden. Der eine steckt in irgendwelchen Tabellen fest, der andere versucht aus der Sicht eines Benutzers zu denken. Man muss viel Zeit in die Vorbereitung stecken und darauf achten, dass die Gruppen nicht zu groß und gut gemischt sind. Und man braucht eine gute Moderation, um alles zu framen. Einer muss wissen, wie die einzelnen Charaktere denken. Denn du kannst von allen lernen. Und am Ende muss das Ding auch umgesetzt werden. Man darf nicht in ein Kasten- oder Silodenken verfallen. ### Wie würdest du heute eure interne UX-Kompetenz einschätzen? Wir haben anfangs ganz klar die ersten Runden gemacht, um das zu lernen. Wir haben viele viele Werkzeuge an die Hand bekommen. Manches davon hat es nicht in unseren Werkzeugkasten geschafft. Methoden wie ein Design Studio oder die Affinity Map sind hingegen tägliches Doing, genauso wie Research – woraus sich nach Iterationen, vielen Gesprächen und auch Verproben mit dem Team deutlich herausbildet, wie sich die UI gestalten lässt. ### Wie wollt ihr euch im Bereich UX langfristig aufstellen? Strategisch ist es so: UX muss Teil von steadybit sein. _Es ist super hilfreich, mit UX&I zu arbeiten, aber UX ist eine Kernkompetenz, wenn du ein Produkt baust. Das musst du im Haus haben._ Die Leute müssen sich hundertprozentig damit auseinandersetzen können. ## Research ### Inwiefern hat sich eure Produktvision durch Research verändert? **\\ **Wir haben viele Interviews geführt, in unserem Netzwerk und eher marketinglastiger mit externen Interviewpartnern. Das hat unser Produkt nochmal stark geprägt. Wir hatten ja angefangen mit reinem Chaos Engineering. Und alle haben gesagt, wow, so einfach ist das bei euch. Es reicht aber nicht, nur auf die einzelnen Probleme draufzuhauen. Wir haben gemerkt, dass wir den Leuten sehr proaktiv sagen müssen: Hier ist eine Schwachstelle, hier lohnt es sich. Wir können die fragilen Momente im Vorfeld analysieren und den Kunden mitteilen, das war uns anfangs gar nicht klar. Das Tool darf keine Zeit stehlen, sondern muss klar sagen, wann das Investment an Zeit und Geld sinnvoll ist. _Kunden merken: Ich vertraue dem Tool, denn ich werde besser in meinen Skills, mein Team kommt voran, unser Unternehmen steht besser da._ ### Gab es noch weitere Learnings? Bei den Interviews mit Freunden und Kollegen gab es weniger Überraschungen. Aber als wir uns ein größeres Netzwerk aufgebaut hatten und mit Leuten reden konnten, die bei riesigen Software- Firmen sitzen, kamen viele neue Erkenntnisse. Die haben ganz andere Probleme auf der Brust und sind dabei zwei, drei Jahre voraus. Dieses Wissen konnten wir nutzen und anderen zugänglich machen, so dass unsere Kunden ihre Probleme früher erkennen. Und ein nettes Nebenlearning: Auch im Silicon Valley kochen sie nur mit Wasser. ### Welche Research-Methoden wendet ihr an? Wir haben vorgefertigte Fragebögen genutzt, die Kernaussagen extrahiert und geclustert. Welche übergreifenden Probleme gibt es und aus welchen Rollen wurden sie beschrieben. ![Diagramm Research-ABC mit vier Feldern um Benutzergruppen, Motive und Ziele, Arbeitsmittel und Umgebung, je mit einer Hypothese, etwa „Nutzer brauchen ein einfaches Tool, um Chaos Engineering zu nutzen“](https://cdn.sanity.io/images/1gpva9gt/production/7e5845e61ac485fe6668ba371b0c8f3f6807fda5-1800x1100.png/research-abc-mit-hypothesen.png?w=2240&fit=max&auto=format) Research-ABC mit Hypothesen Am Ende ist alles in eine riesige [Affinity Map](https://www.uxi.de/artikel/ux-fuer-deep-tech-start-ups) geflossen. Wir wissen nun, wer was wie fordert, wo momentan der größte Druck herrscht und welche Probleme eher auf lange Sicht gelöst werden müssen. Ansonsten machen wir auch immer wieder Design Studios, bei denen wir uns in ersten Skizzen überlegen, wie eine UI aussehen könnte. Da nehmen wir auch die Entwicklersicht mit rein und genauso auch UI-Designer. Die Mischung macht’s nachher. ![Diagramm der UX-Research-Methoden zwischen qualitativ und quantitativ sowie Verhalten und Einstellung, etwa Usability Testing, Analytics, Interview, Umfrage und Fokusgruppen](https://cdn.sanity.io/images/1gpva9gt/production/e710d5f2a3f9f5138faf3e65b1bcc69be7c0d958-1800x1100.png/research-methoden-im-ueberblick.png?w=2240&fit=max&auto=format) Research-Methoden im Überblick ## Kontinuierliche Entwicklung ### Wie seid ihr mit der Doppelaufgabe umgegangen – einerseits das Produkt zu entwickeln, aber auch nach außen zu verkaufen? Diesen Zwiespalt hat man immer, und damit muss man auch spielen. _Das heißt Fake it until you make it oder Good for now. _Du baust dem Kunden etwas, das schon mal einen gewissen Wert vermittelt, aber es reicht nur für gerade jetzt. Und dann nutzt du das Momentum, in dem er das Produkt bedient, und beobachtest, welche Ideen jetzt aus seinem Kopf purzeln. Dafür musst du ihm ein Stück geben, ohne dein Invest zu groß zu machen. **Vielen Dank für das Interview, Benjamin.** ### [Deep Tech trifft Nutzerzentrierung](https://www.uxi.de/whitepaper/deep-tech-whitepaper) Erfahre mit Hilfe von praktischen How-to-Methoden, wie du UX-Prozesse und -Denkweisen in deinem Unternehmen integrieren kannst. Lerne, wie du mit UX starten kannst, wen du dafür brauchst und wie du gute UX-Expert\*innen findest. Und profitiere von wertvollen Praxistipps drei erfolgreicher Deep-Tech-Unternehmen. [Zum Whitepaper](https://www.uxi.de/whitepaper/deep-tech-whitepaper) ## Unsere Expertin - ![Juliana Hirsing](https://cdn.sanity.io/images/1gpva9gt/production/a4ad380ce6e668c3341d3a85329f1e6a776c5098-1840x2028.jpg/juliana-hirsing.jpg?rect=0,94,1840,1840&w=320&h=320&fit=crop&auto=format) [Juliana Hirsing](https://www.uxi.de/expertinnen-und-experten/juliana-hirsing) Senior UX-Writerin [Mehr über Juliana](https://www.uxi.de/expertinnen-und-experten/juliana-hirsing) Juliana bringt seit 2009 Text ins Digitale. Als UX-Writerin sorgt sie dafür, dass Sprache Nutzer\*innen ans Ziel führt und Produkte messbar erfolgreicher macht. ## Als Nächstes Interview ### [UX im hochkomplexen Forschungsumfeld: Interview mit Dr. Christian Matyas vom LIfBi](https://www.uxi.de/artikel/interview-lifbi) Was UX in komplexen Arbeitswelten leisten kann. Ein Gespräch über Nutzerkontakt, gemeinsames Lernen und bessere Entscheidungen im wissenschaftlichen Umfeld. **Auch zum Thema:** [Von der Idee zum $500-Millionen-Verkauf: Mirko Novakovic, Gründer von Instana, im Gespräch](https://www.uxi.de/artikel/von-der-idee-zum-mega-deal-mirko-novakovic-interview) [Vom Usability Review zur eigenen UX/UI-Abteilung: Kyra, Teamlead bei One Data im Interview](https://www.uxi.de/artikel/ux-ui-abteilung-one-logic) ## Hast du eine Idee oder ein verzwicktes UX-Problem? Wir unterstützen dich von der Strategie über die agile Produktentwicklung bis zur Weiterbildung deines Teams. **Nadine Pieper** Senior UX-Beraterin · Berlin ### Lieber gleich sprechen? 30 Minuten per Videocall, kostenlos und unverbindlich. [Termin buchen oder Nachricht schreiben](https://www.uxi.de/kontakt)