Vi ser samma mönster om och om igen: ett team får i uppdrag att bygga en intern plattform, levererar en imponerande mängd Terraform, Kubernetes och pipelines — och två år senare använder halva organisationen den fortfarande inte. Tekniken är sällan problemet. Problemet är att plattformen byggdes som ett IT-projekt, inte som en produkt.
Ett projekt tar slut. En produkt gör aldrig det.
Ett projekt har en budget, en deadline och ett slutdatum. Du bygger det, du levererar det, du bockar av det. En produkt har användare, en roadmap och en livscykel — den blir aldrig ”klar”, den blir bara mer eller mindre värd att använda.
När du behandlar din interna plattform som ett projekt optimerar du för leverans: bli klar i tid, håll budget, stäng ärendet. När du behandlar den som en produkt optimerar du för användning: löser den ett verkligt problem för de utvecklare som ska leva med den varje dag?
Skillnaden låter akademisk tills du ser konsekvenserna. Projekt-plattformen är tekniskt korrekt och samlar damm. Produkt-plattformen är kanske mindre elegant under huven — men folk använder den frivilligt.
Vem är kunden? (Ledtråd: inte du)
Den svåraste vanan att bryta är att bygga plattformen du själv skulle vilja ha. Plattformsteam är ofta de mest seniora ingenjörerna i organisationen, och de bygger därefter — kraftfulla abstraktioner, oändlig konfigurerbarhet, ”gör-vad-du-vill”-flexibilitet.
Men kunden är inte plattformsteamet. Kunden är utvecklaren som bara vill deploya sin tjänst innan lunch utan att läsa 40 sidor dokumentation. För den personen är flexibilitet inte en gåva — det är en räkning. Varje val du skjuter över på användaren är ett beslut de måste fatta, ofta utan att ha kontexten.
En bra intern plattform gör det tråkiga valet åt dig och lämnar dörren öppen för de fall då du faktiskt behöver något annat. Det är hela poängen med golden paths: det rätta sättet ska också vara det enklaste.
Adoption är sanningens minut
Det finns ett mätvärde som avslöjar om du byggt en produkt eller ett projekt: hur många använder plattformen utan att bli tvingade?
Om svaret vilar på ett mandat uppifrån — ”alla team ska migrera till plattformen till Q3” — då har du inte byggt en produkt. Du har byggt en skatt. Tvingad adoption döljer alla problemen: folk använder plattformen för att de måste, klagar i det tysta och hoppar av så fort någon tittar bort.
Frivillig adoption är obekvämt ärligt. Om utvecklare väljer din plattform framför att bygga eget, då löser den ett verkligt problem. Om de inte gör det, då gör den inte det — och ingen mängd interna direktiv fixar det på riktigt. De bästa plattformsteamen vi sett behandlar varje team som en kund de måste vinna, inte en användare de redan äger.
En roadmap, inte ett engångsbygge
Produkter har roadmaps. De har feedback-loopar, releaser och en backlog av saker användarna faktiskt bett om. De har någon som äger frågan ”vad bygger vi härnäst, och varför?”. Interna plattformar behöver samma sak. I praktiken betyder det:
- en produktägare — formell eller inte — som äger vad som byggs härnäst och varför
- en feedback-loop där användare enkelt kan säga vad som är trasigt
- dokumentation och onboarding som en del av produkten, inte något ni skriver om ni hinner
- support som förstklassig uppgift — när en utvecklare kör fast, är plattformsteamet en hjälp eller ett hinder?
Det låter som mycket overhead för ett internt verktyg. Men det är exakt den overhead som skiljer en plattform folk räcker efter från en de går runt.
Vårt korta svar
Om ingen utanför plattformsteamet frivilligt använder plattformen spelar det ingen roll hur välbyggd den är. Behandla den som en produkt: känn din kund, mät verklig adoption och lyssna på dem som lever med den varje dag. Tekniken är den lätta delen — det har den alltid varit.
Den bästa interna plattformen är inte den med flest funktioner. Det är den som folk skulle sakna om den försvann.