AI native er en frase, som næsten ingen faktisk har gjort krav på endnu. Det er underligt, for alt under den findes allerede. Hver retailleverandør har sat en chatbot ind i deres menu. Hver legacy POS har en opsummer sidste uge knap. Hvert lanceringsdæk har det samme OpenAI logo på tredje slide. Mærkatet, der navngiver alternativet, har ligget på bordet, stort set urørt. Vi bruger det på Karo sitet, og det er værd at være præcis om, hvad vi mener med det, før det bliver udvandet.
AI native er ikke et feature flag. Det er ikke en fane i menuen. Det er ikke det, marketingteamet skriver, når engineering teamet tilføjer en OpenAI nøgle til kodebasen.
AI native er en beslutning, virksomheden træffer om, hvordan den er struktureret. Produktet er en konsekvens af den beslutning. Hvis virksomheden ikke er AI native, kan produktet heller ikke være det, uanset hvor mange AI funktioner det leverer.
Sådan ser det ud i praksis. En butikschef i retail ringer lørdag til en self-backed, lille POS partner med et problem. Vagtplanlægningen afspejler ikke hendes butiks lørdagsstigning i kundeflowet. Mandag rulles en fix ud. Ikke en planlagt funktion. Ikke en ticket i en kø. En udrullet fix til netop hendes butik.
Den samme butikschef ringer til en VC-backed leverandør med en kvartalsvis releasecyklus. Leverandøren logger hendes forespørgsel. Forklarer, at funktionsønsker går gennem en kvartalsvis planlægningscyklus. Næste release er om seks uger. Til den tid har hun løst sit lørdagsproblem med tre regneark og en masse weekendarbejde.
Begge leverandører kunne i sidste ende bygge en fix. Forskellen handler ikke om evne. Den handler om struktur.
Hvad AI native faktisk betyder
AI native betyder to ting på én gang, og du har brug for begge, for at ordet skal være ærligt.
For det første er produktet designet med AI i fundamentet, ikke sat ovenpå. AI er driftslaget, der beslutter, foreslår og udfører. Det er ikke et chatvindue syet fast på en legacy transaktionel database. Du kan se, hvordan den distinktion ser ud i Vera, vores retail copilot.
For det andet er virksomheden, der byggede produktet, også organiseret AI native. Lille team. Moderne værktøjer. AI i den daglige arbejdsgang, ikke kun i demoen. Intet vandfald, intet kvartalsvist roadmap udvalg, ingen stiplet linje fra kundens smerte til ingeniørens kø, der tager et kvartal at krydse.
Det meste af retailteknologien har kun den første halvdel. Produktet får et lag AI maling. Organisationsdiagrammet under forbliver præcis det samme, som det var i 2010. Det er derfor, AI føles sat ovenpå, for det er det.
Hvorfor de fleste virksomheder ikke kan levere AI native produkter
En SaaS virksomhed med to hundrede mennesker, tre engineering lag, et produktudvalg, en investorbestyrelse og et kvartalsvist OKR ritual kan ikke levere i den takt, AI kræver. Modellen forbedres hver uge. Retailerens spørgsmål ændrer sig hver lørdag. Den legacy struktur blev designet til at reducere risiko på lange releasecyklusser, og det job løser den fint. Det er bare det forkerte værktøj til en AI native æra.
Vi har alle arbejdet på versionen med otte lag. Mønstrene er kendte. Kunden siger noget en tirsdag. Det havner i et CRM. Et ugentligt triage møde beslutter, om det er en roadmap diskussion værd. Et månedligt roadmap møde beslutter, om det går ind i en kvartalsplan. En kvartalsplan bliver til en sprint. Når ingeniøren læser den oprindelige sætning, er der gået elleve uger, og kunden er enten gået eller har lært at leve uden.
Du kan ikke sætte AI ovenpå det. Du kan kun bygge noget andet.
Hvordan en AI native organisation ser ud
Formen er det modsatte af legacy SaaS formen på næsten hver akse.
Teamet bruger AI til at levere hurtigere end det produkt, de leverer. Kodegennemgang, supportsvar, designudforskning, kunderesearch, interne dokumenter. Hvis dine ingeniører og designere ikke er AI native i deres dag, bliver dit produkt det heller ikke.
Der er intet kvartalsvist roadmap udvalg. Der er en delt kanal med de retailers, der bruger produktet. Signalet skal ikke opsummeres, eskaleres eller oversættes. Ingeniøren læser det. Beslutningen falder samme dag.
Teamet sameje virksomheden. Der er intet ledelseslag, der ikke også leverer, taler med kunder eller mærker produktet, når noget går i stykker. Co-ownership er en strukturel beslutning, ikke et kulturdæk.
Hvorfor dette kun virker uden eksterne investorer
Hvis du har en bestyrelse, der repræsenterer kapital, som vil have kvartalsvise målinger, er strukturen ovenfor ustabil. Før eller siden vil en kvartalsgennemgang kræve en funktion, du ikke tror på. Før eller siden vil en ansættelsesplan tilføje et lag, fordi målingerne kræver en leder. Før eller siden begynder virksomheden at ligne den legacy SaaS, den skulle erstatte.
Nogle af menneskene bag Karo kommer fra Wired to Create, venture studioet, der starter og bygger AI native virksomheder med vilje. Self-backed. Ingen eksterne investorer med en kvartalsvis dagsorden. Linjen er tyve års arbejde med at bygge produkter på den måde på tværs af flere brancher. Karo er ikke Wired to Creates første AI native venture. Det er det næste.
Når organisationsdiagrammet har færre lag end produktets indstillingsmenu, kommer produktet af vejen.
Det er forskellen. Teamet behøver ikke at kæmpe mod sin egen struktur for at levere noget, kunden har brug for. Strukturen blev designet til det, med vilje, fra dag nul.
Hvorfor organisationsdiagrammet ses i produktet
Hvis du evaluerer retailteknologi lige nu, er her testen, som næsten ingen marketingside kan gemme sig fra. Spørg leverandøren, hvordan en funktion kommer fra et kundeopkald til en udrullet release. Tæl trinene. Tæl menneskene. Tæl møderne. Kig så på produktet. Produktet vil afsløre organisationsdiagrammet.
En butikschef i en modekæde med 20 butikker evaluerede fire POS leverandører. Alle fire havde gode produkter i demoen. Tre var VC-backed leverandører med kvartalscyklus, produktudvalg og releasevinduer. En var Karo. Lille, self-backed, lille team, ugentlige cyklusser.
Hun stillede ét spørgsmål. "Hvis mit gulvteam opdagede en fejl i vagtplanen, der koster os lørdagsvagter, hvor lang tid går der, før det er ude i produktion?"
De VC-backed leverandører sagde alle varianter af det samme. Kvartalsvis kadence, produktudvalgsgennemgang, regional godkendelse, derefter udrulning. Tidslinje. 6 til 8 uger i bedste fald.
Karo sagde. "Dage. Hvis dit team finder fejlen mandag, ruller den onsdag, hvis den er kritisk, fredag i den normale cyklus."
Hun valgte Karo. Efter første år var forskellen mere end driftsmæssig. Den var kulturel. Gulvteamet ringede direkte til produktteamet. Problemer blev løst, før de blev til mønstre. Systemet bøjede sig mod hendes drift, ikke omvendt.
Software leveres i den takt, virksomheden, der byggede det, kører i. AI native software skal leveres i AI'ens takt, hvilket er hurtigere, end nogen kvartalsproces kan producere. Det er derfor, AI native i sidste ende er en organisatorisk beslutning. Produktet er den synlige halvdel. Strukturen under er det, der gør produktet muligt.
Hvis du vil se, hvordan det ser ud i praksis, er den foregående læsning i serien AI native retail bygges ikke i bestyrelseslokaler, det bygges på gulvet. Den dækker kundesiden af samme beslutning.