AI native är en fras som nästan ingen faktiskt har gjort anspråk på än. Det är märkligt, för allt under den finns redan här. Varje retailleverantör har klistrat på en chatbot på sin meny. Varje legacy POS har en sammanfatta förra veckan knapp. Varje lanseringsdäck har samma OpenAI logga på tredje sliden. Etiketten som namnger alternativet har legat på bordet, mestadels orörd. Vi använder den på Karo sajten, och det är värt att vara exakt med vad vi menar med den innan den blir urvattnad.
AI native är inte en feature flag. Det är inte en flik i menyn. Det är inte vad marknadsteamet skriver när engineering teamet lägger till en OpenAI nyckel i kodbasen.
AI native är ett beslut företaget tar om hur det är strukturerat. Produkten är nedströms av det beslutet. Om företaget inte är AI native kan produkten inte vara det heller, oavsett hur många AI funktioner den levererar.
Så här ser det ut i praktiken. En butikschef inom retail ringer en självfinansierad, liten POS partner på lördag med ett problem. Schemaläggningen reflekterar inte hennes butiks lördagsökning av kundflödet. På måndag levereras en fix. Inte en schemalagd funktion. Inte en biljett i en kö. En utrullad fix till hennes specifika butik.
Samma butikschef ringer en riskkapitalfinansierad leverantör med en kvartalsvis releasecykel. Leverantören loggar hennes förfrågan. Förklarar att funktionsförfrågningar går genom en kvartalsvis planeringscykel. Nästa release är om sex veckor. Vid det laget har hennes lördagsproblem lösts med tre kalkylblad och mycket helgarbete.
Båda leverantörerna skulle till slut kunna bygga en fix. Skillnaden är inte förmåga. Det är struktur.
Vad AI native faktiskt betyder
AI native betyder två saker samtidigt, och du behöver båda för att ordet ska vara ärligt.
För det första är produkten designad med AI i sin grund, inte påklistrad. AI:n är driftslagret som beslutar, föreslår och utför. Det är inte ett chattfönster fastsytt på en legacy transaktionell databas. Du kan se hur den distinktionen ser ut i Vera, vår retail copilot.
För det andra är företaget som byggde produkten organiserat AI native också. Litet team. Modern verktygskedja. AI i det dagliga arbetsflödet, inte bara i demon. Inget vattenfall, ingen kvartalsvis roadmap kommitté, ingen streckad linje från kundens smärta till ingenjörens kö som tar ett kvartal att korsa.
Det mesta av retailtekniken har bara den första halvan. Produkten får en AI målning. Organisationsschemat under förblir exakt detsamma som det var 2010. Det är därför AI:n känns påklistrad, för det är den.
Varför de flesta företag inte kan leverera AI native produkter
Ett SaaS företag med två hundra personer, tre engineering lager, en produktkommitté, en investerarstyrelse och en kvartalsvis OKR ritual kan inte leverera i den takt AI kräver. Modellen förbättras varje vecka. Retailerns fråga förändras varje lördag. Den legacy strukturen designades för att minska risk på långa releasecykler, och den gör det jobbet väl. Det är fel verktyg för en AI native era.
Vi har alla jobbat på versionen med åtta lager. Mönstren är bekanta. Kunden säger något på en tisdag. Det går in i ett CRM. Ett veckovis triagemöte beslutar om det är värt en roadmap diskussion. Ett månadsvis roadmap möte beslutar om det går in i en kvartalsvis plan. En kvartalsvis plan blir en sprint. När ingenjören läser den ursprungliga meningen har elva veckor passerat och kunden har antingen lämnat eller lärt sig att leva utan det.
Du kan inte klistra på AI på det. Du kan bara bygga något annat.
Hur en AI native organisation ser ut
Formen är motsatsen till legacy SaaS formen på nästan varje axel.
Teamet använder AI för att leverera snabbare än produkten de levererar. Kodgranskning, supportsvar, designutforskning, kundforskning, interna dokument. Om dina ingenjörer och designers inte är AI native i sin dag, kommer din produkt inte att vara det heller.
Det finns ingen kvartalsvis roadmap kommitté. Det finns en delad kanal med retailerna som använder produkten. Signalen behöver inte sammanfattas, eskaleras eller översättas. Ingenjören läser den. Beslutet sker samma dag.
Teamet samäger företaget. Det finns inget chefslager som inte också levererar, pratar med kunder eller känner produkten när något går sönder. Co-ownership är ett strukturellt beslut, inte ett kulturdäck.
Varför detta bara fungerar utan externa investerare
Om du har en styrelse som representerar kapital som vill ha kvartalsvisa mätvärden är strukturen ovan instabil. Förr eller senare kommer en kvartalsvis genomgång att kräva en funktion du inte tror på. Förr eller senare kommer en anställningsplan att lägga till ett lager för att mätvärdena kräver en chef. Förr eller senare börjar företaget se ut som den legacy SaaS det skulle ersätta.
Några av människorna bakom Karo kommer från Wired to Create, venture studion som startar och bygger AI native företag med flit. Självfinansierat. Inga externa investerare med en kvartalsvis agenda. Linjen är tjugo år av att bygga produkter på det här sättet över flera branscher. Karo är inte Wired to Creates första AI native venture. Det är nästa.
När organisationsschemat har färre lager än produktens inställningsmeny kommer produkten ur vägen.
Det är skillnaden. Teamet behöver inte slåss mot sin egen struktur för att leverera något kunden behöver. Strukturen designades för det, med flit, från dag noll.
Varför organisationsschemat syns i produkten
Om du utvärderar retailteknik just nu, här är testet som nästan ingen marknadsföringssida kan dölja sig från. Fråga leverantören hur en funktion tar sig från ett kundsamtal till en utrullad release. Räkna stegen. Räkna människorna. Räkna mötena. Titta sedan på produkten. Produkten kommer att avslöja organisationsschemat.
En butikschef på en modekedja med tjugo butiker utvärderade fyra POS leverantörer. Alla fyra hade bra produkter i demon. Tre var riskkapitalfinansierade leverantörer med kvartalsvis cykel, produktkommittéer och releasefönster. En var Karo. Liten, självfinansierad, litet team, veckovis cykel.
Hon ställde en fråga. "Om mitt golvteam upptäckte ett schemaläggningsfel som kostar oss lördagspass, hur lång tid tar det innan det rullas ut till produktion?"
De riskkapitalfinansierade leverantörerna sa alla variationer av samma sak. Kvartalsvis kadens, produktkommittégranskning, regionalt godkännande, sedan utrullning. Tidslinje. 6 till 8 veckor i bästa fall.
Karo sa. "Dagar. Om ditt team hittar felet på måndag levereras det på onsdag om det är kritiskt, fredag i den normala cykeln."
Hon valde Karo. Efter ett år var skillnaden mer än operativ. Den var kulturell. Golvteamet ringde produktteamet direkt. Problem löstes innan de blev mönster. Systemet böjde sig mot hennes verksamhet, inte tvärtom.
Mjukvara levereras i den hastighet företaget som byggt den levererar i. AI native mjukvara måste levereras i AI:s hastighet, vilket är snabbare än någon kvartalsvis process kan producera. Det är därför AI native i slutändan är ett organisatoriskt beslut. Produkten är den synliga halvan. Strukturen under är vad som gör produkten möjlig.
Om du vill se hur det här ser ut i praktiken är föregående läsning i serien AI native retail byggs inte i styrelserum, det byggs på golvet. Den täcker kundsidan av samma beslut.