In der Entstehungsphase eines Produktes ist die Chance sehr hoch sich zu verzetteln. Man hat so unglaublich viele Ideen und möchte diese alle am Liebsten direkt umsetzen.
Jedoch kollidiert das nun mit der Realität und den natur-gegebenen Einschränkungen (ausgeborgt vom guten alten Projektmanagement Iron Triangle): Budget, Time, Scope
Je mehr Zeitdruck herrscht, gibt es meiner nach zwei grundlegende Ausprägungen:
- schnell, teuer und viel
- schnell, billig und wenig
(wenn du schnell, billig und viel erreichst, dann hast du einiges richtig gemacht. Vielleicht bist du ja auf dem besten Weg zum 🦄)
Je nach dem mit welchen Mitteln du ausgestattet bist, kannst du schnell und teuer gewährleisten. Die meisten jedoch müssen jeden Euro zweimal umdrehen - daher geht oft nur schnell. Wenn man nun schnell eine gutes (ich meine gut genug) Produkt entwickeln möchte, sollte man sich einige Gedanken machen um das "schlecht" wegzubekommen.
Die UX Research oder QA Abteilung gibt es in den meisten Fällen zu Beginn deines Start-ups noch gar nicht. Das ist auch ok so. Du musst dir auch im Klaren sein, dass du deine erste Produktiteration (let's call it MVP) nach erfolgreichem Test (Markttest mit Kunden aka Problem-Solution Fit) auch komplett wegwirfst.
Im Zuge der Produktentwicklung gibt es etliche Methoden sich zu behelfen um zu erkennen wo man zuerst anpackt. Ich persönlich finde den Ansatz des "Value Proposition Design" sehr hilfreich. (siehe auch Osterwalder und Co.). Und ja, es gibt tausend Methoden um Hypothesen zu entwickeln, Nutzer zu befragen, Prioritäten zu definieren - finde den Ansatz der für dich und dein Team am einfachsten ist. Auch das wird sich über den Lebenszyklus deiner Firma hinweg weiterentwickeln und verbessern.
Noch ein kurzer Abstecher zu "Outcome vs. Output":
Das ist zwar ggf. erst später relevant für deine Produktentwicklung, jedoch solltest du auch darauf von Beginn an ein Auge drauf haben. Die schnellste Velocity (=Geschwindikeit in der dein Team die Features durchpeitscht) ist nicht immer der richtige Maßstab. Je mehr Output getrieben du bist (z.B. ein Shareholder sitzt dir im Nacken) um so höher ist das Risiko, dass du den Outcome aus den Augen verlierst. Der Outcome beschreibt wie nützlich deine Features für deine Kunden WIRKLICH sind und welches Problem damit gelöst wird.
Es ist auch etwas schwieriger Outcome-getrieben zu arbeiten (hier kommt wieder deine Vision ins Spiel). Den Schulterschluss zwischen Vision - Produkt - Daten wirst du spätestens jetzt angehen (müssen).
Ein Beispiel:
Du beschreibst mit der Vision, wo die große Reise hingeht.
Mit dem Outcome (im weitesten Sinne das Feature bzw. Featurebundle) beschreibst du, was dein Nutzer für einen Mehrwert erhält bzw. welches Kundenproblem gelöst wird.
Folglich: Was hat dein Kunde für einen Pain, was ist dein Pain Killer (aka Pain Reliever) und wie findet sich das ganze in deiner USP wieder.
Dann definierst du deine Metriken (Achtung: Keine schöngefärbten Shareholder Metriken, die dir in der Produktentwicklung ohnehin nicht weiterhelfen aka Vanity Metrics)
Ganz nach dem Leitsatz: Focus on the pain killer, not the vitamins!
Was ist meiner Meinung nach ein echter MVP:
Immer mit dem einfachsten beginnen, egal wo die Reise hingeht (was ist dein echter und wahrer Pain Killer). Technischen Schnickschnack später optimieren. Zuerst muss das Produkt im Minimum funktionieren (harte Priorisierung und die zugrundeliegenden Daten) bevor die beste Plattform gebaut werden soll.
Kling einfach, ist es aber nicht :)
Stay tuned ...there is more to come
Kommentare
Kommentar veröffentlichen