Outbound programuotojų įrankių įmonėms

Dvi auditorijos, priešingas skonis, viena žinutė

Daugumoje B2B programinės įrangos rinkų pirkėjas ir naudotojas persidengia tiek, kad viena žinutė tinka abiem. Programuotojų įrankiuose jie išsiskiria, ir išsiskiria ne pagal pareigų lygį, o pagal tai, ką kiekvienas laiko įrodymu.

Inžinerijos vadovas arba platformos vadovas, kuris pasirašo, galvoja apie kaštus, riziką, įdiegimą ir apie tai, kas bus, jei tiekėjas dings. Programuotojas, kuris tą įrankį naudos, galvoja, ar jis iš tikrųjų veikia, ką daro esant apkrovai ir ar tai dar vienas sluoksnis, kurį reikės prižiūrėti.

Žinutė, parašyta vien pasirašančiajam, programuotojui atrodo kaip rinkodara, ir jis ją tyliai nužudo be paaiškinimo. Žinutė, parašyta vien programuotojui, niekada nepasiekia biudžeto. Ji turi padaryti abu, o praktiškai tai reiškia techninį teiginį su komercine pasekme: ką sistema daro ir ką tai sutaupo.

Praktinis būdas patikrinti, ar žinutė tinka abiem: perskaitykite ją kaip programuotojas ir paklauskite, ar suprantate, kas techniškai vyksta. Paskui perskaitykite kaip vadovas ir paklauskite, iš kurio biudžeto tai mokama. Jei bent vienas atsakymas neaiškus, žinutė dar nebaigta.

Veto yra ta dalis, kurią iš šalies nuvertina. Inžinerijos organizacijose nemėgstamas įrankis nebūna įdiegtas, kad ir kas jį pirko, o sutartis tyliai nutrūksta pratęsimo metu. Parduoti pro programuotoją reiškia gauti parašą ir po dvylikos mėnesių neturėti pajamų.

Bottom-up ir top-down yra skirtingi produktai

Programuotojų įrankių įmonės nuolat bando abi kryptis viena žinute, o jos struktūriškai nesuderinamos.

Bottom-up reiškia, kad vienas programuotojas įsidiegia įrankį nieko neklausęs, o paskyra vėliau užauga į sutartį. Tam reikia tikrai naudingos nemokamos versijos, savitarnos be pokalbio ir dokumentacijos, kuri pakeičia pardavėją. Outbound čia vaidina nedidelį vaidmenį, daugiausia verčiant esamą naudojimą į sutartį.

Top-down reiškia, kad organizacija priima diegimo sprendimą, dažniausiai dėl valdysenos, kaštų konsolidavimo, atitikties ar nustatyto standarto. Būtent čia outbound veikia, ir žinutė kalba apie organizaciją, o ne apie atskirą programuotoją.

Klaida yra bottom-up produktas, parduodamas top-down. Žinutė pasiekia inžinerijos vadovą, jis klausia komandos, o komanda apie tai negirdėjo ir neturi priežasties norėti. Priešinga klaida yra top-down produktas, reklamuojamas bottom-up: programuotojai išbando, jiems patinka, ir niekas nemoka, nes vertė atsiranda tik organizacijos mastu.

Nuspręskite prieš seką, kuris iš dviejų esate. Atsakymas dažniausiai matomas kainų puslapyje.

Yra ir mišrus atvejis, sunkiausias: produktai, kuriuos pavieniai programuotojai mielai naudoja ir kurie pinigų verti tik kartu. Ten teisinga tvarka yra prieš pirmą žinutę žinoti, kiek įmonėje jau naudojama, ir būtent tą naudojimą padaryti kreipimosi priežastimi.

Mechanizmas nugali naudos pažadą

Klasikinė B2B tekstų taisyklė liepia rašyti naudą, o ne funkcijas. Programuotojų įrankiuose ta taisyklė kenkia, nes naudos pažadas be mechanizmo yra požymis produkto, kuris neveikia.

Programuotojai vertina per klausimą kaip. Žinutė, sakanti, kad produktas sutrumpina build laiką, nepasako nieko patikrinamo. Žinutė, sakanti, kad jis kešuoja priklausomybių sprendimą tarp šakų, todėl inkrementiniai build praleidžia konkretų žingsnį, pasako tai, ką programuotojas iškart palygina su savo sąranka, o nauda išplaukia savaime.

Tai sprendžia ir dviejų auditorijų problemą, nes aiškiai įvardytas mechanizmas skaitomas ir vadovui. Jis skaito jį kaip tikslumą, o tikslumas bet kokiame techniniame gylyje yra patikimumo signalas.

Kita pusė: neapibrėžtumas čia kainuoja brangiau nei bet kurioje kitoje kategorijoje. Žodžiai sklandus, galingas ir platforma yra ne tik silpni, jie skaitomi kaip bandymas išvengti konkretumo.

Gera patikra prieš siunčiant: išbraukite iš žinutės produkto pavadinimą. Jei lieka sakinys, kurį programuotojas gali suprasti, žinutė tinka. Jei lieka aprašymas, tinkantis dar dvidešimčiai tiekėjų, trūksta mechanizmo.

Prieštaravimas visada tas pats

Nepriklausomai nuo produkto, pirmas atsakymas visada yra to paties sakinio variantas: mes tam jau kažką turime, arba mes tai pasidarėme patys.

Dažniausiai tai tiesa, ir ginčytis su tuo reiškia pralaimėti. Kiekviena bent kiek didesnė inžinerijos organizacija turi vidinį skriptą, lentelę, šiek tiek pariestą atvirojo kodo įrankį arba ankstesnį tiekėją. Įrankis egzistuoja. Klausimas yra, kiek kainuoja jį išlaikyti.

Produktyvus atsakymas perkelia pokalbį nuo funkcijos prie priežiūros. Kam priklauso vidinis įrankis. Kas bus, kai tas žmogus išeis. Kiek inžinerinio laiko į jį įdėta per praėjusį ketvirtį. Ko jis nedengia, kas dabar tapo reikalavimu. Nė vienas iš šių klausimų nėra apie jūsų produktą, todėl į juos atsakoma.

Vidiniai sprendimai turi ir nuspėjamą lūžio tašką: jie veikia, kol organizacija peraugą prielaidas, pagal kurias buvo parašyti. Kreiptis būtent tuo momentu, kai riba peržengiama, reiškia ateiti tada, kai vidinis atsakymas jau ėmė strigti, o tai vertingiau už bet kokį konkurentų palyginimą.

Antras prieštaravimas dažnai seka iškart: įdiegimo sąnauda. Ir jis nuginčijamas ne argumentais, o patikimu skaičiumi. Kiek trunka sąranka tokio dydžio komandai, išmatuota, o ne įvertinta, ir ką dėl to reikia paliesti.

Kas programuotojui yra įrodymas

Ne logotipas, ne citata apie malonią partnerystę ir ne procentas be pradinės vertės.

Veikia, maždaug pagal stiprumą:

• Atkartojamas matavimas su nurodyta metodika, įskaitant sąlygas, kuriomis rezultatas negalioja. Būtent ribų paskelbimas padaro visa kita patikima.
• Viešas techninis aprašymas tikros problemos ir kaip ji išspręsta, nesvarbu, ar jis ką nors parduoda. Tai tvariausias turtas, kokį devtools įmonė gali turėti, ir jis parduoda dar prieš prasidedant komunikacijai.
• Prieiga prie kodo ar specifikacijos. Bet kas, ką skeptikas gali patikrinti, paverčia skepsį vertinimu.
• Įvardyta inžinerijos komanda gamyboje panašiu masteliu, aprašyta techniškai, o ne kaip kliento istorija.

Veikia ir tai, ko dauguma vengia: aiškiai pasakyti, kada produktas netinka. Kategorijoje, kurioje visi tvirtina tinkantys visiems, viena sąžininga eilutė apie netinkamus atvejus dažnai yra stipriausias sakinys visame laiške.

Kas patikimumą aktyviai griauna: sugalvoti rodikliai, palyginimų lentelės su akivaizdžiai nuvertintu konkurento stulpeliu ir rinkodaros kalba ant techninių teiginių. Programuotojai visus tris atpažįsta greitai, o atpažinimas būna galutinis.

Trigeriai, einantys prieš pirkimą

Keturi stebimi pokyčiai patikimai eina prieš inžinerinės programinės įrangos pirkimą.

Komandos dydžio ribos peržengimas. Praktikos, veikiančios su aštuoniais programuotojais, lūžta ties dvidešimt penkiais ir lūžta kitaip ties aštuoniasdešimt. Kiekviena riba sukuria poreikį įrankių kategorijai, kuri žemiau buvo nereikalinga. Komandos dydis matomas iš darbo skelbimų, viešų profilių ir techninių publikacijų kiekio.

Migracija. Debesijos tiekėjas, kalbos versija, framework, perėjimas į monorepo arba naujas diegimo modelis. Migracijos vienu metu atveria visus gretimus sprendimus ir dažnai viešai aprašomos pačių komandų.

Incidentas. Viešas veikimo sutrikimas, saugumo pranešimas ar atitikties išvada judina biudžetą greičiau nei bet koks pasiūlymas. Kreiptis iškart yra neskoninga ir dažniausiai kenkia. Kreiptis po šešių aštuonių savaičių, kai finansuojami po analizės numatyti veiksmai, yra laiku.

Penktas, retesnis, bet stiprus trigeris yra auditas arba sertifikacija. Kai įmonė ruošiasi ISO, SOC ar sektoriaus reikalavimams, atsiranda konkretūs, datuoti reikalavimai žurnalams, prieigoms ir procesams, o tai vienas iš nedaugelio atvejų, kai inžinerija perka dėl išorinio termino.

Pirmas platformos arba infrastruktūros darbuotojas. Pirmas skirtas platformos inžinierius reiškia, kad organizacija nusprendė, jog kūrėjų patirtis yra kažkieno darbas. Tas žmogus ateina su mandatu, tuščiu įrankių krepšiu ir naujų kolegų skundų sąrašu.

Kanalai ir kur neiti

Laiškas inžinerijos vadovybei veikia, kai kiekis mažas, o konkretumas didelis. LinkedIn veikia tai pačiai auditorijai lengvesne ranka. Telefonas čia veikia prasčiau nei beveik bet kurioje kitoje B2B kategorijoje, nes netikėtas skambutis laikomas trukdymu.

Trys vietos, kuriose nėra ko veikti. Nesikreipkite į programuotojus per GitHub issues, pull request ar repozitorijų diskusijas. Ta erdvė nėra kanalas, ir naudoti ją kaip kanalą reiškia užsidirbti viešą, ilgalaikę ir pelnytą kritiką. Nekurkite potencialių klientų bazės iš atvirojo kodo prisidėjusiųjų sąrašų. Ir neautomatizuokite personalizacijos iš žmogaus viešo kodo, nes tai skamba įkyriai, o ne dėmesingai, net kai duomenys vieši.

Ketvirta vieta, dėl kurios kyla ginčų, yra techninės bendruomenės Slack ir Discord serveriai. Ten galima būti, bet kaip dalyviui, o ne kaip siuntėjui. Tiesioginė žinutė nepažįstamam žmogui tokioje erdvėje skaitoma taip pat blogai kaip komentaras po pull request.

Riba paprasta: profesinė pašto dėžutė yra priimtina vieta verslo pasiūlymui, o bendra techninė darbo erdvė ne.

Vokietijos atveju prisideda ir teisė: UWG 7 straipsnis laiko šaltą reklaminį laišką ir tarp įmonių nepagrįstu trukdymu, todėl ten LinkedIn yra ne tik taktiškai, bet ir teisiškai protingesnis pirmas kontaktas. Tai nėra teisinė konsultacija.

Sąžiningas matavimas

Atsakymų dažnis šioje kategorijoje yra silpnas signalas, nes techninės auditorijos atsako rečiau nei komercinės, nepriklausomai nuo kokybės. Yra du geresni matai.

Pirmas yra tai, kas vyksta po atsakymo. Pokalbiai apie programuotojų įrankius, kurie kur nors veda, beveik visada apima techninį vertinimą, todėl prasminga konversija yra nuo susitikimo iki bandymo, o ne pats susitikimas. Pipeline, pilnas susitikimų, kurie niekada nepasiekia vertinimo, turi žinutės problemą, o ne kiekio.

Antras yra paveiktos savitarnos registracijos. Kiekvienoje įmonėje su nemokama versija dalis outbound vertės pasirodo taip, kad programuotojas tyliai išbando produktą po kelių dienų nuo žinutės jo vadovui, be jokio priskyrimo. Stebėti registracijas iš tikslinių įmonių, o ne atsakymus iš tikslinių kontaktų, fiksuoja realų poveikį, kurio atsakymų ataskaita nemato visai.

Trečias, jei turite pardavimo ciklą ilgesnį nei ketvirtis, yra pokalbių su technine vertinimo komanda skaičius. Jis juda anksčiau nei pajamos ir tiksliau nei susitikimai, nes rodo, ar pasiūlymas apskritai pateko į vertinimą.

Outbound techniniams produktams vedame taip, kaip reikia: maži sąrašai, tikra paruoša, mechanizmu grįsti tekstai ir priminimai, kurie gerbia lėtą inžinerijos organizacijų sprendimo greitį. Kaina fiksuota: 3 750 EUR pirmą mėnesį, po to 2 850 EUR per mėnesį, nutraukiama bet kada.