När bygget blir billigt blir beslutet dyrt

Varje produktteam har känt det i år: en funktion som tog en sprint tar en eftermiddag, och backloggen töms fortare än någon hinner fylla på med saker som är värda att bygga. Den här artikeln svarar på vad det gör med produktrollen, med de mätningar som hittills publicerats och med urval och datum angivna vid varje siffra.

Är bygget verkligen billigare?

Ja, och den ärliga siffran är mindre än känslan. DORA-rapporten 2025, publicerad av Google Cloud den 23 september 2025 med nära 5 000 svarande, finner att 90 procent använder AI i arbetet och, för första gången, ett positivt samband mellan AI-användning och leveransgenomströmning. Samma rapport finner att AI-användning fortsatt har ett negativt samband med leveransstabilitet: mer förändring skeppas, och mer av den går sönder.

Lenny Rachitskys och Noam Segals enkät med 1 750 produktchefer, utvecklare, designers och grundare, publicerad den 23 december 2025, fann att över hälften sparar minst en halv dag i veckan på sina viktigaste uppgifter. Samma enkät fann att 92,4 procent rapporterar minst en betydande nackdel med verktygen. Båda talen är sanna samtidigt, och ett team som bara citerar det första planerar efter en fiktion.

Varför känns vinsten större än den är?

För att de som upplever den bedömer fel åt samma håll. METR körde en randomiserad kontrollerad studie, publicerad den 10 juli 2025: sexton erfarna utvecklare i öppen källkod, 246 riktiga uppgifter ur deras egna repon, varje uppgift slumpad till att tillåta eller förbjuda AI-verktyg. Med AI tillåtet tog uppgifterna 19 procent längre tid. Före studien hade utvecklarna förutspått 24 procent snabbare, och efter att ha upplevt inbromsningen trodde de fortfarande att AI gjort dem 20 procent snabbare.

Sexton utvecklare är ett litet urval och verktygen var modeller från början av 2025, vilket författarna själva skriver. Det studien slår fast är smalare och mer användbart än en dom över AI: upplevd fart är ett opålitligt instrument. Ett produktteam som vill veta sin verkliga hastighet måste mäta den — ledtid, andel misslyckade ändringar, DORA:s fyra mått — med verktygen på och av.

Vart flyttar flaskhalsen?

Till omdömet. När produktionen slutar vara gränsen avgör tre beslut utfallet, och inget av dem går fortare med en kodassistent.

• Vad som ska byggas: vilket problem, för vem, hur ofta det uppstår och vad det kostar att vänta tre månader.
• Hur ni ska veta att det fungerade: talet som måste röra sig, nedskrivet före bygget, med datumet då det ska läsas av.
• Om användaren kan lita på det: för en AI-funktion de fall där den får svara, de fall där den måste avstå, och hur säkerheten visas.

Marty Cagan skrev den 30 december 2024 att ”the PM role becomes more essential but also more difficult with generative AI-powered products, not less”, och reserverade sin entusiasm för kombinationen av ”someone with very strong judgement” och verktygen. Teresa Torres sa samma sak från discovery-sidan i april 2026: ”Building is very cheap now. That doesn’t mean we should build every idea we have.” Båda beskriver en roll vars knappa insatsvara är omdöme om vad som förtjänar att finnas.

Vad gör ett produktteam med det här?

Tre praktiska drag följer, och vart och ett är billigt att börja med.

• Mät hastigheten med verktygen på och av under en månad, och läs andelen misslyckade ändringar bredvid genomströmningen. DORA:s stabilitetsfynd är det de flesta team upptäcker sent.
• Skriv beslutet före bygget: en sida med problemet, alternativen på bordet, vad som valdes bort och vad som ska vara sant om två månader.
• Lägg de frigjorda timmarna på discovery och på evals. En intervju som syntetiseras av en person och sedan av en modell, och en AI-funktion som specas som testfall före den första prompten, är dit veckan nu går.

Prioriteringsmetoden finns beskriven i att bestämma vad som ska byggas härnäst. För en grundare med begränsad runway avgör samma logik vad det första bygget ska bevisa, och sidan för grundare beskriver den ordningen.

Så arbetar studion med det här

Torn Studios svar är en leveransmodell: en person håller produktrollen och bygger med AI-verktyg, så att ett beslut som tas på måndagen är i kod samma vecka. Kostnaden sägs lika rakt som vinsten. En persons vecka är kapaciteten, och ett team som behöver tre produktroller parallellt gör bättre i att anställa dem. Product Management prissätts per uppdrag, med omfånget satt i förväg och priset fast innan arbetet börjar.