Het bericht kwam de dag voor de geplande lancering

Op 31 juli plaatste het account van Google AI Studio een kort bericht met dank aan de ongeveer 800.000 mensen die de mobiele app voor iOS en Android hadden gereserveerd. Dat bericht kondigde geen lancering aan. Het was een annulering. De zelfstandige app zou helemaal niet verschijnen.

Berichtgeving van diezelfde dag legde de beoogde uitgave op 1 augustus, waarmee de beslissing binnen de laatste vierentwintig uur van een leverschema valt. De reserveringen stonden sinds de eigen ontwikkelaarsconferentie I/O van dit jaar open in Google Play en de App Store, lang genoeg voor zeer veel mensen om hun belangstelling vast te leggen en voor sommige organisaties om die app al in een planning te zetten.

Preordercijfers worden gewoonlijk aangehaald als bewijs dat een lancering veilig is. Dit cijfer werd aangehaald in de mededeling dat de lancering werd geschrapt. Juist die omkering is het deel dat u moet onthouden.

Google noemde de reden, en het was niet het product

Annuleringen komen normaal in nietszeggende verpakking. Deze kwam met een uitleg, en die uitleg is ongewoon direct. "In plaats van u te vragen nog een app te downloaden hebben we besloten een volledig andere aanpak te kiezen: een waarin applicaties vanzelf ontstaan, in de loop van uw dagelijkse gesprekken met Gemini", schreef het bedrijf. Het werkt daarvoor samen met het team van de Gemini-app, op mobiel en op de desktop.

Lees dat eerste deel nog eens. Het bezwaar richt zich niet op de kwaliteit van de app, niet op de rijpheid, niet op de kosten en niet op de ontvangst. Het bezwaar richt zich op de download. In hetzelfde bericht stelde het bedrijf dat duidelijk was geworden dat mensen onderweg software willen bouwen, wat een uitdrukkelijke erkenning is dat de gemeten vraag echt was.

De volgorde is dus: vraag bevestigd, product af, lancering geschrapt. Niets in die volgorde is een productfalen. Het is een besluit over waar een capaciteit hoort te wonen, genomen door mensen die het distributieoppervlak bezitten en niet de functie.

Het afzonderlijke oppervlak is waar u op moet letten

De meeste inkopers beoordelen het risico van een leveranciersroutekaart met adoptiecijfers. Gebruikt iemand het, groeit het, heeft de leverancier zich publiekelijk vastgelegd. Alle drie zijn verkeerde meetinstrumenten, want hier stonden alle drie op groen en telde geen ervan mee. Achthonderdduizend registraties is ongeveer het luidste vraagsignaal dat een productteam kan voortbrengen voor de oplevering, en het verloor.

Het instrument dat wel had gewerkt is structureel en kost een minuut. Stel uzelf twee vragen over elke leverancierscapaciteit waarvan u afhankelijk bent. Bereikt ze u via een eigen oppervlak, dus een eigen app, een eigen console, een eigen portaal of een eigen regel op de factuur? En doet dat oppervlak werk dat het vlaggenschip van de leverancier aannemelijk kan opslokken? Wat op beide ja antwoordt is kandidaat voor consolidatie, ongeacht hoe goed het op dit moment loopt.

Dit voorspelt niet dat elke zulke functie verdwijnt. Het benoemt welk risico u werkelijk draagt. Wanneer een leverancier consolideert, overleeft de capaciteit meestal en het oppervlak niet, dus de verstoring waarvoor u plant is geen functieverlies. Het is een gedwongen migratie op het tijdschema van de leverancier in plaats van het uwe.

Wat overleefde laat zien waar de leverancier serieus is

De webversie van AI Studio bleef onaangeroerd. Google zei erin te blijven investeren en positioneerde die voor mensen die van een idee naar een instructie en verder naar een bedrijf willen gaan. Dat kader is de bruikbare helft van de aankondiging, want het scheidt de twee oppervlakken naar bedoeling: het ene is voor wie bouwt en bleef, het andere overlapte met werk dat de hoofdassistent al kon en verdween.

Voor een team dat plant is de lezing daarmee smaller dan "op Google valt hier niet te bouwen". Ze luidt dat het ontwikkelaarsoppervlak de toezegging droeg en het consumentnabije oppervlak het risico. Wie een werkstroom op de mobiele app wilde bouwen, was de week ongewijzigd doorgekomen door diezelfde werkstroom op de webversie en de onderliggende koppelingen te bouwen.

Voor Europese teams is er een extra punt. Een capaciteit die naar een algemene assistent-app verhuist, verandert niet neutraal van plaats, want de voorwaarden, de beheerrechten en de omgang met gegevens van een consumentenassistent zijn niet automatisch die van een ontwikkelaarsproduct. Wanneer een leverancier zo'n verhuizing aankondigt, vraag die vergelijking dan schriftelijk op voordat u om het nieuwe huis heen plant, en niet erna.

Zet het oppervlak in het contract, niet in de routekaart

De praktische verandering is klein. Wanneer een leverancierscapaciteit in een plan opduikt, benoem dan het leveroppervlak in het document dat bindt, en niet alleen de capaciteit. "Applicaties bouwen beschikbaar in de mobiele applicatie van de leverancier" en "applicaties bouwen beschikbaar" zijn verschillende toezeggingen, en slechts een ervan overleeft een consolidatie. Weigert de leverancier het oppervlak te benoemen, dan is die weigering zelf informatie, en nu is ze goedkoper.

De kosten van nalaten zijn niet dramatisch, en juist daarom wordt het overgeslagen. Een team dat dit kwartaal 20.000 euro aan interne tijd tegenover een mobiele bouw had gezet, is de capaciteit niet kwijt en het geld evenmin. Het is het tijdschema kwijt, en het hoort dat met een dag speling uit een bericht op een sociaal netwerk in plaats van met een opzegtermijn uit een contract. Dat is een klein, vermijdbaar en volstrekt herhaalbaar verlies.

Lees hierna: Brussel heeft zojuist een prijs op Googles zoekdata gezet  |  Chips daalden 20%. Uw rekenkosten niet