Pricing er product management i forklædning

Jeg har lært at behandle pricing med samme respekt, som jeg giver et product roadmap. Ikke fordi det er elegant. Men fordi det er operationelt nødvendigt.

Når pricing er uklar, bliver hvert tilbud et særtilfælde. Rabatter bliver det reelle produkt. Sales ender med at bære dine positioneringsbeslutninger på skuldrene, og de gør, hvad enhver dygtig sælger gør under usikkerhed: lukker aftalen. Det er ikke et moralsk problem. Det er et ledelsesproblem.

Jeg har set mønsteret fra flere vinkler. I industriel teknologi viser pricing drift sig som marginlækage på tværs af konfigurationer, servicevilkår og leveringsløfter. I SaaS viser det sig som packaging-kaos, en pricing-side ingen stoler på, og renewals der føles som forhandlinger frem for et system. I begge tilfælde er roden den samme: ingen driver pricing som et produkt.

Min pointe er enkel: pricing er product management i forklædning. Det kræver hypoteser, segmentering, packaging, eksperimenter og tydeligt ejerskab. Og det kræver en stram kobling til gross margin og leveringsomkostninger—ellers skriver du bare historier med tal på.

Det øjeblik du ikke kan forklare prisen, mister du kontrollen

Da jeg ledede en dansk forretningsenhed i en europæisk smart-building- og home-automation-koncern, havde jeg fuldt P&L-ansvar. Vi leverede connected sensorer og bygningsstyring på tværs af flere lande. Produktporteføljen så sammenhængende ud på slides, men virkeligheden var mere rodet: forskellige kanaler, forskellige kundetyper, forskellige serviceforventninger og forskellige konkurrencemæssige ankre.

I den virkelighed er den hurtigste vej til kaos at lade pricing være “det vi gjorde sidst”. Den næsthurtigste er at lade det være “det sales tror kan vinde i dette kvartal”. Så ender du med et skygge-prissystem bygget af undtagelser: særlige rabatter, skræddersyede bundles, gratis ydelser, forlængede betalingsvilkår og vage løfter, der senere lander som arbejde i driften.

Når det først sker, styrer du ikke prisen. Du styrer fortrydelse.

Derfor begyndte jeg at stille ét spørgsmål, som lyder enkelt, men er brutalt afslørende: Hvorfor tager vi den pris vi tager—for denne kunde, for dette scope, med disse vilkår? Hvis svaret er en fortælling frem for en testbar logik, har du ikke pricing. Du har improvisation.

Driv pricing som et produkt: ejerskab, backlog og releases

Det første skifte er mentalt. Det næste er strukturelt.

Pricing skal have én tydeligt ansvarlig owner. Ikke “finance plus sales plus product i en komité”. Komitéer kan reviewe. De kan ikke eje. Owneren kan sidde i product, det kommercielle eller general management, men skal have mandat til at ændre packaging, rabatregler og approval flows.

Derefter bygger du en pricing-backlog. Helt konkret. En prioriteret liste over pricing-opgaver på samme måde, som du ville styre features:

• Segmenteringsbeslutninger: hvilke kundetyper der skal have forskellige value narratives og forskellige price metrics.
• Packaging-beslutninger: hvad der er inkluderet, hvad der er optional, hvad der er gated, og hvad der er non-negotiable.
• Policy-beslutninger: rabatintervaller, deal desk-regler, approval thresholds og undtagelser, der skal udløbe.
• Instrumentering: hvad du vil måle, så pricing bliver et system—ikke en diskussion.

Til sidst leverer du pricing i releases. Ikke én gang om året. Ikke hver gang du panikker. Pricing-releases kan være små og hyppige: en skarpere package boundary, et nyt add-on, en justeret metric, en opryddet quote-template, en strammere discount policy. Små releases reducerer frygt og mindsker blast radius.

Fire pricing-artefakter jeg læner mig op ad (fordi diskussioner er dyre)

Over tid har jeg lært at læne mig op ad fire enkle artefakter. De er ikke fancy. De forebygger endeløse debatter og tvinger beslutninger frem i lyset.

1) Value metric-statement

Én sætning: “Vi tager betaling baseret på X, fordi X er den bedste proxy for den værdi, vi leverer.” Hvis du ikke kan skrive den, er du ikke færdig.

I SaaS kan det være en usage metric. I industrivirksomheder kan det være kapacitet, throughput eller et defineret scope of supply med tydelige afgrænsninger. Pointen er ikke at være smart. Pointen er at være defensible.

2) Packaging boundary-dokumentet

En side, der siger hvad der er med i base offering, hvad der er optional, og hvad der eksplicit er out of scope. Det er her, marginen beskyttes.

Jeg lærte det på den hårde måde i industrielle kontekster, hvor “små” ekstraer bliver til tilbagevendende omkostninger. Et løfte givet i en salgsdialog kan blive til måneder med engineering support, særlig QA, custom dokumentation eller service-undtagelser. Hvis du vil have et rent P&L, skal du have rene grænser.

3) Discount ladder med udløb

Discounting er ikke ondt. Ubegrænset discounting er. En ladder sætter intervaller, kræver en reason code og tvinger en expiry date på enhver undtagelse.

Udløbet er afgørende. Ellers bliver enhver undtagelse en præcedens—og præcedenser er sådan, din listepris dør stille og roligt.

4) Margin waterfall som sales kan forstå

Hvis sales ikke kan se, hvordan vilkår og scope påvirker gross margin, optimerer de mod revenue. Det er rationelt. Din opgave er at give dem en model, der gør margin synlig og anvendelig.

Da jeg som tidligere COO drev operations inden for elektrificering og energy storage, var cost drivers ikke abstrakte. Engineering-tid, produktionskompleksitet, supply chain-begrænsninger, serviceforpligtelser og warranty-exposure var konkrete. En margin waterfall, der kobler kommercielle vilkår til operationelle omkostninger, er sådan du stopper med at forære værdi væk—uden at gøre sales til revisorer.

Kontrollerede eksperimenter, ikke pricing-debatter

Når fundamentet er på plads, kan du begynde at arbejde som et product team: formulér en hypotese, test den, og behold det der virker.

Jeg kan godt lide eksperimenter, der er svære at game og lette at måle:

• Packaging A/B: to bundles med tydelige forskelle, tilbudt efter regel til et defineret segment.
• Fence tests: et nyt prisniveau kombineret med en begrænsning (support tier, SLA, lead time) for at se, om kunder reelt værdsætter opgraderingen.
• Channel consistency checks: samme segment, forskellig kanal—sammenlign rabatadfærd og churn eller repeat purchase.
• Term monetization: prissæt det du i dag giver væk, fx hurtigere levering, udvidet garanti, højere service levels eller integrationssupport.

Eksperimenter fejler, når virksomheder forsøger at teste alt på én gang. Pricing er et system. Ændr én lever, observer, og skift så den næste.

I mit venture-arbejde er den disciplin ikke til forhandling. Med Shopeno, hvor modellen er 0 procent omkostning og 0 procent kommission for lokale shop owners, er pricing ikke bare et tal. Det er positionering, distribution og tillid. Du kan ikke “discount’e” dig til klarhed, når kerne-løftet allerede er offensivt. Det tvinger en product-tilgang: definér value exchange præcist, beslut hvad der monetiseres (og hvorfor), og hold systemet sammenhængende.

Den kvartalsvise checklist jeg bruger til at holde pricing sund

Her er den operating cadence jeg ville implementere i dette kvartal, hvis pricing føles glidende. Til ejere og operatører, der vil have vækst uden at forære værdi væk.

1. Skriv pricing-narrativet i almindeligt sprog: ét afsnit der forklarer værdi, segmentering og metric. Hvis det læser som marketing, så skriv det om.
2. Frys package boundaries: publicér hvad der er in og out, og gør quoting afhængig af det.
3. Indfør en discount ladder: sæt thresholds, reasons, approval og expiry dates.
4. Start med maksimalt tre segmenter: målet er gentagelighed, ikke akademisk præcision.
5. Vælg ét eksperiment: packaging, terms eller add-ons. Kør det i en afgrænset periode med ren måling.
6. Review margin waterfall pr. segment: ikke kun gennemsnitsmargin. Kig efter hvor kompleksitet og løfter spiser profit.
7. Dræb én undtagelse: fjern én tilbagevendende “special case” fra systemet. Det er ofte her, den reelle leverage ligger.

Hvis du vil have en parallel fra et andet område, ser jeg samme operationelle behov i AI-programmer: de bedste teams behandler arkitektur som en checklist—ikke som et diagram. Samme disciplin gælder her. Pricing er et operating system. Hvis du ikke ejer det, kommer det til at eje dig. (Relateret: AI Architecture Isn’t a Diagram. It’s an Operator’s Checklist.)

Min holdning: stop med at delegere pricing til felten

Jeg argumenterer ikke for rigid pricing, der ignorerer virkeligheden. Jeg argumenterer for eksplicitte pricing-beslutninger der matcher dine produktgrænser og dine leveringsomkostninger. Fleksibilitet er fint, når det er governed. Kaos er dyrt, når det bliver normaltilstand.

Hvis du ikke kan forklare, hvorfor du tager den pris du tager, er du ikke “customer-centric”. Du er uafklaret. Og sales vil beslutte for dig—én aftale ad gangen.

Behandl pricing som product management. Giv det en owner. Byg artefakterne. Kør kontrollerede eksperimenter. Kobl hver ændring til margin-effekt og leveringsrealiteter. Så kan du vokse uden at forære værdi væk.