Cel tego sprintu:
W ciągu najbliższych 10 dni wybierzesz jeden pomysł na IP, zweryfikujesz go rynkowo i zdobędziesz pierwsze sygnały zainteresowania (Leady), pisząc jak najmniej kodu/treści.

Czy to możliwe bez gotowego produktu? Tak. Historia LangFlow (o której pisałem w tym artykule) pokazuje, że dobrze spozycjonowane MVP w “Tornadzie” sprzedaje się samo.

Ale zanim ruszymy po leady, musimy naprawić błąd, który zabija 90% software house’ów na starcie: brak prawa do własnego kodu.

Zaczynamy od przygotowania prawnego i sprzedażowego przedpola.

Pomysłów na stworzenie swojego IP jest naprawdę sporo, ale który wybrać? celowo narzuciłem nam w tym kursie limit 10 dni. Nie dlatego, że planuje spamować ludzi na Linkedin z Waszą pomocą aby zdobyć te upragnione leady. Nie. W tym kursie chcę z Wami wybrać takie IP Opportunity, które ma taką pozycję, że leady same do Was przyjdą w 10 dni. Czy to w ogóle jest możliwe? Zobacz sam na przykład LangFlow, o którym piszę powyżej. Tak, to jest jak najbardziej możliwe.

Natomiast aby w ogóle móc pracować nad swoim IP, trzeba mieć do tego odpowiednie przedpole.

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ą.

#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.

1. 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.

2. 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.

3. Twój kod piszesz za swoje pieniądze.

4. 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

5. 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”.

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 w tym artykule.

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.