Inlägget kom dagen före den planerade lanseringen

Den 31 juli publicerade kontot för Google AI Studio ett kort meddelande med tack till de omkring 800 000 människor som hade förbokat bolagets mobilapp på iOS och Android. Meddelandet var ingen lansering. Det var ett inställande. Den fristående appen skulle inte komma alls.

Rapporteringen samma dag lade den tänkta utgivningen till den 1 augusti, vilket placerar beslutet inom de sista tjugofyra timmarna av ett leveransschema. Förbokningarna hade varit öppna i Google Play och App Store sedan bolagets egen utvecklarkonferens I/O tidigare i år, tillräckligt länge för att väldigt många skulle hinna registrera sitt intresse och för att en del organisationer redan skulle ha skrivit in appen i en plan.

Siffror över förbokningar brukar anföras som bevis för att en lansering är säkrad. Den här siffran anfördes i beskedet om att lanseringen ställdes in. Just den omkastningen är det som är värt att behålla.

Google angav skälet, och det var inte produkten

Inställda produkter brukar komma inlindade i ingenting. Den här kom med en förklaring, och förklaringen är ovanligt rak. "I stället för att be dig ladda ned ännu en app har vi bestämt oss för ett helt annat angreppssätt: ett där applikationer uppstår naturligt, i dina vardagliga samtal med Gemini", skrev bolaget. Det samarbetar för detta med teamet bakom Gemini-appen, både på mobil och på skrivbordet.

Läs den första delen igen. Invändningen gäller inte appens kvalitet, dess mognad, dess kostnad eller dess mottagande. Invändningen gäller nedladdningen. I samma meddelande skrev bolaget att det hade blivit tydligt att människor vill bygga programvara i farten, vilket är ett uttryckligt erkännande av att den uppmätta efterfrågan var verklig.

Ordningsföljden är alltså: efterfrågan bekräftad, produkt färdig, lansering inställd. Ingenting i den följden är ett produktmisslyckande. Det är ett beslut om var en funktion ska bo, fattat av dem som äger distributionsytan och inte funktionen.

Den separata ytan är det man ska hålla ögonen på

De flesta inköpare bedömer risken i en leverantörs färdplan med siffror över användning. Använder någon det, växer det, har leverantören bundit sig offentligt. Alla tre är fel mätinstrument, för här var alla tre gröna och inget av dem vägde. Åttahundratusen registreringar är ungefär den högsta efterfrågesignal ett produktteam kan åstadkomma före leverans, och den förlorade.

Instrumentet som hade fungerat är strukturellt och tar en minut. Ställ två frågor om varje leverantörsfunktion du är beroende av. Når den dig genom en egen yta, alltså en egen app, en egen konsol, en egen portal eller en egen rad på fakturan? Och utför den ytan ett arbete som leverantörens huvudprodukt rimligen skulle kunna svälja? Det som svarar ja på båda är kandidat för konsolidering, oavsett hur bra det går just nu.

Detta förutsäger inte att varje sådan funktion försvinner. Det säger vilken risk du faktiskt bär. När en leverantör konsoliderar överlever funktionen oftast och ytan gör det inte, så störningen du ska planera för är inte förlorad funktionalitet. Det är en påtvingad flytt enligt leverantörens tidtabell i stället för din.

Det som överlevde visar var leverantören menar allvar

Webbversionen av AI Studio rördes inte. Google sade sig fortsätta investera i den och riktade den till dem som vill gå från en idé till en instruktion och vidare till en affär. Den inramningen är den användbara halvan av beskedet, eftersom den skiljer de två ytorna åt efter avsikt: den ena är för dem som bygger och den blev kvar, den andra överlappade ett arbete som huvudassistenten redan klarade och den försvann.

För ett team som planerar blir läsningen därmed smalare än "här går det inte att lita på Google". Den lyder att utvecklarytan bar åtagandet och den konsumentnära ytan bar risken. Den som tänkte bygga ett arbetsflöde på mobilappen hade tagit sig oförändrad genom veckan genom att bygga samma flöde mot webbversionen och gränssnitten under den.

För europeiska team finns en punkt till. En funktion som flyttar in i en allmän assistentapp byter inte plats på ett neutralt sätt, eftersom villkoren, administrationsrättigheterna och hanteringen av uppgifter hos en konsumentassistent inte automatiskt är desamma som hos en utvecklarprodukt. När en leverantör aviserar en sådan flytt, begär då den jämförelsen skriftligt innan du planerar runt det nya hemmet, inte efteråt.

Ytan hör hemma i avtalet, inte i färdplanen

Den praktiska förändringen är liten. När en leverantörsfunktion dyker upp i en plan, namnge då leveransytan i det dokument som binder, och inte bara funktionen. "Applikationsbyggande tillgängligt i leverantörens mobilapplikation" och "applikationsbyggande tillgängligt" är olika åtaganden, och bara det ena överlever en konsolidering. Vägrar leverantören namnge ytan är även det svaret information, och det är billigare att få nu.

Kostnaden för att låta bli är inte dramatisk, och därför hoppas den över. Ett team som hade satt 200 000 kronor i intern tid mot ett mobilbygge detta kvartal har varken förlorat funktionen eller pengarna. Det har förlorat tidplanen, och får veta det med en dags varsel genom ett inlägg i ett socialt nätverk i stället för genom en uppsägningstid i ett avtal. Det är en liten, undvikbar och fullständigt upprepbar förlust.