Wie man in 3 Monaten ein SaaS-Produkt baut

Im heutigen Podcast dreht sich alles um das Thema „Wie man ein digitales SaaS Produkt von einer Idee zum Launch bringt“. Unsere Zielgruppe sind nicht nur CEO's, sondern auch Produktmanager ohne grosse Entwicklungserfahrung. Wir möchten herausfinden, was das Geheimnis hinter  erfolgreichem Produktmanagement ist. In unserem Gespräch werden wir uns mit dem Fundament des Produktmanagements, Projektstrategie, Produktdiscovery, -delivery und -marketing beschäftigen. Letztlich geht es um den praktischen Ansatz, wie man ein erfolgreiches SaaS-Produkt auf den Markt bringt.

Willkommen in der Welt des Produktmanagements!

Ihr fragt euch, wie man von einer Idee zu einem erfolgreichen digitalen SaaS Produkt kommt? Keine Sorge, ihr seid bei uns genau richtig. Wir lernen die Tricks kennen, um das Produktmanagement einfach und pragmatisch zu gestalten. Vergessen wir die komplizierten Frameworks, denn heute geht's darum, wie man ohne viel Anstrengung erfolgreich Produkte auf den Markt bringt.  

Valentin, wir kennen uns schon von 5 bis 6 Unternehmungen, bei denen wir zusammengearbeitet haben und in einem agilen Setup SaaS-Produkte gebaut haben. Wir haben wahrscheinlich in den vergangenen 15 Jahren immer wieder zusammengearbeitet mit mixed Teams, also zum Teil remote oder vor Ort.

Midlife Unternehmer Podcast

Abonniere unseren Podcast und begleite uns auf der Reise durch das Unternehmertum

Praktische Erfahrungen zu den Themen Lead Management, Produktmarketing und Produktmanagement. Lösungen von gleich gesinnten Software-Unternehmern mit ihren Geschichten zur Work-Life-Balance.

Den Podcast anhören, Wie man in 3 Monaten ein SaaS-Produkt baut

 

Du hast dort immer Produkte gebaut und ich habe extrem schätzen gelernt, wie du es schaffst, so pragmatisch, und gefühlt ohne viel Anstrengung, so nebenbei und ohne überarbeitet zu sein, diese Produkte auf den Boden zu bringen und gleichzeitig auch noch die Entwicklungsteams zu managen.

Das hat mich beeindruckt! Trotzdem frage ich mich – das knallharte Priorisieren, das transparente Vorgehen und das Teammanagement – das ist doch nicht alles. Da muss mehr dahinterstecken. Wenn man in der Theorie schaut, gibt es ein Fundament vom Produktmanagement

Das ist in der Schnittmenge zwischen der Technologie, User Experience und Business.

In der Technologie, ob es Frontend, Backend, Entwicklungsprozesse oder CICD ist.

• Fundament: mit Product Management bewegen wir uns in der Schnittmenge von Technologie, UX und Business:
  • Web Technologies: Frontend, Backend, Entwicklungsprozess, CICD
  • UI/UX Design: Mockups, User Flows, Information Architecture
  • Business: Businessmodel, Financial KPIs
  • Projektmanagement: Scrum, Kanban, Backlogs, Estimations
  • Data Analytics: BI Tools
• Product Management heisst aber auch...
  • Product Strategy: Vision, Ideal Customer Profile,
  • Product Discovery: Research, Interviews, Prototyping, Testing
  • Product Delivery: Requirement Specifications, Product Roadmap, Priorisierung
  • Produktmarketing: Positioning, Messaging, Differentiators

Bei UI oder UX Designs geht es um Mockups, User Flows, Information Architecture. Oder im Business, wenn es um Business Modelle, Financial KPI’s geht. Aber auch Projektmanagement – Scrum, Kanban, Backlogs, die ganzen Userstories. Bestimmt nicht nur Data Analytics, man muss einfach ein tiefes Verständnis haben. Also, das ist das Fundament.

Aber Produktmanagement geht auch um Projektstrategie. Also eine Vision, wer ist der Kunde. Es geht um Product Discovery, wie man das recherchiert. Man macht Interviews mit der Zielgruppe, es geht ins Protoyping. Man testet es wieder. Es geht ins Product Delivery. Also die Requirement Specifications, es geht um Product Roadmap und die Priorisierung. Schlussendlich auch um Produktmarketing, wie du auf den Markt gehst, um eine Positionierung, mit einem Messaging, was sind deine Alleinstellungsmerkmale.

Meine These ist, dass man diese Skills doch gar nicht in aller Tiefe in einer Person findet. Und zwar auch bei dir nicht.

Schmerztablette oder Vitamin?

Darum frage ich dich heute, wie du die Produkte gebaut hast, was hat funktioniert, und was weniger. Ich möchte jetzt nicht über komplizierte Frameworks sprechen, das mache ich ja schon genug. Das mache ich auch super gerne irgendwelche Frameworks anzuwenden. Aber es geht um den pragmatischen Ansatz, wie man ein SaaS Produkt auf den Boden bringt.

Darum möchten wir diese drei Themenbereiche anschauen. Vielleicht kannst du auf das erste eine Antwort geben. Warum baust du ein SaaS Produkt?

Ich glaube, es ist vorwiegend dann, wenn man für eine spezifische Kundengruppe ein Problem löst.

Dort hat das ideale Kundenprofil, wir nennen es das Ideal Customer Profile (ICP) entweder ein Pain, wo man etwas lösen muss, oder ein Bedürfnis. Und so ist man entweder ein „Pain Killer“ – eine Schmerztablette oder ein Vitamin. In der Realität sind die meisten Vitamine, die Verbesserungen von einem Prozess oder etwas bringen und selten ein „Pain“, ohne das es nicht gehen würde und das Schmerzen verursacht.

Wie geht man vor?

Also gibt es eigentlich wenige "Pain Killers", sondern viel mehr Vitamine. Wie gehst du vor, was machst du anders im Vorgehen, wenn du ein Vitamin baust?

Ich glaube, wichtig ist, dass man mit verständlichen Methoden arbeitet. Dass man einfache, klare Prozesse und Frameworks hat. Ein einfaches Framework, das ich cool finde, ist der „Golden Circle“ von Simon Sinek. Das strukturiert im Why? How? und What? und man kann sich daran orientieren.

Gerade beim Produkt bauen gilt: einfach & pragmatisch schlägt immer kompliziert & perfektionistisch. Jedes Mal. Das war auch meine Erfahrung in den vergangenen 20 Jahren.

Als ich angefangen habe als Entwickler, im Produktmanagement und dann etwas grösser in Produkt-Teams. Und jetzt auch regelmässig bei den SaaS Produkten, man lernt immer etwas. Man muss es dynamisch anwenden, aber es ist nicht ein 10'000 Schritte Prozess, der mit allen Details durchgedacht ist.

Es wird zusammengebracht, indem man versucht, sich in die Person hineinzuversetzen, viel Passion bringt und die auch rüberbringt an die Developer, das Team und die anderen. Damit man sich an einer Vision orientieren kann und immer weiss, wo der Nordstern ist und wo man hin will.

Was ist das Resultat?

Was ist von so einem pragmatischen Ansatz, schlussendlich das Produkt?

Am Schluss, wenn man alles richtig macht, bekommt man immer ein digitales Produkt. Das kann auch eine Mobile App sein, ein SaaS-Produkt oder ein Online-Service, die du für deine Zielgruppe anbietest und ihnen wirklich einen Mehrwert schafft, wenn sie es nutzen, dass es ihnen besser geht oder mehr erreichen können.

Das Problem, das wir sehen, wenn unendlich diskutiert wird und das Produkt nie released wird, du kommst nicht vorwärts und es verzögert sich. Die Verfahren und das ganze Produktteam bringen am Schluss nicht mehr das raus, was man sich erhofft.

Wie man Geld verpufft

Sag doch zuerst, womit man so richtig gut Geld verpuffen kann, anstatt an einer zielgerichteten Lösung zu arbeiten?

Unklare Zielgruppe

Ich glaube, das Erste ist schon im „Warum“, wenn man nicht genau weiss, für wen man eine Lösung baut. Wenn das Ideal Customer Profile (ICP) nicht klar ist und jeder eine andere Vorstellung hat, wer der Kunde sein könnte, was der Nutzen genau sein sollte und wenn man keinen Cornerstone hat – also einen Eckstein oder einen klaren Nordstern. Dann werden alle drauflos entwickeln und die ganze Zeit wieder alles ändern. Jede Woche neue Diskussionen und immer wieder Grundsatzdiskussionen oder man verliert sich völlig in Details und kann den Nutzen nicht mehr machen.

Wenn man auch nicht weiss, wie man es validieren möchte und keine Akzeptanzkriterien hat, von denen man weiss, wenn man sie erfüllt hat, ist es gut. Wenn man auch nicht spürt, wer der Kunde ist.

Da gibt es oft einen grossen Gap zwischen dem Kunden und dem Entwickler. Der Entwickler ist vielleicht an einem anderen Ort und weiss gar nicht, wie der Kunde tickt, wie er lebt, wie er das Tool nutzt und wie er damit überhaupt umgehen muss.

Fehlende Ownership

Und wo sind diese Fehler im Vorgehen? Wo kann man dort Geld verlieren?

Dort ist es auch oft, dass man einfach ineffizient arbeitet. Das Erste ist mal, wenn keine Ownership da ist, wenn niemand für dieses Produkt steht, die Entscheidungen verantwortet und gegenüber anderen verteidigt.

Man ist eine Gruppe, etwas unklar und alle dürfen mitreden und keiner weiss, wo es hingehen soll. Jede Woche kommt der CEO, dann hat der Investor wieder eine Idee, dann hat der Entwickler wieder ein Tool released, es hält niemand wirklich die Fäden zusammen. Wenn dieser Prozess nicht gemanaged ist, wenn alle alles machen können, alle möchten am liebsten die eierlegende Wollmilchsau.

Wenn man nie gelernt hat, Nein zu sagen und alle Features gleich implementieren will, dann gibt es eine unendlich lange Development Liste, die nie fertig wird. Wenn man ein Projekt überlädt, viel zu viele Stakeholders drin sind, und man es zu vielen Leuten recht machen will, wie in den Dilbert Comics, wo es ganz viele Buttons gibt, weil jeder noch einen gewünscht hat.

Oder wenn man einfach das Know-How nicht hat, wenn man ein SaaS-Produkt bauen will, aber nicht weiss, wie man ein Projekt baut, weil einem das Wissen fehlt. Es gibt gar nicht so viele Leute, die wissen, wie man ein SaaS Produkt baut.

Und wenn man nie gelernt hat, zu priorisieren und Features gegeneinander abzuwägen. Das fällt allen sehr schwer. Wenn man etwa eine Business-Idee hat und kein Techie ist, keine technischen Leute hat und die Verantwortung nicht an Product Owners geben kann. Wenn man viel zu wenig Zeit hat, um die in ein Produkt zu stecken, sondern mit ganz vielen anderen Sachen beschäftigt ist, weil man eben noch Marketing und Sales machen muss.

Fehlendes Alleinstellungsmerkmal

Wie sieht es aus mit dem Alleinstellungsmerkmal? Beim Resultat, ist es wirklich so wichtig, dass man sich differenziert?

Man sieht oft, wenn man diffuse Lösungen hat, die sich weder fokussieren noch billiger sind. Man sagt ja immer, man sollte 10x Verbesserung bekommen, 10 Mal mehr Nutzen schaffen. Das kann man auch machen, indem man 10x günstiger ist. Wenn man es fast gratis abgibt und nur 10 % der Kosten hat, aber den gleichen Value.

Sonst muss man mehr Value liefern, oder man macht einen Mix. Man ist vielleicht ein Drittel günstiger und dreimal besser, dann hat man auch 10X.

Das vergisst man oft, man erhält eine schwammige Lösung, die keinen klaren besseren Nutzen hat. Die Leute finden, es ist etwas besser, aber bringt nicht wirklich viel. So kann man die Leute nicht überzeugen, weil man ist meistens ein neues Produkt oder jemand Neues.

Darum muss man immer den Nutzen und das Resultat am Schluss im Fokus haben und herausfinden, wie man das messen kann. Damit man den Kauf Value auch quantifizieren kann.

Wie verhindert man diese Ineffizienzen?

Man kann Geld verbraten, indem man die Zielgruppe nicht kennt, den Prozess nicht managen kann, kein Ownership hat, nicht priorisiert oder auch keinen Nutzerfokus hat. Das leuchtet ein.

Diese Problembeschreibung tönt für mich so komplex wie ein SAP-Integrationsprojekt, das ein Jahr dauert und man trotzdem noch nicht richtig angefangen hat. Wie macht du das pragmatisch, wie kannst du diese Probleme lösen?

Ich glaube, der erste Schritt ist, dein Ideal Customer Profile (ICP) zu finden. Im Idealfall kennt man das natürlich, man ist vielleicht selbst der Nutzer oder hat lange mit ihnen gearbeitet und ist drin. Aber oft ist das nicht der Fall.

Nutzen und Probleme kennen

Und wenn es nicht der Fall ist, muss man einen Weg finden, wie man dorthin kommt. Zuerst schreibt man es auf, macht ein Persona-Projekt. Man leitet genau ab, was die Needs und Pains sind. Nicht nur, dass sie 50 Jahre alt, männlich sind und ein Handy haben. Das trifft auf entschieden zu viele Leute zu. Dann muss man es validieren. Wir machen es bei einer neuen Produktidee so, dass wir es dokumentieren. Wir machen eine Slide oder Skizze und verschicken E-Mails an die mögliche ICP-Zielgruppe. Wir validieren es in Calls und man sieht dann schon in 10 Calls und die Leute fragen sich, was genau der Nutzen ist, dann ist man wohl nicht auf dem richtigen Weg, diese Erfahrung haben wir selbst auch bereits gemacht.

Dann validiert man sie Schritt für Schritt und erhöht die Komplexität. Zuerst bespricht man es, dann macht man einen Mockup. Man zeichnet es und baut vielleicht einen klickbaren Prototyp und testet ihn. So hat man immer mehr Fleisch am Knochen, gibt mehr Energie rein und fängt nicht gleich mit dem Entwickeln an. Wenn man eine Skizze macht und diese gleich entwickeln lässt, dann ist es kostspielig und das Risiko ist hoch.

So versucht man, mit Experimenten dorthin zu kommen.

Strategie, Umfang, Struktur, Skelett und Oberfläche

Also du gehst jetzt schon in den Prozess rein. Kannst du den genauer beschreiben? Wie baust du jetzt so ein Produkt?

Ja, ich möchte dazu drei Sachen sagen:

1. Es geht darum, wie man ein Produkt designt.
2. Dann arbeiten wir in einem „Rhythmus“.
3. Und der dritte Teil, wie man es entwickelt.

Für „Design the product“ könnte man ganz viele Podcasts nur über den Designprozess machen. Ich fasse es zusammen, ich arbeite sehr gerne und erfolgreich mit einem Modell.

Das heisst „The 5 Elements of UX“ von Jesse James Garrett:

1. Strategy
2. Scope
3. Structure
4. Skeleton
5. Surface

Dort hast du eine klare Struktur drin, wie du relativ einfach auf ein Produkt kommst, das der User dann auch sehen kann. Man kann es testen oder später dann entwickeln. Es ist wichtig, dass man zuerst weiss, für wen und was man bauen muss und erst am Schluss, wie es dann aussehen soll.

Nicht anfangen, über die Button-Farbe zu diskutieren, wenn man gar nicht weiss, welchen Use Case man abbilden will.

Dann hat man natürlich die agilen Methoden, da gibt es verschiedene. Die bekanntesten sind sicher Scrum und Kanban. Wichtig ist, dass man eine Methodologie hat und sich daran hält und dass man diesen Prozess klar definiert hat. Aber man kann auch da lange religiöse Diskussionen führen, welches besser ist. Da werden die Scrum'sche Prozesse noch erklärt.

Dann sollte man mit Mockups zu arbeiten, damit es schnell sichtbar wird. Das ist für einen selbst wichtig, damit man eine klare Abgrenzung hat und dass man es auch zeigen kann, mit Kunden testen kann und dass auch intern alle wissen, wie das am Schluss funktionieren soll – idealerweise mit klickbaren Prototypen.

Da gibt es heutige Technologien, die das gut machen, mit Figma oder Balsamiq. Dann zum Rhythmus, es sind ein paar Punkte, die ich in den Fokus setzen möchte.

Ich arbeite in einem „scrumisch“ agilen Development Prozess. Man hat Sprints, die für mich funktionieren und alle zwei Wochen geplant werden, aber mit einem kleinen Backlog. Nicht der riesige erdrückende Ballast, dass jeder eine Idee und User Stories reinschreibt.

Als Produktmanager benötigst du einen kleinen Backlog und du sagst klar, wo der Fokus ist. Alle können so auch committen, dorthin zu kommen. Man arbeitet in kleinen Teams, 3 bis max. 6 Leute, inkl. den Designern. Damit alle verstehen, wo die Reise hingeht und sich auch dynamisch anpassen und in jedem Sprint ein Commitment geben können, wo sie hinkommen wollen.

Dann hat man Daily Standups, Touchpoints Huddles, was auch immer. Es ist gut, eine Struktur zu haben, um den Fortschritt zu messen. Dann kann man monatlich oder zweimonatlich, das ist vom Team abhängig, einen Rückblick machen und sich iterativ immer verbessern.

Dann lohnt es sich schon, dass man als Produktmanager oder mit dem Management, möglichen Investoren oder Product Owners, Auftraggeber ein Quarterly Planning macht. 

Vision und Roadmap

Ich arbeite sehr gerne mit Vision und Roadmap. Dass man eine grosse langfristige Vision hat, wohin man hin will, was man gerne hätte und wie man es schafft, dass man dorthin kommt.

Um wirklich diesen Mehrwert zu schaffen. Da ist oft der Gap auch riesig zu den Entwicklern. Man muss das eigentlich immer viel mehr kommunizieren, als man das Gefühl hat, wie das Endprodukt sein soll. Das kann man mit Bildern oder Videos machen, um wirklich dieses Bild zu vermitteln.

Wenn man die Vision in eine jährliche Roadmap runterbricht, die sehr grob ist, mit grossen Zielen und die dann in Quarterly Roadmaps plant. Ich habe das meistens mit einer normalen Präsentation gemacht. In einem einfachen Dokument, eine Seite, die alle anschauen können und diskutieren. In den Quarterly Roadmaps ist es logisch, dass das aktuelle Quartal etwas genauer ist, mit den Sachen, die man erreichen möchte.

Und das nächste Quartal ist schon ungenauer, das dritte Quartal ist sehr „fuzzy“. Man will ja da nicht ein Atomkraftwerk, sondern man baut ein Produkt, von dem man noch nicht so genau weiss, wo das Endziel sein wird. Man will ja dann lernen und iterativ dorthin kommen. Also sagt man, in drei Monaten habe ich die erste Version. Und dann kommt die nächste Version und auf dem Weg muss noch vieles gelernt werden.

Ich glaube, das dynamische ständige Updaten, ist wichtig. So kann man visualisieren, ist aber immer bereit, Sachen wieder zu ändern. Dass man auch in jedem Quartal grosse Ecksteine legt, die eine Veränderung bringen. Oft wenn man im Alltag fragt, gibt es 300 kleine Features, die man verbessern muss. Das sieht aber der Endkunde nicht so fest, sondern nur der einzelne User. Dann hat man vielleicht ein halbes Jahr entwickelt und das Gefühl, das Produkt ist nicht weitergekommen.

Jedes Quartal sollte man sich mindestens einen Pflock stecken, von dem man sagt, dass dieser das Produkt aufs nächste Level bringt. Manchmal hat das auch keinen Effekt, aber manchmal einen grossen. Langfristige Ziele schafft man nur, wenn man ständig wieder daran arbeitet.

Sonst ist man überfordert vom täglichen Geschrei und den Wünschen von Sales und Customers. Neben dem Prozess und der Vision, braucht man, sobald man grösser wird, eine Top-100-Feature-List. Alle haben Wünsche, alle sind superwichtig.

Jetzt muss es gemacht werden, wenn ich das hätte, könnte ich noch einen Kunden mehr haben. Dann muss man sie reinschreiben und sie immer wieder aktualisieren, damit es plausibel ist, dass es viele andere Wünsche gibt. Man muss es immer gegeneinander priorisieren.

Eine Liste hat immer etwas zuoberst und etwas zuunterst. Und so ist es auch klar, dass nicht alle wünschen können. Trotzdem ignoriert man es nicht einfach. Das ist auch ein Dead-End, man verliert die Leute auf dem Weg, wenn man immer Nein sagt. Und die Realität ist, dass man immer Nein sagen muss.

Stolpersteine

Dann gibt es noch ein paar Stolpersteine, die man vermeiden muss. Mit der Erfahrung kann man etwas abstrahieren und pragmatisch abwägen, wann will ich releasen, was ist der MVP und lasse dafür im Scope Sachen weg.

Zu viele Features

Am Anfang hat man immer eine zu grosse Liste. Ich habe noch nie erlebt, dass die Liste zu klein war. Dann schaut man, was man wegnehmen kann und das kann pragmatisch sein. Dass man sich auch nicht in den Projektmanagement-Tools verliert, von denen es so unendlich viele gibt.

Oder Tasks Lists, wo man 3000 Tasks drauf hat, alle wissen, was sie machen müssen.

Dann ändert etwas und man hat nur schon einen halben Tag, um das Tool auf den neuesten Stand bringen. Also vereinfachen. Lieber kurze, einfache Sachen nutzen, eine einfache To-do-List, auch wenn es nur Post-its an der Wand sind, als zu viele Tools.

Und wie immer, Nein sagen. Feature Creep kommt immer, es gibt überbordende Wünsche. Man muss immer das ICP verinnerlichen. Was soll man, was gibt einen Mehrwert und was ist einfach nicht wichtig? Damit man es auf den Boden bringt, releasen und Sachen auch später noch machen kann. Wenn man das selbst nicht so gut kann, das Know-how für gewisse Skills nicht hat, dann muss man Hilfe holen, Wissen einkaufen.

Das Rad nicht neu erfinden

Auf der technischen Seite ist es so, dass wenn man clevere Entwickler hat, bauen sie am liebsten alles selbst. Sie wollen neu erfinden und möglichst keine bestehenden Lösungen nutzen, weil sie nicht genau das machen, was man will. Da muss man pragmatisch sein. Es ist nicht Rocket-Science.  Meistens bauen wir ja Applikationen, die darauf aufbauen. Darum geht es immer um Speed. Wenn man schnell releasen kann, dann kann man auch schneller verbessern. Wenn man langsam releast, muss man richtig sein.

Wie man das SaaS-Produkt mit Entwicklern baut

Du hast vorher gesagt, Hilfe holen. Das ist ein guter Übergang. Die Entwicklung, wie machst du schlussendlich das Team, welches das Ding baut? Du bist ja selbst der Product Manager und nicht aktiv in der Entwickelung?

Das ist oft ein Hindernis, die meisten Leute sind Businessleute mit Businessideen. Sie möchten gerne etwas bauen, haben eine Vision, wollen eine App oder ein Tool. Sie haben aber noch nie etwas gebaut, hatten noch nie einen Co-Founder oder CTO dabei.

Der Co-Founder der alles kann

Jetzt möchten sie gerne diesen mysteriösen eierlegende Wollmilchsau Co-Founder, der auch designen kann, UX und den Kunden versteht und auch noch alles alleine entwickelt. Wenn man den hat, dann Go for it, nimm ihn, das ist super. Es ist aber auch Glück und wenn man am Anfang nicht gleich diesen technischen Co-Founder hat, dann kann man ihn auch erst später finden und später einbauen, wenn man vielleicht schon eine MVP hat und er sich das besser vorstellen kann. Top-Leute sind immer beschäftigt, die kommen nicht einfach.

Die Agentur

Also haben wir die Möglichkeit, eine Agentur anzustellen. Das kann auch funktionieren, man kann es definieren und live stellen.

Es hat aber zwei Nachteile. Für die Agentur ist es immer ein Projekt. Sie fangen an, haben ein Enddatum, dann ist es aus den Augen aus dem Sinn. Du möchtest aber ein lebendiges Produkt, das sich weiterentwickelt und Ownership hat. Darum ist es ein Widerspruch. Dazu ist es auch noch relativ teuer.

Remote Teams

Das Zweite sind Freelancer, Aufbau von Remote Teams.

Es gibt gute Plattformen wie Upwork, Toptal, Fiverr und andere Sachen. Da habe ich ausgezeichnete Erfahrungen gemacht, man muss das aber üben und einen Prozess haben, wie man sie findet und rekrutiert und wie man sie auch schnell wieder ausmistet, wenn es keinen Match ist.

Da kann man aber ausgezeichnete Entwickler finden, die auch etwas Ownership haben und auch preislich vernünftig sind. Oder man schafft da wirklich mit einem Remote Team wenn man etwas mehr Budget hat und wenn es eine langfristige Sache ist. Dann rekrutiert man sie und baut es mit ihnen auf. Sie können auch wachsen, am besten an einem Standort.

Ich empfehle am Anfang, dass es einfacher ist, wenn es näher ist und in der ähnlichen Zeitzone.

Als wenn man gerade auf die Philippinen oder Indonesien geht, das macht es schwieriger. Generell ist es bei Remote Teams so, dass man entweder selbst eine starke Product Person ist. Oder man holt sich jemand rein, der das Ownership des Produkts hat.

Das kann als Advisor sein oder sonst ein Partner. Aber jemand hat die Ownership. Die Remote Teams sind dann oft wieder sehr weit weg vom Business und vom Kunden. Als CEO verbrennst du dich einfach, wenn du alles selber machst. Wenn du Produkte baust, Kunden und Funding dann ist es eine Frage der Zeit, bis man wirklich keine Energie mehr hat.

Wie sieht man, dass man auf dem richtigen Weg ist?

Dein Lösungsansatz für diese Probleme ist immer ein glasklares ICP. Interviews mit Zielgruppe, dann der Rhythmus mit Vision und Roadmap und letztlich die Entwicklungsprozesse, das Teammanagement im Griff zu haben.

Wie merke ich, dass es auch funktioniert? Gibt es Anzeichen dafür, dass ein Resultat herauskommt und der richtige Weg ist? Wie siehst du das?

Wir vergleichen das ja oft mit Random Acts of Marketing (RAMs). Man macht etwas und plötzlich funktioniert etwas oder auch nicht.

Im Produktmanagement ist es ja ähnlich, man orientiert sich an einem "educated Guess". Es sind zwei Dimensionen, die man verfolgen möchte.

Du möchtest einen messbaren Value Add für dein ICP erhalten. Da gibt es auch verschiedene Framework, wenn man weiss, was die Acceptance Criterias sind oder eine engpasskonzentrierte Strategie (EKS) hat, wo man immer weiss, ob es mehr Licht oder mehr Wasser benötigt, damit die Pflanze wachsen kann.

Oder ein Framework, wie „Jobs to be done“, wo man auch messen kann. Wie haben wir das gelöst, was der Endkunde will? Geht es ihm jetzt besser oder hat man an ihm vorbeientwickelt?

Es ist dann wichtig, dass man es immer wieder misst und vergleicht. So kann man auch den Trend rausfinden, ob es nach oben oder unten geht. Man kann das teilweise nicht so gut quantifizieren, aber Trends kann man gut quantifizieren. Man muss die Living Documents, wie die Roadmap immer wieder updaten.

Und sich einen Schritt rausnimmt und fragt, ob man auf dem richtigen Weg ist. Die zweite Dimension ist, dass man ein Shipped Product hat. Es gibt ja einen Friedhof von Startups, die seit Jahren am Entwickeln sind und immer noch Geld investieren, weil sie ja immer noch Features benötigen, bevor sie live gehen. Eines Tages muss man "shippen". Man sagt das auch so.

Als Founder oder als Visionary, solltest du eigentlich "embarrassed" sein, dass du dein Produkt "shippst"

Wichtig ist, dass du immer Verbesserungen und Verbesserungen nachlieferst. Das Kontinuierliche ist wichtiger als das perfekte Produkt.

Und was auch hilft, ist, wenn man ein motiviertes Entwicklungsteam hat, das mitdenkt, tiefe Fluktuation hat und dich nicht verlässt. Und eine Umgebung schafft, dass die Leute langfristig daran mitarbeiten wollen, mehr Value generieren und wenn man Glück hat, findet man auch diese ominösen 10X Entwickler. Die finde ich gelegentlich auch, sie sind aber selten.

Man kann auch mit normalen Entwicklern und motivierten Leuten einen guten Mehrwert schaffen.

Gibt es erfolgreiche Beispiele?

Hast du ein paar Beispiele, in denen du aufzeigen kannst, dass es Resultate gegeben hat?  

Ja, da habe ich ein paar aufgelistet. Ein paar habe ich selbst gebaut. Eines ist Payyo, ein Payment-Gateway wie Stripe, aber sehr auf Tourismus fokussiert.

Das war eine Extraktion von einem bestehenden Produkt, wir haben die einzelnen Funktionen gelöst, aber nicht ein eigenes Produkt hatten, als ein Stand-Alone.

Wir wollten das dann zu zweit bauen. Dann haben wir 3er und 4er-Teams gehabt.

Wir haben ganz klar gesagt, 3 Monate, dann müssen wir live sein. Was ist der Core, was wir können müssen? Wie können wir aufzeigen, dass wir die wichtigsten Sachen lösen?

Das hat dann auch geklappt, wir haben noch zwei Entwickler dazu geholt. Das Team ist noch in der gleichen Form da, und es sind 6–7 Jahre später. Das hat sehr funktioniert, dass alle diesen Ownership-Gedanken haben.

Dann auch andere Sachen, wie bei Trekksoft war es so, dass wir zuerst einen simplen Prototyp bauten. Bevor wir das richtige Produkt gebaut haben. Die erste Version von Trekksoft wurde in 2 Wochen über Weihnachten entwickelt. Wir wollten schauen, ob es funktioniert und hatten auch kein Geld. Dann hat ganz vieles nicht gut funktioniert, aber das Core-Ding schon, die Buchungslösung.

Dann haben wir eine Mobile-App gebaut, wie Square, mit der man Kreditkarten Payments machen kann. Es war klar, wir wollten etwas revolutionäres machen.

Etwas, das wir auf einer Konferenz, an einem Launch-Day zeigen können. Wir wussten, wir haben 3 Monate, wir haben ein limitiertes Budget und es muss live gehen.

Wir haben noch nie Kreditkarten Payments gemacht mit so einem Swiper. Dann haben wir den Scope zusammengestaucht und je näher der Release-Day kam, desto mehr haben wir aus dem Scope gestrichen. Einfach, damit wir launchen können. Es ist dann sogar auch live gegangen. Das war recht cool.

Dann gibt es Beispiele wie Doodle. Es war auch ein Produkt, wo wir neben dem Studium einen Prototyp gemacht haben, weil wir ein Problem hatten, wir waren selbst das ICP von kompliziertem Termine planen.

Es konnte ein Riesenproblem lösen. Das Produkt ist auf 10 Jahre skaliert, mit ziemlich gleichem Design. Wir haben immer Neues probiert. Aber man kann sich streiten, ob man es besser gemacht hat.

Dann gibt es SmallPDF, das auch aus einem Need gekommen ist, weil jemand im Ausland war. Er wollte seine Post als Scans zugeschickt bekommen und seinen Eltern beibringen, wie man Scans verkleinert, darum heisst die Webseite SmallPDF.

Offensichtlich hatten sehr viele Leute das gleiche Problem. An einer Core-Funktion wird immer mehr rundum gebaut, dass es eine ganze Suite von Lösungen ist.

Ein Produkt, das wir auch am Entwickeln sind, ist ein Chatbot für die Hotellerie. Dort ist ganz klar der Fokus, was sind die Use-Cases von Hotelgästen und vom Concierge. Was brauchen sie, kein Blabla, sondern was will der einzelne Hotelgast und wann ist es einfach, ein Chat zu machen.

Die persönlichen Learnings

Es kommt mir bekannt vor. Beim Neubau einer Webseite, auch bei kleinen Projekten, hat man die Idee, was man alles noch reinpacken muss.

Man will, dass das Ding grösser wird. Diesen Pragmatismus, den du beschrieben hast, ist auch dort notwendig. Was sind denn deine persönliche Learnings, wie gehst du damit um? Du schaffst es, gefühlt nebenbei oder mit einer gewissen Ruhe das Produkt umzusetzen. Wie machst du das?

Scope

Ich glaube, Schritt für Schritt. Wie fällt man einen ganzen Wald, Baum für Baum! Dass man mit einem kleinen Scale anfängt, wenn man in ein Team kommt mit einer Produktidee, dass man nicht gerade alles über Bord wirft, alle Frameworks implementieren will und alle die Sachen, von denen ich erzählt habe, umsetzen will.

Sondern man schaut genau, wo man anfangen will. Wenn es alle verstanden haben und es funktioniert, gehen wir ans Nächste. Im Hinterkopf muss man schon die Vision halten, wo man hin möchte. Aber man muss Schritt für Schritt Sachen verändern.

Es geht um harte Entscheidungen – das Schwierigste ist vorwiegend im Scope. Dass man den Umfang verkleinert, und zu Sachen Nein sagt. Das ist sicher ein Punkt. Das Zweite ist auch, sich einzugestehen, wenn man falsch ist.

Oder wenn gelernt hat, dass das ICP anders ist, und man eine andere Entscheidung macht. Das ist okay, wenn man sich dessen sicher ist. Man muss nicht immer konsistent sein. Wie es in anderen Umgebungen der Fall sein sollte. Man sollte auch emotionslos entscheiden. Auch wenn man das Feature oder Design mega cool fand, wenn es nicht funktioniert, ist es das Falsche.

Nur der Kunde hat das Sagen

Ich glaube, es ist auch wichtig, dass man sich nicht von externen Stakeholders beeinflussen lässt.

Nur dann, wenn die ICP einem das sagt, dass es klar ist oder der Nutzen nicht besser wird. Deine Vision soll sich nur anhand vom ICP aktualisieren. Wenn man anfängt zu zweifeln an der Vision, wenn man verunsichert ist, dann hört man auf dieses und jenes. Auf Investoren, auf das Board, auf Kollegen, die gar nicht dein ICP sind. 

Dann baut man etwas komplett Unnützes. Dann geht es noch um Skills, die man lernen kann, oder zumindest wissen muss, dass es wichtig ist.

Passion

Der Differentiator in der Rekrutierung von Leuten, von einem guten Produkt, von einem Entwickler, ist immer Passion. Es gibt immer eine Firma, die mehr zahlt.

Gerade in Zürich, wo Google ist, die Financial Services und Banken, kannst du nur überzeugen, indem die Leute auch an deinen Traum glauben und es auch zu ihrem Traum machen.

Es gibt ja diesen Spruch: "If you don't build your dreams, someone will hire you to help build theirs". 

Aber ich glaube nicht, dass die anderen an deinem Traum bauen müssen. Sondern man muss die Leute ins Boot holen, ein Feuer soll entfachen und alle arbeiten daran.

Das unterschätzt man, das ist ja überall wichtig, für alles, was man macht.

Key-Take-Aways

Du hast jetzt so viel erzählt, ich habe schon wieder die Hälfte vergessen. Was gibst du diesen CEO's und Produktmanager mit, die jetzt pragmatisch ein SaaS Produkt bauen wollen? Kannst du das zusammenfassen?

Lass dich nicht entmutigen

Die eine Ebene ist schon mal, sich nicht entmutigen lassen. All diese sogenannten erfolgreichen Overnight-Success Beispiele. In der Realität war es auch nicht ganz so.

Das Wichtigste, ist es eine Vision zu haben. Als Gründer und Builder benötigt man die grosse Geschichte. Es braucht vielleicht Fake-it-untill-you-make-it, bis du dorthin kommst.

Aber dass man kontinuierlich eine Verbesserung sieht, dass es immer etwas mehr wird.

Es ist ja dann auch ein Marathon, und kein Sprint. Es geht lange, bis es dann so weit kommt. Und alle kochen mit Wasser. Wenn ich die Press Releases, LinkedIn Posts und Sales Pitches lese, dann ist das immer die „pretty Version“. Es ist oft nicht die Wahrheit.

Und es ist ja auch nicht Rocket Science, sondern man muss immer dran bleiben.

Dann kommt Fokus auf die ICP. Die Motivation muss dorthin kommen, dass man das ICP cool findet und den Kunden gerne hat. Es gibt Bücher, wie von Stefan Merath, die Kunst seine Kunden zu lieben.

Man muss gerne Zeit mit den Kunden verbringen, gerne ihre Probleme und Needs verstehen. Dann baut man ein besseres Produkt. Wenn ich ein Produkt baue für jemanden, den ich doof finde, dann wird es nie ein gutes Produkt.

Pragmatisch sein

Be pragmatic – immer weiter daran arbeiten, akzeptieren, dass es nicht perfekt ist. Der Speed ist viel wichtiger, als Perfektion.

Fokus

Das Zweite ist die ICP. Fokus, Fokus, Fokus. mehr Fokus. Sich ja nicht verwässern lassen, immer die Wollmilchsau im Kopf haben und ja nicht dorthin gehen.

Und lernen, was die Kunden wollen und es zehnmal besser lösen.

Vision

Und das Letzte, das ist wohl das Grösste: die Vision. Die Passion und sich treiben lassen von der Vision. Das ist das Kernding.

Man ist auch nie so gut, wie der Category Leader. Aber deine Passion und Vision ist Key. Die kann das Feuer entfachen bei deinen Kunden, bei deinen Early-Stage-Kunden, deinen Mitarbeitern, Investoren und Developers. Sie nehmen alle Energie aus deiner Passion raus.

So kann man auch schauen, dass dich niemand verlässt, das hat eigentlich hervorragend funktioniert.