--- title: "MVP-Pivot oder Nutzerführung ändern? Der Fall Offlinery" canonical: https://wavect.io/de/blog/mvp-pivot-or-change-user-flow/ language: de description: "MVP-Pivot oder kleinerer Eingriff? Kevin Riedl zeigt am Kundenprojekt Offlinery, wie ein Produktteam Nutzerfeedback auf eine konkrete Entscheidung zurückführt." image: "https://wavect.io/img/blog/headers/header_mvp-pivot-or-change-user-flow.png" author: ["Kevin Riedl"] published: "2026-11-11" updated: "2026-11-11" reviewed: "2026-11-11" --- # MVP-Pivot oder anderer Ablauf? Was Offlinerys Nutzer uns zeigten [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 4 Min Lesezeit · 11. November 2026 Zuletzt geprüft 11. November 2026 [**Weiter**](/de/blog/product-factory-kills/) TL;DR Bei Offlinery wollten manche Nutzer das spontane Treffen, schrieben sich aber zuerst. Gemeinsam mit unserem Kunden ließen wir deshalb die Person, die angesprochen werden wollte, über den ersten Schritt entscheiden. Für Produktteams vor einem Pivot lohnt sich dieselbe Frage: Welchen Teil der ursprünglichen Annahme stellt das beobachtete Verhalten tatsächlich infrage? Die Nutzer taten fast genau das, was wir mit unserem Kunden erwartet hatten. Zwei Menschen waren in der Nähe, ein Match kam zustande, manche verabredeten sich spontan auf einen Kaffee. Das kleine Wort „fast“ beschäftigte uns. Zwischen der Benachrichtigung und dem persönlichen Kontakt lag bei einigen ein Schritt, der in der ursprünglichen Idee kaum Platz hatte. Sie schrieben sich zuerst. Offlinery war das Produkt unseres Kunden. Wir bei Wavect unterstützten ihn bei der Produktentscheidung und der Umsetzung. Vor dem Bau hatten wir mit dem Kunden eigene Marktforschung betrieben und vorhandene Quellen ausgewertet. Die Ergebnisse sprachen aus unserer Sicht dafür, dass sich ein Teil der Befragten wieder persönliche Begegnungen im Alltag wünschte. Ob dieselben Menschen nach einem Hinweis auf dem Handy sofort auf jemanden zugehen würden, war eine eigene Annahme. Die Produktidee ist im [öffentlichen Offlinery-Repository](https://github.com/wavect/offlinery) dokumentiert. ## Was sagte ein Match im Umkreis von 25 Metern aus? Ein Match gab dir einen Hinweis, den ein Blick allein kaum liefern kann. Da war jemand in deiner Nähe, der grundsätzlich angesprochen werden wollte. Unsere Ausgangsthese war, dass Frauen, die sich im Alltag eine persönliche Ansprache durch Männer wünschten, dieses Interesse gern signalisieren würden. In den [ursprünglichen Einstellungen](https://github.com/wavect/offlinery/blob/681716145e03f268be24f1828b33441b842d828d/mobile/localization/en.ts#L91-L105) konnte man wählen, ob man selbst auf jemanden zugehen, angesprochen werden oder beides wollte. Auch die Uhrzeiten ließen sich eingrenzen. Die Benachrichtigung kam nach meiner Erinnerung erst, wenn die andere Person höchstens 25 Meter entfernt war. Da konnte man einander unter Umständen schon sehen. Eine Frage war trotzdem offen. Passt es ihr *gerade jetzt*, wenn ich rübergehe? Manche holten sich diese Antwort lieber direkt bei der Person. ## Wer entschied, ob vorher eine Nachricht möglich war? Zusammen mit dem Kunden entschieden wir uns für eine Einstellung. Die Person, die angesprochen werden wollte, bestimmte selbst, ob andere ihr vorher schreiben konnten. Für die einen war gerade das spontane Hallo der Reiz an Offlinery. Für andere gehörte zum selben Treffen, vorher kurz gefragt zu werden. Beides ließ sich mit einer Einstellung abbilden. | Was ich mir wünsche | Vor dem Ansprechen | Nach dem Kennenlernen | | --- | --- | --- | | Sprich mich direkt an | Nachrichten ließen sich ausschalten. Der erste Kontakt fand persönlich statt. | Wer sich getroffen hatte, konnte einander schreiben. | | Schreib mir vorher kurz | Vor dem Ansprechen waren ein, zwei Nachrichten möglich. | Man konnte an die persönliche Begegnung anknüpfen. | Wofür eine Nachricht *nachher* gut war, erklärte schon die [Einführung zur Begegnungsansicht](https://github.com/wavect/offlinery/blob/681716145e03f268be24f1828b33441b842d828d/mobile/localization/en.ts#L365-L370). Wer beim Abschied vergessen hatte, die eigene Nummer weiterzugeben, konnte sie nachreichen. Die ein, zwei Nachrichten *vorher* hatten einen anderen Zweck. Sie sollten den Schritt aufeinander zu erleichtern. ## Was wollten die Leute mit der ersten Nachricht klären? Mit einer Nachricht wie *Passt’s gerade, wenn ich kurz rüberkomme?* lässt sich genau diese Unsicherheit klären. Die Antwort kann den Unterschied machen zwischen jemandem, der aus heiterem Himmel vor dir steht, und jemandem, auf den du dich schon freust. Hätten wir nur gezählt, wie oft die Leute schrieben, wäre uns die entscheidende Beobachtung entgangen. Manche legten direkt danach das Handy weg und trafen sich. Die Rückmeldungen zur Nähe waren gemischt. Einige fanden es unangenehm, dass ein fremder Mensch erfahren konnte, wie nah sie waren. Wer über Offlinery auf andere zugehen wollte, musste ein persönliches Verifizierungsgespräch mit dem Team führen. Nutzer konnten Begegnungen bewerten. Rückmeldungen konnten beeinflussen, wen das System zusammenbrachte, oder Anlass für eine erneute Prüfung bis hin zur Kontosperre geben. Die [damalige Einführung in der App](https://github.com/wavect/offlinery/blob/681716145e03f268be24f1828b33441b842d828d/mobile/localization/en.ts#L313-L322) erklärte diese Vorabprüfung. Auch eine geprüfte Identität ließ offen, ob jemand in diesem Moment angesprochen werden wollte. ## Wann lohnt sich eine Änderung am Ablauf, wann ein Pivot? Ich würde das Team bitten, für die nächste Roadmap-Entscheidung einen konkreten Nutzungsfall zu rekonstruieren. Welches Ergebnis wollte die Person erreichen? Welchen Schritt hat sie selbst eingefügt? Was konnte sie danach tun? Bei Offlinery hat gerade die letzte Frage unsere Entscheidung geprägt. Für einige war der kurze Austausch der Weg zu der persönlichen Begegnung, für die sie die App geöffnet hatten. | Beobachtung im eigenen Produkt | Nächste Entscheidung für das Team | | --- | --- | | Menschen erreichen das versprochene Ergebnis über einen Umweg. | Finde heraus, welche Unsicherheit der zusätzliche Schritt ausräumt. Teste die kleinste Änderung, die diesen Schritt erleichtert. | | Derselbe Schritt hilft einer Gruppe und stört eine andere. | Prüfe, ob die betroffene Person selbst wählen kann. Bei Offlinery entschied das Gegenüber, wie der Erstkontakt aussehen durfte. | | Auch bei einem leichten Einstieg verfolgen die Kunden dauerhaft ein anderes Ziel. | Prüfe die ursprüngliche Problemannahme erneut, bevor du das nächste Entwicklungsbudget für denselben Ablauf freigibst. | Im Kundengespräch würde ich ein frühes „Das würde ich nutzen“ wieder aufgreifen und nach dem letzten tatsächlichen Versuch fragen. Für welche Lösung hat die Person schon Zeit aufgewendet oder Geld ausgegeben? Solche Fragen gehören in die [Discovery-Phase eines Softwareprojekts](/de/software-development-guide/what-is-a-discovery-phase/). Wie man daraus eine Entscheidung für die Roadmap macht, beschreiben wir im [Beitrag über Feature-Fabriken](/de/blog/product-factory-kills/). ## Woran würde ich heute erkennen, ob die Nachricht geholfen hat? Ich würde bei beiden Beteiligten freiwillig und getrennt nachfragen, ob sie tatsächlich miteinander gesprochen haben und ob die Ansprache willkommen war. Ausgangspunkt wäre das Match in der Nähe. Würde ich erst ab der ersten Nachricht zählen, fielen alle aus der Auswertung, die sich für die Direktansprache entschieden hatten. Eine ausgebliebene Antwort auf die Nachfrage würde ich gesondert erfassen. Sie kann auch von jemandem kommen, der ein schönes Treffen hatte. Außerdem wählen die Leute ihren Modus selbst. Selbst wenn in einer Gruppe mehr Treffen zustande kämen, könnte das an den unterschiedlichen Vorlieben liegen. Für Offlinery haben wir keine Vorher-nachher-Zahl zu den Treffen, die wir hier veröffentlichen können. Wie die Benachrichtigung auf einem gesperrten Handy ankam, solange die Leute überhaupt noch in der Nähe waren, steht in unserer [technischen Fallstudie zu Offlinery](/de/case-studies/offlinery/). Steht ein Pivot zur Entscheidung, bring einen aktuellen Nutzungsfall in eine [Software-Discovery](/de/services/software-discovery/) mit. Wenn du die strittige Stelle schon kennst, [schildere uns den konkreten Ablauf](/de/contact/?intent=software-dev). ## Häufige Fragen zur Produktentscheidung ### Wie unterscheide ich ein Problem im Ablauf von einem falschen Produktversprechen? Schau dir an, was nach dem unerwarteten Schritt passiert. Erreichen Nutzer so weiterhin das Ergebnis, für das sie gekommen sind, hast du einen konkreten Ablauf zum Testen. Verfolgen sie wiederholt ein anderes Ziel, lohnt sich eine neue Prüfung des Produktversprechens. ### Warum hat Offlinery zwei Wege zum Erstkontakt angeboten? Manche wollten direkt angesprochen werden. Andere wollten sich vorher kurz abstimmen. Die Person, die angesprochen werden wollte, konnte Nachrichten bis nach der Begegnung ausschalten oder vorab ein, zwei Nachrichten zulassen. ### Hat die Änderung mehr persönliche Begegnungen ausgelöst? Wir haben gesehen, dass sich manche nach einem kurzen Austausch spontan trafen. Wie viele zusätzliche Treffen durch die Änderung zustande kamen, können wir aus dieser Beobachtung allein nicht ableiten. ### Wer sollte über eine Einstellung entscheiden, die zwei Personen betrifft? Frag zuerst, wer die Folgen spürt, wenn der Kontakt unerwünscht ist. Bei Offlinery entschied deshalb die Person, die angesprochen werden sollte, ob sie vorab Nachrichten zuließ. ### Was braucht ein Produktteam für ein Discovery-Gespräch? Ein aktueller Fall reicht für den Einstieg. Halte fest, was jemand erreichen wollte, was tatsächlich passiert ist und welche Entscheidung für die nächste Entwicklungsrunde davon abhängt. Produktstrategie ## Weiterlesen Scope, Product-Market-Fit, glaubwürdige Releases und Entscheidungen für nützliche Produkte. [Hier starten**Ein messbarer Weg zum Product-Market-Fit**](/de/blog/road-to-product-market-fit/) - [Bringt KI das Wasserfallmodell zurück? Wie viel Vorabplanung ist sinnvoll?](/de/blog/ai-waterfall-upfront-planning/) - [ChatGPT Search Console: Was der Business Hub für dein Unternehmen bedeuten könnte](/de/blog/chatgpt-search-console-business-hub/) - [Enterprise-Software: Geschäftsregeln klären, bevor KI den Code schreibt](/de/blog/enterprise-business-rule-conflicts/) - [Scope vs. Armature: API-Nutzung durch Agenten statt bloßer Erwähnungen](/de/blog/scope-vs-armature-agent-api-adoption/) - [KI-MVP-Scope: Abnahmekriterien, Eval-Set und SoW](/de/blog/ai-mvp-scope-template/) [Nächster Artikel**Bringt KI das Wasserfallmodell zurück? Wie viel Vorabplanung ist sinnvoll?**](/de/blog/ai-waterfall-upfront-planning/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 4 Min Lesezeit · 11. November 2026 Zuletzt geprüft 11. November 2026 [**Weiter**](/de/blog/product-factory-kills/)