Det hele begyndte med en skinnende ny lancering. Google havde netop afsløret Geminis multimodale funktioner – en teknologi, der så lovende ud, at den potentielt kunne løse problemer med interaktionen mellem mennesker og browsere. Ingeniørteamet regnede med, at det ville blive et hurtigt eksperiment med lav risiko.
Ét hold prøvede det. Så et andet. Så et tredje.
Men selvom konceptet var spændende, var det faktiske værktøj ikke helt klar. Det var på et tidligt udviklingsstadie, ikke klar til produktion og bestemt ikke tilpasset teamets anvendelse.
“Det var en distraktion, der nemt kunne have afsporet fremskridtene med eksisterende prioriteter, hvis vi ikke havde trukket i bremsen,” fortæller Anand Sainath, teknisk chef og medstifter hos 100x, som traf beslutningen om at stoppe integrationen.
Andre har dog ikke været lige så heldige. For mange hold kaprede jagten på “den næste store ting” langsomt produktkøreplanen. Tilbage stod et kludetæppe af halvfærdige værktøjer og oversete prioriteter – noget Sainath omtaler som den stille omkostning ved skinnende-objekt-syndromet.
Hvad er skinnende-objekt-syndromet egentlig?
Skinnende-objekt-syndromet (SOS) opstår, når hold bliver afledt af nye værktøjer, rammeværker eller teknologier, ofte på bekostning af eksisterende prioriteter.
“Når en ny teknologi dukker op, som det er tilfældet med AI i dag, bliver markedet begejstret over dens anvendelsesmuligheder. Der kan opstå et pres for at skifte fokus til trenden for at være foran konkurrenterne,” siger Raju Malhotra, CPTO hos Certinia.
Det er dér, det “skinnende” værktøj eller rammeværk begynder at snige sig ind i jeres planer og “trækker ingeniørerne væk fra det arbejde, der faktisk betyder noget for kunderne i dag.”
Evernotes historie opfylder alle felter på skinnende-objekt-syndromets bingoplade. Virksomheden havde alle de rigtige ingredienser: loyale brugere, et solidt produkt og en tydelig niche. I stedet for at satse endnu mere på kernefunktionerne udvidede virksomheden til fysiske produkter og lancerede ufærdige produktfunktioner som Work Chat.
Produktet blev oppustet, ydeevnen faldt, og brugerne forlod det til fordel for enklere værktøjer som Notion og Google Keep. I 2022 blev Evernote opkøbt, og i begyndelsen af 2023 var det meste af personalet blevet afskediget.
SOS ender ikke altid i konkurs eller masseafskedigelser, men det afsporer næsten altid fremdriften ved at:
- Forsinke projektleverancer: Hyppige skift til nye teknologier midt i et projekt kan forstyrre planlægningen, afbryde eksekveringscyklusser og introducere et oppustet, uplanlagt omfang. Det var præcis, hvad der skete med FBI’s Virtual Case File-projekt. Efter fem år og et forbrug på $170 millioner blev projektet opgivet, blandt andet fordi den skiftende bureaukratisk-forretningsmæssige afstemning konstant brød leverancerytmen.
- Øge ingeniøromkostningerne: Uden et rammeværk til at evaluere nye teknologier fører skinnende-objekt-drevne beslutninger ofte til for mange værktøjer, teknisk gæld og høje softwareudviklingsomkostninger. Hold bruger endda tid på prototyper, der aldrig lanceres, eller endnu værre: bliver implementeret og derefter skrevet om.
- Dræbe udviklerproduktiviteten: Hvert nyt værktøj betyder endnu en læringskurve, flere fejl og flere “hurtige tests”, der sjældent forbliver hurtige. Det spreder ingeniørerne for tyndt, reducerer produktiviteten med op til 40% og fører til udmattelse og konstant brandslukning – energi, der kunne være gået til at bygge centrale produktfunktioner.
- Udhule interessenternes tillid: SOS sender også et forkert signal til virksomhedens ledere. Når prioriteterne ændres for ofte, og tidsplanerne skrider, kan ledelsen på C-niveau begynde at sætte spørgsmålstegn ved ingeniørteamets evne til at levere. Når tilliden først er væk, er den svær at genvinde.
Stop fortrydelsen over skinnende objekter: 3 kontrolspørgsmål til dit team
Du kender den slags kaos, skinnende-objekt-syndromet kan skabe i dit team. Så hvordan afgør du, om det nye bibliotek, SDK eller den nye tjeneste er det værd – før det dræner tid og fokus? Vores eksperter har nogle faste kontrolspørgsmål:
- Er det en “indpakning” eller et “plaster”?
Sainaths filter, når han håndterer skinnende nye værktøjer/teknologi, er enkelt: Løser dette noget, der er vigtigt på lang sigt, eller er det bare et plaster?
“Et plaster lapper blot mindre kanttilfælde eller dækker over kortsigtede begrænsninger. Men sandsynligheden er stor for, at den næste version af modellen løser det alligevel. Hvad du har bygget, bliver derefter øjeblikkeligt forældet.”
Han er mere interesseret i at bygge indpakninger – rene lag oven på grundlagsmodeller, der tilfører reel anvendelighed gennem design, arbejdsgange eller kontekst.
“Begrebet LLM-indpakning blev tidligt brugt næsten nedsættende, men grundlæggende er mange værdifulde produkter bygget oven på underliggende teknologi,” kommenterer Sainath. “Se bare på Cursor. Man kunne argumentere for, at det bare er en indpakning, men det skaber betydelig, fokuseret værdi.”
Efter hans opfattelse er lappeløsninger distraktioner, der nemt kan udvikle sig til skinnende objekter. Veltænkte indpakninger kan derimod blive kerneprodukter.
- Hvad vælger vi ikke at bygge?
Ifølge Malhotra er det lige så vigtigt at holde styr på, hvad teamet vælger ikke at bygge, som på det, der kommer med på køreplanen. “Det forhindrer os i at jagte funktioner, der måske ser godt ud i en demo, men som faktisk ikke forbedrer det daglige arbejde,” siger han.
Selv når teamet ikke er sikre på, at noget er klar til en bredere udrulning, tester de det stadig med de første brugere. “Det giver os feedback uden at forstyrre køreplanen.”
- Hvad er forretningsværdien?
For Customer.ios tekniske vicepræsident, Paul Senechko, er forståelsen af forretningsværdien bag den tekniske indsats det første og mest kritiske filter. Hvis et nyt værktøj eller system ikke tjener et af disse formål, siger han, er tidspunktet sandsynligvis ikke det rigtige.
“Vores virksomheds ledelsesprincip er, at vi er kundeeksperter,” forklarer Senechko. “Vi bruger dette princip til at styre vores investeringer i teknologi for at sikre, at vi bygger med kunden og virksomheden for øje.”
For at holde sit team fokuseret på det væsentlige støtter Senechko sig til nogle få enkle, men effektive spørgsmål: Hvad koster dette os i tid og ressourcer? Forbedrer det vores produkt? Vil det hjælpe vores kunder med at få større succes?
Sainath tilføjer sin egen vinkel med det, han kalder “hvad nu hvis”-spørgsmålene: “Hvad sker der, hvis den underliggende teknologi bliver 10 gange bedre? Bliver vores produkt automatisk bedre, eller bliver det pludselig irrelevant?”
Han undersøger også den indsats, der kræves for at realisere disse forbedringer: “Får vi automatisk gavn af disse fremskridt, eller kræver det en større omarkitektur at indhente dem?”
Ved at gennemspille disse scenarier med dit team kan du træffe beslutningen om, hvorvidt du skal prioritere den nye teknologistak eller holde fast i det, der allerede fungerer.
Sikring af din køreplan mod syndromet med skinnende objekter (uden at dræbe innovationen)
Når spændende ny teknologi får sit gennembrud, skal du tage den med et gran salt og afveje innovation mod reelle fremskridt.
Sådan håndterer CTO'er frygten for at gå glip af noget og holder deres teams fokuserede på det væsentlige:
- Definér afslutningskriterier for projekter, før du går i gang
Mange “undersøgende” teknologiforsøg udvikler sig til langvarige sideprojekter med gradvist voksende omfang og tilbagevendende teknisk gæld, primært fordi ingen definerer, hvordan eller hvornår de slutter. Hvis der ikke er ejerskab, en tidsplan eller succeskriterier, er det kun et spørgsmål om tid, før syndromet med skinnende objekter kører det hele i sænk. For at undgå det skal du behandle hvert teknologiforsøg som en produktfunktion: afgrænset, tidsbegrænset, ejet og drevet af et reelt anvendelsestilfælde.
Som Senechko siger: “Anvend det på små, men reelle anvendelsestilfælde, og gå så videre derfra. Når vi beslutter os for at eksperimentere med nye tendenser, sørger vi for at identificere et lille eller velafgrænset område, hvor vi kan teste og verificere, at det fungerer. På den måde kan vi eksperimentere og opnå reel erfaring med teknologien, før vi satser stort på den.”
Inddrag en tværfunktionel evaluator (EM + PM + staff-ingeniør) til en objektiv vurdering, og opret en struktureret tidsplan, der omfatter:
- Maksimal varighed: Begræns det til 2 sprints (+1 buffer) for at holde det enkelt og testbart
- Gå/Stop-milepæle med afslutningsbetingelser: Definér et eksplicit evalueringstidspunkt, hvor teamet beslutter, om det skal fortsætte, gentages eller stoppes (over 10 % af byggeprocesserne mislykkedes, eller der mangler integration med CI/CD-værktøjet).
Senechko foreslår endda, at teams eksperimenterer med initiativer med fast tid og variabelt omfang, hvor hans team fastsætter en indledende “appetit” på, hvor meget tid de er villige til at bruge, og sigter mod at levere det mest værdifulde resultat inden for dette tidsrum. “Det har gjort det muligt for os at innovere og fejle hurtigt, når de nye retninger ikke ser ud til at føre i den rigtige retning.”
- Brug målepunkter til at måle succes
Når den tekniske gennemførlighed og den tekniske arbejdsbyrde er klarlagt, skal du definere, hvordan succes ser ud. Det er forskellen mellem en disciplineret udrulning og et SOS-projekt, hvor omfanget hele tiden vokser. Opbyg en ramme, der måler succes på tværs af flere dimensioner:
- Medarbejdere: Øget produktivitet blandt udviklere, flere timer med fordybet arbejde
- Processer og arbejdsgange: Kortere køretid for testpakker, færre regressioner, mere effektive udrulningsarbejdsgange, kortere tid til markedet
- Kundeoplevelse: Bedre sideydelse, færre UX-klager, forbedrede svartider
- Systemydelse: Hurtigere databehandling, lavere infrastrukturudgifter, færre hændelser eller tilbagerulninger
- Kend dine kunder
“At holde kursen handler om at være ærlig omkring, hvor kundeværdien bliver skabt,” hævder Malhotra. “Tendenser kan lyde spændende, men de kan hurtigt blive distraktioner, hvis de ikke direkte hjælper kunderne med at udføre deres arbejde bedre eller hurtigere.”
Dette princip kommer til udtryk i, hvordan mange teams nu kobler produkt- og udviklingsteamet sammen med kundesucces for at følge kunder i deres arbejde. Et par udviklere deltager i supportopkald, onboarding-sessioner eller kundeopfølgninger for at få ærlig feedback uden filter. Når man hører direkte, hvad der forvirrer brugerne, hvad der går i stykker, og hvad der bliver rost, opbygger det empati og kan endda skærpe prioriteringen i udviklingsteams.
Men det er ikke nok bare at lytte. For at identificere, hvor kunderne reelt har problemer, skal du supplere den kvalitative feedback med produkttelemetri. Det er sandsynligt, at dit analyseværktøj (PostHog, Amplitude, Heap) ikke udnyttes fuldt ud til dette formål. Begynd at følge, hvordan brugerne rent faktisk interagerer med produktet: helt ned til klik, skift, navigationssløjfer og fejlforløb.
Sammenhold disse adfærdsdata med supportsager for at finde mønstre. Bliver en funktion ignoreret, fordi den er svær at finde? Kan brugerne ikke gennemføre kritiske arbejdsgange? Brug disse signaler med høj informationsværdi som udløsere for kundeorienterede pilotprojekter.
Med tiden opbygger du naturligt en form for "kundens stemme" med kundernes problemer, feedback, begejstring og tilbagevendende blokeringer, som flyder fra kundesuccesteams ind i produkt- og udviklingsbeslutninger.
Det er det samme system, som Senechkos team brugte til at prioritere arbejdet ud fra målbar kundeværdi: “Et stort antal kunder og krav om lav latenstid har fået vores team til at opfinde løsninger, som standardteknikker ikke kunne levere. Investering i vores tekniske platform er en del af vores virksomheds DNA, fordi vi har set gevinsten for både kunderne og virksomheden.”
I sidste ende vil reelle fremskridt inden for udvikling komme af at designe nye funktioner, der udvider det, der allerede fungerer, ikke af at bygge uden om det eller tilføje noget helt nyt ovenpå. Sådan udvikler teams sig uden at ødelægge gennemprøvede systemer.
“Innovation behøver ikke at betyde forstyrrelse. Den bør styrke det, der allerede fungerer, og hjælpe kunderne med at bevæge sig hurtigere med mindre besvær,” siger Malhotra enkelt.
Vil du have flere indsigter som denne? Tilmeld dig The CTO Club-nyhedsbrevet.
