Am Anfang stand nur eine Hypothese: Mütter in der frühen Elternzeit suchen Freundinnen in ihrer Nähe und würden dafür eine App nutzen. Heute liegt ein fertiges Produkt mit Go-to-Market-Plan vor mir, mamabande, das ich von der ersten Skizze bis zur gebauten App selbst durch den Discovery-Prozess geführt habe. Kein Design-Team dazwischen, kein Wartezimmer. Mit Werkzeugen wie Lovable, Supabase und Claude Code kann heute jede PM einen Prototyp bauen, ohne auf Design-Ressourcen zu warten. Das klingt nach Demokratisierung, schafft aber eine neue Frage: Wenn alle prototypen können, was macht den PM-Prototyp aus? Die Antwort liegt nicht im Tool, sondern in der Intention. Eine PM prototypiert, um eine Hypothese zu testen. Ein Designer prototypiert, um eine Erfahrung zu gestalten. Beide nützlich, beide unterschiedlich. Dieser Artikel zeigt den PM-Prototyp an einem realen Fall.

Was ist ein PM-Prototyp?

Ein PM-Prototyp ist die billigste Form, eine Geschäftshypothese sichtbar zu machen. Er muss nicht schön sein. Er muss eine falsifizierbare Aussage testen: "Wenn wir X zeigen, erwarten wir Y." Bei mamabande hieß die erste Version genau das: ein klickbarer Rohbau, der den Kern-Flow durchspielte, ob eine Mutter eine andere Mutter in ihrer Nähe findet. Kein Matching-Algorithmus, kein ausgefeiltes Profil, kein Chat. Nur die eine Frage, ob die Idee überhaupt trägt. Andere Formate beantworten dieselbe Frage: eine Fake-Door-Landing-Page, die misst, ob jemand klickt. Ein Wizard-of-Oz-Test, bei dem ein Mensch hinter dem Vorhang das tut, was später eine Maschine tun soll. Allen gemeinsam ist, dass sie auf die teuerste Frage der Discovery antworten, ob das überhaupt jemand will.

Marty Cagan beschreibt Product Discovery als Antwort auf vier Risiken: Value (will jemand das?), Usability (kann jemand das nutzen?), Feasibility (können wir das bauen?) und Business Viability (funktioniert das geschäftlich?). Klassisch verantwortet die PM vor allem Value und Viability, der Designer die Usability, Engineering die Feasibility. Als Solo-Builderin bei mamabande lag plötzlich alles bei mir. Das war kein Vorteil, sondern eine Falle: Wer alle vier Risiken gleichzeitig prüfen will, prüft am Ende keines sauber. Mein Anker blieb deshalb die teuerste Frage zuerst, der Value. Die Usability-Tests kamen erst, als die Value-Hypothese hielt. Diese Reihenfolge ist der Wert, nicht die Vollständigkeit.

Die Superkraft heißt Framing

Der wichtigste Beitrag der PM zum Prototyping ist nicht das Bauen. Es ist die Entscheidung, was gebaut wird. Bei mamabande war die schwierigste Arbeit nicht die App, sondern das Framing davor: Welches Problem genau, für welche Mütter, in welcher Lebensphase, in welchem Kontext. Erst der Design-Thinking-Prozess mit echten Müttern hat die Hypothese geschärft. Meine erste Annahme war zu breit. Die Nutzertests haben sie zugespitzt, ich habe den Prototyp angepasst und erneut getestet. Dieses Zuspitzen, nicht das Coden, ist die eigentliche PM-Arbeit.

Eine PM, die mit Lovable einen klickbaren Prototyp baut, denkt hoffentlich trotzdem wie eine PM: nicht in Pixeln, sondern in Hypothesen. Die Verlockung des Details ist real. Wer plötzlich Farben, Schatten und Animations-Timing anpassen kann, verliert leicht den Blick dafür, ob gerade das Richtige getestet wird. Bei mamabande hat mich der Prozess davor bewahrt: Jede Iteration hatte eine Frage, keine Politur ohne Zweck. Genau hier liegt die Chance, PMs, die schnell genug bauen, um ihre Hypothesen selbst zu testen, ohne auf Design-Ressourcen zu warten.

Was ich gebaut habe

Der ganze Bogen von mamabande sah so aus: Aus der geschärften Hypothese wurde ein Prototyp. Den habe ich mit Müttern aus dem Pilotkreis getestet, anhand des Feedbacks optimiert und erneut getestet. Erst als der Kern trug, habe ich die App selbst gebaut, mit Lovable und Supabase, ohne Design-Auftrag. Jetzt habe ich ein MVP gebaut und prüfe das GTM-Konzept, um Mamas den Mehrwert von Mamabande wirklich auf ihr Smartphone zu bringen.

Die größte Veränderung ist die Geschwindigkeit. Was früher Wochen Abstimmung mit einem Design-Team gebraucht hätte, lief bei mamabande in Tagen: Hypothese, Prototyp, Test, Anpassung, nächster Test. Aber Geschwindigkeit ist nur dann wertvoll, wenn die Hypothese stimmt. Schnell das Falsche zu bauen ist nicht besser als langsam das Falsche zu bauen. Genau deshalb steht bei mir der Prozess vor dem Tool.

Kritische Einordnung

In großen Teams mit starkem Design ist PM-Prototyping oft die schlechtere Wahl, weil Designer dasselbe schneller und besser können. mamabande war ein Sonderfall: ein Soloprojekt ohne Design-Team, in dem Selbstbauen die einzige Option war. Es bleibt das Risiko der Hybrid-Rolle: PMs, die "auch Designerin spielen", werden möglicherweise weder der einen noch der anderen Rolle gerecht. Die Demokratisierung der Werkzeuge demokratisiert nicht automatisch die Perspektive. Trotzdem: Dort, wo Design-Kapazität knapp ist und eine Hypothese schnell getestet werden muss, ist der PM-Prototyp das richtige Werkzeug, solange klar bleibt, welche Frage er zuerst beantwortet und welche er offen lässt.