Problem validieren Startup: Ablauf vor dem Build

Problem validieren Startup

Ein Startup-Problem validieren heisst, vor dem Build zu prüfen, ob eine klar umrissene Zielgruppe einen wiederkehrenden Job hat, der weh tut, und ob die Betroffenen heute schon Zeit, Geld oder Umwege investieren. Sie fragen nicht, ob die Idee «cool» klingt. Sie sammeln vergangenes Verhalten, wiederkehrende Reibung und Formulierungen, die ohne Ihren Pitch kommen. In dieser Phase zählt ein Problem-Satz mehr als eine Feature-Liste.

Der Text richtet sich an Gründerinnen, Gründer und Innovationsverantwortliche in der Schweiz, die zuerst ein Repository öffnen oder einen Builder beauftragen wollen. Er bleibt auf der Problem-Ebene. Landingpages, Concierge-Tests, Interviews und Vorkauf als Gesamtbild stehen in Startup-Idee validieren. Dieser Beitrag ist schmaler: Er beantwortet, ob das Problem einen Build-Schritt rechtfertigt.

Problem validieren

Belege, dass eine definierte Gruppe einen Job oft genug und schmerzhaft genug erlebt, um Verhalten zu ändern.

Lösung validieren

Belege, dass Ihr Produkt Verhalten ändert oder eine Zusage auslöst, meist nachdem das Problem glaubwürdig ist.

Annahme

Ein Satz, den Sie widerlegen könnten: wer leidet, wie oft, was passiert heute stattdessen.

Problem validieren Startup: so läuft die erste Runde

Behandeln Sie die Arbeit als kurze Sequenz, nicht als ein einziges Gespräch. Bei engem Scope schaffen Sie die erste Runde in einer Woche.

1. Das Problem in einem Satz festhalten

   Person, Situation und heutige Kosten nennen (Zeit, Geld, Risiko, Reputation). Fehlt eines davon, sind Sie noch bei der Idee.

2. Orte auflisten, an denen der Schmerz sichtbar wird

   Postfach, Tabelle, Telefon, Papierordner, Agenturrechnung. Der Ort zeigt, wen Sie interviewen und worauf Sie achten.

3. Nach vergangenem Verhalten fragen

   Letztes Mal, was versucht, was bezahlt. Ihre Lösung zeigen Sie erst, wenn die Geschichte auf dem Tisch liegt.

4. Schmerz und Häufigkeit einordnen

   Wie oft tritt es auf, gab es schon Beauftragung, Kauf oder Eigenbau? Begeisterung für Ihren Pitch ist kein Score.

5. Festlegen, was das Problem widerlegt

   Notieren Sie, was Sie hören müssten, um die Idee zu parken. Wenn nichts Sie überzeugen könnte, sammeln Sie Bestätigung, keine Validierung.

Was zählt als Beleg, was nicht

Starke Signale wirken unspektakulär: dieselbe Geschichte bei Fremden, derselbe Workaround in drei Gesprächen, Geld für eine halbe Lösung, ein Prozess, den alle hassen, den niemand ersetzt hat, weil Alternativen scheiterten.

Schwache Signale sind «tolle Idee» von Freunden, eine volle Warteliste ohne Folgeaktion, ein begeisterter Einzelkäufer ohne Termin im Kalender, und Desk Research, der nur zeigt, dass der Markt auf Papier existiert. Trends und Reports liefern Kontext; sie ersetzen kein Verhalten in Ihrem Segment.

Was Problem-Validierung nicht beweist

Auch eine solide Problem-Validierung lässt Lücken. Sie zeigt nicht, dass Ihr Funktionsumfang gewinnt, dass Fremde Ihren Preis zahlen, dass Akquise funktioniert oder dass Sie bauen und betreiben können innerhalb Ihrer Mittel. Sie schützt die Idee nicht: Ideen als solche sind in der Schweiz nicht schützbar, nur Ausführung und Marke (IGE: Können Ideen geschützt werden?).

Ein erfundenes Beispiel: Lieferscheine in einem KMU

Ein erfundenes Beispiel: Eine Gründerin adressiert Office-Managerinnen in Betrieben mit 20–80 Mitarbeitenden in der Deutschschweiz. Die Annahme: fehlende Lieferscheine von Lieferanten kosten mehrere Stunden pro Woche und verzögern Rechnungen. Sie interviewt acht Managerinnen, die sie nicht privat kennt. Sechs erzählen dieselbe Schleife: Mail an den Lieferanten, warten, Finanz fragen, intern eskalieren. Vier nutzen eine gemeinsame Tabelle, die jemand vor Jahren gebaut hat. Niemand nennt eine App aus dem Pitch der Gründerin. Zwei sagen, sie würden keinen weiteren Login «nur für Erinnerungen» einführen. Die Gründerin parkt die App und formuliert das Problem neu: «Finanz braucht Liefernachweis vor Freigabe», mit anderem Käufer und schärferem Test. Kein Code; die Widerlegung war «Managerinnen adoptieren kein separates Erinnerungs-Tool».

Wer nachlegen sollte, wer verkürzen kann

Wann das Product Validation Package passt

Das Product Validation Package passt, wenn das Problem real genug wirkt, um es mit deployter Software, bezahlter Akquise und gemessenem Nutzungsverhalten zu testen, nicht wenn Ihnen noch die ersten ehrlichen Interviews fehlen. In den Wochen 1 bis 4 entsteht eine echte App; ab Woche 5 prüfen Sie, ob das Verhalten zum auf Papier validierten Problem passt. Sind Sie noch nicht dort, bleiben Sie in der Discovery, bevor Sie ein Build-Gespräch über die Kontaktseite vereinbaren.