Bye-Bye Wave – Google stellt Entwicklung ein

Ich nutze Wave, ich mag Wave, ich mag Wave so sehr, dass es im Blog sogar eine eigne Wave Kategorie gibt,  ich mag Wave sogar so sehr, dass ich den ein oder anderen dazu gezwungen habe (und das in 2-3 Fällen erfolgreich) Wave zu nutzen.

Und jetzt ist bald Ebbe am digital beach, denn Google stellt die Entwicklung von Wave ein – wahrscheinlich eine logische Konsequenz aus hohen Erwartungen und wenig Akzeptanz des Produkts, dass Mail 2.0 sein sollte.

Auf Mashable.com hat Christina Warren einen sinnvollen Artikel geschrieben über das was man aus dem Fehlschlag Wave lernen kann. Spannend finde ich v..a. das Google hier einige Sachen angekreidet werden, die man eigentlich zu den Basics von Projekt- und Produktmanagement zählen sollte, aber trotzdem sind sie verrissen worden.

Und was ich noch viel spannender finde – ich selber habe (natürlich auf viel kleinerer Flamme) vergleichbare Fehler gemacht und befürchte werde sie auch in Zukunft wieder machen. Also schauen wir uns Christinas Kritik an :

1. Erwartungmanagement

Ganz zentrales Thema in jedem Projekt – wird leider oft nicht so sehr beachtet:  Erwartungshaltung meiner Kunden.

Bei Google Wave ist es ein Problem gewesen, dass sich schon vor der ersten Live-Tests große Erwartungen aufgebaut haben, denn hey, wenn was neues von Google kommt, dann ist das meist gut. Und dann auch noch von den Leuten, die maßgeblich an Google Maps mitgewirkt haben. Und schwupps haben aller wunderweiss was erwartet

Ich ehrlich gesagt nicht, weil die frühen Wave Infos an mir vorbeigegangen sind, ich dass erst mit der Keynote wahrgenommen habe und wave dann mit dem developer test relativ zeitnah in Aktion gesehen habe.

Aber auch da waren meine Erwartungen extrem hoch, weil mir mehrere Leute mit IT / Progger Hintergrund mit glänzenden Augen von den Features berichtet haben und weil so ein closed Beta nur für Entwickler natürlich Begehrlichkeiten weckt. Und solche Begehrlichkeiten können ein tolles Marketingtool sein um Nachfrage anzukurbeln – siehe Apple und das ipad.

Ganz elementare Lektion – Feuer und Flamme sein für eine Idee ist eine feine Sache ABER am Ende des Tages müssen Erwartungen erfüllt werden und Versprechen gehalten werden, daher ist es oft besser den Ball flach zu halten statt das gaaaanz große Bild zu malen.

Und auch gaaaanz wichtig: Erwartungsmanagement heißt v.a. Abgleichen was du dem Kunden anbietest und was der Kunde glaubt von dir zu bekommen. Stichwort Kommunikation entsteht beim Empfänger.

Für ein Projekt heißt das aus meiner Sicht in der Praxis, dass im Idealfall schriftlich festgehalten wird:

• was du anbietest (und was eben auch nicht, was optional ist oder wo nach Aufwand abgerechnet wird)
• was die Leistung kostet
• bis wann sie erbracht wird
• welche Mitwirkung von Kunden zu erbringen ist

2. Definition von Nutzen für den Kunden

Wave war alles und gar nichts zugleich. Will sagen der User konnte theoretisch alles mögliche damit machen, aber so richtig konkrete Fälle für Anwendungen waren selten definiert.  (Erinnere ich mich an die Keynote, dann war es doch v.a. der Technikaspekt der im Vordergrund stand – woaah Echtzeit, woah online Kollaboration, die Anwendungsfälle waren eher seichte Sachen wie Abendplanung über 5 Leute hinweg)

Und wenn etwas alles und garnichts ist, dann wird der User es im Zweifel als garnichts wahrnehmen weil der konkrete Nutzen nicht erkennbar ist.

Wenn man Bock hatte auf Wave und so wie ich auch ein paar Leute gefunden hat, denen das ähnlich ging UND mit denen man gemeinsame Projekte hatte (schon unwahrscheinlich, dass die Konstellation oft auftaucht), dann gab man Wave ne Chance und hat sich rangetastet an die Funktionen.

War aber auch viel Trial-and-Error dabei, Inhalte waren unübersichtlich, Email Kommunikation lief parallel und schwupps war der Pflegeaufwand  / Koordinationsbedarf sogar größer als vorher. Nach ein paar Wochen gab es ein paar Sachen die mal echt gut gelaufen waren, weil wir die Geduld hatten und  eben auch die Auswahl an 3-4 Projekten (gleichzeitig liefen auch 2-3 andere garnicht weil Beteiligte keinen Bock auf Wave hatten)

Unsere hohen Erwartungen und das Trara traffen also ein diffuses “mmmmh mal gucken was das so kann”.

Was lernt uns das? Dem Kunden einfach und klar zeigen was vorher ein Problem war (vielleicht garnicht so extrem wahrgenommen) und jetzt durch uns besser wird. Das ist glaube ich gerade dann wichtig, wenn man ein (sei es auch nur für den Kunden) völlig neuartiges Produkt anbietet. “Das ist mein Produkt und das bringt es dir”, klingt auch total simpel. Klingt wieder erschreckend simpel, aber auch da macht klares aufzeigen das Leben leichter für alle. V.a. wenn es hier schon gelingt wieder zu verdeutlichen wie Nutzen und Erwartungen ineinander greifen und man für den angepeilten Nutzen auch eindeutige Zielgrößen festlegt, die hinterher Erfolge bewertbar machen.

3. Test und Livegang

Der Klassiker : “lass uns mal so mit ner final beta eher softlaunchen”. Das wäre die positive Formulierung. Negativ formuliert: deine Anwendung ist buggy obwohl du schon im Livebetrieb bist.

Oft genug schwierig hier abzuwägen zwischen “jetzt müssen wir aber auch mal die echten User ranlassen” zu “mmmh, das eine Feature würde uns noch gut tun”, ganz karl sind die Grenzen vermutlich nicht aber permanente Fehler im Livebetrieb – ärgerlich und Kunden die man so verliert kommen nie wieder und sorgen im Zweifel dafür, dass andere erst garnicht kommen.

Also was tun? Testen bis zur Perfektion? Klingt gut ist aber nicht realistisch. Ist sicher auch eine Frage was das Projekt so können soll – hab ich überhaupt Zeit und Geld für langes testen oder geht es um einen Testballon, der im Feld klären soll, ob Potential für mehr da  ist. Generell bin ich ja inzwischen Fan von schnell und schmutzig – nur zu schmutzig darf es nicht sein zumindest nicht in der Außenwirkung.

Und wenn man – so wie Google – hohe Erwartungen geschürt hat und einen Ruf zu verlieren hat, dann muss der Umfang der Funktionen die stabil sind schon höher ausfallen auch wenn es Raketentechnik ist und die Nutzer einem die Bude einrennen.