Det hele startet med en skinnende ny lansering. Google hadde nettopp avduket Geminis multimodale funksjoner–en teknologi som så lovende ut til potensielt å kunne løse problemer med samhandling mellom mennesker og nettlesere. Ingeniørteamet regnet med at det ville bli et raskt eksperiment med lav risiko.
Ett team prøvde det. Så et annet. Deretter et tredje.
Men selv om konseptet var spennende, var det faktiske verktøyet ikke helt klart. Det var på et tidlig stadium, ikke klart for produksjon og definitivt ikke tilpasset teamets bruksområde.
«Det var en distraksjon som lett kunne ha avsporet fremdriften på eksisterende prioriteringer hvis vi ikke hadde satt på bremsene», forteller Anand Sainath, teknologisjef og medgründer i 100x, som tok beslutningen om å stoppe integrasjonen.
Andre har imidlertid ikke vært like heldige. For mange team kapret jakten på «det neste store» sakte, men sikkert produktplanen. Det som sto igjen, var et lappverk av halvferdige verktøy og nedprioriterte oppgaver–noe Sainath omtaler som den stille kostnaden ved skinnende objekt-syndromet.
Hva i all verden er skinnende objekt-syndromet?
Skinnende objekt-syndrom (SOS) oppstår når team blir distrahert av nye verktøy, rammeverk eller teknologier, ofte på bekostning av eksisterende prioriteringer.
«Når en ny teknologi dukker opp, slik tilfellet er med KI i dag, blir markedet begeistret over bruksområdene. Det kan oppstå press om å dreie mot trenden for å holde seg foran konkurrentene», sier Raju Malhotra, CPTO i Certinia.
Det er da det «skinnende» verktøyet eller rammeverket begynner å snike seg inn i planene dine og «trekker ingeniørene bort fra arbeidet som faktisk betyr noe for kundene i dag».
Historien om Evernote krysser av for alle rutene på bingokortet for skinnende objekt-syndrom. Selskapet hadde alle de riktige ingrediensene: lojale brukere, et solid produkt og en tydelig nisje. I stedet for å satse enda mer på kjernefunksjonene sine gikk selskapet over til fysiske produkter og lanserte halvferdige produktfunksjoner som Work Chat.
Produktet ble overlesset, ytelsen sank, og brukerne gikk over til enklere verktøy som Notion og Google Keep. I 2022 ble Evernote kjøpt opp, og tidlig i 2023 var de fleste ansatte sagt opp.
SOS ender ikke alltid i konkurs eller oppsigelser, men det sporer nesten alltid av fremdriften ved å:
- Forsinke prosjektleveranser: Hyppige skifter til nye teknologier midt i prosjektet kan forstyrre planleggingen, avbryte gjennomføringssykluser og føre til omfattende, uplanlagt omfang. Det var akkurat det som skjedde med FBIs Virtual Case File-prosjekt. Etter fem år og 170 millioner dollar i utgifter ble prosjektet skrinlagt, delvis fordi den skiftende tilpasningen mellom byråkratiet og virksomheten stadig brøt leveranserytmen.
- Øke ingeniørkostnadene: Uten et rammeverk for å evaluere ny teknologi fører beslutninger drevet av skinnende objekter ofte til for mange verktøy, teknisk gjeld og høye kostnader for programvareutvikling. Team bruker til og med tid på prototyper som aldri lanseres eller, enda verre, blir satt i drift og deretter skrevet om.
- Redusere utviklernes produktivitet: Hvert nye verktøy betyr en ny læringskurve, flere feil og flere «raske tester» som sjelden forblir raske. Det sprer ingeniørene tynt utover, reduserer produktiviteten med så mye som 40 % og fører til utmattelse og konstant brannslukking–energi som kunne ha gått til å bygge produktets kjernefunksjoner.
- Svekke interessentenes tillit: SOS sender også feil signal til virksomhetens ledere. Når prioriteringene endres for ofte og tidsplanene sprekker, kan toppledelsen begynne å stille spørsmål ved ingeniøravdelingens evne til å levere. Når tilliten først er borte, er den vanskelig å vinne tilbake.
Stopp anger over skinnende objekter: 3 kontrollspørsmål for teamet ditt
Du vet hvilket kaos skinnende objekt-syndrom kan skape i teamet ditt. Så hvordan avgjør du om det nye biblioteket, SDK-et eller den nye tjenesten er verdt det–før den tapper deg for tid og fokus? Ekspertene våre har noen faste kontrollspørsmål:
- Er det en «innpakning» eller et «plaster»?
Sainaths filter når han vurderer skinnende nye verktøy eller ny teknologi, er enkelt: Løser dette noe som er viktig på lang sikt, eller er det bare et plaster?
«Et plaster dekker bare over mindre særtilfeller eller kortsiktige begrensninger. Men sjansen er stor for at den neste versjonen av modellen løser det uansett. Og da blir det du har bygget, umiddelbart utdatert.»
Han er mer interessert i å bygge innpakninger–rene lag oppå grunnmodeller som tilfører reell brukervennlighet gjennom design, arbeidsflyter eller kontekst.
«Begrepet LLM-omslag ble tidlig brukt på en nesten nedsettende måte, men i bunn og grunn er mange verdifulle produkter bygget på underliggende teknologi», kommenterer Sainath. «Se på Cursor. Man kan hevde at det bare er et omslag, men det gir betydelig, fokusert verdi.»
Etter hans syn er midlertidige lappeløsninger distraksjoner som lett kan bli til skinnende objekter. Gjennomtenkte omslag kan derimot bli kjerneprodukter.
- Hva velger vi ikke å bygge?
Ifølge Malhotra er det like viktig å følge med på hva teamet velger å ikke bygge, som på det som havner i veikartet. «Det hindrer oss i å jage funksjoner som kanskje ser bra ut i en demonstrasjon, men som faktisk ikke forbedrer det daglige arbeidet», sier han.
Selv når teamet ikke er sikre på at noe er klart for bredere utrulling, tester de det likevel med tidlige brukere. «Det gir oss tilbakemeldinger uten å forstyrre veikartet.»
- Hva er forretningsverdien?
For teknologidirektøren i Customer.io, Paul Senechko, er det å forstå forretningsverdien bak teknologiarbeidet det første og viktigste filteret. Hvis et nytt verktøy eller system ikke tjener noen av delene, sier han, er tiden sannsynligvis ikke inne for det.
«Vårt ledelsesprinsipp er at vi er kundespesialister», forklarer Senechko. «Vi bruker dette prinsippet til å styre investeringene våre i teknologi, slik at vi sørger for å bygge med kunden og virksomheten i tankene.»
For å holde teamet sitt jordnært støtter Senechko seg på noen få enkle, men kraftfulle spørsmål: Hva koster dette oss i form av tid og ressurser? Forbedrer det produktet vårt? Vil det hjelpe kundene våre med å lykkes bedre?
Sainath legger til sitt eget perspektiv, med det han kaller «hva om»-spørsmålene: «Hva skjer hvis den underliggende teknologien blir ti ganger bedre? Blir produktet vårt automatisk bedre, eller blir det plutselig irrelevant?»
Han undersøker også innsatsen som kreves for å realisere disse forbedringene: «Vil vi automatisk dra nytte av disse fremskrittene, eller vil det kreve en omfattende omarkitektur for å holde tritt?»
Ved å spille ut disse scenariene med teamet kan dere lettere ta avgjørelsen om hvorvidt dere skal prioritere den skinnende nye teknologistakken eller holde dere til det som allerede fungerer.
Sikre veikartet mot syndromet med skinnende objekter (uten å ta livet av innovasjonen)
Når spennende ny teknologi svikter, må du ta det med en klype salt og balansere innovasjon med reell fremgang.
Slik håndterer CTO-er frykten for å gå glipp av noe og holder teamene sine jordnære og fokuserte:
- Definer avslutningskriterier for prosjekter før dere starter
Mange «utforskende» teknologiforsøk utvikler seg til langvarige sideprosjekter med gradvis økende omfang og tilbakevendende teknisk gjeld, hovedsakelig fordi ingen definerer hvordan eller når de skal avsluttes. Hvis det ikke finnes eierskap, tidsramme eller suksesskriterier, er det bare et spørsmål om tid før syndromet med skinnende objekter kjører hele prosjektet i grøfta. For å unngå det bør dere behandle hvert teknologiforsøk som en produktfunksjon: avgrenset, tidsbegrenset, med en tydelig eier og drevet av et reelt bruksområde.
Som Senechko sier: «Bruk det på små, men reelle bruksområder, og bygg videre derfra. Når vi bestemmer oss for å eksperimentere med nye trender, sørger vi for å identifisere et lite eller godt avgrenset område der vi kan teste og kontrollere at dette fungerer. På denne måten kan vi eksperimentere og få reell erfaring med teknologien før vi satser stort på den.»
Involver en tverrfunksjonell gjennomgang (EM + PM + seniorutvikler) for en objektiv vurdering, og opprett en strukturert tidsplan som inkluderer:
- Maksimal varighet: Begrens til 2 sprinter (+1 buffer) for å holde det effektivt og testbart
- Milepæler for fortsettelse/stopp med avslutningsbetingelser: Definer et tydelig vurderingstidspunkt der teamet bestemmer om det skal fortsette, gjenta eller stoppe (over 10 % av byggingene mislyktes, eller manglende integrasjon med CI/CD-verktøyet).
Senechko foreslår til og med at team eksperimenterer med initiativer med fast tidsramme og variabelt omfang, der teamet hans setter en innledende «appetitt» for hvor mye tid de er villige til å bruke, og tar sikte på å levere det mest verdifulle resultatet innenfor dette tidsvinduet. «Dette har gjort det mulig for oss å innovere og mislykkes raskt når de nye retningene ikke ser ut til å føre i riktig retning.»
- Bruk måltall til å måle suksess
Når den tekniske gjennomførbarheten og arbeidsmengden for utviklingen er forstått, må du definere hvordan suksess ser ut. Det er grensen mellom en disiplinert utrulling og et SOS-prosjekt som har fått et stadig større omfang. Bygg et rammeverk som måler suksess på tvers av flere dimensjoner:
- Mennesker: Økt utvikler produktivitet, flere timer med fordypet arbeid
- Prosesser og arbeidsflyter: Kortere kjøretid for testserier, færre regresjoner, slankere utrullingsarbeidsflyter, redusert tid til markedet
- Kundeopplevelse: Bedre sideytelse, færre UX-klager, forbedrede responstider
- Systemytelse: Raskere databehandling, lavere infrastrukturkostnader, færre hendelser eller tilbakeføringer
- Kjenn kundene dine
«Å holde kursen handler om å være ærlig om hvor kundeverdien skapes,» hevder Malhotra. «Trender kan høres spennende ut, men de kan raskt bli distraksjoner hvis de ikke direkte hjelper kundene med å utføre arbeidet sitt bedre eller raskere.»
Dette prinsippet kommer til uttrykk i hvordan mange team nå kobler sammen produkt og utvikling med kundesuksess for direkte observasjon. Noen utviklere deltar i brukerstøttesamtaler, onboardingøkter eller kundemøter for å få reelle og ufiltrerte tilbakemeldinger. Å høre på første hånd hva som forvirrer brukerne, hva som går galt, og hva som får ros, skaper empati og kan til og med gjøre prioriteringen i utviklingsteamene skarpere.
Men det er ikke nok å bare lytte. For å identifisere hvor kundene faktisk møter utfordringer, bør du supplere kvalitative tilbakemeldinger med produkttelemetri. Det er stor sannsynlighet for at analyseverktøyet ditt (PostHog, Amplitude, Heap) er underutnyttet til dette formålet. Begynn å spore hvordan brukerne faktisk samhandler med produktet: helt ned til klikk, veksleknapper, navigeringssløyfer og feilforløp.
Kombiner disse atferdsdataene med brukerstøttehenvendelser for å oppdage mønstre. Blir en funksjon ignorert fordi den er vanskelig å finne? Klarer ikke brukerne å fullføre kritiske arbeidsflyter? Bruk dette som tydelige signaler for pilotprosjekter med kunden i sentrum.
Over tid vil du organisk bygge et «kundens stemme»-skjema med kundesmertepunkter, tilbakemeldinger, begeistring og tilbakevendende hindringer som strømmer fra kundesuksessteamene inn i produkt- og utviklingsbeslutningene.
Det er det samme systemet Senechkos team brukte for å prioritere arbeid basert på målbar kundeverdi: «Et stort kundevolum og krav om lav forsinkelse har drevet teamet vårt til å finne opp løsninger som standardteknikker ikke kunne levere. Investering i den tekniske plattformen vår er en del av selskapets DNA, ettersom vi har sett gevinsten dette har gitt både kundene og virksomheten.»
Til syvende og sist vil reell fremgang innen utvikling komme av å utforme nye funksjoner som utvider det som allerede fungerer, ikke av å bygge rundt det eller koble på noe helt nytt. Slik kan team utvikle seg uten å ødelegge utprøvde systemer.
«Innovasjon trenger ikke å bety omveltning. Den bør styrke det som allerede fungerer, og hjelpe kundene med å jobbe raskere og med mindre innsats,» sier Malhotra enkelt.
Vil du ha flere innsikter som denne? Abonner på nyhetsbrevet til The CTO Club.
