Wie wichtig es ist, UX in der frühen Start-up-Phase zu verankern, verrät Benjamin Wilms, Gründer von steadybit

2019 hat Benjamin Wilms steadybit 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. 

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 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.

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.

Am Ende ist alles in eine riesige Affinity Map 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.

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.