800.000 forudbestillinger købte ingen lancering

Opslaget kom dagen før den planlagte lancering

Den 31. juli lagde kontoen for Google AI Studio en kort besked op med tak til de omkring 800.000 mennesker, der havde forudbestilt selskabets mobilapp på iOS og Android. Beskeden var ikke en lancering. Den var en aflysning. Den selvstændige app ville slet ikke udkomme.

Omtale fra samme dag placerede den planlagte udgivelse den 1. august, hvilket lægger beslutningen inden for de sidste fireogtyve timer af en leveringsplan. Forudbestillingerne havde været åbne i Google Play og App Store siden selskabets egen udviklerkonference I/O tidligere på året, længe nok til, at rigtig mange kunne registrere deres interesse, og til at nogle organisationer allerede havde skrevet den app ind i en plan.

Tal for forudbestillinger bliver normalt nævnt som bevis på, at en lancering er sikker. Dette tal blev nævnt i beskeden om, at lanceringen var aflyst. Netop den ombytning er den del, man skal huske.

Google nævnte grunden, og det var ikke produktet

Aflysninger kommer sædvanligvis pakket ind i ingenting. Denne kom med en forklaring, og forklaringen er usædvanligt direkte. "I stedet for at bede dig om at hente endnu en app har vi besluttet at vælge en helt anden tilgang: en, hvor applikationer opstår naturligt i løbet af dine daglige samtaler med Gemini", skrev selskabet. Det samarbejder om det med holdet bag Gemini-appen, både på mobil og på skrivebordet.

Læs første led igen. Indvendingen retter sig ikke mod appens kvalitet, dens modenhed, dens omkostning eller dens modtagelse. Indvendingen retter sig mod hentningen. I samme besked skrev selskabet, at det var blevet tydeligt, at folk gerne vil bygge software, mens de er på farten, hvilket er en udtrykkelig anerkendelse af, at den målte efterspørgsel var virkelig.

Rækkefølgen er altså: efterspørgsel bekræftet, produkt færdigt, lancering aflyst. Intet i den rækkefølge er en produktfejl. Det er en beslutning om, hvor en funktion skal bo, truffet af dem, der ejer distributionsfladen og ikke funktionen.

Den separate flade er det, man skal holde øje med

De fleste indkøbere måler risikoen ved en leverandørs køreplan på tal for udbredelse. Bruger nogen det, vokser det, har leverandøren bundet sig offentligt. Alle tre er forkerte måleinstrumenter, for her var alle tre grønne, og ingen af dem talte. Otte hundrede tusind tilmeldinger er omtrent det højeste efterspørgselssignal, et produkthold kan frembringe før levering, og det tabte.

Det instrument, der ville have virket, er strukturelt og tager et minut. Stil to spørgsmål til enhver leverandørfunktion, du afhænger af. Når den dig gennem sin egen flade, altså sin egen app, sin egen konsol, sin egen portal eller sin egen linje på fakturaen? Og løser den flade en opgave, som leverandørens hovedprodukt sandsynligvis kunne optage? Det, der svarer ja til begge, er kandidat til konsolidering, uanset hvor godt det går lige nu.

Det er ikke en forudsigelse om, at enhver sådan funktion forsvinder. Det er en måde at sige, hvilken risiko du faktisk bærer. Når en leverandør konsoliderer, overlever funktionen som regel, og fladen gør ikke, så den forstyrrelse, du skal planlægge efter, er ikke tab af funktionalitet. Det er en tvungen migrering efter leverandørens tidsplan i stedet for din.

Det, der overlevede, viser, hvor leverandøren mener det

Webudgaven af AI Studio blev ikke rørt. Google sagde, at man fortsat investerer i den, og placerede den til dem, der vil gå fra en idé til en instruktion og videre til en forretning. Den indramning er den brugbare halvdel af meddelelsen, for den adskiller de to flader efter hensigt: den ene er til dem, der bygger, og den blev, den anden overlappede en opgave, hovedassistenten allerede kunne løse, og den forsvandt.

For et hold, der planlægger, er læsningen derfor snævrere end "her kan man ikke regne med Google". Den er, at udviklerfladen bar tilsagnet, og den forbrugernære flade bar risikoen. Den, der ville bygge et arbejdsforløb på mobilappen, ville være kommet uændret gennem ugen ved at bygge det samme forløb på webudgaven og de grænseflader, der ligger under.

For europæiske hold er der et yderligere punkt. En funktion, der flytter ind i en generel assistentapp, skifter ikke sted på neutral vis, for vilkårene, administrationsrettighederne og databehandlingen hos en forbrugerassistent er ikke automatisk dem, der gælder for et udviklerprodukt. Når en leverandør varsler sådan en flytning, så bed om den sammenligning skriftligt, før du planlægger omkring det nye hjem, og ikke bagefter.

Fladen hører i kontrakten, ikke i køreplanen

Den praktiske ændring er lille. Når en leverandørfunktion dukker op i en plan, så navngiv leveringsfladen i det dokument, der binder, og ikke kun funktionen. "Applikationsbygning tilgængelig i leverandørens mobilapplikation" og "applikationsbygning tilgængelig" er forskellige tilsagn, og kun det ene overlever en konsolidering. Nægter leverandøren at navngive fladen, er det svar også information, og det er billigere at få nu.

Omkostningen ved at lade være er ikke dramatisk, og derfor bliver det sprunget over. Et hold, der havde sat 150.000 kroner af intern tid op mod en mobil opbygning i dette kvartal, har hverken mistet funktionen eller pengene. Det har mistet tidsplanen, og det får det at vide med en dags varsel fra et opslag på et socialt netværk i stedet for med et varsel fra en kontrakt. Det er et lille, undgåeligt og fuldstændigt gentageligt tab.

Læs videre: Bruxelles har netop prissat Googles søgedata  |  Chipaktier faldt 20%. Prisen på regnekraft ikke