Produkt-MVP für SCIARA: drei Learnings und ein paar Schätze

Im letzten halben Jahr durfte ich an einem wirklich außergewöhnlichen Projekt mitarbeiten. Zusammen mit fünf weiteren mittelständischen IT-Firmen haben wir das MVP für SCIARA gebaut: Die Plattform Sciara ermöglicht es, die sozialen Auswirkungen von Maßnahmen gegen die Klimakrise besser zu erforschen und wird so Entscheider*innen mehr Sicherheit in ihren Entschlüssen geben.

Die MVP Phase, die alle unsere Firmen pro bono unterstützt haben, endet gerade. Ein guter Zeitpunkt, um aufzutauchen und die vergangene Zeit zu reflektieren. Im Moment bemühen wir uns in einer Crowdfunding-Kampagne (auf startnext.de/sciara) darum, das Projekt nahtlos fortsetzen zu können. Und schon aus der MVP-Phase nehme ich drei wichtige Erkenntnisse mit, die ich auch jenseits des konkreten Projekts nützlich finde.

Unterscheide klar zwischen Kunden, Usern und Investoren

Aus vielen Projekten bei großen Konzernen bin ich es gewohnt, immer wieder die User-Fahne hochzuhalten. Unsere Kund*innen – also die Menschen, die bei uns Projekte beauftragen und kundenseitig verantworten – sind in der Regel nicht die User der Produkte, die wir bauen. Der Automatismus, für die Nutzerinnen und Nutzer zu kämpfen ist deshalb bei mir so groß gewesen, dass wir in unserem ersten Pitch bei unseren eigenen Firmen die Kundenperspektive beinahe außer Acht gelassen haben. Wir haben viel darüber nachgedacht, wie SCIARA sich anfühlen muss, damit User gerne wiederkommen und dabei anfangs unsere Kund*innen in Entscheidungspositionen in Konzernen und Parteien etwa aus den Augen verloren. Gerade in der sehr frühen Phase war es aber genauso wichtig, sich zu überlegen, was einen potenziellen Kunden davon überzeugt auch anzubeißen.

Die dritte Gruppe, die die Investoren, in der ersten Phase also Geschäftsführer*innen unserer eigenen Firmen, „ticken“ dann nochmal anders als unsere Kund*innen. Common Sense? Gutes Stakeholder Management? Ja, vielleicht – dennoch glaube ich, dass wir häufig von einer „typischen“ Konstellation geprägt sind und es sich deshalb lohnt, die Balance neu zu betrachten, wenn wir das Spielfeld wechseln. Ich hätte vor diesem Projekt nie gedacht, dass ich mal als Product Owner unseren UXer bremsen muss, weil ein Entwurf zwar großartig für die User ist, die Story für die Kunden aber schlechter macht.

Verstehe Dein Produkt – wirklich.

„Wir bauen eine Plattform, mit der man soziale Experimente in der Klimafolgenforschung durchführen kann, damit Entscheider*innen wirksame Maßnahmen gegen die Klimakrise treffen können.“ Vermutlich braucht es ein paar Zeilen mehr, um die Produktidee wirklich klar zu machen, aber im Kern ist unser Produkt eine Plattform. Oder doch nicht? Eine der wichtigsten Diskussionen in der frühen Projektphase war die Frage: Was bieten wir unseren Kunden wirklich an? Es zeigt sich: Nicht die Plattform ist unser Produkt, sondern Antworten auf Fragen zu sozialen Dynamiken von Klimaschutzmaßnahmen.

Ok, aber ist das nicht Marketing, also wie man das Produkt verkauft? Nein, gerade für die Frage „Was ist das MVP?“ ist diese Antwort essenziell. Denn sie bedeutet, dass unser MVP eben keine coole App oder Plattform alleine sein kann, sondern dass wir zeigen müssen, dass wir Antworten auf relevante Fragestellungen geben können. Das MVP ist eigentlich „das Ergebnis eines ersten sozialen Experiments“.

Erst diese Klarheit hat es uns ermöglicht, ein minimales Set an Features zu finden und überhaupt zu entscheiden, was „gut genug“ für ein MVP ist. Wenn man nicht gerade eine „Plattform für…“ baut, mag es häufig tatsächlich so sein, dass die IT-Lösung selbst das Produkt ist. Besonders dann, wenn Kund*innen und Nutzer*innen auseinanderfallen, lohnt es sich aber zu hinterfragen, ob „die App“ oder „die Plattform“ wirklich selbst das Produkt sind, oder „nur“ ein Mittel, um das wirkliche Produkt zu erbringen.

Verbinde ein gutes Verständnis der Plattform-Aspekte mit einem konkreten Use Case

Wie funktionieren YAGNI (You ain’t gonna need it) und KISS (Keep it small and simple) für eine Plattform (mehr zu beiden gibt es hier)? Puristen würden vermutlich sagen: „Gar nicht – wir bauen die Plattformaspekte dann, wenn wir Dinge zum zweiten oder dritten Mal anfassen“. Sie würden also mit einem dritten Akronym DRY (Don’t repeat yourself) antworten.

Was für klassische Produkte sicher eine gute Strategie ist, hat uns beim Bau der SCIARA Plattform aber vor eine Herausforderung gestellt: Wir wollten mit unserem MVP eine gewisse Flexibilität haben und auch zeigen, schließlich müssen wir Kund*innen davon überzeugen, dass wir auch deren Frage effizient mit SCIARA beantworten können. Gleichzeitig machen jede Verallgemeinerung und jede Konfigurierbarkeit das Produkt und die Entwicklung komplexer und damit langsamer. Unsere MVP-Phase war fest umrissen und jede Abwägung zwischen den verschiedenen Aspekten tat weh.

Der Mittelweg, der für uns schließlich funktioniert hat: Wir haben in vielen Diskussionen ein gutes Verständnis für die grundsätzliche Flexibilität der Plattform entwickelt und gleichzeitig einen sehr konkreten Use Case umgesetzt. In vielen unserer User Stories fand sich daher irgendwo im Vorspann der Satz: „Später wollen wir vermutlich X, Y und Z frei konfigurieren und brauchen Flexibilität für A, B, C.“ Gleichzeitig haben wir anhand des konkreten Use Cases die Akzeptanzkriterien auf das absolute Minimum reduziert. Das hat uns ermöglicht, Konfigurierbarkeit und Plattform-Aspekte „mitzunehmen“, wo es technisch kaum einen Unterschied macht, und „liegenzulassen“, wo es Aufwand oder Komplexität stark erhöht hätte. Auch heute wäre meine persönliche Meinung: „Man kann keine Meta-Systeme bauen“, allerdings würde ich sie jetzt ergänzen um „…, aber es hilft ein gutes Gefühl für die „Meta-Physik“ zu haben“.

Echte Schätze

Die SCIARA MVP-Phase hatte noch viele weitere Schätze für mich parat: Mein erster „echter“ Investoren-Pitch für ein Startup, politikfrei mit sechs Firmen Software bauen oder den Austausch mit den Forscher*innen am Potsdam Institut für Klimafolgenforschung. Aber am Ende ist es die Idee von SCIARA, die mich nach wie vor am meisten antreibt: Mit Software dazu beizutragen, wirksame Maßnahmen gegen die Klimakrise zu entwickeln und vor allem umzusetzen.

Wenn diese Gedanken hier nützlich waren, würde ich mich deshalb über eine Unterstützung unter startnext.de/sciara bis zum 14.2.2021 freuen.

► Im Artikel “Crowdfunding fürs Klima” gibt es mehr Infos zum Projekt.

---

Über den Autor