Senior produktleder sier at leveringsteam må fokusere på friksjon i stedet for å jage automatisering

Når det gjelder prosjektleveranser, fokuserer jeg på å definere hva vi bygger og hvorfor, samordne teamene rundt prioriteringer og sørge for at vi leverer pålitelig og raskt. Det innebærer å jobbe tett med utviklingsteamet om gjennomføringen, samtidig som jeg følger nøye med på kundeinnvirkning, kvalitet og kontinuerlig forbedring.

You should also read

• Eisenhower-matrisen: Slik prioriterer du oppgaver på en smart måte

• Tips for å bygge Slack-profilen din

• Slik mestrer du ressursstyring i prosjektledelse

Hvorfor kunstig intelligens endrer prosjektleveranser fra reaktive til strategiske

Kunstig intelligens har endret både rollen min og den daglige prosjektleveransen grunnleggende. Tidligere var leveransene avhengige av manuell koordinering, reaktiv feilsøking og menneskelig analyse. I dag, med kunstig intelligens integrert i arbeidsflytene våre, har arbeidet blitt mer strategisk.

Dette bruker jeg mindre tid på nå:

• Manuell sortering og feilsøking: Tidligere krevde det flere runder med kommunikasjon på tvers av teamene å identifisere rotårsakene til feil. Nå kan systemer med kunstig intelligens oppdage, klassifisere og til og med foreslå løsninger automatisk. Dette reduserte den innledende innsatsen betydelig.
• Å skrive detaljerte spesifikasjoner for alle særtilfeller: I stedet for å dokumentere alt uttømmende på forhånd, baserer vi oss i større grad på AI-assistert utforskning, simuleringer og raske iterasjoner for å forbedre løsningene.
• Statussporing og koordineringsarbeid: Fremdriftssporing, oppsummering og rapportering er nå automatisert, noe som reduserer behovet for konstante oppfølginger.

Saloni deler

Rollen min har utviklet seg fra å følge opp gjennomføringen tett til å forme hvordan intelligente systemer gjennomfører på våre vegne.

Dette får mer av oppmerksomheten min:

• Å definere de riktige problemene og signalene: Siden kunstig intelligens kan handle raskt, er kvaliteten på input mye viktigere. Jeg bruker mer tid på å tenke gjennom hva som skal overvåkes, hvilke signaler som er viktige, og hvordan systemene bør reagere.
• Å utforme AI-assisterte arbeidsflyter: I stedet for bare funksjoner utformer vi ende-til-ende-flyter der AI-agenter oppdager problemer, utfører handlinger og noen ganger til og med løser dem. Dette skiftet fra verktøy til systemer er nå en betydelig del av rollen min.
• Kvalitet og tillit: Når kunstig intelligens tar eller foreslår beslutninger, blir det avgjørende å sikre pålitelighet, forklarbarhet og brukertillit. Jeg bruker mer tid på å validere resultater og definere sikkerhetsmekanismer.
• Hastighet med ansvarlighet: Vi leverer raskere enn før, men forventningene er også høyere. Det handler ikke bare om å bevege seg raskt, men om å bevege seg raskt uten tilbakefall. Denne balansen krever skarpere produktforståelse.

Overordnet sett er dette det som har endret seg i prosjektleveranser: Vi har gått fra en menneskedrevet, reaktiv modell til en mer AI-forsterket, proaktiv modell. Vi oppdager problemer tidligere, løsningstidene blir kortere, og teamene bruker mindre tid på brannslukking og mer tid på å forbedre selve systemet.

Rollen min har derfor utviklet seg fra å følge opp gjennomføringen tett til å forme hvordan intelligente systemer gjennomfører på våre vegne.

Slik endrer kunstig intelligens hendelsessortering

Vi forsøkte ikke å automatisere alt. I stedet fokuserte vi på områder med høy frekvens og kognitivt repeterende arbeid som bremset utviklerne. Hendelsessortering og RCA var et slikt område fordi det skjer daglig, har høye tidskostnader og i stor grad er mønsterbasert.

Agentoppsettet vårt inkluderer en signalagent som oppdager avvik i telemetridata, en kontekstagent som henter logger, spor og relaterte kjøringer, en RCA-agent som genererer rotårsak og dokumentasjon, og en handlingsagent som oppretter en sak med all kontekst. Dette var det enkleste stedet å begynne fordi suksess kan måles gjennom MTTR.

Det førte til at vi bygde en RCA-motor oppå observasjonslaget vårt.

Slik løser AI-drevne systemer kompleksitet i virkelige tilfeller

Vi bygde en RCA-motor for å redusere MTTR, men den virkelige endringen var overgangen fra manuell undersøkelse til systemstyrt diagnostisering. Problemet var at når en feil oppsto, var loggene spredt på tvers av tjenester, ingeniørene måtte rekonstruere flyten manuelt, og årsaksanalyse var i stor grad avhengig av individuell erfaring. Selv for kjente problemer varierte MTTR fordi prosessen ikke var repeterbar.

Som løsning bygde vi en RCA-motor som ligger oppå observasjonslaget vårt og gjør tre ting automatisk:

Sammenstilling av kontekst

• Henter logger, måledata og kjøringsspor på tvers av tjenester
• Gjenoppbygger den nøyaktige feilbanen (trinn for trinn i en batch eller flyt)

Mønstergjenkjenning + likhetsdeteksjon

• Sammenligner problemet med historiske hendelser
• Bruker innebyggingsrepresentasjoner til å identifisere lignende hendelser som har funnet sted

AI-assistert forslag til årsak

• Klassifiserer problemet (dataproblem, konfigurasjonsproblem, koderegresjon, infrastruktur)
• Foreslår den mest sannsynlige årsaken
• Fremhever underbyggende bevis, ikke bare et svar

Hvorfor effekten av AI avhenger av systemkvaliteten

Tidlig antok vi at et LLM-lag direkte ville forbedre resultatene. Det gjorde det ikke. De første versjonene var skuffende. Det vi raskt lærte, var at AI ikke reparerer rotete systemer. Den forsterker dem. Og vi lærte at datakvalitet er viktigere enn modellkvalitet.

Vi brukte mye tid på å rette opp inkonsekvente logger, manglende kontekst på tvers av tjenester og dårlig definerte signaler. Da de underliggende dataene ble strukturerte og pålitelige, fungerte selv enkle AI-oppsett godt.

Tillit er like viktig som nøyaktighet. Selv når RCA-motoren eller systemet for sortering av hendelser viste seg å være teknisk korrekt, brukte ikke ingeniørene det. Hvorfor? Fordi det ikke forklarte seg selv.

Tidlig antok vi at et LLM-lag direkte ville forbedre resultatene. Det gjorde det ikke. AI reparerer ikke rotete systemer. Den forsterker dem. Datakvalitet er viktigere enn modellkvalitet.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Saloni MalhotraOpens new window

Senior produktleder, FoU-teamet hos o9 Solutions

Folk trenger ikke perfekt AI. De trenger forståelig AI. Den virkelige gevinsten er ikke hastighet — det er fokus. Vi trodde AI bare ville gjøre oss raskere. Men ingeniørene lukket ikke bare saker raskere. De begynte å spørre: «Hvorfor finnes denne typen problem i det hele tatt?» Det er et annet nivå av tenkning. Smalt og spesifikt slår ambisiøst og bredt. Vårt første instinkt var å bygge et bredt, intelligent system. Det mislyktes. Innføringen av AI var ikke et stort sprang. Det var en rekke små, tydelige seire.

Vi så en endring først da vi knyttet til bevis (logger, spor, sammenligninger) og viste hvorfor systemet kom frem til en bestemt konklusjon. Som et resultat brukte vi mindre tid på gjentakende undersøkelser og mer tid på forbedringer på systemnivå. Deretter oppnådde vi gode resultater ved å velge spesifikke bruksområder (som RCA for batchfeil), løse dem grundig og utvide gradvis.

Slik forbedrer AI-verktøy effektiviteten i prosjektleveranser

Her er teknologistakken vår.

AI- og intelligenslag:

• LLM-er (modeller i GPT-klassen) — RCA, oppsummering, klassifisering
• Innebyggingsrepresentasjoner + vektordatabase (FAISS / Pinecone) — likhetssøk, henting av hendelser
• RAG-rørledninger — forankring av AI-resultater i logger og historiske data
• Avviksdeteksjon (regler + ML) — deteksjon av feil­mønstre

Observasjon og data:

• Logging og overvåking (Elastic / Datadog / OpenTelemetry)
• Systemer for distribuert sporing
• Datapipelines (Python, strømming-/batchbehandling)
• Lag for lagring av telemetri og utvikling av funksjoner

Leveranse og arbeidsflyt:

• CI/CD (GitHub Actions / Jenkins)
• Oppfølging av problemer (Jira eller tilsvarende)
• Rammeverk for validering av lanseringer / simulering

Utviklerproduktivitet:

• Kodeassistenter (GitHub Copilot eller tilsvarende)
• Interne AI-kopiloter for feilsøking og spørring mot systemer

Samlet sett har utviklingen de siste 6–12 månedene vært:

• Fra dashbord → AI-assistert innsikt
• Fra manuell triage → automatisert RCA
• Fra isolerte verktøy → sammenkoblede pipelines
• Fra reaktiv feilsøking → proaktiv oppdagelse

Slik øker Claude og Figma teamets produktivitet

Det har vært overraskende effektivt for oss å kombinere Claude med Figma. Tidligere brukte vi en arbeidsflyt som så slik ut: Produktlederen skrev en PRD, designeren tolket den, og deretter fulgte flere runder med frem og tilbake.

Nå legger vi grove ideer, arbeidsflyter eller til og med ustrukturerte notater inn i Claude og ber den strukturere arbeidsflyter, foreslå kanttilfeller og utvikle tanker på skjermnivå.

Deretter overfører vi dette direkte til Figma, der vi lager skisser mye raskere, utforsker variasjoner raskt og tenker gjennom mikro-tekst og tilstander.

Hvorfor lettvektsystemer erstatter tradisjonell prosjektstyring

Tradisjonelle systemer fungerte, men de var trege å tilpasse, hadde store koordineringskostnader og var ofte frakoblet det som faktisk skjedde i systemet. Slik så «tradisjonelt» ut: detaljerte PRD-er utarbeidet på forhånd (ofte utdaterte etter noen uker), faste sprintplaner med rigid omfang, manuell statusoppfølging (daglige standuper, rapporter, dashbord) og separate verktøy for planlegging, gjennomføring og overvåking.

Nå har vi gått fra omfattende PRD-er til modulære spesifikasjoner og levende kontekst. Med denne nye tilnærmingen kan vi dele opp ting i: problembeskrivelse, sentrale arbeidsflyter og begrensninger. Vi kan også lagre dem i lettvektsformater (dokumenter + oppgaver) og bruke LLM-er til å utvide med kanttilfeller og generere testscenarioer.

Vi bruker nå langt mindre tid på å skrive uttømmende dokumenter (PRD-er på 10–15 sider i Confluence). I stedet har vi et strukturert input på én side med problemet, brukerflyten og begrensningene.

For å gjøre dette brukte vi følgende verktøy:

• Confluence (redusert bruk)
• Jira (primær sannhetskilde)
• LLM-lag (GPT-modeller via API)
• Figma
• Claude (for strukturering av arbeidsflyter)

Her er prosessen vår:

• Strukturert input på én side:
  • Problem
  • Brukerflyt
  • Begrensninger
• Vi legger det inn i Claude / LLM for å:
  • Utvide arbeidsflyter
  • Generere kanttilfeller
  • Utarbeide akseptansekriterier
• Vi konverterer det direkte til Jira-oppgaver + Figma-skisser

Effekten ser slik ut:

• ~40–50 % reduksjon i tiden fra idé → første versjon
• Færre runder med frem og tilbake mellom produktledelse, design og utvikling
• Mye tydeligere første versjon av funksjonene

Hvordan AI-integrasjon endrer leveranseritualer

Videre har definering av omfang gått fra uttømmende til retningsgivende. Tidligere prøvde vi å definere alt på forhånd og dekke alle spesialtilfeller i PRD-er. Nå definerer vi problemet, de viktigste arbeidsflytene og begrensningene. Deretter bruker vi AI til å utvide spesialtilfeller, simulere scenarioer og fremheve mangler. Omfang handler ikke lenger om fullstendighet på dag én; det handler om å sette en tydelig retning og legge til rette for en rask forbedringssløyfe.

Om fem år vil planer ikke lenger bli «skrevet» – de vil bli generert kontinuerlig. Jeg tror planer vil være levende systemer, ikke dokumenter. AI vil kontinuerlig oppdatere prioriteringer, risikoer og tidslinjer basert på gjennomføring i sanntid, kundesignaler og systemtilstand. Planlegging vil være dynamisk og alltid oppdatert, ikke en periodisk øvelse.

Saloni deler

AI fungerer best når det fjerner en reell, daglig utfordring, ikke når det legges til som et ekstra lag.

Hvorfor det er viktig å håndtere friksjon før AI tas i bruk

Ikke start med AI. Start med friksjon.

Det er fristende å spørre: «Hvor kan vi bruke AI?» Det er vanligvis feil utgangspunkt. Spør heller: Hvor sløser teamene gjentatte ganger med tid? Hvor avhenger arbeidet for mye av noen få personer? Hvor går ting saktere når presset øker? Velg ett av disse områdene og løs det grundig.

AI fungerer best når det fjerner en reell, daglig utfordring, ikke når det legges til som et ekstra lag.

Følg med

Du kan følge Salonis arbeid på LinkedIn.

Flere ekspertintervjuer kommer på The Digital Project Manager!