Product Case · Eigenes Produkt

HappyNest: ein komplexes Familienprodukt von Discovery bis zur Launch-Vorbereitung strukturieren

Discovery, Product Strategy, Produktlogik, UX, Requirements, Backlog, Entwicklungssteuerung, QA und Launch-Vorbereitung – in eigener Verantwortung.

Discovery
Product Strategy
Produktlogik
UX / User Flows
Requirements
Jira / Backlog
Entwicklungssteuerung
QA
Launch-Vorbereitung

Aktueller Stand: Launch-Vorbereitung

Ausgangslage

Am Anfang stand ein reales Problem aus dem Familienalltag, keine fertige Produktidee: Informationen, Termine, Aufgaben und Zuständigkeiten verteilen sich über Köpfe, Chats und Kalender.

Zu klären war also nicht, welche Features gebaut werden, sondern was der Gegenstand des Produkts überhaupt ist.

Problem

Aus einem diffusen Alltagsbedarf musste ein Produkt entstehen, das gebaut, getestet und gelauncht werden kann – mit begrenztem Budget und begrenzter Zeit.

Die inhaltliche Schwierigkeit lag in der fachlichen Komplexität: Familienthemen sind selten eindeutig eine Aufgabe, ein Termin oder eine Information.

Meine Rolle

Founder und Product Lead in einer Person: Discovery und Product Strategy, Produktlogik, UX und User Flows, Requirements und User Stories, Jira-Backlog, Entwicklungssteuerung, QA und Launch-Vorbereitung.

Dazu kam Verantwortung, die ich zuvor als angestellter Product Owner nicht in dieser Breite getragen habe: Budget, Entwicklungsfortschritt, Qualität und den nächsten Release.

Vorgehen

Discovery → Product Strategy → fachliches Modell → User Flows → Requirements und User Stories → priorisiertes Jira-Backlog → Delivery mit Refinements → QA und Abnahme → Launch-Vorbereitung.

Entscheidungen wurden dokumentiert statt mündlich getroffen. Das half dabei, Diskussionen zu verkürzen und Sonderfälle sichtbar zu machen, bevor sie im Code landeten.

Stakeholder & Go-to-Market

Parallel zur Umsetzung: Positionierung, Pitch und Vorbereitung der Markteinführung – unter anderem im Rahmen des AC²-Gründungswettbewerbs (2. Platz mit Pitch und PitchDeck).

Zentrale Product-Entscheidungen

Nicht was gemacht wurde, sondern warum – und was es geändert hat.

Fachliche Objekte statt eines universellen Aufgabenobjekts

Ausgangslage

Eine Familieninformation kann zunächst nur Information sein – daraus können aber Termine, Aufgaben, Fahrdienste oder Klärungsbedarf entstehen.

Product-Frage

Wie bildet man das ab, ohne Information, Verantwortung und Entscheidung miteinander zu vermischen?

Entscheidung

Klar getrennte fachliche Objekte und Beziehungen statt eines generischen Aufgabenobjekts, das alles abbilden soll.

Warum

Bessere UX, weniger Sonderlogik im Code und deutlich einfachere Erweiterbarkeit späterer Funktionen.

Release-Schnitt entlang von Nutzerszenarien

Ausgangslage

Der Funktionsumfang wuchs schneller als die Umsetzungskapazität – der Launch rückte nicht näher.

Product-Frage

Was gehört wirklich in die erste launchfähige Version, und woran misst man das?

Entscheidung

Der erste Release wurde auf durchgängig nutzbare Alltagsszenarien geschnitten, nicht auf einen Feature-Katalog.

Warum

Ein kleinerer, aber vollständig nutzbarer Kern lässt sich testen, bewerten und tatsächlich veröffentlichen.

Artefakte aus dem Produkt

Jeder Screen zeigt eine Entscheidung, nicht nur ein Interface.

Product Screen: Familien-Übersicht

Übersicht statt AufgabenlisteZeigt die Entscheidung, Information und Verantwortung getrennt darzustellen – die Übersicht beantwortet zuerst „was ist relevant“, nicht „was ist offen“.

User Flow: Information → Aufgabe → Zuständigkeit

Flow einer AlltagssituationDer Flow macht sichtbar, an welcher Stelle aus einer Information eine Zuständigkeit wird – die Grundlage für Requirements und Sonderfälle.

Backlog-Ausschnitt: priorisierter Release-Schnitt

Backlog mit Release-FokusBelegt, wie aus dem fachlichen Modell ein priorisierter, umsetzbarer Release-Schnitt entstanden ist.

Ergebnis / aktueller Stand

HappyNest ist ein durchgängig strukturiertes Produkt: Produktlogik, User Flows, Requirements und Backlog sind geklärt, die Entwicklung läuft entlang definierter Release-Schnitte. Der Stand ist Launch-Vorbereitung – Abnahmen, QA und Go-to-Market-Vorbereitung.

Learnings

Fachliche Klarheit zuerst: Wo Objekte und Zuständigkeiten früh sauber getrennt sind, entstehen später deutlich weniger Sonderfälle.
Ein Release-Schnitt entsteht aus Nutzerszenarien, nicht aus Feature-Listen. Diese Reihenfolge würde ich heute noch früher erzwingen.
Was ich anders machen würde: den ersten launchfähigen Kern noch kleiner definieren und Erweiterungen konsequenter nach hinten schieben.

Diese Art von Struktur fehlt in deinem Produkt?

Projekt besprechen Nächster Case: PackSplit