Daan Löning, Head of Product bei Helpling

Wir treffen Daan im alten Büro von Helpling. Der Umzug ist fast komplett. Ein paar wenige Kisten und eine Tischtennisplatte stehen noch im Erdgeschoss der Jägerstraße 71 in Berlin. Ein paar Hausnummern weiter zeigt er uns seinen neuen Arbeitsplatz, an dem es schon prächtig wuselt. Als wir ihn interviewen, schwärmt Daan von Optimizely, erklärt uns ihren Schritt zu ReactJS und warum Kommunikation die wichtigste Fähigkeit in seiner Position ist.

Hallo Daan, was ist deine Aufgabe bei Helpling?

Bei Helpling leite ich seit einem Jahr das Produktteam. Zu meinen Aufgaben gehört es zum Beispiel, für unsere Entwicklerteams für Rückfragen zur Verfügung zu stehen. Ich coache die Product Owner und sorge dafür, dass unsere Produktentwicklung auch auf unsere Unternehmensziele einzahlt. Mein Job ist ein sehr kommunikativer, ich muss mit jedem Teammitglied sprechen, Probleme identifizieren und dafür sorgen, dass sie gelöst werden.

Für die Entwicklung unserer Apps schaue ich mir Designentwürfe an und überlege, wie man diese optimieren kann. Dafür nutzen wir Umfragen und User-Tests und unsere Business-Intelligence-Abteilung nutzt verschiedene Daten aus unserem Data Warehouse, um Analysen zu fahren.

Welches Projekt beschäftigt dich aktuell?

Kürzlich haben wir unsere Reinigungskräfte-App gerelauncht, die wir in den letzten Wochen komplett mit ReactJS gebaut haben. Die App ist ein Tool für die von uns vermittelten Reinigungskräfte, um ihren Arbeitsalltag zu organisieren und Rechnungen zu verwalten. Die App wird sehr viel genutzt.

Wir haben circa 50 bis 60 Prozent Daily Active User. Das schafft nicht mal Snapchat.

Die Entwicklung hat viel Spaß gemacht, denn wir wollten nicht einfach nur ein Interface nehmen und es 10 Prozent besser machen. Unser Ziel ist es “worldclass” zu sein. Das sind wir stand heute auf jeden Fall noch nicht. Wir wollen aber, dass andere Produktentwickler sagen: “Dieses Feature wollen wir genauso gut wie Helpling machen”. Darum haben wir uns für das Facebook-Framework ReactJS entschieden, was für unsere Ziele einfach das passende gewesen ist. Seit letztem Jahr haben wir eine größere Migration gefahren, bei der wir unsere gesamte Tech-Plattform modernisiert haben.

Was waren die ersten Schritte bei der Neuentwicklung der Reinigungskräfte-App?

Angefangen haben wir vor circa drei Monaten. Im Laufe der Zeit haben uns viele Verbesserungsvorschläge seitens der Reinigungskräfte erreicht, wie z. B. Mehrsprachen-Funktionalität, schnellere Ladezeiten, bessere Offline-Handhabung, etc. Es ist für uns aber extrem wichtig, dass sie mit der App und ihrem Reinigungsalltag zufrieden sind. Also haben wir uns überlegt, wie eine neue App aussehen könnte.

Wir versuchen immer sehr offen zu sein und haben uns Feedback aus allen Unternehmensteilen eingeholt, insbesondere bei den Abteilungen Recruiting und Operations, die im täglichen Austausch mit den Reinigungskräften stehen.

Zusätzlich haben wir Umfragen erstellt, die wir sowohl an Personen im Unternehmen, als auch an die von uns vermittelten Reinigungskräfte geschickt haben. Dann haben wir uns natürlich Google Analytics angeschaut, was wir intensiv nutzen, um das Nutzerverhalten in der bestehenden App zu analysieren.

Wie ging es dann weiter?

Im nächsten Schritt haben wir die ersten Designs erstellt. Wir versuchen dabei immer die Unternehmensziele nicht aus den Augen zu verlieren. Zum Beispiel haben wir das Ziel, dass die Reinigungskräfte es leichter haben, mit der App ihren Alltag zu organisieren und noch länger in der App bleiben, als sie es ohnehin schon tun.

Wir haben daraufhin einen Low Fidelity Prototypen erstellt, um ein erstes Gefühl dafür zu bekommen, in welche Richtung die Entwicklung geht. Es folgten viele schnelle Iterationen. Unsere Recruiter testeten zum Beispiel erste Versionen in einer Mockup-App.

Wenn man weiß, dass  Features vielleicht nicht drin bleiben, dann baut das Engineering sie auch nicht so gut.

Im nächsten Schritt testeten Reinigungskräfte die App. Wir wussten dadurch praktisch schon vor dem Start der Programmierung, dass die App mit einer sehr hohen Wahrscheinlichkeit funktionieren wird. Unser Ziel ist es, bevor wir eine Zeile Code schreiben, 70 Prozent aller Features getestet zu haben.

Warum habt ihr euch für ReactJS entschieden?

Die Entscheidung wurde im Prinzip von unseren Frontend-Entwicklern getrieben. Etwa im Mai dieses Jahres haben wir einen neuen mobilen Buchungs-Funnel mit React eingeführt und die Zahlen waren sehr gut. Das hat uns bestärkt komplett auf ReactJS umzustellen.

Abgesehen von der Schnelligkeit, spielt noch die Tatsache mit rein, das ReactJS webbasiert ist. Dadurch können wir für alle Plattformen unsere Applikation in einen nativen Container laden und eine enorme Komplexitätsreduktion erreichen. Also statt unsere Reinigungskräfte- und die Kunden-App für Web, Mobile Web, Android und iOS jeweils separat zu entwickeln, brauchen wir gerade mal die Hälfte an Plattformen zu berücksichtigen. Das hilft, um wirklich geile Sachen bauen zu können.

Wie sind die Entwickler-Teams aufgebaut?

Bei uns sind die Teams nicht nach Expertise, sondern nach KPIs organisiert. Jedes Team “owned” zwei und ist dafür zuständig, dass diese sich mittelfristig verbessern. Das bedeutet, dass die Entwickler im Grunde überall dort arbeiten, wo ihre KPI beeinflusst wird.

Sie arbeiten also an Performance-Identifikatoren und verfolgen damit direkt Unternehmensziele, was auch eine stärkere “Ownership” bedeutet. Die Teams sind sehr nah am Produkt, wodurch alle in eine gemeinsame Richtung marschieren. Wir haben mit der Methode sehr gute Erfahrungen gemacht.

Auf welche Hürden seid ihr bei der Programmierung der Reinigungskräfte-App gestoßen?

In der agilen Entwicklung rechnet man ja damit, dass User nicht alles verstehen und dass  nicht alles direkt funktioniert. Als Team versteht man, was dieser Button macht, denn wir haben uns den ja ausgedacht. Und dann sieht man einem Usertest einer Reinigungskraft zu – und sie drückt den Button einfach nicht. (lacht)

Am Anfang hatten wir zum Beispiel zwei Navigationsebenen. Die klassische Navigation unten und eine Subnavigation ganz oben am Bildschirm. Die Subnavigation hat aber einfach Keiner gesehen. Da mussten wir also nochmal ran.

Ein anderer Fall war unser Kalender. In sieben von neun Interviews brauchten die Leute 10 Minuten, um herauszufinden, wie man den Tag wechselt. Das war ein bisschen peinlich.

Bei der Messaging Funktion hatten wir uns erst ein eigenes Design überlegt. Aber die User sind einfach an die Chat-Apps von Facebook und WhatsApp gewöhnt, und an deren Design haben wir uns dann auch angepasst.

Wie sieht dein Tagesablauf aus?

Mein Arbeitstag beginnt schon morgens in der U-Bahn, wo ich eine halbe Stunde Zeit habe in E-Mails, Skype und Slack reinzuschauen. Zwischen 9 und 9.30 Uhr komme ich im Büro an. Ab 10 Uhr beginnen die Standups der Entwicklerteams. Ich versuche bei jedem Team einmal die Woche dabei zu sein. Aber auch nicht öfter, denn sonst wird man zu sehr involviert. Das Team um den Product Owner soll ja die Entscheidung treffen. Einmal pro Woche dabei zu sein ist ideal für das Team.

Für die Teammitglieder ist das einfach ein Gefühl der Sicherheit, wenn sie wissen, ich bin bei Fragen da. Aber ich atme ihnen nicht ins Genick.

Montags haben wir noch ein Kick-off mit IT, Product und BI und besprechen, was in der Woche ansteht und was wir letzte Woche erreicht haben. Zweimal die Woche findet ein Meeting mit Product und Design statt, um Prozesse zu verbessern und uns absprechen, wenn zwei Teams zusammenarbeiten müssen.

Der Rest des Tages kann dann aus Userinterviews bestehen oder Gesprächen mit Unternehmen. Es kann auch sein, dass wir uns Daten anschauen und A/B Tests aufsetzen. Oder ich mache mir Gedanken, wie wir Features bauen und optimieren können. Das ist immer sehr abwechslungsreich.

Bitte erzähle uns deinen Werdegang.

Nach der Bundeswehr habe ich in London Mathematik studiert. Eigentlich war mein Plan mal Mathematikprofessor zu werden. Hat genau so lange gehalten bis ich die ersten Professoren getroffen habe. Die waren mir zu abgedreht.

Nach dem Bachelor war ich unentschlossen, was ich machen sollte und habe mich in Deutschland auf ein Management-Trainee Programm bei allen möglichen großen, deutschen Unternehmen beworben. Die Antworten klangen immer gleich: Sehr geehrter Herr Löning, vielen Dank für ihre Bewerbung. Im Moment suchen wir keine Mathematiker. Mir war schon klar, dass sie niemanden brauchen, der ihnen etwas ausrechnet. Aber in England ist das so, dass man alles Mögliche studieren kann, aber seine eigentliche Ausbildung im Unternehmen macht.

Über Umwege bin ich dann bei einer Bank gelandet, wo ich drei Jahre M&A gemacht habe. Als die Lernkurve immer flacher wurde, war mir klar, dass ich das nicht für den Rest meines Lebens machen wollte, auch wenn der Job Spaß gemacht hat.

Mit dem Kollegen Stefan, der mir gegenüber saß, habe ich dann Kinderfee gegründet und damit waren wir eine der ersten transaktionalen Marktplätze in Europa. Wir sind von der Bank in Frankfurt zum Gründen nach Düsseldorf. Aber nach sechs Monaten sind wir zurück nach Berlin gezogen, zurück in die Heimat sozusagen.

Später kam dann noch die Putzfee hinzu, was sehr ähnlich zu Helpling war. Im letzten Jahr sind wir dann als Team zu Helpling gekommen.

Welche Tools verwendet ihr?

Optimizely nutzen wir sehr, sehr viel im Team. Wir haben eine Person, die fast nichts anderes macht. Und dabei sprechen wir nicht von Conversionrate-Optimierung. Das macht das Marketing-Team selbst.

Optimizely ist mein absolutes Lieblingstool.

Bei uns ist das ja nicht so wie bei einem Shop, wo wir direkt mehr verkaufen, weil wir etwas verändern. Wenn wir etwas ändern, und dadurch z.B. die Zufriedenheit der Reinigungskräfte steigt, müssen wir genau schauen, ob das auf Kosten der Kundenzufriedenheit geht oder nicht. Das ist deutlich komplexer.

Um solche Compound-Effects besser analysieren zu können, haben wir Optimizely in unser Data-Warehouse integriert. Dafür braucht man dann ein wenig Statistik. Hätte ich dafür Mathematik studieren müssen? Nein. Aber es beruhigt mich, wenn ich sehe, dass unsere Business-Intelligence-Abteilung das gut macht.

Welche anderen Tools verwendet ihr?

Wie gesagt ist Optimizely für mich das wichtigste Tool. Und wir versuchen Tools zu nutzen, die bereits bekannt sind. Es gibt ja Leute, die “nerden” bei Tools total aus und versuchen alles aus den Prozessen herauszuholen. Ich bin eher weniger der Prozess-Typ.

Die Suche nach dem perfekten Tool kann auch ein Produktivitätskiller sein.

Google Docs verwenden wir mittlerweile recht viel, da wir auch Teammitglieder haben, die remote arbeiten. Hotjar und Google Analytics natürlich. Tableau zur Datenabfrage und -visualisierung. Zur Kommunikation verwenden wir Slack und Skype. Jira als Ticketsystem. Wir nutzen Newrelic für Performance-Monitoring .

Außerdem nutze ich ein kleines MacBook, damit ich es überall hin mitnehmen kann.

Was sind für dich wichtige Themen und Trends in der Produktentwicklung?

Eigentlich versuche ich mich davon immer ein bisschen fern zu halten. Meist stellt sich heraus, dass ein Trend dann doch nicht das ist, was für alles genutzt werden kann. Bei uns hat aber jeder Product Owner die Möglichkeit etwas auszuprobieren. Und wenn das funktioniert, dann nehmen wir das mit ins gesamte Team.

Eine Sache, die wir aktuell testen, ist “Jobs to be done”. Das ist ein Framework, das sich nicht an Personas orientiert, sondern die Frage stellt, welchem Zweck das zu verkaufende Produkt dem Konsumenten oder Käufer dient. Und genau das untersuchen wir gerade hinsichtlich der von uns vermittelten Reinigungskräfte.

Was würdest du Leuten empfehlen, wenn sie sich überlegen ins Produktmanagement einzusteigen?

Es hat bei mir definitiv geholfen, dass ich vorher schon mal gegründet habe. Auch soziale Fähigkeiten sind mega wichtig, sowohl um Probleme zu finden, als auch zu managen. Du forderst von deinen Kollegen sehr viel Input und Eigeninitiative. Wir müssen bei viel Input mit bedacht vorgehen: Welche Ideen sollten wir weiterverfolgen und welche müssen leider auf dem Ideenstapel bleiben? Da ist dann das Gespräch in der Küche mit Kollegen besser geeignet als ein extra Meeting.

Was macht dich wahnsinnig bei der Arbeit?

Ich bin nicht jemand, dem Dokumentation viel Spaß macht, obwohl das ein wichtiger Teil der Arbeit ist. Aber zum Glück gibt es Leute im Team, denen das eher liegt. So gleicht sich das ein bisschen aus.

Welche Bücher oder Blogs kannst du empfehlen?

Ich versuche in meinem Medienkonsum ein bisschen Chaos zu haben, um nicht immer den gleichen Einflüssen ausgesetzt zu sein. Was ich relativ gerne lese, ist Hackernews oder die Startup-Medien wie Deutsche-Startups.de oder Gründerszene.

Einen tollen Blogpost, den ich empfehlen kann, ist von Daniel Freser “Good Customer Development, bad Customer Development”. Angelehnt an den Klassiker „Good Productmanagement, bad Productmanagement” vom Netscape Gründer Ben Horowitz. Sehr gut zu lesen.

Außerdem kann ich “Entreprenerd” von Jack Kinsella empfehlen. Ein Buch vollgestopft mit Learnings.

Oder von Ben Horowitz: „The hard thing about hard things.“ Hat mir wirklich Spaß gemacht zu lesen.

Vielen Dank für das Interview!

Dieses Interview wurde am 7. September 2016 im neuen Office bei Helpling in Berlin geführt.