Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.
Softwareudviklere elsker - med et glimt i øjet - at hade sælgere.
Sælgere er generelt lidt for glatte, lidt for smilende, lidt for hjertelige og også dygtige til at undvige eller parere, når man fagligt argumenterer for sine forbehold overfor det system, man lige har fået præsenteret og lynhurtigt har spottet ikke vil fungere.
Alle alarmklokker ringer, men kun for de kodekyndige, mens alle andre mentalt er i fuld gang med at designe og implementere den forestående katastrofe.
Lad os for nemheds skyld kalde softwaresystemet for XYZ og XYZ’s repræsentant(er) under mødet for “sælger”.
Problemet er, at softwareudviklere generelt er dårlige sælgere selv og derfor gang på gang bliver kørt ud på et sidespor, når beslutninger ikke bliver truffet på baggrund af data og faglige argumenter.
Jeg har tidligere selv oplevet at fejle i mine forsøg på at retfærdiggøre overfor de reelle beslutningstagere i lokalet, hvorfor et stykke teknik ikke kan blive en succes i virksomheden.
Det tog en del år, før jeg begyndte at forstå mekanismerne i det, der foregik og hvorfor mine forsøg på at få andre til at fatte XYZ’s åbenlyse mangler ikke lykkedes.
Mange og kompleske årsager
Årsagerne til, at XYZ ikke er det rigtige produkt i situationen, kan være mange og komplekse.
Produktet er måske godt nok, men ikke bygget til den størrelse virksomhed, du arbejder i.
Et enterprise produkt er sjældent et godt fit, hvis man arbejder i en virksomhed med 20-25 ansatte uanset, at det er uhyre generisk og, citat sælger: “...med lidt hjælp fra en af jeres dygtige udviklere kan XYZ skræddersys til lige præcis jeres behov”. Yrk…
Omvendt kan et produkt også være godt, men for småt eller for komplekst at sætte op, fordi jeres virksomhed reelt beskæftiger sig med et andet domæne end det, XYZ egentlig er bygget til.
Nogle gange kræver det bare en høj grad af teknisk indsigt samt en vis mængde domæneviden at kunne gennemskue, hvorvidt XYZ passer ind eller ej.
Derfor er softwareudviklere med forretningsforståelse i så høj kurs - de er nogle af de få, der kan italesætte og forstå prioriteringer på ledelsesgangen og tillige har teknisk detailviden til at have et overblik over hele virksomhedens værdikæden fra start til slut.
De kan derfor som de eneste reelt gennemskue, hvorvidt XYZ understøtter virksomhedens nuværende og fremtidige behov.
De højt besungne profiler
Udfordringen her kan være, at disse højt besungne profiler ikke konverterer deres viden til reel indflydelse ved at stemple ind og ikke mindst ud på de rigtige tidspunkter.
Fejl nummer 1, en softwareudvikler med forretningsforståelse kan begå op til en præsentation af XYZ, er ikke at forstå sin rolle til mødet og forberede sig derefter.
Det handler for eksempel om at læse publikum i god tid inden mødet.
Sagt på en anden måde: Man siger i poker, at hvis du sætter dig ned ved et bord og efter 10 minutter ikke har spottet, hvem der er det svageste led - så er det DIG, de andre vil forsøge at blanke af.
Det samme gør sig i store træk gældende hér, specielt hvis du arbejder i en kompleks organisation med mange, nogle gange modstridende interesser på spil.
Hvem er inviteret?
Spørg derfor dig selv: Hvem er inviteret til mødet? Er du den eneste person med teknisk indsigt til stede i rummet?
Er der andre end dig - hvis ja, hvem er de og hvorfor er de inviterede?
Følg pengene: Er der beslutningstagere til stede (ham eller hende med det store stempel) eller er det udelukkende stråmænd, der blot skal videreformidle deres indtryk af XYZ højere op i systemet?
Spørg andre, du har gode relationer til, om der reelt er tale om en åben udvælgelse eller er beslutningen om et køb allerede truffet, måske andetsteds, som del af en anden aftale?
Den slags forberedelse kan i nogle tilfælde være langt vigtigere end hvilke features XYZ indeholder. Undervurder aldrig, hvor meget signalværdi, der kan ligge i et nej til en mødeindkaldelse.
Du vil drage stor nytte af først at læse publikum, inden du ser på, hvad XYZ er for noget, specielt hvis projektet er politisk ladet (led efter ordene “strategisk betydning”, “must-win battle” og lignende).
Kæmp for ikke at blive inddraget
Hvis du ser store røde lamper blinke, så gør alt, hvad du kan for ikke at blive inddraget.
Find på en undskyldning, et andet projekt med en snarlig deadline, der har højere prioritet end et salgsmøde.
Meld dig i alleryderste konsekvens syg, hvis du finder det påkrævet - hvis du helt oprigtigt ikke mener, dine indvendinger alligevel ikke vil blive taget alvorligt, hvorfor så involvere sig? What’s in it for them? What’s in it for you?
Hovedreglen er dog heldigvis, at dine ledere tager dig med, fordi de stoler på dig og har brug for dig.
Du er inviteret, fordi du har vist, du bringer din faglighed og domænekendskab i spil til fordel for virksomheden. Dine eventuelle forbehold vil have betydelig vægt i det videre forløb. Du er med, fordi du er vigtig for virksomheden.
Max tre ture - og så skal du tie stille
Det leder mig til fejl nummer to: Du er med og tror, at man automatisk har veto-ret, fordi man er tekniker til en XYZ præsentationen og fejlagtigt antager, at et nej fra dig er lig med et “farvel og tak, vi ringer om et par dage”.
Det er jo dig og dine lønkroner, der skal kode på systemet, så selvfølgelig vil der ikke blive købt noget ind, hvis du siger nej, ikke?
Hvis man vil have veto-ret i en virksomhed, så skal man sørge for at sidde for bordenden som direktøren for det hele.
Misforstår man sin rolle også i denne sammenhæng, så er risikoen for at blive stemplet som en primadonna med nykker overhængende, fordi man i et tiltagende skingert tonefald gentager de samme tekniske argumenter igen og igen.
Den slags er absolut ikke karrierefremmende, men giver kun dine kollegaer en masse at snakke om, når du ikke er til stede, specielt hvis du er mut og fornærmet resten af mødet.
Pas på med det - max tre ture i manegen med samme argumentation og derfra, så skal du enten finde på noget bedre eller tie stille.
Nuvel. Du sidder til XYZ præsentationen, du er med i samtalen og folk lytter, hvis du åbner munden. Salgstalen med tilhørende Powerpoint er ovre - hvad så nu?
Jeg vil foreslå at stille sælger spørgsmål i følgende tre kategorier for at afdække, hvad XYZ reelt er for en størrelse og for at indsamle kvalitative data som input til det videre forløb: “Kan du fortælle om sikkerhedsmodellen i XYZ”?
Her er du på hjemmebane
Start en diskussion om sikkerhed og sikkerhedsaspekter i XYZ.
Det er et område, hvor du kan bringe din tekniske indsigt i spil, ligesom sikkerhed også har/skal have ledelsens bevågenhed set i lyset af, hvor højt sikkerhed er kommet på dagsordenen de seneste 8-12 måneder.
Sikkerhed er et område, hvor du lynhurtigt vil få at se, hvorvidt repræsentanten for XYZ rent faktisk kender og har brugt produktet igennem længere tid - ved vedkommende egentlig, hvilke større enkelt-dele, et single signon består af og hvorvidt XYZ understøtter den ADFS, som I har kørende?
Der er grænser for, hvor teknisk man bør blive (igen, hvem er med på mødet?), men fokuser som udgangspunkt på slutbruger-oplevelsen, såsom understøttelsen af SSO og de store linier heri.
I disse tider kan du med fordel også dreje diskussionen ind på GDPR, og hvordan XYZ understøtter de usecases, som GDPR dikterer omkring for eksempel anonymisering af historiske data.
Der vil altid være sikkerhedsmæssige fokusområder, der ligger højt på dagsordenen i medierne og i specifikke brancher, så tag fat i dem, der giver mening i forhold til produktet.
Uanset udfaldet, så vil en diskussion om sikkerhed være værdifuld input i det videre forløb og du vil have gjort en forskel på mødet ved at italesætte sikkerhed som en høj prioritet.
“Hvornår har du sidst selv foretaget en installation af XYZ”?
Der er mange afarter af spørgsmålet afhængigt af, hvad XYZ er - ideen her er at trykprøve sælgers erfaring med produktet udover den salgstale, du lige har hørt og som vedkommende har gennemført mange gange før.
Hvis det er for eksempel et opensource-produkt, og du taler med en fra et konsulenthus, der påkalder sig at være førende ekspert på lige præcis dét produkt, så kan man spørge om, hvordan firmaet er aktiv i communityet omkring produktet. Koder de selv på produktet? Hvad er det i så fald, de har bidraget med?
Det kan også være et enterprise closed-source produkt, der er tale om - her må man så være lidt mere kreativ og måske spørge til, hvor mange installationer, vedkommende selv har foretaget hos andre kunder.
Hvor mange? På hvilke versioner? Hos hvilke kunder?
Afhængig af temperaturen i mødelokalet og fortroligheden imellem jer, må du så kontakte en reference hos et tidligere firma for at høre om deres erfaringer?
Har sælger et dybere kendskab?
Hvis vedkommende glider af eller svarer på noget andet end det, du spørger ind til, så er det sandsynligt (men ikke bevist), at sælger ikke har et dybere kendskab til produktet udover et udvidet produktblad og sunshine casestudies, man kan finde på XYZ’s hjemmeside.
Fremfor alt, så opsøg ikke nødvendigvis konflikten, selvom der er potentiale (fejl nummer tre?).
Tænk dette spørgsmål som en hjælp til sælger, så vedkommende får lejlighed til at snakke sig ind på, hvor bredt funderet vedkommende er f.eks på baggrund af mange forskellige installationer hos mange forskellige firmaer. Vedkommende kan så gribe chancen eller lade være - du leverede et godt oplæg, vedkommende må selv sparke den ind over stregen.
Tag noter, hvis sælger i dine øjne falder igennem og brug dem, når I internt laver en plus-minusliste hos de forskellige leverandører, der er i spil.
“Hvad klager jeres kunder mest over for tiden?”
En god måde at teste troværdigheden af en sælger er ved at spørge ind til dem, der bruger produktet, men som ikke har haft udelukkende gode oplevelser. Alle firmaer med mange kunder har utilfredse brugere og hvor er det i XYZ’s tilfælde, der gør ondt?
Eksempel: Hvis I diskuterer på mødet, hvilken version af XYZ, I skal starte på, så kan det være en god ide at fokusere på de eksisterende kunders oplevelse af produktet.
Som del af din forberedelse skal du kigge efter, hvorvidt XYZ arbejder målrettet med sine kunder på at finde og rette de uhensigtsmæssigheder, der altid opstår.
Jeg vil tro, du på store systemer i løbet af en times tid vil kunne afdække via sociale medier, forums osv., om der danner sig et billede af specifikke typer af problemer på XYZ-installationer af den type, I har i tankerne i jeres firma. Er der generelle performanceproblemer? Klager brugere af XYZ over dårlig support?
Se efter trends
Se efter trends - tag noter og spørg ind til det, du ser, kunderne beskriver og spørg så ind til det, du har noteret dig, med nogle velvalgte HV-ord.
Der kan være gode forklaringer på, at XYZ har haft problemer, så giv sælger mulighed til at svare for sig og være ærlig omkring de ting, du har fået øje på.
Du kan bruge situationen til at hjælpe sælger til at skabe troværdighed til produktet og det firma, han repræsenterer.
Igen, så vil en diskussion om andre kunders oplevelser af XYZ uanset svarene fra sælger give værdifuld feedback til jer i det videre forløb.
Der er naturligt nok ikke en færdig skabelon for, hvad du skal spørge om for at få de svar, I har brug for til at komme videre, men disse spørgsmål eller kategorier af spørgsmål er en destilleret version af, hvad jeg selv har lært og set virke gennem en del år efterhånden i branchen.
Hvad virker for dig og hvad har du selv været vidne til?
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.