Det mest brugbare nej, jeg har fået
Et nej om timing er mere brugbart end et nej om produktet. Det fortæller dig, hvad du skal bygge om, i stedet for hvad du skal blive bedre til at argumentere for.
Jeg fik et nej fra en revisor, og det var det mest brugbare nej, jeg har fået indtil nu.
Der var faktisk interesse. Problemet var, at firmaet havde skiftet system den 1. februar, og begrundelsen lød omtrent sådan her: det er et stort arbejde at skifte system, så det gør vi ikke lige igen.
Det, der slog mig, var nogle trætte aftener et halvt år tidligere, hos nogen, jeg aldrig har mødt, i et system, jeg ikke selv bygger.
Hvorfor det er en gave
Et nej er som regel ubrugeligt. Man får sjældent den rigtige grund at vide, og selv når man gør, handler den om noget, man ikke kan gøre noget ved lige nu.
Det her nej var anderledes, fordi det pegede på en helt bestemt uge i et helt bestemt firma. Der lå et stykke arbejde, som nogen havde lavet, og som havde været så ubehageligt, at det låste et indkøb i årevis bagefter.
Så gik det op for mig, at jeg havde tænkt på migreringen som kundens projekt. Noget, de skulle igennem, før min del begyndte. Set fra deres side var min del ikke begyndt endnu, og deres del var hele beslutningen.
Hvad jeg lavede om
Jeg brugte weekenden på at bygge onboardingen om, så det tunge er gjort, før nogen logger ind første gang. Klienter importeret, skabeloner og aftalebreve klar, mailen sat op.
Migreringen kører i baggrunden. Fra Penneo tager den cirka 20 minutter. Fra Creditro cirka 2 timer for 500 sager. Det er tal fra faktiske kørsler, og der er en pointe i, at de to er så forskellige: det ene system afleverer data, som var det tænkt til at blive flyttet, og det andet gør det ikke.
Resten kan gøres på en eftermiddag.
Ingen sætter flueben selv
Systemet verificerer selv hvert trin. Der er ikke et eneste sted, hvor man selv sætter flueben ved, at man er færdig.
Det lyder som en lille ting og er den beslutning, jeg har brugt mest tid på. En onboarding, man kan lyve sig igennem, er ingen onboarding.
Det gælder alle steder, hvor software beder et menneske om at bekræfte, at noget er gjort. Hver gang du lader brugeren markere et trin som færdigt, har du gemt en påstand i din database og behandlet den bagefter som en kendsgerning. Så vokser der en hel underskov af tilstande, der ser rigtige ud, og som ingen har tjekket. Det er den samme fejl, som når en model får lov at rapportere sin egen succes.
Så alle seks aktive trin bliver detekteret. Er firmainfoen udfyldt? Er der underskrivere? Er kollegerne inviteret rigtigt? Er der kørt en migrering, der faktisk stemmer? Og forsvinder en af dem igen, fordi nogen sletter en underskriver i marts, kommer trinnet tilbage.
Prøven er de næste firmaer
Onboardingen var en dag gammel, da jeg skrev det her ned. De næste firmaer skal vise mig, om den holder, og jeg har ingen tal på, om den flytter et eneste nej til et ja.
Det, jeg ved, er, at et systemskifte låser et hus i årevis, og at timing derfor er en større faktor end produktet i rigtig mange af de samtaler, jeg kommer til at have. Den slags kan jeg ikke bygge mig ud af. Jeg kan kun sørge for, at flytningen er en lille opgave den dag, nogen endelig står i vinduet.