Wir wurden das Start-up, mit dem wir selbst gern gearbeitet hätten
Bei der Entstehung dieses Produkts wurden keine Pivot-Tabellen konsultiert.
Seit unser Team Ende 2023 zusammengekommen ist, machen wir Kundenprojekte für Start-ups. Ihre MVPs bauen, ihre technischen Schulden abtragen, ihre Infrastruktur skalieren. Gute Arbeit, interessante Probleme, solider Umsatz.
Dann begannen wir Anfang 2024, Arheev zu bauen – unsere eigene HR-Plattform – und plötzlich standen wir auf der anderen Seite jedes Gesprächs, das wir je mit Start-up-Kunden geführt hatten.
Ein eigenes Produkt neben einem Dienstleistungsgeschäft zu bauen, ist viel schwerer, als wir es unseren Kunden erzählt hatten.
Die klassische Agenturfalle
So denken Dienstleistungsunternehmen meist über eigene Produkte:
„Wir nutzen unsere freie Zeit, um ein internes Produkt zu bauen. Wenn es bei den Kundenprojekten ruhig ist, arbeiten wir daran. Das wird großartig!“
Wir wussten, dass das eine Falle ist. Wir hatten gesehen, wie es bei anderen Agenturen schiefging. Wir sagten uns, bei uns würde es anders laufen.
Es lief nicht anders.
Die ersten Monate sind alle begeistert. Leute melden sich freiwillig, am Wochenende an Arheev zu arbeiten. Es geht schnell voran. Wir bauen einen funktionierenden Prototyp, holen erstes Feedback ein, alles großartig.
Dann kommt ein großes Kundenprojekt herein. „Nur zwei Wochen“, sagen wir uns. „Dann geht’s zurück zu Arheev.“
Drei Monate später ist Arheev unangetastet und wir haben die Hälfte unserer Entscheidungen vergessen.
Was wir geändert haben (und was tatsächlich funktioniert hat)
Nachdem das zum zweiten Mal passiert war, führten wir eine Regel ein: Arheev bekommt 30 % unserer Kapazität, jede Woche, egal was passiert.
Nicht „wenn wir Zeit haben“. Nicht „wenn es bei den Kunden ruhig ist“. Einfach … 30 % sind für unser Produkt reserviert. Immer.
Das fühlte sich beängstigend an. Was, wenn wir Kundenaufträge ablehnen müssten? Was, wenn wir Deadlines nicht einhalten könnten?
Wie sich zeigte, macht eine feste Grenze effizienter. Wir wurden besser darin, Kundenprojekte zu schätzen. Wir hörten auf, zu allem Ja zu sagen. Wir stellten eine weitere Person ein, damit wir Puffer hatten.
Und bei Arheev kamen tatsächlich regelmäßig neue Features heraus.
Das Mobile-App-Desaster
Bei der Arheev-Mobile-App kamen auf der Android-Seite alle Probleme auf einmal.
Google kündigte die 16KB-Page-Size-Anforderung an. React Native brauchte Updates. Die Hälfte unserer Abhängigkeiten war nicht kompatibel. Ein Albtraum aus technischen Schulden, wie wir ihn bei Kunden sonst zu Premium-Sätzen aufräumen.
Nur war das unser Produkt, unser Problem, unsere Wochenenden.
Wir verbrachten drei Wochen damit, Alignment-Probleme in nativen Libraries zu debuggen. Niemand bezahlte uns dafür. Wir konnten es niemandem in Rechnung stellen. Wir mussten es einfach tun, weil die Alternative gewesen wäre, nicht zu liefern.
Das ist der Teil, den wir Start-up-Kunden nie wirklich erklärt hatten: Manchmal muss man die Kosten für Plattformanforderungen, kaputte Abhängigkeiten und technische Änderungen, die man nicht verursacht hat, einfach schlucken.
Nutzern wirklich zuhören (mit Lehrgeld)
Für Kundenprojekte haben wir einen Prozess. Nutzerforschung, Wireframes, Prototypen, Tests. Sehr professionell.
Für Arheev? Wir bauten, was wir für sinnvoll hielten, lieferten es aus und sahen zu, wie die Leute verwirrt waren.
Ein Feature, an dem wir drei Wochen gebaut hatten – dieser clevere automatisierte Genehmigungsworkflow – wurde buchstäblich von niemandem genutzt. Alle genehmigten einfach alles manuell, weil unser „cleveres“ System niemand verstand.
Wir haben es entfernt und etwas Einfacheres gebaut. Dauerte vier Stunden. Die Leute nutzen es tatsächlich.
Bei einem Kunden hätten wir unsere komplexe Lösung wahrscheinlich wochenlang verteidigt. Beim eigenen Produkt? Man behebt es einfach, weil es niemanden sonst gibt, dem man die Schuld geben könnte.
Was das an unserer Kundenarbeit verändert hat
Wenn ein Start-up-Kunde heute sagt: „Das Mobile-Deployment übernehmen wir selbst“, nicken wir nicht einfach. Wir erzählen ihm von den drei Wochen, die wir mit 16KB-Seitengrößen verbracht haben.
Wenn er ein komplexes Feature bauen will, weil es cool wirkt, zeigen wir ihm unseren verworfenen Genehmigungsworkflow.
Wenn er versucht, Produktarbeit „zwischendurch“ neben anderen Prioritäten unterzubringen, erklären wir, warum wir 30 % Kapazität reservieren mussten. Ohne diese Regel wäre Arheev nie erschienen.
Wir sind besser in der Kundenarbeit, weil wir dieselben Probleme als internes Start-up durchlebt haben. Nicht als Berater, die darüber gelesen haben. Als Team, das um 23 Uhr Code ausgeliefert hat, weil ein Deployment kaputt war und Nutzer warteten.
Die unbequeme Wahrheit
Arheev zu bauen hat uns klargemacht, wie viel leichter es ist, Ratschläge zu geben, als sie zu befolgen.
Wir sagten Kunden „einfach schnell liefern und iterieren“, während wir wochenlang Arheev-Features perfektionierten.
Wir sagten „konzentrieren Sie sich zuerst auf die Kernnutzer“, während wir versuchten, jedes denkbare Feature für jeden denkbaren HR-Anwendungsfall zu bauen.
Wir empfahlen „einfach schlägt komplex“, während wir komplexe Lösungen bauten, weil wir dachten, wir wüssten es besser.
Auf der anderen Seite zu stehen zwang uns, tatsächlich zu praktizieren, was wir predigten. Oder es zumindest zu versuchen.
Wo wir heute stehen
Arheev ist live. Leute nutzen es. Wir bauen weiter Features, beheben Bugs und haben uns damit abgefunden, dass Software nie „fertig“ ist.
Wir machen weiterhin Kundenprojekte, sie bringen nach wie vor den Großteil unseres Umsatzes. Aber wir betreiben jetzt auch unser eigenes Produkt.
Es ist unordentlich. In manchen Wochen bekommt Arheev mehr als 30 %. In manchen weniger. Wir lernen noch dazu.
Wir sind ein besseres Dienstleistungsunternehmen, weil wir dasselbe durchgemacht haben wie unsere Kunden. Den Druck, die Kompromisse, die langen Nächte beim Debuggen von etwas, das „eigentlich einfach sein sollte“.
Wenn wir einem Kunden sagen, dass etwas schwer ist, weiß er, dass wir das nicht nur sagen, um mehr Stunden abzurechnen. Wir haben es selbst gemacht.
