Der Beitrag erschien einen Tag vor dem geplanten Start
Am 31. Juli veröffentlichte das Konto von Google AI Studio eine kurze Nachricht und bedankte sich bei den rund 800.000 Menschen, die die mobile App für iOS und Android vorbestellt hatten. Diese Nachricht war keine Ankündigung eines Starts. Sie war eine Absage. Die eigenständige App würde überhaupt nicht erscheinen.
Berichte vom selben Tag setzten den vorgesehenen Start auf den 1. August an, womit die Entscheidung in die letzten vierundzwanzig Stunden eines Auslieferungsplans fällt. Die Vorbestellungen liefen seit der hauseigenen Entwicklerkonferenz I/O in diesem Jahr über Google Play und den App Store, lange genug, dass sehr viele Menschen ihr Interesse hinterlegen konnten und manche Unternehmen diese App bereits in eine Planung geschrieben hatten.
Vorbestellungszahlen werden üblicherweise als Beleg dafür angeführt, dass ein Start sicher ist. Diese Zahl stand in der Mitteilung, dass der Start abgesagt wird. Genau diese Umkehrung ist der Teil, den man behalten sollte.
Google nannte den Grund, und es war nicht das Produkt
Absagen kommen normalerweise ohne jede Erklärung. Diese kam mit einer, und die Erklärung ist ungewöhnlich direkt. "Anstatt Sie zu bitten, noch eine weitere App herunterzuladen, haben wir uns für einen völlig anderen Ansatz entschieden: einen, bei dem Anwendungen ganz natürlich im Verlauf Ihrer alltäglichen Gespräche mit Gemini entstehen", schrieb das Unternehmen. Es arbeitet dafür mit dem Team der Gemini-App zusammen, auf Mobilgeräten und auf dem Desktop.
Lesen Sie den ersten Halbsatz noch einmal. Der Einwand richtet sich nicht gegen die Qualität der App, ihre Reife, ihre Kosten oder ihre Aufnahme. Der Einwand richtet sich gegen den Download. In derselben Nachricht hieß es, es sei deutlich geworden, dass Menschen unterwegs Software bauen möchten, was ein ausdrückliches Eingeständnis ist, dass die gemessene Nachfrage echt war.
Die Abfolge lautet also: Nachfrage bestätigt, Produkt fertig, Start gestrichen. Nichts an dieser Abfolge ist ein Produktversagen. Es ist eine Entscheidung darüber, wo eine Fähigkeit wohnen soll, getroffen von Menschen, denen die Vertriebsoberfläche gehört und nicht die Funktion.
Auf die eigene Oberfläche kommt es an
Die meisten Einkäufer bewerten das Risiko einer Anbieter-Roadmap mit Nutzungszahlen. Verwendet es jemand, wächst es, hat sich der Anbieter öffentlich dazu bekannt. Alle drei sind die falschen Messgeräte, denn hier fielen alle drei positiv aus und keines davon zählte. Achthunderttausend Registrierungen sind ungefähr das lauteste Nachfragesignal, das ein Produktteam vor der Auslieferung erzeugen kann, und es verlor.
Das Messgerät, das funktioniert hätte, ist strukturell und in einer Minute angelegt. Stellen Sie zu jeder Anbieterfunktion, von der Sie abhängen, zwei Fragen. Erreicht sie Sie über eine eigene Oberfläche, also eine eigene App, eine eigene Konsole, ein eigenes Portal oder eine eigene Position auf der Rechnung? Und erledigt diese Oberfläche eine Aufgabe, die das Hauptprodukt des Anbieters plausibel übernehmen könnte? Was beide Fragen mit Ja beantwortet, ist ein Kandidat für Konsolidierung, unabhängig davon, wie gut es gerade läuft.
Das ist keine Vorhersage, dass jede solche Funktion verschwindet. Es ist eine Aussage darüber, welches Risiko Sie tatsächlich tragen. Wenn ein Anbieter konsolidiert, überlebt die Fähigkeit meist und die Oberfläche nicht. Die Störung, für die Sie planen müssen, ist also nicht der Verlust einer Funktion. Es ist eine erzwungene Umstellung nach dem Zeitplan des Anbieters statt nach Ihrem.
Was überlebt hat, zeigt, wo der Anbieter es ernst meint
Die Webversion von AI Studio blieb unangetastet. Google erklärte, weiter in sie zu investieren, und richtete sie an Menschen aus, die von einer Idee über eine Eingabe bis zu einem Geschäft kommen wollen. Diese Einordnung ist die nützliche Hälfte der Ankündigung, denn sie trennt die beiden Oberflächen nach Absicht: Eine ist für Entwickler und blieb, eine überschnitt sich mit einer Aufgabe, die der Assistent des Hauses ohnehin erledigen konnte, und ging.
Für ein planendes Team lautet die Lesart deshalb enger als "auf Google ist hier kein Verlass". Sie lautet: Die Entwickleroberfläche trug die Zusage, die verbrauchernahe Oberfläche trug das Risiko. Wer einen Arbeitsablauf auf der mobilen App bauen wollte, hätte denselben Ablauf gegen die Webversion und die darunterliegenden Schnittstellen gebaut unverändert durch die Woche gebracht.
Für europäische Teams gibt es einen zusätzlichen Punkt. Eine Fähigkeit, die in eine allgemeine Assistenz-App wandert, wechselt nicht neutral den Ort, denn die Bedingungen, die Verwaltungsrechte und der Umgang mit Daten eines verbrauchernahen Assistenten sind nicht automatisch dieselben wie bei einem Entwicklerprodukt. Wenn ein Anbieter einen solchen Umzug ankündigt, fordern Sie diesen Vergleich schriftlich an, bevor Sie um das neue Zuhause herum planen, und nicht danach.
Die Oberfläche gehört in den Vertrag, nicht auf die Folie
Die praktische Änderung ist klein. Wenn eine Anbieterfunktion in einer Planung auftaucht, benennen Sie die Auslieferungsoberfläche in dem Dokument, das bindet, und nicht nur die Fähigkeit. "Anwendungsentwicklung verfügbar in der mobilen Anwendung des Anbieters" und "Anwendungsentwicklung verfügbar" sind unterschiedliche Zusagen, und nur eine davon übersteht eine Konsolidierung. Weigert sich der Anbieter, die Oberfläche zu benennen, ist auch diese Antwort eine Information, und sie ist jetzt billiger zu haben.
Die Kosten des Unterlassens sind unspektakulär, weshalb es übersprungen wird. Ein Team, das in diesem Quartal 20.000 Euro interne Arbeitszeit gegen einen mobilen Aufbau gestellt hatte, hat weder die Fähigkeit noch das Geld verloren. Es hat den Zeitplan verloren, und es erfährt davon mit einem Tag Vorlauf aus einem Beitrag in einem sozialen Netzwerk statt mit einer Frist aus einem Vertrag. Das ist ein kleiner, vermeidbarer und beliebig wiederholbarer Verlust.
Weiterlesen: Brüssel hat Googles Suchdaten gerade bepreist | Chipaktien fielen 20%. Ihre Rechenkosten nicht



