Od usług do exitu do IBM w 3 lata (LangFlow case study) oraz plan na SHGrowth na 2026. Plus: Leady w 10 dni z Twojego IP - jak mieć dobre umowy, jak to sprzedać i wybrać odpowiednie IP
SHGrowth to strategia, doradztwo i gotowe narzędzia dla founderów IT. Pomagam transformować firmy usługowe w wysokomarżowych liderów opartych na IP.
Cześć! Tu Maciej Matt Greń. Od 17 lat pomagam firmom IT uciec z pułapki sprzedawania godzin. W SHGrowth pokazuję, jak zamienić firmy usługowe IT w wysokomarżowy biznes oparty na IP. W darmowej części poznasz odpowiedź dlaczego warto dokonać tej transformacji, a w płatnej sekcji otrzymasz narzędzia do tego jak to wdrożyć. W dzisiejszym numerze:
Ukryty kluczowy element tworzenia swojego IP - drive
Jak firma z Brazylii w 2 lata zamieniła się z firmy usługowej w produktową aby zostać kupiona przez IBM - historia Logspace i LangFlow
Leady w 10 dni z Twojego IP cz. 1
zmiana umów z klientami aby móc swobodnie wytwarzać IP
zmiana sposobu sprzedaży aby zrobić miejsce na IP-led service
IP Opportunity Radar - filtr tornada
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.
Ukryty kluczowy element tworzenia swojego IP - drive
Stworzenie swojego IP (open source, kurs, ebook, webinar, boilerplate) to dobry sposób na wręczenie klientom gotowego produktu, który przyśpiesza im rozwiązanie określonego problemu. Po co to robić? bo przejście o kilka kroków dalej dzięki Twojej pomocy to dobry start Twojej relacji z klientem. To, że Twoje rozwiązanie go tam zaprowadziło sprawia, że nie masz konkurencji, bo tylko Ty znasz swoje rozwiązanie najlepiej na świecie. Co więcej, miejsce do którego zaprowadziłeś klienta, to często granica jest własnych możliwości wdrożeniowych. W skrócie - musisz go dalej przenieść suchą stopą na koniec tej drogi i chętnie Ci za to zapłaci.
Takie IP, które daje realną wartość odbiorcy można pisać bardzo długo. Poprawiać, stabilizować, dodawać nowe funkcje, zanim się go dostarczy do rąk społeczności. Mijają miesiące, czasem nawet lata. Projekt pochłonął już olbrzymią cześć Twoich środków, a Ty nadal go nawet nie dałeś w ręce wybranych osób.
To dramat i sam dobrze go znam bo obecnie ciągle przesuwamy wypuszczenie naszego projektu OSS na światło dzienne. Bo codziennie jest coś do poprawy, dodajemy funkcje i testujemy na naszych pilotażowych klientach.
źródło: ChatGPT
To pali nie tylko czas, ale też energię, którą nazywam drive’em. Drive, dlatego bo jedziesz po określonym torze, czujesz, że ten tor jest dobry i systematycznie przyśpieszasz. Gdy jednak robisz coś przez miesiące w zaciszu swojego komputera, to drive jest tylko Twój. Twój drive natomiast jest delikatny bo ma na niego wpływ to czy w danym momencie życia masz spokojną twórczą głowę czy też jest to czas chaosu, zawirowań, trosk.
Dochodzisz do momentu gdy drive spada do zera, a projekt, piękny, cudowny projekt, stracił właśnie życie.
Czy tego chcemy dla siebie i naszych inicjatyw?
Na pewno nie. Nikt nie chce patrzeć na swoje dzieło, jak zostaje zamknięte w pudełku na strychu. Dlatego warto znaleźć dużo wcześniej moment, gdy mamy jeszcze duże pokłady drive’a (energii) i wyjść z tym do świata.
Uczucie cringe chyba najlepiej do tego momentu pasuje. Czujesz, że robisz coś pierwszy raz, że pokazujesz swój kod jakbyś zapraszał kogoś do brudnego pokoju. Trzeba natomiast to uczucie zaakceptować i z tym cringe’owym uśmiechem wypuścić projekt na świat.
Masz już swoje IP? już spaliłeś swój drive niepotrzebnie.
Sam fakt, że już posiadasz stworzone swoje IP oznacza, że spaliłeś bardzo dużo swojego drive, na stawianie budynku, nie widząc czy podłoże to skała czy piasek. Jak odkryć odpowiednie podłoże na Twój projekt? piszę o tym w kursie Leady w 10 dni z Twojego IP. To część płatna tego newslettera, która przez najbliższe miesiące będzie zbiorem precyzyjnych kroków, narzędzi, przykładów jak szybko walidować odkryte IP i złapać pierwsze leady.
Wracając do drive’a. To do czego Ciebie zachęcam to abyś przestał kodzić. Nie pisz już ani jednej linijki kodu. Zamiast tego zrób coś innego.
Naładuj swój drive. Jak to zrobić?
Największą siłą napędową artysty, a powiedzmy sobie wprost - tworząc projekt OSS masz w krwi 100% artysty, który patrzy jak przed nim piętrzy się jego dzieło, jest to gdy jego dzieło jest docenione.
W przypadku projektów OSS, aby coś zostało docenione to trzeba podzielić się swoim pomysłem ze światem. Pomysłem, nie projektem OSS. To duży dyskomfort bo wymaga od nas wyjścia do ludzi, obcych i pytania o opinię na temat danego problemu. W książce Business Model Canvas jest to tzw. Customer Discovery, proces w którym próbujemy odkryć sytuację naszego odbiorcy, jego bóle i potrzeby. Nie rozmawiamy o rozwiązaniu!
Dzięki Customer Discovery nasz drive napełnia się lub... może zostać totalnie opróżniony z paliwa gdy okazuje się, że po pierwszej rozmowie z odbiorcą otrzymujesz deszcz feedbacku i pytań, które nagle okazują się oczywiste.
Jak robić customer discovery opisuję w Leady w 10 dni z Twojego IP, natomiast polecam bardzo książkę Mom Test (momtestbook.com), polecił mi ją kiedyś Kamil Osiecki https://www.linkedin.com/in/osiecki-kamil/ , CEO Ideamotive (dziękuję!) gdy doradzałem Ideamotive w budowie nowego silnika wzrostu. Książka Mom Test tłumaczy jak prowadzić rozmowy typu Customer Discovery aby nie kierować rozmówcy na błędny tor, który ma potwierdzić nasze hipotezy.
Dla mnie przykładowo w projekcie OSS, który teraz realizujemy bardzo brutalną prawdą było gdy postawiłem mój smart-vending koło konkurencji. Przychodzi klient, przykłada kartę, pyk, w 15 sekund ma produkt. W moim rozwiązaniu - musi wejść na stronę, podpiąć kartę, zarejestrować się... no masakra. Jak ja mogłem na to nie wpaść, że to będzie mega problem?
Byłem zauroczony moim rozwiązaniem. Artyści tak mają. Lubimy tworzyć, tworzyć, tworzyć. Zmieniać, poprawiać. To nasze naturalne bezpieczne środowisko.
Można powiedzieć, że artyści mają naturalny drive z robienia czegoś dla siebie. Pewnie dlatego nie potrzebujemy opinii innych gdy jesteśmy w procesie tworzenia. Z drugiej strony, przełączenie naszego drive’a na opinię innych sprawi, że to co tworzymy będzie faktycznie komuś służyć.
Przestawienie swojego drive’a na słuchanie opinii vs samego siebie to brutalny proces. Z drugiej strony, jeszcze bardziej cierpimy gdy to co tworzymy, nikogo nie interesuje. Ostatecznie, każdy artysta potrzebuje być dostrzeżony, dlatego jedyną drogą jest najwcześniej jak się da zbierać informacje zwrotne od ludzi, którym chcemy pomóc.
To dobra droga aby drive, który ma określoną ilość paliwa otrzymywał je z zewnętrznego źródła.
Jak firma z Brazylii w 2 lata zamieniła się z firmy usługowej w produktową
Karwatka Brothers Framework to 9-etapowa strategia transformacji firmy usługowej w wysokomarżowy biznes oparty na IP, polegająca na sfinansowaniu własnego produktu z zysków generowanych na fali technologicznego “Tornada”. Pozycja Goryla Usługowego to status niekwestionowanego lidera w tej niszy, który dzięki unikalnej ekspertyzie przestaje konkurować stawką godzinową, a klienci sami zabiegają o współpracę z nim.
Czasem ten proces trwa wiele lat. Jeśli dobrze się wstrzelisz, tak jak to było z firmą Logspace, od startu firmy do sprzedaży do IBM minęły niecałe 3 lata... imponujące.
Logspace zaczął jak każda inna firma usługowa. Founder opublikował artykuł na Medium (https://medium.com/logspace/launching-logspace-company-services-principles-goals-e077fa8cad93) o tym, że zakłada firmę usługową, prosta strona jak ich wiele na rynku wskazywała na kolejny nudny start w czerwony ocean usług systemów szytych na miarę na głównym rynku uczenia maszynowego.
źródło: https://web.archive.org/web/20220405031625/https://logspace.ai/
Zachęcam do przeczytania wpisu Rodrigo Nadera (https://www.linkedin.com/in/rodrigo-nader-673163bb/), obecnego prezesa LangFlow (dawniej Logspace) jaką miał wizję na swoją firmę. Mówiąc brutalnie - nie imponuje.
“Logspace was developed to help businesses and organizations that have an interest in Machine Learning to find the right fit for their specific needs, offering custom solutions powered by robust technologies, with pipelines that start from experimentation all the way up to deployment.”
Może ta szczerość i prostota to była recepta na sukces? tego nie wiem. Wiem natomiast, że szybko zaczęli tworzyć swoje IP. Nazwali to LangFlow - GUI do Langchain. Stworzyli to narzędzie w marcu 2023 roku i od razu zaczęło rosnąć jak na drożdżach. Jak?
Reddit.
Reddit to świetne narzędzie do złapania trakcji na Github
To właśnie Reddit napędził pierwszą falę użytkowników. Wiosną 2023 Reddit był najgorętszym miejscem dla projektów AI - każdy nowy tool „for LangChain” natychmiast trafiał przed tysiące developerów. Posty o LangFlow pojawiły się równocześnie na r/MachineLearningNews, r/LangChain, r/LLMDevs i r/LanguageTechnology, z wysokim poziomem zaangażowania (upvotes, komentarze, dyskusje).
Z danych historycznych Reddit API oraz metryk porównywalnych projektów (Flowise, AgentGPT, AutoGPT), publikowanych w dokładnie tym samym okresie, wiemy, że posty AI z 50–200 upvotes generowały od kilku do nawet kilkunastu tysięcy przekliknięć do repozytoriów GitHuba.
Wpis o LangFlow na Reddit miało bardzo podobną skalę reakcji więc w pełni bezpiecznie można przyjąć, że w pierwszych dniach wygenerowało co najmniej kilka tysięcy wejść na repozytorium. W świecie OSS to wystarczy, aby wskoczyć na GitHub Trending i uruchomić efekt domina: Slack LangChain, Discordy AI, Twitter, newslettery, blogi.
Reddit był zapałką.
źródło: https://www.reddit.com/r/machinelearningnews/comments/11uqdju/meet_langflow_an_open_source_ui_for_langchain_ai/
To tylko tytuł i video! nic więcej. Odpowiedni wątek na Reddit, odpowiedni moment w rynku. Idealny przykład złapania tornada.
Potem nastąpił wybuch na Github. Repozytorium łapało gwiazdki jak dziecko nowe zabawi w sklepie. UI for LangChain to majstersztyk nazewnictwa. Nie było tutaj nic sprzedażowego. Po prostu UI do LangChain. 100% trafia w pragmatyków, którzy tego właśnie potrzebowali.
Równolegle Rodrigo zaczął pisać na Linkedin. Zanalizowałem 231 postów…
Ewolucja komunikacji: od developer tool do enterprise platform
Analiza 231 postów Rodrigo Nadery, CEO Logstack z ostatnich 2 lat pokazuje wyraźną transformację. Nie chodzi tylko o wzrost zaangażowania (z ~20 do 50-200 komentarzy na post), ale o fundamentalną zmianę pozycjonowania.
Faza 1: Początki (2023) - “UI for LangChain”
Pierwsze posty były proste i techniczne. “We are excited to announce LangFlow - An Open Source UI for LangChain”. Hashtagi: #ai #langchain #chatgpt #gpt3 #gpt4 #opensource.
Zaangażowanie: 20-30 komentarzy. Styl: developer talking to developers. Posty głównie własne o funkcjach produktu. To był moment, gdy Reddit napędzał ruch, a LinkedIn był dodatkowym kanałem. Rodrigo nie próbował być thought leaderem po prostu informował o narzędziu.
Faza 2: Budowanie społeczności (2023-2024) - “10k stars!”
Gdy Langflow osiągnął 10k GitHub stars, posty zaczęły się zmieniać. “Big news! Langflow has hit 10k stars on GitHub!” to milestone, który buduje wiarygodność.
Zaangażowanie rosło do 30-50 komentarzy. Pojawiły się reposty treści społeczności np. gdy ktoś pisał o LangFlow, Rodrigo to udostępniał. Wygląda jakby to był moment, gdy zrozumiał, że LinkedIn to nie tylko kanał informacyjny, ale platforma do budowania marki.
Faza 3: Przełom - akwizycja DataStax (10-11 miesięcy temu)
“HUGE news... Langflow is being acquired by DataStax!” - ten post miał 156 komentarzy i 7 repostów. To był moment, gdy wszystko się zmieniło. Pozycjonowanie przeskoczyło z “developer tool” na “enterprise AI platform”. Posty zaczęły mówić o “empowering enterprises”, nie tylko o “prototyping with LangChain”. Zaangażowanie skoczyło do 50-100 komentarzy na post. Rodrigo zaczął częściej repostować treści o trendach AI — nie tylko o Langflow, ale o całym ekosystemie.
Faza 4: Dojrzałość produktu (8-10 miesięcy temu) - “Langflow 1.0, 1.1, 1.2...”
Główne nowe wydania LangFlow: 1.0, 1.1, 1.2, 1.3, 1.4. Każdy release to osobny post z konkretnymi funkcjami. Zaangażowanie stabilne i wysokie: 47-142 komentarze na postach.
Ale to też moment, gdy Rodrigo odkrył, że reposty edukacyjne działają lepiej niż własne posty. Repost o Stanford LLMs lecture: 126 komentarzy, 388 repostów. Memo CEO Opendoor o “Default to AI”: 653 komentarze, 126 repostów.
Mix contentu: 60% reposty (trendy AI, edukacja) + 40% własne (releases, funkcje). To już nie był Rodrigo jako developer tool creator - to był thought leader, który dobiera najlepsze treści z ekosystemu AI.
Faza 5: IBM Era (2-8 miesięcy temu) - Enterprise positioning
Kolejna akwizycja: “DataStax is now part of IBM”. Pozycjonowanie przeskoczyło na executive level. Posty o strategic partnerships: IBM + Anthropic, NVIDIA GTC, watsonx Orchestrate.
Zaangażowanie najwyższe w historii w takich tematach:
GitHub Copilot Extensions: 786 komentarzy, 128 repostów
Reinforcement Learning post: 866 repostów (tylko 28 komentarzy, ale viral na repostach)
Stanford LLMs: 388 repostów
To był moment, gdy Rodrigo zrozumiał mechanikę LinkedIn: reposty o trendach AI generują więcej zaangażowania niż własne posty o produktach. 59% postów to reposty i strategiczne dobierane treści, które pozycjonują go jako eksperta, który wie, co się dzieje w AI.
Faza 6: Obecnie (ostatni miesiąc) - Competitive positioning
“AgentKit vs LangFlow” to już nie tylko informacja o produkcie, ale strategiczne pozycjonowanie w kategorii. Langflow 1.6 z Advanced Parser: 333 komentarze. IBM + Anthropic partnership: 117 repostów. Styl: strategic + competitive + technical. Mniej postów, ale wyższe zaangażowanie. Więcej oryginalnych postów o produktach oraz strategiczne reposty.
59% postów to reposty. To nie jest lenistwo, to strategiczne dobieranie treści, które pozycjonuje go jako kogoś, kto wie, co się dzieje w AI. Własne posty o produktach są ważne, ale to reposty budują wiarygodność jako thought leader.
Druga lekcja: zaangażowanie rośnie z pozycjonowaniem. Gdy był “developer tool creator”, miał 20-30 komentarzy. Gdy stał się “enterprise AI leader”, ma 50-200 komentarzy. To nie przypadek. To efekt zmiany pozycjonowania i grupy docelowej.
Trzecia lekcja: milestone’y działają. 10k GitHub stars, Langflow 1.0, akwizycje - każdy milestone to okazja do posta, który buduje wiarygodność i zaangażowanie.
Rodrigo przeszedł przez różne grupy decydentów na LinkedIn:
2023: “UI for LangChain” trafia w developerów, którzy potrzebują narzędzia
2024: “Enterprise AI platform” trafia w decision makers, którzy potrzebują bezpiecznego wyboru
2025: “Thought leader” trafia w ludzi, którzy chcą wiedzieć, co będzie dalej
Każda grupa wymagała innej komunikacji. Rodrigo nie próbował być wszystkim dla wszystkich. Dostosowywał komunikację do fazy rozwoju, w której był Langflow.
Co to oznacza dla Twojego firmy usługowej IT?
Przykład Logspace jest dla mnie niesamowicie budujący. Po pierwsze, pokazuje jak firma usługowa IT, pokorna, prosta, może szukając bólu i rozwiązując go w odpowiedni sposób w odpowiednim momencie rynku zamienić się w firmę opartą o swoje IP.
Po drugie, to, że jest to firma z Brazylii pokazuje, że Karwatka Brothers Framework nie ma granic. Działa zarówno w Polsce, jak i w każdym innym miejscu na świecie. Kluczem jest dopasowanie DNA firmy, do odpowiednio dobranej technologii/trendu, która trafia w Tornado no i oczywiście - egzekucja. Jak widzicie po postach na Reddit, Linkedin - to nie jest mistrzostwo świata. To co dało im siłę nośną to było odpowiednie trafienie w tornado.
Jeśli budujesz IP i chcesz użyć LinkedIn do budowania pozycji eksperckiej, obserwuj ewolucję Rodrigo:
Zacznij od własnych postów o produkcie - budujesz wiarygodność jako twórca
Dodaj reposty treści społeczności - pokazujesz, że jesteś częścią ekosystemu
Dobieraj najlepsze treści z kategorii - budujesz pozycję thought leadera
Używaj milestone’ów - każdy sukces to okazja do posta
Pozycjonuj się strategicznie - nie tylko informuj, ale pokazuj, gdzie jesteś w kategorii produktu, który tworzysz
LinkedIn to nie tylko kanał sprzedażowy. To platforma do budowania pozycji eksperckiej, która później przekłada się na biznes. Rodrigo pokazuje, jak to zrobić systematycznie przez 2 lata.
Leady w 10 dni z Twojego IP - cz 1.
Jak zacząć budować własne IP?
Jednym z pierwszych etapów na drodze bo bycia Gorylem Usługowy, którego firmy często nie potrafią przejść, jest moment, w którym przestają oddawać pełnię praw do wszystkiego, co wytworzą.
Postawię taki bet: Pracujesz na złych umowach.
Takich, w których za każdym razem przekazujesz klientowi pełne prawa autorskie do wykonanego dzieła…
Oczywiście, jest wiele sytuacji, w których klienci nie zgodzą się na nic innego, ale w sektorze oprogramowania są całe warstwy kodu – frameworki, biblioteki, narzędzia – które można tworzyć na własne potrzeby.
Jeśli w trakcie projektu widzisz, że wyłania się moduł, który może się przydać dla innych klientów w Twoim lejku sprzedaży, albo jest łudząco podobny do tego co zrobiłeś wcześniej dla innego klienta - to wiedz, że to pierwszy mocny sygnał, że znalazłeś tzw. IP Opportunity.
IP Opportunity to nic innego jak okazja na stworzenie swojego IP, które nie jest w konflikcie z interesem klienta, jest dla niego pomocą bo korzystając z Twojego IP przyśpiesza swoją pracę, dostaje więcej funkcji, ma stabilniejszy system.
Tych okazji w swojej firmie usługowej IT będziesz miał setki, jak nie tysiące. Czy dane IP Opportunity warto realizować opisze poniżej. Skupmy się na zrobieniu sobie do tego miejsca od strony formalnej.
Nie jestem prawnikiem, ale od ponad 12 lat pracuję nad umowami z klientami i prawnikami.
#1 Zapis o swoich narzędziach
Pierwsza rzecz to powinniście mieć zapis o tym, że poza korzystaniem z oprogramowania OSS, macie prawo na korzystanie z własnych narzędzi, które wytworzyliście na rzecz przyśpieszenia pracy nad projektami. To są wszelkiego rodzaju skrypty automatyzujące, pomagające w CI/CD, ale też własne biblioteki i komponenty, które zespoły tworzą aby ułatwić sobie pracę. Oczywiście, licencja na tego typu oprogramowanie powinna być jasna w umowie i pozwalająca klientowi na korzystanie z niej do realizacji swoich działań biznesowych łącznie z możliwością odsprzedania tej licencji np. w momencie sprzedaży firmy klienta.
Po co ten zapis? bo daje Wam możliwość użycia własnego IP przy założeniu, że rozwijacie je na swój koszt i nie jest to przejęcie know-how klienta.
Jest to elastyczne rozwiązanie, które klient akceptuje bo jest dla niego dość logiczne, że tak jak korzystamy z projektów OSS, to możemy korzystać także z gotowych szablonów projektów, modułów, aby obniżyć koszt wytworzenia systemu także dla klienta.
Natomiast istotne jest aby jasno oddzielić pracę nad swoimi bibliotekami od pracy nad kodem klienta oraz jeśli pracujecie w modelu godzinowym - nie pobierać opłaty za tą część systemu. Ważne jest także jasne komunikowanie z klientem to czego Wasze narzędzia dotyczą, najlepiej tworząc oddzielny SOW (Statement of Work) pod ten zakres prac wraz z określoną licencją.
Tutaj pojawia się pierwsze niebezpieczeństwo bo nie chcemy tworzyć za darmo kodu tylko dlatego, że wydaje nam się, że może nam się kiedyś przydać. Do tego bardzo pomocne będzie narzędzie, które obok Testu Tornada stworzyłem na potrzeby mojego warsztatu o nazwie IP Opportunity Radar. To narzędzie pozwala w oparciu o zebrane dane z różnych źródeł dokonać analizy i przedstawić matrycę porównawczą, które IP Opportunity ma największy potencjał na bycie zalążkiem tornada. W naszym kursie poruszę kilka filarów IP Opportunity Radar, a w tej części przedstawię najważniejszy z nich.
Wracając jednak do naszej sytuacji, gdy już widzicie taki kawałek kodu, który może warto zamienić w swoje IP możecie przystąpić do rozmów z klientem. Najlepiej robić to jeszcze zanim zaczniecie prace. Jest to możliwe, bo podczas analizy wymagań jest duża szansa, że Wasz zespół sam odkryje, że część systemu można by było wydzielić do uniwersalnego kodu. To pierwszy krok. Nauczyć zespół tak patrzeć na projekty jak na puzzle, których cześć pasuje tylko do siebie, a cześć będzie pasowała do innych układanek.
Gdy już odkryjecie IP Opportunity i załóżmy oceniliście już jego potencjał, możecie ustalić plan rozmowy z klientem.
jeśli klient nie potrzebuje praw do tej części kodu bo nie przeszkadza mu, że ktoś inny skorzysta z niego, to nic nie stoi na przeszkodzie aby mu dać ofertę, która jest dla niego super atrakcyjna: zrobimy to taniej bo będziemy mieć dzięki temu szansę wdrożyć nasze biblioteki na Twoim projekcie.
Kluczowe: klient ma rabat nie dlatego, że piszecie kod za jego pieniądze, tylko dlatego, że pozwalacie mu zintegrować kod napisany przez Was na Wasz koszt z jego systemem i go na nim testować. Jest Design Partnerem. Więcej o tym pisze Tomek Karwatka w książce The5 oraz w dodatku w Karwatka Brothers Framework.
#2 Rabat na dane IP dajesz RAZ
Skoro pierwszy klient dostał rabat za to, że testowaliście na nim swój kod i otrzymał działające rozwiązanie, to kolejny klient na ten sam projekt nie dostaje tej samej oferty.
Od początku sprzedajecie dwie rzeczy. Usługę wytworzenia systemu oraz licencję na kod wraz z możliwym dostosowaniem (również na licencji).
To oznacza, że jest duża szansa, że już drugi klient pozwoli Wam zarobić więcej niż ten pierwszy bo wartość jaką otrzymał jest taka sama jak pierwszy klient, a nie musiał Wam robić przysługi. Nie ma argumentu do negocjacji. Nawet więcej - dostaje lepszy kod niż jakbyście go napisali za pierwszym razem bo już był sprawdzony w boju. Cena więc powinna być taka jaką normalnie by miał zapłacić za wytworzenie tego systemu z przekazaniem pełnych praw, a może nawet wyższa bo korzystając z istniejącego modułu dostarczycie system szybciej i z lepszą jakością.
Dlaczego? bo jesteście jedyni na rynku mający tą licencję. Klient nie ma z czym porównać Waszej ceny.
#3 Klient chętnie zapłaci Tobie za licencję
Zrozumienie tych różnic w dynamice negocjacji zmienia wszystko. Gdy klient przychodzi do Ciebie po “custom development”, od razu ustawia się w pozycji właściciela. Płaci za Twój czas, więc oczekuje, że wszystko, co powstanie, będzie jego własnością. Jeśli w tym momencie spróbujesz zachować prawa do części kodu (udzielając licencji), klient niemal zawsze zażąda rabatu. W jego oczach “nie dostaje wszystkiego”, więc powinien zapłacić mniej.
Zupełnie inaczej wygląda rozmowa, gdy klient przychodzi kupić od Ciebie produkt – nawet jeśli ten produkt jest jeszcze niekompletny. Wówczas od pierwszej minuty rozumie, że kupuje rozwiązanie problemu, a nie wyłączne prawa do kodu. Nie oczekuje, że stanie się właścicielem Twojego IP, tak jak nie oczekuje, że stanie się właścicielem kodu Salesforce’a czy SAP-a, gdy kupuje licencję.
Co więcej, jeśli pokażesz mu, że do “pełnego szczęścia” (Whole Product) brakuje kilku funkcji, które są na Twojej roadmapie, często zgodzi się za nie zapłacić w ramach wdrożenia. Finansuje w ten sposób Twoje R&D, ale nie żąda w zamian praw własności, bo kupuje “przyspieszenie rozwoju produktu”, z którego będzie korzystał. To zdrowy model budowania IP: klient płaci za rozwój Twojego produktu, bo rozwiązuje to jego problem tu i teraz.
Relacja z design partnerem i jego biznes jest dla Ciebie bardzo ważna, dlatego istotne jest zaadresowanie jego obaw.
Korzystanie z Twojego IP powinno być wartością dla klienta. Jeśli tak nie jest to możliwe, że ten obszar chce zachować dla siebie na swoją wyłączność - musisz to z nim ustalić i odkryć gdzie on potrzebuje IP, a gdzie wystarczy mu licencja.
Jego know-how jest dla niego kluczowe. To gdzie możesz rozważać tworzenie IP to narzędzia, moduły, które nie naruszają jego tajemnic i tylko w porozumieniu z nim.
Twój kod piszesz za swoje pieniądze.
Jasno określony zakres tego co jest objęte licencją na Twoje IP, a co na przekazaniu praw dot. reszty systemu pozwoli uchronić Ciebie przed problemami
Skorzystanie z Twojego IP powinno umożliwić klientowi dalszy samodzielny rozwój tej części systemu, która na nim polega. Vendor-lock to najgorsze co możesz dać swojemu design partnerowi.
A teraz jak już wiesz trochę więcej jak od strony formalnej i sprzedażowej prowadzić rozmowy z klientami…
Zatrzymaj się, zanim „dopiszesz” cały produkt
Gdy już masz ten kawałek kodu – framework, moduł, zalążek produktu – pojawia się pokusa, która zabija najwięcej inicjatyw w firmach usługowych IT.
Zamiast wyjść z tym do ludzi, zamykasz się w biurze.
Wydaje Ci się, że nie możesz nic zrobić, bo to tylko „wtyczka”, „mały moduł”, „niekompletny system”. Próbujesz na własny koszt rozwijać to dalej, bo boisz się momentu, w którym klient zapyta: „A czy to jest gotowe?”, a Ty będziesz musiał odpowiedzieć: „Nie”.
źródło: ChatGPT
Lęk ten jest tylko w Twojej głowie. Nie musisz kłamać. Nie musisz mówić rynkowi, że masz coś, czego nie masz. Nawet jeśli Twój kod ma bugi i jest gotowy w 30% to wiesz już z tych wszystkich wcześniejszych projektów, albo przynajmniej masz wizję, jak powinien wyglądać ten system w całości. To jest ten moment, w którym musisz się zatrzymać. Zamiast kodować w ciemno przez kolejne pół roku, wyjdź do rynku z tym, co masz.
IP Opportunity Radar - filtr Tornada
Jeśli spojrzysz na nasz przykład z LangFlow to widzisz, że artykuł na Reddit to bardzo prosty post. Zapewne stworzenie go wymagało 30 min pracy. Jeśli popatrzysz na repozytorium LangFlow, jak ono wówczas wyglądało (jest pod tym linkiem: https://github.com/langflow-ai/langflow/archive/refs/tags/v0.0.31.zip) to zobaczysz, że jest to bardzo surowy i prosty produkt. Typowe MVP.
Zatem jak się stało, że pragmatycy, którzy stronią od takich projektów nagle chcieli rzucić się na niego? Bo LangFlow nie był w oderwaniu od ekosystemu OSS. To było UI for LangChain! To pozycjonowanie było KLUCZOWE.
Pragmatycy w tornado LangChain szukali właśnie tego narzędzia i fakt, że było dopiero na początku swojej drogi wcale ich nie odstraszył. Jaka jest kluczowa lekcja?
Wrażenie całego produktu dla Twojego nowego IP w tornado buduje się najlepiej w oparciu o technologię, która już tam jest.
I tutaj jest pierwszy brutalny filtr w naszym kursie “Leady w 10 dni z Twojego IP”.
Jeśli Twoje IP Opportunity nie bazuje na technologii będącej obecnie w tornado (czyli fazie gdzie jest masowo adoptowana przez pragmatyków), to nie będzie wystarczająco dużo leadów wokół niego się kręciło aby złapać je w 10 dni.
To do czego dążymy w naszym kursie “Leady w 10 dni z Twojego IP” to odrzucić wszystkie IP Opportunities, które nie przechodzą przez ten filtr.
Dam Tobie dwa przykłady.
React Native Geolocation
Pracując z klientem odkryliście, że warto stworzyć bibliotekę do obsługi modułu GPS, bo te wbudowane w React Native, są niewystarczające. Stworzyliście coś co robi to dokładniej, a na dodatek widzicie na rynku firmę Transistor Software https://github.com/transistorsoft, która sprzedaje tego typu moduł za kilkaset dolarów na rok. Myślicie, że rynek jest olbrzymi bo przecież jest bardzo wiele firm, które korzystają z GPSa w swoich aplikacjach. Czujecie ten ból oraz widzicie nagrodę tuż przed sobą. Problem w tym, że React Native już dawno przeszedł fazę tornado, jest teraz na głównej ulicy. Co więcej, sam aspekt GPS to nie jest coś co idzie zawsze w parze z samym React Native, jest to tylko pewien aspekt jednej niszy w React Native - geo-based apps. Co to oznacza?
Pęd pragmatyków dawno się skończył a Twój produkt atakuje przypadki użycia w małej niszy. Główny rynek systematycznie przechodzi na Flutter’a lub React Native, ale panika i i pęd już są dawno za nim. To nie wygeneruje Wam leady w 10 dni, może w 10 miesięcy, ale to w nie pozwoli Wam stać się globalną, wysokomarżową firmą. Zobaczcie tylko jak duża jest firma Transistor Software, która od 10 lat nad tym pracuje. Jest to jednoosobowa działalność Christophera Scotta, widać to chociażby o po tym kto kontrybuuje do flagowego projektu React Native Background Geolocation https://github.com/transistorsoft/react-native-background-geolocation
Drugi przykład to llm-router.
LLM-router to projekt open source, który obecnie ma tylko kilka gwiazdek. Strona projektu (https://llm-router.cloud/) tłumaczy czym jest, poza oczywiście narzędziem pozwalającym na zmianę kierunku ruchu danych pomiędzy np. chmurą (OpenAI/Gemini etc.) vs private-cloud z Twoim własnym modelem LLM. Jest to projekt, który może zginąć jeśli będzie oderwany od ekosystemu, który jest w w tornadzie - w tym przypadku LangChain. LangChain słynie z tego, że szybko staje się skomplikowany (”spaghetti code”). Dla developera LangChain, wdrożenie obsługi zapasowych modeli (fallback) w czystym kodzie jest uciążliwe. Ta biblioteka robi to 10x szybciej i czyściej. Jest to potencjalnie bardzo dobra pozycja ataku tornada AI…ale, trzeba wyciągnąć lekcje z LangFlow i dokonać rebrandingu, aby LL-router stał się naturalnym przedłużeniem LangChain.
Śmię twierdzić, że lekki pivot w komunikacji, trochę inny sposób publikacji i zmiana nazwy repozytorium może wywołać LangFlow effect, o którym czytaliśmy na początku tego artykułu.
Dotarliśmy do końca pierwszej części inicjatywy “Leady w 10 dni z Twojego IP”. W kolejnej części poznamy kolejne elementy IP Opportunity Radar, które pozwolą szybko odsiewać pomysły na IP oraz pierwsze metody testowania swojego IP.