Jak skutecznie uruchomić internetowy projekt
11 godz. 20 min · Biznes i Automatyzacje
Grzegorz RógIdea ArchitectZarówno w Polsce jak i za granicą uruchomiłem już dziesiątki projektów... Były to zarówno narzędzia, SaaSy jak i infoprodukty. Praktycznie wszystkie uruchomione przeze mnie projekty lądowały na głównej stronie Product Hunt i już od pierwszego dnia - zarabiały. Wszyscy biznesowi mentorzy powtarzali, że "powinienem skupić się na jednej rzeczy". Tymczasem w mojej ocenie, to, co robię daje mi wolność i co równie ważne - pozwala ciągle się uczyć. Moje projekty zarabiają kilka-kilkanaście tysięcy dolarów miesięcznie, co czasem wystarcza, żeby utrzymać niewielki zespół, niekiedy nawet to jest niepotrzebne, wystarczy sporo automatyzacji i produkt, który jest niemal w 100% marżowy. Początkowy etap projektów daje mi ogromną frajdę - lubię sam odkrywać i kreować produkt, który następnie testuję i wypuszczam na rynek. Na przestrzeni lat, w tym zakresie wyrobiłem sobie utarte ścieżki, z których ciągle korzystam, ale też pozwalam sobie na wiele eksperymentów po to, by w ciągle zmieniającym się ekosystemie internetowych produktów - uczyć się, co działa. Późniejszy etap projektów raczej mnie nudzi - zatrudnianie, tworzenie dużego zespołu oraz zarządzanie nim, to nie jest coś co mnie ekscytuje. Zauważyłem też, że wraz ze skalowaniem zespołu często maleją także zyski z projektów, na których mi zależy. Zwykle więc staram się, aby moje projekty... pozostały małe (ale bardzo dochodowe), co daje mi wolność: finansową i czysty kalendarz. Jeśli któryś z nich rozwija się za szybko, myślę o sprzedaży i exicie, ale tym nie będziemy zajmować się w tym Kursie. Sprzedałem w Internecie produkty dla ponad 300 tysięcy osób. Od infoproduktów jak kursy i ebooki, przez narzędzia i SaaSy. Każdy z tych projektów ma swoją specyfikę i konkretne techniki, które wykorzystuję, by go rozwijać. Każdy nauczył mnie czegoś nowego i w każdym z nich popełniłem jakieś błędy. W tym Kursie, chciałbym powiedzieć Ci wszystko, co wiem o uruchamianiu produktów, które są już "w miarę gotowe", czyli są blisko Product Market Fit, bądź czekają na premierę jako infoprodukt czy narzędzie. Chcę przekazać Ci mój sposób na to, jak przygotowuję produkt do premiery, jak myślę o marketingu, automatyzacjach, treściach czy stronie WWW i w końcu jak układam to w taki sposób, aby po prostu działało! Jakiś czas temu udzieliłem wywiadu na temat moich projektów Courtlandowi, twórcy ruchu Indie Hackers, który jest bliski temu, co robię. Jeśli masz chwilę, posłuchaj go tutaj. Jednak moja filozofia ma istotne odchylenie: uważam, że nie każdy projekt powinien być tworzony jednoosobowo. Prawie zawsze stawiam na małe zespoły - kilku co-founderów i kilka osób do pomocy lub na freelance, bo wierzę, że w ten sposób można robić większe rzeczy, dające więcej wartości, z potencjałem na pozyskanie rozsądnego finansowania czy exit.
W trakcie Kursu dowiesz się o trzech kluczowych fazach związanych z międzynarodową premierą projektu: Przygotowaniu do premiery, Premierze oraz działaniach po premierze. Sama premiera jest dość symboliczna i nie ma aż tak dużego znaczenia - to, dlaczego jest ważna, to pozwala wybrać datę, w której to, co sobie założyliśmy w produkcie powinno się zmaterializować. W trakcie Kursu pokażę Ci wiele narzędzi oraz wytłumaczę moje podejście i frameworki, które pozwalają mi co jakiś czas wypuszczać z sukcesami produkty na rynek. Pomówimy o automatyzacjach, które towarzyszą mi na każdym kroku a także doborze stacku w kontekście marketingu. Dowiesz się, co działa dla mnie najlepiej w tym konkretnym momencie. Czy warto stawiać wyłącznie na działania organiczne, czy wspierać się płatną reklamą i innymi kanałami. Gdzie warto się pokazać i co warto robić po to, aby sama premiera dała nam dodatkowy boost i pozwoliła zdobyć wartościowe leady. Mam nadzieję, że zebrane w ten sposób wskazówki, pozwolą Ci uniknąć moich błędów, zyskać mnóstwo czasu a także oszczędzić pieniądze, które inaczej mógłbyś przepalić na niepotrzebne działania.
Idealnie, jeśli masz już produkt lub jesteś blisko MVP, które chcesz wypuścić na rynek. W takim przypadku, możesz razem ze mną podążać po kolejnych obszarach, które poruszam w tym Kursie i tworzyć swój własny plan na premierę. Jeśli jednak dopiero tworzysz czy planujesz uruchomienie swojego produktu - ten Kurs też będzie przydatny tylko pod warunkiem, że nie oczekujesz od niego pomocy we wczesnej fazie - wymyślania i samej kreacji. Jeśli masz jasną wizję tego, co stworzysz, świetnie! Ten Kurs powinien przybliżyć Cię do wyjścia z produktem na rynek na etapie, gdy będzie on już gotowy. Dobrze by było, gdybyś podążając za mną w kolejnych lekcjach, znalazł/a czas na odniesienie moich spostrzeżeń do Twojego projektu i praktyczną pracę nad przygotowaniami do premiery, nawet jeśli ta jest jeszcze odległa.
Ten Kurs jest starannie przygotowany z myślą o:
Witaj w kolejnej lekcji, w której porozmawiamy trochę o procesie
developmentu i wdrażania.
I oczywiście służy on wdrażaniu produktów takich jak narzędzia czy aplikacje czy
SaaS, więc będzie to odpowiednie do tych produktów.
Ale ja stosuję akurat te metody również do zarządzania swoimi mniejszymi
projektami i swoimi zadaniami.
Również używam aplikacji Linear, o której chcę powiedzieć
teraz i tej metody do swoich pobocznych projektów i nawet do mojego, do mojej
listy zadań, którą realizuję właśnie z pomocą metody Linear.
Używam tego we wszystkich moich projektach i chciałbym, żebyś ją
teraz poznał czy poznała.
Jest taka strona, która nazywa się Linear Method i tutaj znajdziesz
omówienie tej całej metody.
Ona jest oparta o pewien framework budowania oprogramowania,
aczkolwiek można korzystać z różnych tutaj frameworków w zależności od tego, który
lubimy bardziej, który mniej.
Ja szczerze mówiąc nie lubię żadnego, jeśli chodzi o
takie stricte reguły Stosowania czy to na przykład Scruma, czy innych.
Nie lubię żadnego, dlatego, że każdy z nich tak naprawdę jest specyficzny i
dostosowany do odpowiedniej wielkości zespołu, do odpowiedniej wielkości
projektu i do odpowiedniej fazy tego, w jakiej ten projekt funkcjonuje.
A często to jest tak, że ludzie po prostu trzymają się tej jednej metody i trzymają
się jej kurczowo, Mimo tego, że nie jest ona odpowiednia na jakimś etapie budowania
projektów, to oczywiście nie chcę wchodzić w rolę PMA i tłumaczyć
wszystkich tych zawiłości.
Uważam, że wchodzenie na tak głęboki poziom w tym kursie nie ma sensu,
Zresztą zajęłoby dość długo.
Natomiast skuteczne prowadzenie zespołów, które wdrażają Twoje produkty
jest na pewno sztuką, której trzeba się nauczyć i którą trzeba opanować.
I polecam Ci to, jeśli zamierzasz odpalać swoje własne startupy.
Ja powiem o tym moim takim trochę przyspieszonym podejściu do tej metody.
Wdrażam w całości tą metodę, która jest tutaj podana.
Na Linear mamy tutaj bardzo jasno i bardzo fajnie określone główne zasady
tego, jak budujemy oprogramowanie.
Dlaczego powinniśmy to robić?
Dlaczego nie powinniśmy być ciągle zajęci?
Dlaczego powinniśmy priorytetyzować proste rzeczy?
I nie będę tego wszystkiego tłumaczył, ale w skrócie większość zasad, które tutaj są
i większość tych practices to jest dokładnie to, co mi przyświeca przy
budowaniu projektów i oprogramowania.
Następnie mamy Direction, czyli jak wyznaczyć sobie tą ścieżkę w produkcie.
Jak widzisz nie są to jakieś skomplikowane i długie długie dokumenty.
Jest tu po prostu sporo bardzo prostych zasad, które sprawdzają się i można
przeczytać to dosłownie w pół godziny.
Mamy tutaj też takie podstawowe zasady korzystania z narzędzia Linear, które jest
genialne i które polecam Ci nawet jak pracujesz sam nad projektem po to, żeby
priorytetyzować sobie pewne zadania, dodawać Milestone, a jeśli
jesteś w zespole, tym lepiej.
Tutaj można właśnie tym skutecznie zarządzać.
Ja korzystam zawsze z Lineara, nie korzystam z Asany, nie korzystam z Trello
i z Jira wszystkich innych narzędzi.
Korzystam z Lineart zarówno do zadań w developmencie, jak i do
zadań bardziej miękkich.
Natomiast jeśli chodzi o takie rzeczy, o których będziemy mówić później, związane z
marketingiem, raczej używam do tego notion.
Natomiast tutaj mamy informacje o tym, dlaczego nie powinniśmy na przykład pisać
user stories I z tym się totalnie zgadzam, że dlaczego powinniśmy
zamiast tego pisać issues.
No i tutaj się tego wszystkiego oczywiście dowiesz.
Dowiesz się też z tych z tej dokumentacji.
Jak pracować z samym narzędziem?
Samo narzędzie jest rewelacyjne i pozwala nam tworzyć cykle w ramach tych cykli.
To jest akurat jeden cykl.
Czyli mamy sporo cykli, cykli, na których pracujemy.
To jest jeden cykl, który zawiera mnóstwo różnych zadań, które
zostały w ramach tego cyklu zdefiniowane, przypisane do odpowiedniego
miejsca, opatrzone odpowiednim labelem, przypisane do właściwej osoby i którym
została przypisana odpowiedni estymat. I teraz.
To jest akurat moja metoda pracy, którą wypracowaliśmy w zespole i
w miarę wszędzie się tego staramy trzymać.
Operujemy w dwutygodniowych cyklach, czyli co dwa tygodnie robimy sobie spotkanie
w gronie osób, które rozwijają produkt i tam dyskutujemy o tym,
jakie zadania udało nam się w tym konkretnym cyklu osiągnąć i
robimy planowanie na kolejny cykl.
Więc można powiedzieć taka trochę metoda scrumowa i to faktycznie dobrze działa.
Natomiast nie stosujemy się do wielu rzeczy, które też wywodzą się ze Scruma.
Na przykład nie robimy retrospekcji i tego typu rzeczy w małym, zwinnym zespole.
Po prostu wybraliśmy te rzeczy, które dla nas są dobre i wiem, że project
managerowie mogą się ze mną nie zgodzić.
Mogą powiedzieć to, co słyszę bardzo często, że jeżeli stosujemy jakiś
framework Scrum, to powinniśmy albo stosować go w całości, albo odrzucić, bo
częściowe, wybiórcze stosowanie takich frameworków nie ma sensu.
No ale po prostu my wypracowaliśmy to, co dla nas działa najlepiej.
I zamiast przyjmować te frameworki jako prawdę objawioną, po prostu iterowaliśmy
sobie stopniowo po takim schemacie pracy, który nam wszystkim odpowiada.
I oczywiście nie musi on być w porządku dla wszystkich zespołów,
ale dla nas po prostu jest.
Nasz zespół jest dobrany pod kątem odpowiednich wartości, które przyświecają
każdej osobie i one są spójne.
Pracujemy asynchronicznie, pracujemy bez powiadomień.
Pracujemy wyłącznie w taki sposób, że mamy tutaj te gotowe
zadania, dystrybuujemy je, określamy dla nich właściwy priorytet i w linearze
można nad tymi wszystkimi zadaniami sobie.
Można dzielić je na projekty.
Oczywiście mamy szereg projektów tutaj stworzonych, mamy poszczególne widoki,
mamy też te issues, czyli poszczególne problemy przypisane do odpowiedniej osoby.
Mamy milestone, mamy kalendarz. To wszystko.
Nie będę tego oczywiście opowiadał.
To wszystko wynika z tej liny, metod i lina, że jest bardzo szczegółowo opisane,
jak powinniśmy używać tego narzędzia i w zasadzie większość tych rzeczy stosuję,
aczkolwiek też stosujemy je wybiórczo do tych do tych elementów, które które
nam pasują bardziej czy mniej.
Więc jeśli mamy tutaj jakieś zadanie, to mamy też do niego dyskusję, Można
dodać do niego zdjęcia, filmy i tak dalej.
Można zobaczyć jak się zmieniały jego statusy, można też zobaczyć estymaty.
To akurat jest nasza metoda, która powoduje, że jeden punkt to
uznajemy jako jedną godzinę.
I to jest bardzo fajne, ponieważ możemy sprawdzić, ile godzin ktoś zadeklarował
na zrobienie na przykład jakiegoś zadania.
Później tę godzinę każdy sobie jakby sprawdza, czy faktycznie tyle to
było i ewentualnie modyfikuje ten temat.
Co jest bardzo dobre, dlatego że to pozwala nam nauczyć się, ile w praktyce
jest jakby potrwało wykonanie zadania, a ile sobie versus to, co
wcześniej założyliśmy.
Na samym początku mieliśmy z tym ogromne problemy i wszyscy zakładali, że
coś potrwa godzinę, a trwało trzy.
Ale jak już zaczęliśmy uzupełniać estymaty i zaczęliśmy zmieniać te wagi punktowe Już
po wykonaniu taska, to się okazywało, że zaczęliśmy umieć lepiej przewidywać, ile
zajmie nam wykonanie konkretnego zadania I w ten sposób, pracując właśnie na Lineage,
bardzo dużo nauczyliśmy się i zrozumieliśmy z tego, jak pracujemy,
Zrozumieliśmy tego, ile czasu nam to zajmuje, dzięki czemu teraz
możemy dużo skuteczniej planować.
Więc co dwa tygodnie spotykamy się na takie review sprintu, gdzie omawiamy to,
co zrobiliśmy i omawiamy to, co chcemy zrobić dalej i planujemy taski, wrzucamy
taski po prostu, czyli te issues do kolejnego cyklu.
W takim dwutygodniowym cyklu oczywiście mogą się pojawić różne
dodatkowe rzeczy, które tam wpadają.
No i Linear ma naprawdę świetny sposób na monitorowanie tego wszystkiego, ponieważ
możemy bardzo łatwo tutaj zobaczyć, kto tutaj jeszcze mieliśmy etap, gdzie na
przykład nie każdy dodawał te swoje wagi i tak dalej, i
później dochodziliśmy do tego etapami.
Natomiast tutaj mamy informację o tym, kiedy ktoś podjął jakieś zadanie, kiedy je
skończył, zbliżając się przez te dwa tygodnie od początku do końca cyklu.
I mamy bardzo jasne statystyki, które mówią o tym, kto ile zadań
rozpoczął, skończył, wykonał, ile mieliśmy zaplanowane, ile zrobiliśmy.
No i w ten sposób bardzo fajnie nauczyliśmy się planować.
Oczywiście lider ma też szereg rzeczy, które pozwalają na przykład połączyć
się z repozytorium z GitHub em.
Więc jak robimy jakiegoś commita, może on nam automatycznie zamknąć taska.
No jest to po prostu genialne oprogramowanie do
robienia tego typu rzeczy.
I proszę zwrócić uwagę jeszcze na to, że każdy cykl, który tutaj mamy, ten
dwutygodniowy, dla mnie też jest opatrzony pewnymi milestone ami.
Czyli ja wpisuję sobie tutaj dokładnie te rzeczy, które z mojego, z
mojej perspektywy są ważne.
Na ogół są to rzeczy, które chcę komunikować klientom i dokładnie w tym
dwutygodniowym cyklu również operujemy w takim kontekście, że ja przynajmniej co
dwa tygodnie chcę będąc CEO w projekcie czy czy po prostu co-founderem, który
komunikuje się z klientami, chce wypuścić jakieś nowe funkcje, dać jakiś jakiś
sygnał o tym, że coś się zmieniło w projekcie, że coś udoskonaliliśmy,
że coś ulepszyliśmy.
I ten okres co dwa tygodnie jest całkiem niezły na to.
Ja właśnie wpisuję sobie tutaj w każdym cyklu staram się znaleźć też takie
zadania, które będą zadaniami na zewnątrz.
Czyli definiując cykl myślimy sobie jest mnóstwo takich zadań, które trzeba zrobić,
żeby ulepszyć architekturę oprogramowania, żeby usprawnić działanie bazy danych.
Tylko że to są rzeczy, których nie widzą klienci.
I to nie jest jakby konkretny feature, że coś wprowadziliśmy, co im
po prostu usprawnia pracę.
Więc moim zadaniem, jeśli jestem takim trochę PM'em w tym projekcie, jest to,
żeby na tym cyklu zdecydować i wrzucić do niego też kilka takich
tasków, które mi pozwolą po prostu informować klientów o tym, że
coś się fajnego dzieje dla nich.
Więc na ogół właśnie jest to podsumowanie cyklu.
Tutaj i tutaj wprowadziliśmy funkcję one time offer.
To była dla mnie ważna funkcja, którą mogłem ogłosić i zakomunikować światu.
I zawsze dwa, trzy czy cztery takie elementy staram się wpisać na każdy ten
dwutygodniowy cykl dla naszego zespołu.
Co dwa tygodnie komunikuję to na Slacku czy na naszym community, tak, żeby klienci
widzieli, że coś fajnego się dzieje.
Albo co tydzień wrzucam jakieś tam update'y.
Jeśli jeśli te rzeczy rzeczywiście są kończone w jakimś tam czasie właśnie
na przykład co kilka dni.
Natomiast co miesiąc, czyli co dwa takie cykle, robię większy update
i wypuszczam z nim mailing.
I tutaj macie przykład takiego maila i macie informację o tym,
co nowego wprowadziliśmy.
Na przykład funkcję zapłać ile chcesz, raty, integrację taką, taką i taką.
I co stało się?
Widzi na przykład, że mieliśmy jakiś rekordowy cyber week, że wprowadziliśmy
Google Pay w metodach płatności, że pobieramy automatycznie te e-maile, że
wprowadziliśmy ważność ciasteczek dla partnerów i tak dalej, i tak dalej.
I to, nad czym pracujemy, że pracujemy nad Easy 2.0, że pracujemy nad listą
oczekujących i mamy też dziesiątki drobnych usprawnień, jak to robię.
I robię to właśnie na podstawie tego, co mam w liderze,
czyli na podstawie tego zamkniętego cyklu.
wybieram te z tasków, te z zadań, które zasługują na opisanie i zasługują
na zakomunikowanie klientom.
No i albo robię je w formie większych ogłoszeń, albo wybieram szereg tasków,
które po prostu są mniejszymi jakimiś fix'ami i jeśli uznam, że są też
wartościowe dla klientów, to tworzę takiego bloga, w którym właśnie
te informacje się znajdują.
Oprócz tego również mamy changelog, który prowadzimy na stronie czy na Notion
lub też z pomocą innych narzędzi, o których powiem Ci później przy
okazji strony internetowej.
I staramy się robić to tak, żeby nasi klienci byli po prostu
informowani o tym, co tutaj się dzieje.
Jedna ważna rzecz oprócz całego dev teamu ma tutaj też wejście
osoba z obsługi klienta.
Dzięki temu taka osoba może lepiej reagować na zgłoszenia od klientów.
Może też dodawać tutaj specyficzne zadania.
Na to mamy osobny proces i osobny projekt, gdzie może je dodawać.
Natomiast ważne jest to, że taka osoba pytana na przykład o to, kiedy dodamy
obsługę Google Pay, widzi, że mamy to w backlogu.
Mamy na przykład estymat na wykonanie tego w kolejnym cyklu i prawdopodobnie możesz z
dużym prawdopodobieństwem odpowiedzieć takiemu klientowi, że pracujemy nad
tym i będzie dostępne w ciągu np.
Czterech tygodni, dając oczywiście jakiś właściwy zapas, ale jest to super ważne,
ponieważ nie ma ciągłego ping ponga, nie ma pytania dev team o to, kiedy to będzie,
a kiedy tamto i czy nad tym pracujemy czy nie.
Po prostu wszystko w moich projektach jest super transparentne i wszyscy mają dostęp
do jak największej ilości informacji.
Natomiast starannie opracowane poradniki dla każdej z tych osób mówią jej, gdzie te
informacje może znaleźć i jak może z nich skorzystać.
Także to jest sposób organizacji pracy zespołu, który tworzy taki produkt.
I tak jak wspomniałem, ja też w cyklach tworzę sobie na przykład info produkty i
dodaję tutaj zadania na lina, że w bardzo podobny sposób.
Natomiast jeśli chodzi o to, jak wygląda w praktyce kodowanie tych komponentów i ten
design, system czy framework, który mamy, też chcę ci to pokazać i w kolejnej
lekcji krótko o tym opowiem.