De flesta B2B-bolag har inget tillväxtproblem. De har ett arkitekturproblem.

När en grundare säger att de har ett tillväxtproblem har jag lärt mig att översätta. I nio fall av tio är tillväxten bara symtomet som går att mäta, pipeline som planade ut, kvartalet som missades, den nya säljaren som inte kommer upp i produktion. Det de faktiskt har är ett arkitekturproblem. Intäkterna läcker ut genom fogar som aldrig konstruerades för att hålla tryck, och hur mycket volym man än häller i toppen så tätar det inte en struktur som läcker i skarvarna.

Skillnaden spelar roll, för den avgör vad ni gör på måndag. Ett tillväxtproblem lockar er att göra mer av det ni redan gör: mer outbound, mer content, fler anställda, fler system. Ett arkitekturproblem säger åt er att stanna upp och fråga om det ni skalar över huvud taget är byggt för att skalas.

01 · SymtometMotorn går på grundaren

Den tydligaste diagnosen jag känner till är också den enklaste. Ta två veckors semester och titta på prognosen. Om affärer stängs för att du stänger dem, för att du råkar veta vilken invändning som ska tas i förväg, vem som faktiskt skriver under, när man ska tacka nej, då har du inget säljsystem. Du har en grundare som säljer, med ett CRM påskruvat för att det ska se ut som en process.

Det är ingen kritik. Grundarledd försäljning är precis rätt i början. Grundaren bär övertygelsen, kontexten och den mönsterigenkänning som ingen playbook ännu kan kodifiera. Problemet är att exakt det som tog er till några tiotals miljoner i omsättning är det som nu sätter taket. Mönsterigenkänning överförs inte av sig självt. Den går ut genom dörren varje kväll och tar prognosen med sig.

02 · FällanVerktyg är inte arkitektur

Det andra mönstret är närmast universellt. Någonstans på vägen mot skala gick bolaget och handlade. Ett CRM, ett sekvensverktyg, en intent-plattform, en content-motor, ett samtalsanalysverktyg, en dataleverantör. Varje inköp löste en verklig och lokal smärta. Ingenting av det ackumulerar värde, eftersom delarna aldrig designades för att passa ihop.

Arkitektur är inte summan av era verktyg. En hög med förstklassigt tegel är ingen byggnad. Det som gör komponenter till ett system är designen ovanför dem: de gemensamma definitionerna, överlämningarna, beslutsmandaten, datamodellen som låter ett steg informera nästa. Utan det designlagret ökar varje nytt verktyg ytan och driftskostnaden utan att öka hävstången. Ni känner er mer upptagna och bättre instrumenterade, och motorn kan precis lika lite som förut.

Det är därför ”vi behöver bara städa i CRM:et” sällan är den verkliga lösningen. CRM:et är stökigt för att processen det ska koda inte finns som en gemensam överenskommelse. Man konfigurerar sig inte ur ett definitionsproblem.

03 · Sex pelare, ett språkSå ser en designad motor ut

Varje kommersiell motor, oavsett bransch och säljmodell, går att lösa upp i sex dimensioner. Vi använder samma sex begrepp genom hela kundresan, medvetet, eftersom ett gemensamt språk i sig är en del av arkitekturen:

• Mål. En intäktsmodell byggd underifrån, ett KPI-träd, kapacitetsplanering och scenarier med utlösare i stället för önsketänkande.
• Kunder. ICP, segmentering, kvalificering, och, minst lika viktigt, vilka ni aktivt diskvalificerar.
• Budskap. Värdeerbjudanden, narrativ hierarki och de kanalanpassningar som håller berättelsen sammanhängande överallt där den dyker upp.
• Process. Pipeline-steg, exitkriterier och samarbetsavtalet mellan marknad och sälj.
• Organisation. Intäktsorganisationen, beslutsmandaten, successionen och de protokoll för kunskapsöverföring som gör att kunnandet inte försvinner med personer.
• Verktyg. Stackens arkitektur, dataintegration och attribution som faktiskt håller för granskning.

Poängen med att namnge alla sex är inte taxonomi för sin egen skull. Poängen är att svaghet i en pelare maskerar sig som ett problem i en annan. Grundare kommer till oss övertygade om att de har ett budskapsproblem, decket landar inte, när det verkliga felet sitter i Kunder: de berättar en alldeles utmärkt historia för fel segment. Eller så är de säkra på att de har ett processproblem eftersom affärer står still, när boven är Mål: det finns ingen gemensam definition av vilka affärer som över huvud taget hör hemma i pipeline.

04 · OrdningenDiagnostisera, bygg sedan

Är problemet arkitektoniskt är ordningen inte förhandlingsbar. Ni diagnostiserar innan ni bygger, och ni bygger innan ni optimerar. De flesta bolag gör tvärtom. De optimerar, A/B-testar ämnesrader, finjusterar annonsbudget, ovanpå en process som aldrig blev designad, och de bygger, rekryterar, lägger till verktyg, innan de vet vilken pelare det faktiskt läcker ur. Ansträngning går in; hävstång kommer inte ut.

En riktig diagnos poängsätter varje pelare ärligt: vilka som är bärande, vilka som är dekoration och vilka som tyst håller på att ge vika under den vikt ni lagt på dem. Den ger en karta över var intäkterna läcker och varför, och en prioriterad ordning för att åtgärda det. Den kartan är värd mer än något enskilt initiativ, för den säger lika mycket om vad ni inte ska göra som om vad ni ska göra.

Först när ni ser strukturen bygger ni, medvetet, pelare för pelare, där varje åtgärd är designad för att passa dem omkring sig. Och först när strukturen håller optimerar ni, för optimering är hävstång applicerad på ett system som fungerar. Applicerad på ett som inte gör det är den bara rörelse.

05 · Därför ackumulerar den värdeUtdelningen av design

Skälet till att arkitektur är värd obehaget i att sakta ner är att den, till skillnad från volym, ackumulerar värde. En dokumenterad playbook gör att nästa rekrytering kommer upp i produktion snabbare än den förra. Tydliga exitkriterier gör prognosen mer trovärdig för varje kvartal. En gemensam definition av ICP gör varje efterföljande beslut, budskap, kanal, prissättning, billigare att fatta och mer sannolikt rätt.

Verktyg skrivs av. Antal anställda är linjärt. Arkitekturen är den enda delen av motorn som blir mer värdefull ju längre den går, eftersom den förvandlar individuell ansträngning till organisatorisk förmåga. Det är hela poängen: att bygga ett system som kan gå, och förbättras, utan att vara beroende av grundarens mönsterigenkänning för att hänga ihop.

Så innan ni godkänner nästa verktyg, nästa rekrytering, nästa kampanj, ställ den svårare frågan. Är det här tillväxt, eller är det arkitektur? Läcker motorn hjälper det inte att fylla på mer bränsle. Designa strukturen först. Skala den sedan.