”Produktdrevet” – det lyder godt, men hvad betyder det?

Påstand: De fleste organisationer lider ikke af mangel på udvikling, men af mangel på (fælles) retning.

Problemet, hvis jeg skal sætte det på spidsen, er, at der bliver leveret masser af nyt, når projekt-rutsjebanen suser derudaf med en rundtur omkring Marketing, Juridisk, Salg, Kundesupport osv. – men værdien er sværere at få øje på.

Det klassiske mønster ser sådan ud:

• Roadmaps fyldes med features
• Projekter bliver afleveret og/eller parkeret
• Organisationen bliver god til at producere, men mindre god til at lære

Og så kommer den ubehagelige sætning i kvartalsopfølgningen: “Vi har leveret alt det, vi sagde vi ville. Hvorfor kan vi ikke se effekten?”.

En produktdrevet tilgang, eller “product-driven” hvis vi skal være internationale, starter med at gøre det spørgsmål til et styringsprincip.

“Vi har leveret alt det, vi sagde, vi ville. Hvorfor kan vi ikke se effekten?”

Hvad er et produkt egentlig?

Et produkt er ikke bare en app, et system eller en teknisk løsning. Et produkt er en værdiskaber, der løser et reelt problem for kunder og brugere og samtidig skaber værdi for virksomheden – gennem indtjening, effektivitet eller markedsposition.

Tænk på produktet som en restaurantoplevelse: Maden betyder meget, men helheden afgør, om gæsten kommer igen. Bestilling, ventetid, service, atmosfære og betaling er ikke sideopgaver – de er en del af produktet.

På samme måde er onboarding, support, implementering, salg, marketing og drift ofte lige så afgørende som det, der bliver udviklet. Det er dér, friktion opstår, adoption dør, og værdi forsvinder – eller dér, tilfredshed og effekt for alvor skabes.

Netop derfor kan “produktdrevethed” ikke ejes af én rolle eller én afdeling. Produktet er en tværgående disciplin, fordi oplevelsen og værdien skabes på tværs.

Tænk på produktet som en restaurantoplevelse: Maden betyder meget, men helheden afgør, om gæsten kommer igen. Bestilling, ventetid, service, atmosfære og betaling er ikke sideopgaver – de er en del af produktet.

Fra projektlogik til produktlogik

Mange organisationer arbejder stadig efter projektlogik. Man definerer scope, sætter en deadline og planlægger leverancer, og succes bliver i praksis målt på, om man kom i mål til tiden og inden for budget. Det kan give ro i styringen, men det kan også skjule det vigtigste spørgsmål: Skabte det, vi leverede, faktisk en mærkbar effekt?

Forestil dig, at en organisation lancerer en ny selvbetjeningsløsning for kunder. Projektet bliver en succes på papiret. Alt bliver leveret som aftalt, go-live sker til tiden, og styregruppen klapper. De giver endda kage på lanceringsdagen plus middag med anstændig vin efterfølgende.

Men tre måneder senere ringer kunderne stadig til supporten i samme omfang, sagsbehandlingstiden er uændret, og medarbejderne har opfundet workarounds, fordi flowet ikke passer til virkeligheden. I projektlogikken er opgaven løst. I produktlogikken er arbejdet først lige begyndt.

I en produktlogik flytter man fokus fra output som features og leverancer til outcome: den effekt man skaber, de adfærdsændringer man ser hos brugerne, og den værdiskabelse der kan dokumenteres. Det skifte ændrer to ting fundamentalt:

1. Mål bliver styrende, ikke planerne.
2. Læring bliver en del af arbejdet, ikke noget der sker bagefter.

I projektlogikken er opgaven løst. I produktlogikken er arbejdet først lige begyndt.

Historien bag produktdrevet: Fra fabrik til feedback-loop

Begrebet ”produktdrevet” kommer ikke ud af ingenting. Det er et barn af flere idéstrømme, der hver især skubbede organisationer væk fra planstyring og hen mod læring og værdiskabelse.
‍

1. Lean: Mindre spild, mere flow
   Lean-traditionen (oprindeligt fra produktion) satte ord på en central ambition: at fjerne spild og optimere flow, så indsatsen bliver til værdi, ikke ventetid og overproduktion.
2. Agile: Reaktionsevne over detaljerede planer
   Agile-bevægelsen gjorde op med den tunge plan- og dokumentationskultur i software og satte samarbejde, fungerende leverancer og evnen til at reagere på forandring øverst.
3. Lean Startup: Byg, mål, lær
   Lean Startup populariserede idéen om, at fremskridt i usikre markeder måles som læring, og at man systematisk skal forkorte feedback-loopet: bygge, måle, lære.
4. Produktmodellen: Outcome, empowerment og ejerskab
   De seneste år er “produktmodel” og “product operating model” blevet et fælles sprog for organisationsdesign, hvor teams får ansvar for problemer (ikke bestillingslister) og måles på outcome.
   ‍

Den røde tråd: Værdi opstår ikke af at levere mere. Værdi opstår af at lære hurtigere, vælge klogere og justere løbende.

Outcome er en disciplin – ikke en KPI-øvelse

Når man siger “vi vil styre efter outcome”, lyder det ofte som noget, der hører hjemme i et dashboard. Men outcome er ikke bare et nyt sæt KPI’er. Det er en arbejdsform, hvor man konsekvent tvinger sig selv til at svare på det, der er svært, før man bygger det, der er nemt.

Det starter med tre spørgsmål, som mange springer over, fordi de tager tid og kræver uenighed i fuld offentlighed:

• Hvilken forandring vil vi skabe hos brugeren?
• Hvilken værdi skal produktet skabe for forretningen?
• Hvad vil vi måle som tegn på, at vi faktisk lykkes?

Når de spørgsmål er tydelige, ændrer samtalen sig. I stedet for “vi bygger X” begynder man at arbejde baglæns fra målet. Man formulerer hypoteser om, hvad der kan skabe den ønskede effekt, og man designer små og kontrollerede eksperimenter, der kan af- eller bekræfte hypoteserne, før man investerer tungt. Det er her, mange transformationer knækker. Teams får nye ceremonier og nye roller, men de får ikke nye måder at tænke mål, læring og prioritering på.

Data er produktets kompas

Hvis outcome er destinationen, er data det, der fortæller dig, om du kører den rigtige vej eller bare har god fart på. At være produktdrevet forudsætter, at man kan se, om målene nås, om adfærd ændrer sig, og om løsninger faktisk bliver brugt. Uden det bliver prioritering en blanding af mavefornemmelser og den stærkeste stemme i rummet.

Det betyder ikke, at alt skal reduceres til tal. Men det betyder, at data og metrikker ikke kan være et sideprojekt, I bestiller på et tidspunkt. Det er en kernekompetence i produktorganisationer, fordi den gør læring konkret. Hvad virker? Hvad virker ikke? Og hvad skal vi gøre mere eller mindre af?

At være produktdrevet forudsætter, at man kan se, om målene nås, om adfærd ændrer sig, og om løsninger faktisk bliver brugt.

Skab alignment ellers går det skævt

En af de mest almindelige fejl er at behandle det at arbejde produktdrevet som noget, produktfolk bare kan rulle ud til resten af organisationen.

Det ender typisk med to parallelle virkeligheder: Produktteams taler om outcome og læring, mens resten af organisationen stadig styrer efter leverancer, deadlines og projektplaner. Og så opstår friktionen.

Forestil dig en B2B-virksomhed, der vil øge aktiveringen i et nyt produkt: Flere kunder skal fra “vi har købt det” til “vi bruger det” inden for de første 30 dage. Produktteamet vil arbejde produktdrevet og går i gang med at undersøge, hvor kunderne falder fra. De vil forenkle onboarding, teste en mere guidet opsætning og måle på aktiveringsrate, tid til første succes og frafald i opsætningsflowet.

Samtidig danser resten af organisationen til en anden melodi. Kundesucces bliver målt på antal gennemførte onboarding-calls, ikke på om kunderne faktisk bliver selvkørende. Salg har lovet specifikke features til to store kunder og presser på for at få dem på plads inden næste review.

Marketing har planlagt en kampagne, der sender flere leads ind, selvom produktet ikke er nemt at komme i gang med endnu. Og økonomi vil have en fast leveranceplan, fordi budgettet er bundet op på konkrete milepæle.

Resultatet er, at produktteamet konstant bliver trukket væk fra at forbedre aktiveringen og over i at levere det, der passer ind i andres mål og kalender. Alle leverer på deres KPI’er, men den fælles effekt udebliver, fordi der ikke er ét fælles succeskriterium, der trumfer de andre.

At arbejde produktdrevet kræver, at flere dele af organisationen flytter sig i takt. Ledelsen skal sætte retning, definere rammerne og gøre prioritering til et reelt valg. Teams skal have kompetencer og mandat til at levere og lære. UX og design skal bringe brugerindsigt tættere på beslutningerne. Data og analytics skal være en integreret del af produktarbejdet, så læring bliver løbende. Og HR skal understøtte de kompetencer og den organisering, der gør det muligt.

Når kun dele af organisationen skifter logik, opstår der siloer, og effekten udebliver. Ikke fordi nogen vil det dårligt, men fordi styringssystemet trækker i én retning, mens ambitionen peger i en anden.

Produktteams taler om outcome og læring, mens resten af organisationen stadig styrer efter leverancer, deadlines og projektplaner. Og så opstår friktionen.

Funding er dér, produktlogik bliver testet

Et af de steder, hvor forskellen mellem projekt- og produktlogik bliver helt konkret, er i funding. I klassisk budgetstyring finansierer man ofte planer: et projekt med et scope, en tidsplan og et forventet output.

Men produktlogik handler om noget andet. Her finansierer man i højere grad teams og produkter over tid, fordi værdiskabelse sjældent er en engangsleverance. Den kræver kontinuitet, ejerskab og mulighed for at justere kursen, når man lærer noget nyt.

Logikken er enkel – man finansierer teamets potentiale til at skabe værdi og bruger data og læring til løbende at justere investeringerne. Det er svært i organisationer, der er bygget op omkring projektporteføljer og årlige budgetcyklusser. Men hvis man vil have reelle outcome-resultater, er det ofte en nødvendig bevægelse, fordi den skaber stabilitet omkring det, der skal forbedres over tid, og fleksibilitet i forhold til hvordan.

Tre spørgsmål afslører, om I er på vej

Hvis du vil teste, om I er produktdrevne i praksis og ikke kun i sprog, så start her:

1. Er I enige om, hvad produktet er, og hvilken værdi det skal skabe for både bruger og forretning?
2. Bliver teams målt og styret på outcome, eller primært på leverancer?
3. Har I data nok til at lære hurtigt nok, og bruger I den læring til at prioritere?

Hvis svaret er “tja” på bare ét af dem, er der sandsynligvis mere at hente i fælles klarhed end i flere processer. Og det er i virkeligheden den mest produktdrevne pointe af dem alle.

📺 Se også webinaret med Peter Lindberg:
‍De siger, vi skal være produktdrevne – men hvad f***** betyder det?

‍