Defensibility handler om, hvor svært det er for en konkurrent at tage dine kunder, når den først beslutter sig for at prøve. Du måler det ud fra, hvad angriberen skal bruge: penge, tid eller adgang, den ikke kan købe sig til. Et produkt, som enhver udvikler kan genbygge på tre uger, har lav defensibility, uanset hvor godt det ser ud.
Defensibility og moat beskriver samme idé fra to sider. En moat er strukturen. Defensibility er den praktiske vanskelighed, en konkurrent møder, når den forsøger at trække en bestemt kunde væk. Du tester det kunde for kunde, ikke marked for marked.
Et eksempel. Du sælger bogføringssoftware til 900 små virksomheder, og hver konto indeholder tre års kategoriserede transaktioner. At skifte betyder at eksportere, genimportere og genkontrollere den historik. Budgetter otte timer af en bogholders tid til 65 euro i timen, og skiftet koster den kunde 520 euro. En konkurrent, der tager 29 euro om måneden, skulle give omkring 18 måneder gratis blot for at dække det, fordi 18 gange 29 er 522 euro. Det er defensibility, du kan sætte et tal på.
Kilder omfatter data, der kun findes, fordi kunden brugte dit produkt, integrationer til systemer, de er afhængige af, kontrakter, myndighedsgodkendelser og distribution, som en konkurrent ikke kan købe sig adgang til.
Misforståelsen er at sidestille defensibility med hemmeligholdelse. At skjule din kode beskytter kun lidt, fordi konkurrenter kopierer det synlige produkt, ikke implementeringen. En anden misforståelse er timing: mange grundlæggere skriver om defensibility, som om den allerede findes ved lancering. På dag ét er næsten intet forsvarligt.
Foundors genererede plan rejser spørgsmålet om defensibility i konkurrenceafsnittet. Det svar, der holder, er konkret: navngiv det, der ophobes i din virksomhed over tid, og hvad en konkurrent ville skulle bruge for at indhente det.
