Projekt starten

Etage 01 · Software

MVP-Entwicklung, in Wochen live.

MVP-Entwicklung bedeutet, die schlankste Version Ihres Produkts, das Minimum Viable Product, live zu bringen, für die sich Fremde registrieren und zahlen. yop in Tallinn legt den Umfang mit Ihnen fest, baut in kurzen Zyklen und schaltet live, damit Sie von Kunden lernen statt von Folien.

Umfang kürzen

Was reinkommt, was wartet.

Schieben Sie Funktionen zwischen „Im MVP“ und „Später“. Fünf sind eine gesunde erste Version.

Im MVP 0

Später 0

    Tippen Sie auf eine Funktion, um sie zu verschieben.

    Bereit?

    Ist Ihre Idee bereit für ein MVP?

    Ein MVP lohnt sich, wenn es eine klare Sache zu lernen gibt und jemanden, der sie lernen will. Prüfen Sie beide Listen, bevor Sie einen Workshop buchen.

    Bereit, wenn

    • Sie in einem Satz sagen können, was Nutzer darin tun.
    • Sie die ersten zwanzig Nutzer selbst erreichen.
    • Sie wissen, welche Zahl über Weiter oder Stopp entscheidet.
    • Sie akzeptieren, dass Version eins bewusst klein aussieht.

    Noch nicht, wenn

    • die volle Funktionsliste feststeht und nichts nach „Später“ darf.
    • außerhalb des Teams noch niemand die Idee kennt: Sprechen Sie zuerst mit fünf Käufern.
    • das Startdatum wichtiger ist als das, was Sie daraus lernen.

    Nach Frage kürzen

    Nennen Sie die Frage, der Schnitt folgt.

    Eine erste Version soll eine Frage beantworten. Wählen Sie die Frage und sehen Sie, welche Funktionen es in Version eins schaffen.

    Umfang nach Frage

    Die eine Frage

    Melden sich Leute an?

    Die eine Zahl

    Anteil Besucher mit Anmeldung

    • LandingpageVersion 1
    • AnmeldungVersion 1
    • Die KernaufgabeSpäter
    • KasseSpäter
    • ErinnerungsmailsSpäter
    • NutzungsmessungVersion 1
    • Admin-BereichSpäter
    • Native AppSpäter

    Version eins: 3 von 8 Funktionen

    Typischer Schnitt

    Bewusst klein, echt ab Tag eins.

    Welche Funktionen meist in eine erste Version gehören
    FunktionFunktionIm MVPSpäter
    Registrierung, LoginJa–
    Die eine KernaufgabeJa–
    ZahlungenWenn Sie ab Tag eins kassierenTarife und Rechnungen
    Admin-BereichEinfachAlle Rollen und Berichte
    IntegrationenEine, die zähltDer Rest
    Mobile AppErst responsives WebNative Apps

    Ein MVP entwickeln

    So entsteht ein MVP ohne verlorenes Jahr.

    Ein MVP entsteht so: das eine benennen, was Sie lernen müssen, das Produkt auf die beweisende Aufgabe kürzen und früh zu zahlenden Nutzern bringen.

    v0.1
    01

    Risiko benennen

    Schreiben Sie die eine Annahme auf, an der das Produkt scheitert. Genau sie testet das MVP.

    v0.2
    02

    Umfang kürzen

    Registrierung, Kernaufgabe, Zahlung bleiben. Alles andere kommt später, auch Lieblingsfunktionen.

    v0.3
    03

    Ablauf entwerfen

    Klickbare Ansichten für die Kernaufgabe, getestet von fünf echten Nutzern, bevor Code entsteht.

    v0.4
    04

    Bauen, live gehen

    Kurze Zyklen mit Staging-Link. Version eins geht an echte Nutzer, nicht an einen Demo Day.

    v1.0
    05

    Messen, entscheiden

    Zählen Sie, was Nutzer tun, nicht was sie sagen. Dann nächste Funktion, Kurswechsel oder Stopp.

    Nach dem Launch

    Die ersten Wochen mit echten Nutzern.

    Der Launch ist die Mitte eines MVP, nicht das Ende. So laufen die Wochen danach meist, und das tun Sie und wir jeweils darin.

    Launch-Tag

    Live, keine Demo

    Version eins geht an echte Nutzer, mit Tracking nach DSGVO und einem Weg, Sie im Produkt zu erreichen.

    Woche 1

    Beobachten

    Wir lesen mit Ihnen Registrierungen, Absprünge und die ersten Nachrichten. Noch keine neuen Funktionen.

    Woche 2–3

    Sprechen

    Kurze Gespräche mit Nutzern, die blieben, und solchen, die gingen. Ihre Worte bestimmen die nächste Änderung.

    Woche 4

    Entscheiden

    Nächste Funktion, Kurswechsel oder Stopp, auf Basis der einen Zahl, die Sie am Anfang genannt haben.

    Was Sie bekommen

    Am Ende des MVP.

    Version eins ist mehr als eine App unter einem Link. Diese Teile behalten Sie, egal was die Zahlen sagen.

    Das Live-Produkt

    Echte Software auf Ihrer Domain, für die sich Fremde registrieren, die sie nutzen und, wenn das die Frage ist, bezahlen.

    Code, der wächst

    Ein sauberes Repository in Ihrem Konto, so gebaut, dass neue Funktionen darauf aufsetzen statt daneben.

    Die Zahl, gemessen

    Die eine Kennzahl, die Sie gewählt haben, gezählt ab dem ersten Besucher, mit den Events dahinter.

    Lernnotizen

    Was Nutzer getan und gesagt haben und was uns überrascht hat, aufgeschrieben für Ihr Team und Ihre Investoren.

    Nächste Schritte

    Die Funktionen, die warten mussten, sortiert nach echtem Nutzerwunsch.

    Typische Fallen

    MVP-Tipps, die wir nicht teilen.

    Oft hören wir

    „Erst perfekt, dann zeigen.“

    Was wir sehen

    Feinschliff kostet Wochen und lehrt nichts. Nutzer verzeihen eine schlichte Ansicht, doch sie gehen, wenn die Kernaufgabe hakt.

    Oft hören wir

    „Ein MVP ist ein billiger Prototyp.“

    Was wir sehen

    Ein Prototyp zeigt eine Idee. Ein MVP ist echte Software, die Menschen nutzen, so gebaut, dass der Code wachsen kann, wenn die Antwort Ja lautet.

    Oft hören wir

    „Mehr Funktionen, mehr Chancen.“

    Was wir sehen

    Jede zusätzliche Funktion verwischt das Ergebnis. Mit einer Kernaufgabe wissen Sie genau, wofür Nutzer kamen oder warum sie gingen.

    Ihre erste Version

    Umfang kürzen, den Kern liefern.

    Bringen Sie die Idee mit. Wir entscheiden mit Ihnen, was in Version eins kommt und was warten kann.

    Fragen

    Bevor Sie eine Zeile Code schreiben.

    Wie lange dauert ein MVP?

    Die meisten ersten Versionen, die wir zuschneiden, passen in wenige Wochen Bauzeit. Die genaue Zahl ergibt sich aus dem Analyse-Workshop, nicht aus einer Vorlage.

    Ein MVP (Minimum Viable Product) ist echte Software, für die sich echte Nutzer registrieren und die sie nutzen. Ein Prototyp zeigt dagegen nur eine Idee.

    Ein Team, weil es den ganzen Weg verantwortet: Umfang, Design, Code, Launch und die Daten für die nächste Entscheidung. Bei yop führt dasselbe kleine Team vom Entwurf bis zum Launch, so fällt nichts zwischen mehrere Freelancer.

    Das hängt von der Kernaufgabe und den nötigen Integrationen ab. Nach einem Analyse-Workshop nennen wir einen Festpreis für die erste Version, das Budget steht also vor Baubeginn fest.

    Registrierung, die eine Kernaufgabe und eine Messung, ob Menschen sie nutzen, dazu die Zahlung, wenn genau das die Frage ist. Alles andere wartet, bis Nutzer zeigen, welche Funktion sie als Nächstes brauchen.

    Wir lesen die Zahlen mit Ihnen und wählen einen von drei Wegen: nächste Funktion, Kurswechsel oder Stopp, bevor mehr Geld fließt. Funktioniert die Idee, wächst der MVP-Code meist zum vollen Produkt, statt weggeworfen zu werden.

    Ja, aber eine responsive Web-App ist meist schneller gebaut und geändert und braucht keine Store-Prüfung. Mit der App-Entwicklung starten wir nativ, wenn die Hauptaufgabe am Handy selbst hängt: Kamera, Standort oder Arbeit ohne Netz.