Braterskość jako istotny element sukcesu SH, Bolesne wyjście z niszy - przykład Callstack, Jak SOFTIQ urósł na GenAI,Czym jest Silnik OSS w Callstack i Rigby
Grow Your Software House to metody, narzędzia GPTs, analizy i nagrania, które pomagają software house'om odkryć swój silnik wzrostu.
Cześć! Nazywam się Maciej Greń i od 17 lat zajmuję się rozwojem firm typu Software House. Grow Your Software House to biuletyn z częścią darmową na Linkedin rozwinięty o płatne analizy tutaj na Substack wraz z wiedzą, narzędziami i filmami pokazującymi jak przestać błądzić i zacząć systematycznie rozwijać swój Software House. W dzisiejszym numerze:
braterskość jako istotny element sukcesu SH
Wyjście z niszy gdzie działa Twój silnik wzrostu może być bolesne - przykład Callstack
GenAI Silnik Wzrostu czyli jak SOFTIQ zbudował skalowalną sprzedaż na AI w Public'u
czym jest Open Source Growth Engine - przykład Callstack i Rigby
Zebrana wiedza w tym biuletynie powinna być używana z rozwagą i na własną odpowiedzialność. Zapożyczam w nim nagminnie frazy z języka angielskiego, wybaczcie, robię to celowo ponieważ w codziennej pracy korzystamy z tych fraz nieustannie.
Braterskość jako istotny element sukcesu SH
Paul Graham, jeden z twórców Y Combinator, podkreślał, że jednym z głównych powodów odrzucania aplikacji jest fakt, że startup ma tylko jednego założyciela, choć nie jest to sztywna zasada – solo-founderzy bywają przyjmowani, ale rzadko. Podobnie w ostatnim wywiadzie mówił Tomek Karwatka. To nie jest przypadek, że wiele z ich inkubowanych firmy ma początek we Wrocławiu. To nie piękno miasta tylko bliskość founderów jest kluczem. Po co fizyczna bliskość? Bo jak jest ciężko, jak są intensywne rozmowy to trzeba je budować na relacji osobistej.
Co-founderem może być Twoja żona, przyjaciel, rodzina, znajomy. Z rodziną najlepiej wypada się "na zdjęciu rodzinnym”, dlatego wiele osób błędnie zakłada, że co-founderem powinien być ktoś obcy. Unikamy budowania relacji bliskiej, przyjaźni, a jest to jedna z supermocy, które są niesamowicie istotne. Przyjaciel to ktoś kto przede wszystkim nas kocha. Tak, miłość jest to słowo dość niebezpieczne w biznesie, natomiast Ci, którzy faktycznie mają takiego przyjaciela w swojej firmie wiedzą o czym piszę. To ktoś komu nie zależy na pieniądzach tak bardzo jak na relacji z Tobą. To ktoś, kto będzie Ciebie wspierał w trudach i mówił szczerą prawdę gdy widzi, że idziesz w złą stronę.
To jak bardzo niedoceniany jest taki co-founder jest niestety zabójcze. Po pierwsze, często widzę firmy, które wchodzą w relacje udziałowe i nazywają kogoś co-founderem gdy tak naprawdę nie ma z daną osobą mocnych relacji. Biznes przecież nie musi iść w parze z “miłością” prawda? Przecież na koniec dnia chcemy wszyscy zarobić i to powinno nas razem łączyć?
No właśnie... problem w tym, że gdy pieniądze są mniejsze niż oczekiwaliście, lub pojawia się inna lepsza okazja dla Twojego co-foundera aby zrobić lepszy biznes z kimś innym to co go będzie trzymało z Tobą?
Jeśli nie macie więzi, nie lubicie ze sobą przebywać poza pracą i wspólnego przekonania, że chcecie razem iść w jedna stronę to niestety takie sytuacje doprowadzą do następujących wydarzeń:
Negocjacji udziałów “bo inaczej odejdę”
Presji aby zmienić kierunek “w bardziej rentowny tu i teraz”
Oczekiwania wysokiego wynagrodzenia bo “są inne oferty, które mogę przyjąć i odejść”
Niestety, okazuje się, że to co razem budujecie jest uzależnione od jakiejś iluzorycznej transakcji wiszącej w głowie Twojego "co-foundera", której termin nieuchronnie się zbliża, a Ty nie masz jak "zapłacić", co więcej - masz tonę stresu.
A co będzie Ciebie motywowało do dalszej pracy gdy w nocy przejdzie Ciebie zimny dreszcz i do ranka będziesz walczył z myślami, które paraliżują?
To są naprawdę ciężkie momenty, których przejście samemu jest arcy trudne. Wówczas co-founder, który razem z Tobą przejdzie przez ciemną dolinę i przywróci wiarę jest bezcenny.
Oczywiście może się zdarzyć, że z obiektywnych przyczyn co-founder musi odejść. W swoim życiu miałem jednego co-foundera, który jest moim przyjacielem do dziś, a z którym musiałem się pożegnać w bardzo trudnych okolicznościach gdy zarówno ja jak i on spaliliśmy już nasze oszczędności i naturalnie nie było możliwości iść wspólnie dalej. To co jest piękne to to, że jesteśmy nadal w kontakcie i nie ważne jak długo ze sobą nie rozmawiamy to zawsze gdy wracamy do siebie jest to poczucie “braterskości”.
Posiadanie co-foundera, z którym mamy głęboką wieź jest kluczowe w każdym momencie budowania firmy.
co-founder nie musi mieć udziałów
Takie osoby, które są dla Ciebie wsparciem, są z Tobą “w wspólnym autobusie od pierwszych dni” nie muszą być od razu udziałowcami. Uważam, że jednym z gigantycznych błędów popełnianych przez founderów jest patrzenie na kluczowych pracowników bez udziałów jak na osoby, które nigdy nie będą w stanie tak mocno się oddać firmie jak "udziałowcy", zatem aby ich w pełni zaangażować trzeba im te udziały dać. Jest to fatalne założenie, która prowadzi do złych decyzji:
oferowanie udziałów kluczowym pracownikom, gdy im nie zależy na tych udziałach tylko na wspólnej wizji, szacunku, przyjaźni prowadzi do zabicia idealnie działającej relacji i zamiany jej w Twoje ciągłe oczekiwania i pretensje, że "teraz jesteś udziałowcem, więc powinieneś to czy tamto"
braterskość w relacji jest dla wielu osób bardziej kluczowe niż udziały. Niedoszacowanie potencjału braterskości w pracy z kluczowymi pracownikami, wprowadzanie menadżerów pomiędzy Wami osłabia Waszą współpracę
zamiana relacji braterskiej na relacje biznesowe czyli "obsypywanie" kluczowych pracowników pieniędzmi licząc, że to ich bardziej zmotywuje. Ich motywuje wspólna praca, nie tak bardzo kasa, która raz jest, raz jej nie ma.
wprowadzenie OKR's itp. systemów operacyjnych dla firmy przez zewnętrznych konsultantów, którzy niszczą relacje partnerskie między Wami bo "oceniają wydajność” pomijając złożone aspekty związane z wcześniejszymi ustaleniami między Wami, wieloletnim wydajnym modelem współpracy, który opiera się na głębokim rozumieniu Waszych potrzeb.
Kluczowi pracownicy potrzebują być doceniani, potrzebują głębokiej więzi z założycielem. Niekoniecznie musi to być przyjaźń. Czasem wystarczy podziw, spójność idei i wartości. Tak jest z Elonem Muskiem, który z racji posiadania zespołu Aspergera, nie buduje więzi tak samo jak osoby bardziej relacyjne. Dzięki swojej postawie, oddaniu, ambicji, haryzmie - buduje poczucie elitarności, misji, głębszego sensu. Wielu firmom tego brakuje, dlatego ludzie pragną pracować w firmach Elona.
Taki zespół wsparcia, dla którego bycie razem jest ważniejsze niż najszybsza podróż w jedną stronę - jest kluczowy. To, że jesteście razem w autobusie im wystarcza, nawet jeśli autobus z bardzo dobrze wyposażonego zamieni się na jakiś czas w stary model. Będziecie w nim razem i nie będziecie w stanie sobie wyobrazić jazdy z kimś innym.
Jest kilka sytuacji gdy braterska wieź, pomimo, że wydaje się bardzo mocna może być szybko zerwana. Poniżej te rzeczy, które bezpośrednio doświadczyłem w mojej pracy z firmami.
5 grzechów głównych, które trwale, czasem nieodwracalnie niszczą braterską wieź z co-founderem.
Gdy Twój co-founder Ciebie o coś szczerze z serca prosi, ale Ty tego nie zrobisz i zbagatelizujesz jego potrzeby. Gdy jest coś bardzo ważnego dla Twojego co-foundera i używa prośby oznacza to, że doszedł do ściany. Argumenty racjonalne nie działają, odwołuje się do Waszej relacji i liczy, że się opamiętasz. Niestety często jest to niemy krzyk, który jest pomijany. To systematycznie niszczy relację szczególnie gdy jesteś w trybie agresywnej ekspansji lub walki o przetrwanie łatwo można zignorować tego typu sygnały.
Gdy karzesz swojemu co-founderowi coś zrobić bo “jesteś tutaj szefem"Odwracamy tutaj role. Zamiast prośby stosujesz argument siły, przewagi, roli, tytułu. Karzesz coś zrobić swojemu co-founderowi wbrew jego woli, ignorując jego uwagi. Niszczysz w ten sposób wieź i zamieniasz swojego co-foundera w zadaniowca.
Gdy wchodzisz w konflikt np. podważasz co-foundera publicznie zabierając mu poczucie własnej wartości. Kłócenie się publicznie, podważanie kompetencji publicznie boli. Twój co-founder czuje się zdradzony. Nie mylmy tutaj posiadania sprzecznych zdań na dany temat. Piszę tutaj o ataku na co-foundera, który prowadzi do jego zranienia.
Gdy nie spełniasz swoich ustaleń z co-founderem, pomimo, że możesz to zrobić. Robisz to z pozycji siły, jesteś chciwy.Chciwość niestety może doprowadzić Ciebie do zdrady Twojego co-foundera. Wykorzystując swoją pozycję masz władzę nad Twoim co-founderem. Jeśli użyjesz jej przeciw niemu zabijesz relację.
Gdy robisz coś za plecami swojego co-foundera, cos co narusza jego zaufanie w podstawy Waszej relacji.Co-founder Tobie ufa. Zakłada, że mu ufasz i działa z pełnym zaangażowaniem. Jeśli w tym czasie naruszasz jego zaufanie, np. sabotażujesz jego pracę bo nie chce Ci się z nim “walczyć”, gdy jesteś niespójny z nim, Twój co-founder nie jest w stanie tego zrozumieć. To poczucie zawodu i frustracji, połączone z brakiem zrozumienia Twoich działań szybko prowadzi do zniszczenia relacji.
Oczywiście nie zawsze Ty jesteś problemem. Twój co-founder może być pod wpływem różnych głosów, myśli, lęków. To może prowadzić do jego rozchwiania emocjonalnego, obniżenia poziomu profesjonalizmu, który może Ciebie zachęcać do pójścia na skróty - robienia czegoś za jego plecami, niechęci do konfrontacji, niechęci do rozmowy, nawet potyczek słownych. Pamiętaj, że mając relację braterską, miłości z Twoim co-founderem możesz po prostu do niego podejść i zaprosić go na “kręgle, bilarda, wspólny jogging, granie na PS” cokolwiek robiliście razem gdy byliście blisko aby przywołać te wspomnienia i użyć tej więzi jako platformy do otwarcia. Wsłuchanie się w swojego co-foundera pozwoli Tobie na powrót do głębi relacji, oczyszcza atmosferę.
Tutaj niestety pojawia się jedna bardzo brutalna prawda - to oczyszczenie relacji jest bardzo trudne do zrobienia gdy jesteście od siebie daleko. Fizyczna relacja, spotkanie, bycie razem w codzienności to potężna platforma. Founderzy bardzo tego niedoceniają mając nadzieję, że przecież będzie wszystko dobrze i remote co-founding się czasem udaje. Gdy jednak przyjrzysz się historii firm to łatwo zobaczysz, że co-founderzy, kluczowi pracownicy są ze sobą codziennie, mają mocną relację. Nie dlatego, że nie można pracować online. Robią to dlatego bo wiedzą, że ich wieź buduje ich wspólne zaufanie i poczucie “siedzenia w jednym autobusie”. To poczucie daje sens, wzmacnia wieź, która natomiast dodaje sił do codziennej nudnej, żmudnej, czasem rozczarowującej - pracy.
GenAI Silnik Wzrostu czyli jak SOFTIQ zbudował skalowalną sprzedaż na AI w Public'u
GenAI jest na ustach praktycznie każdego biznesu. Każdy patrzy na swoje zadania, procesy i myśli “czy to jest dobry kandydat do użycia GenAI?”…
GenAI to niewątpliwie Tornado a nawet nazywam go Cyklonem bo Tornado zazwyczaj zmienia niszę horyzontalną, a tutaj zarówno horyzontalnie jak i w wielu wertykalnych niszach na raz siła “obietnicy oszczędności czasu, usprawnienia procesu, poprawy jakości dzięki GenAl” powoduje, że każdy o tym teraz myśli.
Nawet pragmatycy w dużych firmach, którzy zazwyczaj czekają na “nowy standard” i “kompletny produkt” sami próbują być na topie i próbują wyrzeźbić coś z AI. Szybko się oczywiście zderzają z barierą wejścia bo tak naprawdę technologia GenAI jest jeszcze dla nich niewątpliwie niekompletnym produktem, bo jak nazwać coś co potrafi generować piękne eseje podczas gdy w innym momencie myli się w prostych równaniach matematycznych (oczywiście wiem że jest GPT5 pro, które jest do badań naukowych, ale ma podobne ograniczenia fundamentalne jak cała gama LLMów).
Zatem mamy Cyklon GenAI czyli spotęgowane Tornado.
Pomimo, że pragmatycy stoją dzielnie w organizacjach i mówią “to AI to jest jeszcze dalekie od użycia u nas” to czują ze strony managementu niepokój bo “konkurencja już się chwali, że dzięki AI obcięli koszty o X%”.
Pragmatycy muszą zakasać rękawy i ... brodzić w błocie. To chyba najgorsze co chcą robić. Oni nie zostali zatrudnieni do robienia R&D. Oni zostali zatrudnieni do dostarczania wartości firmie w obszarze, w którym się uczyli, pracowali, budowali swoje kompetencje przez lata. Nurkują w świat AI i toną w otchłani rozwiązań, platform, to istny hydepark.
W tym samym czasie firma SOFTIQ, Software House z Gliwic buduje swój silnik wzrostu na ...zamówieniach publicznych. Nie tylko w Polsce, ale też za granicą. Robi to ręcznie, ale gdy tylko pojawia się pierwszy LLM - zaczynają eksperymentować. Próbują optymalizować swój proces aplikowania. Usprawniają to dla siebie, nie aby zrobić z tego produkt, to nie był ich cel. Rosną i to wbrew globalnemu trendowi na rynku Software Housów. Gdy SH zwalniają w latach 2023-2024 to oni zatrudniają. Usprawniają swoją wewnętrzną platformę AI do aplikowania do zamówień publicznych, a dzięki AI przechodzą na inne kraje, Skandowania, Islandia, UK.
Ich produkt staje się kompletny i w sumie pojawiło się pytanie:
Czemu tylko SOFTIQ ma być jedynym jego użytkownikiem?
Odkrywają więc niszę wertykalną, w której dając swoją platformę nie zbudują sobie bezpośredniej konkurencji tylko pomogą firmom z innego segmentu rosnąć. Budownictwo.
Tak powstał serwis Przetargi.io, który pomaga firmom w tym segmencie radykalnie przyspieszyć proces zgłaszania się do przetargów. Software House użył swojego wewnętrznego produktu aby uderzając do tych pragmatyków, którzy i tak w tych firmach czują presję od zarządu aby “zrób coś z tym AI” nagle SOFTIQ jest jak zbawiciel. Gotowy produkt pod ich niszę.
Od otwarcia platformy minęło kilka miesięcy a SOFTIQ już ma na niej ponad 100 klientów. Gdy spojrzycie na cennik ich usługi - tanio. Jak SH zarabia? klienci potrzebują dostosować narzędzie do swoich potrzeb. Tak samo jest i tutaj.
Platforma to potwierdzenie, że system działa. Jest jak rozbudowane demo, które pozwala pragmatykom z danego segmentu zaufać i przełamać ich opór.
To dopiero początek bo oczywiście każda firma ma swoje wewnętrzne struktury dokumentów, procedury itp. Tutaj z racji, że SOFTIQ jest liderem w tym narzędziu mogą mieć zupełnie inne stawki, oparte o dostarczoną wartość a nie spędzone godziny. Jest to wzorcowy przykład silnika wzrostu opartego na produkcie wertykalnym, dla danej niszy branżowej.
Budowa w danej niszy wertykalnej narzędzia, nawet będącego prototypem to w mojej ocenie idealny sposób dla Software Housów aby sprzedawać custom development na systemy GenAI.
Dużo łatwiej jest iść do jednej niszy i budować tam wizerunek lidera i też łatwiej jest zdobywać kolejnych klientów gdy kilku pierwszych zrobi się "po kosztach”. To strategia Bowling Alley z książki “Inside the Tornado” Geoffrey’a Moore’a.
Pamiętajcie jednak, że robienie projektów w danej niszy to nie jest jeszcze silnik wzrostu. Silnik powinien prowadzić do liderstwa w danej niszy. Co to znaczy?
Jeśli faktycznie chcecie iść drogą SOFTIQ to musicie też zakasać rękawy i budować nowy brand w danej niszy. Brand ekspertyzy dziedzinowej, która dostarcza wartość biznesową, nie technologiczną. Musicie chcieć stać się liderem w tej niszy. Bez tego, będziecie tylko kolejnym SH z kilkoma projektami zrobionymi po kosztach, które nie są odpowiednio wykorzystane do budowania liderstwa. SOFTIQ buduje to liderstwo zarówno w public'u jak i w danej niszy branżowej. W której niszy Wy chcecie być liderem?
Wyjście z niszy gdzie działa Twój silnik wzrostu może być bolesne - przykład Callstack
Open Source Growth Engine wykorzystuje projekt open source jako platformę do zbudowania liderstwa firmy usługowej (Software House). Proste? Niekoniecznie. Wg. tej analizy projektów OSS jest kilkanaście milionów, a tylko niewielki promil z nich można bezpośrednio wykorzystać do budowania Silnika Wzrostu dla Software House.
Jakie są kluczowe cechy projektu OSS aby stał się sercem silnika wzrostu w SH?
Dana technologia (bo projekt Open Source to nic innego jak po prostu technologia) powinna zmieniać paradygmat w danej niszy i wywoływać Tornado. Tornado (z książki “Inside the Tornado”) powstaje gdy zbiera się bardzo duża masa różnych frontów atmosferycznych. W biznesie to firmy, które mają jeden cel - maksymalizacje zysku. To pierwsza siła odwiecznie pchająca każdą firmę do przodu - zwiększyć zysk.
Druga siła to opór (paradygmat obecny) w uzyskaniu tego zysku, czy to w narzędziach czy to w ludziach, czy w braku dostępu do zasobów. Te dwie siły normalnie ze sobą się nie zderzają bo jedna siła nie widzi ujścia jej gdy się ściera z drugą.
Przez długi czas rynek główny (pragmatycy w firmach na tym rynku) widzi nową technologię, ale mówi:
"To zbyt skomplikowane, zbyt ryzykowne, nie ma do tego wsparcia."
Opór przed zmianą jest silniejszy niż obietnica zysku. To jest właśnie faza Przepaści (Chasm) i Kręgielni (Bowling Alley) z książki Inside the Tornado. W przepaści technologia jest testowana przez innowatorów i wizjonerów i udowadnia swoją prawdziwą wartość. Napięcie rośnie, fronty się zbliżają, ale jeszcze nie ma gwałtownego zderzenia.
Gdy to ujście powstaje (tam jest kompletna usługa lub kompletny produkt OSS gotowy aby być użyty przez pragmatyków) wówczas tworzy się tornado. Powstaje de facto standard, który eliminuje ryzyko wyboru złej opcji dla pragmatyków (liderów technologicznych) w organizacjach w głównym rynku danej technologii.
Ekosystem partnerów, którzy dotychczas zdobywali określone nisze daną technologią jest gotowy, aby dostarczyć kompletne, działające rozwiązanie dowolnej firmie, którą na tą technologię stać.
W tym momencie, nagle, cała skumulowana energia – całe to ciśnienie z "frontu dążenia do zysku" i "frontu oporu starego paradygmatu" – znajduje swoje ujście w nowej technologii, która łamie stary paradygmat wprowadzając nowy.
I wtedy następuje Tornado.
Cały rynek, jak jeden organizm, rzuca się, aby zaadoptować nowy standard, ponieważ dalsze pozostawanie przy starej technologii jest teraz postrzegane jako większe ryzyko niż sama zmiana.
Technologia React Native właśnie była czymś takim w latach 2016-2020. Trend tworzenia przez biznesy dedykowanych aplikacji mobilnych był jak olbrzymi front atmosferyczny, który ścierał się z frustracja pisania dwóch oddzielnych aplikacji na dwie główne platformy (Android i iOS). Pojawiały się różne obiecujące rozwiązania, ale brakowało przełamania oporu pragmatyków w dużych organizacjach. Nadal dla nich PhoneGap nie był standardem. Standardem natomiast był już w tym czasie React.js. Wspierany przez Metę (wówczas Facebook) był już w fazie Main Street tzn. Tornado się skończyło i walkę technologii frontendowych dla mas wygrał właśnie React.js. To stworzyło całą rzeszę technicznych liderów, ktorzy znali "React" i poczuli potrzebę przeniesienia pewnych fundamentalnych założeń tej technologii na aplikacje mobilne.
W tym czasie gdy React Native gwałtownie zdobywał zainteresowanie liderów technologicznych wizjonerów, którzy nie bali się wdrażać te technologię w swoich biznesach, Mike Grabowski zaangażował się na 100% i tworzył kontrybuował do masy projektów OSS, jednym z najbardziej spektakularnych w tamtym czasie, który został zmergowany do React Native Core. To był dopiero początek.
Mike systematycznie był w samym centrum rozwoju tej technologii blisko liderów technologicznych z całego świata i z Mety (wówczas Facebook). Ponieważ React już był na Main Street (czyli na głównym rynku zgodnie z modelem Geoffrey'a Moore'a) czyli stał się standardem, oraz ponieważ Meta intensywnie kontrybuowała do rozwoju React Native, a społeczność liderów technologicznych sumienie ewangelizowała o gotowości React Native, technologia ta przełamała opór pragmatyków i stała się Tornadem. Mike i jego zespół z Callstack stali się frontem dla świata biznesu, który chciał przejść na React Native. Meta nigdy nie miała tego w swoim modelu biznesowym i na rękę było i nadal jest otwierać swój kod aby biznes sam go utrzymywał. Callstack stał się numerem jeden aby taki most zapewnić.
Wszystko rosło pięknie gdy w 2024 ktoś w Callstacku postanowił spróbować ugryźć jeszcze większy tort, tzn. zaatakować niszę React będącą na Main Street. Zmienili swoją stronę, zaczęli zmieniać komunikację do rynku, do społeczności technologicznej... i nie pykło. Poniżej strona Callstack 2024.
Jak to powiedział Krzysztof Pawlak, Ex-CSO w Callstack w jednym z ostatnich wywiadów:
wycofaliśmy się z tego szybciej niż na to się decydowaliśmy.
Co się stało? Nagle z racji olbrzymiej siły obecnej marki, bycia top of mind zaczęli pojawiać się klienci z innego segmentu. Nie na React Native, na ogólne usługi. Main Street z React.js nie jest dobry na usługi z stawkami premium. Main Street dąży do standardu nie tylko technologii ale też spłycenia ceny bo rynek masowy rodzi masowo developerów w tej technologii, ekspertów i proste zasady popytu i podaży powodują, że stawki premium nie mają racji bytu. Callstack zderzył się z ścianą. Nagle lukratywne projekty na marże 80-90% nie były nawet w sferze marzeń. "Dawna” marka nadal przyciągała masę klientów, a nowa - przyciągała klientów, którzy nie chcieli płacić premium dla firmy, która w sumie nie jest dla nich premium.. bo poza React Native, Callstack nie istnieje w ich głowie w ten sposób.
To właśnie dowód na to, że silnik OSS w Callstacku jest oparty o React Native i nawet ostatnia transakcja, w której firma została sprzedana za bajeczną kwotę 0.5 mld zł nie sprawiła, że z firmy odszedł Mike. A może mógł? Wg. Mnie niestety i stety jest częścią sukcesu Callstack jako osoba kluczowa i twarz w community jego odejście wraz z transakcją byłoby nie do zaakceptowania dla nowych właścicieli Callstacka.
Czym jest OSS Growth Engine w Callstack i Rigby
Przypadek Callstack'a, w którym firma usługowa staje się kluczowym komercyjnym powiernikiem dla technologii Open Source (React Native), nie był przypadkiem. To powtarzalny wzorzec, który można zdefiniować jako Open Source Software Growth Engine (OSSGE). Jest to strategiczny model, który wyjaśnia, jak firma może zbudować pozycję lidera, opierając swój rozwój na przełomowym projekcie OSS. Jego fundamentem jest diagnoza **paradygmatu**, który dany projekt OSS przełamuje.
Diagnoza ta zaczyna się od kluczowego pytania: czyj pożar gasi ten projekt OSS – biznesu czy technologii?
Odpowiedź na to pytanie determinuje całą ścieżkę wejścia na rynek danej technologii.
W przypadku React Native mieliśmy do czynienia z Technologicznym Przełomem Paradygmatu. Pożar płonął w działach IT, a jego paliwem była nieefektywność tworzenia kodu na dwie platformy oddzielnie. W takim scenariuszu firmy na rynek głównym (czyli tym gdzie jest większość firm), składający się z pragmatycznych liderów technologicznych, nie zaadoptuje nowej technologii, dopóki nie otrzyma silnego sygnału, że jest ona bezpieczna i ma przyszłość. Ten sygnał musi pochodzić od Goryli Technologicznych – technologicznych gigantów, takich jak Meta, który swoim autorytetem i zasobami daje technologii gwarancję stabilności - kluczowa dla pragmatyków.
Kiedy Goryl daje zielone światło, cały rynek rzuca się, by zaadoptować nowy standard, tworząc Tornado – okres gwałtownego, masowego wzrostu. To właśnie w tej chwili powstaje idealna próżnia dla firmy usługowej, by stała się Gorylem Usługowym, czyli liderem szytych na miarę wdrozeń komercyjnych dla nowej technologii.
Istnieje jednak druga, równie potężna ścieżka, inicjowana przez Biznesowy Przełom Paradygmatu. W tym wariancie projekt OSS rozwiązuje głęboki, strategiczny problem dla konkretnych nisz biznesowych, tak jak robi to Medusa.js dla złożonego handlu B2B. Tutaj sygnał dla rynku musi pochodzić od Goryli Biznesowych – szanowanych liderów rynkowych, takich jak Heineken czy Mitsubishi, którzy swoim sukcesem udowadniają jej wartość biznesową.
Droga na rynek jest tu bardziej metodyczna i wymaga strategii Kręgielni, czyli zdobywania zaufania klienta nisza po niszy.
Liderstwo w oczach społeczności technologicznej danego projektu OSS jest kluczowe
Niezależnie od ścieżki, sukces w modelu OSSGE zależy od istnienia rynkowej próżni i zdolności firmy usługowej do stania się nie tylko partnerem, ale aktywnym współtwórcą i opiekunem określonej technologii OSS, co daje jej milczący mandat od rynku do zdefiniowania technicznej przyszłości. Goryl Usługowy tak długo nim pozostanie jak długo będzie animował i prowadził społeczność liderów technologicznych danego projektu OSS.
Kto jest decydentem dla Software House, który korzysta z OSS Silnika Wzrostu?
Na powyższym diagramie przedstawiłem serce Silnika OSS. Co jest bardzo istotne, rodzaj nowego paradygmatu będzie określał do kogo Goryl Usługowy (czyli Twój Software House jeśli chce użyć silnika OSS i stać się bezdyskusyjnym liderem) kieruje swoje usługi, jakim językiem mówi.
Jeśli paradygmat jest technologiczny to głównym decydentem jest lider technologiczny, który sam wybrał dany projekt OSS dla swojej firmy i teraz szuka najlepszych dróg do realizacji swojego projektu.
Jeśli nowy paradygmat pochodzi od potrzeb biznesowych, wówczas Goryl Usługowy będzie komunikował swoje usługi do decydentów biznesowych. Widać to bardzo wyraźnie gdy porównamy główne strony firm Callstack oraz Rigby.
Callstack z swoim "Your React & React Native Development Experts" brzmi bardzo...zwykle. Najcenniejsza przestrzeń na samej górze strony tłumaczy dlaczego:
Callstack was founded a few months after React Native was released to support developers and companies looking to use it, without having to worry about the complexity of building native apps.
Since then, we’ve helped teams of all sizes succeed with React Native, while contributing to the core framework and maintaining key open source tools.
przekaz jest w 100% do społeczności technicznej, która tak naprawdę ich bardzo dobrze zna. Czyta ich e-booki nt. wydajności aplikacji zbudowanych na React Native, chodzi na ich konferencje, korzysta z ich bibliotek. Każda firma, która chce zainwestować w przejście na tą technologię, a boryka się z budową takich kompetencji w swojej firmie - przyjdzie do Callstacka.
Inaczej jest z Rigby, firmy która jest wzorem Goryla Usługowego dla projektu Open Source - Medusa.js Mówi o tym sam Prezes Medusa.js.
Rigby skupia się na kliencie biznesowym, ich strona nie stawia jako główny przekaz "Medusa Experts", ona jest skupiona na dostarczeniu wartości biznesowej, a Medusa jest dla Rigby najlepszą technologią aby zrealizować ten cel.
Co interesujące, Rigby stworzyło swój własny produkt OSS o nazwie Mercur.js, który jest książkowym przykładem strategii opisanej w książce Inside the Tornado, gdzie w momencie gdy różne nisze biznesowe aplikują daną technologię, Goryl Usługowy (Rigby) dostarcza dla nich "Cały Produkt" czyli platformę do budowy marketplace'ów B2B na Medusa.js.
Mercur i Rigby są konsekwentni - nadal komunikują do decydenta biznesowego bo wiedzą, który paradygmat (biznesowy) przełamuje ich technologia. To dla wielu wydaje się drobnym detalem, ale jest to kluczowe.
To do kogo komunikujemy nasze usługi, produkty, warunkuje też jakimi spostrzeżeniami (Insights) zdobytymi z naszej pracy z tego typu klientami go edukujemy. Jeśli przełamując paradygmat biznesowy, nie rozumiejąc tego aspektu, komunikujemy wartościami technicznymi - mówimy do rynku "nie jesteśmy gotowi aby być Serwisowym Gorylem bo nie rozumiemy Was." Dopiero zespół developerski tych firm może przynieść Was na tacy do decydentów biznesowych, ale to bardzo długa i bolesna droga, podczas której zespół developerski może dojść do wniosku, że w sumie to sami mogą to zrobić za Was.
Jest jeszcze kilka miejsc gdzie OSS Growth Engine potrafi skutecznie i trwale budować przewagę konkurencyjną dla SH. Napiszę o tym w kolejnych numerach naszego biuletynu.
Po słowie
Sprawdzenie, który OSS projekt jest idealny dla danego SH oraz przeniesienie firmy z poziomu 0 do 10/10 to moja specjalizacja. Jeśli jesteś SH, który albo siedzi “na złotym jajku” czyli ma w rękach popularny projekt OSS lub chciałby skierować swój rozwój w stronę projektu OSS - zapraszam do kontaktu (mat@shgrowth.com).