Kamil DzikowskiCTO · Inżynieria w erze AI · Doradztwo
To nie pieniądze są sukcesem — jesteś nim Ty.
EN PL
← Wróć na bloga

Jak zbudować to, co trzeba — co powiedziałem przyszłym founderom na Uniwersytecie Chalify

Budowanie jest proste — trudne jest decydowanie, czego nie budować. Wnioski z warsztatów dla founderów na temat lean MVP, testu WhatsApp i używania AI jako sparingpartnera, a nie automatu.

Kamil Dzikowski podczas prelekcji na warsztatach dla startupów na Khalifa University w Abu Zabi.

Występowałem jako ostatni tego dnia. Sala pełna inżynierów z Uniwersytetu Chalify, którzy nie chcą tylko pisać kodu — chcą zakładać firmy. Przede mną odbyły się już dwie znakomite sesje: jedna o walidacji i modelowaniu biznesowym, druga o design thinking. Kiedy wstałem, słuchacze już dwukrotnie usłyszeli, dlaczego należy walidować pomysły, zanim zacznie się budować.

Więc nie wracałem do tego tematu. Zacząłem tam, gdzie oni skończyli. Nauczyli się, jak znaleźć problem wart rozwiązania i jak go przetestować . Moim zadaniem było odpowiedzieć na kolejne pytanie — to, które spędza mi sen z powiek częściej niż jakiekolwiek inne: kiedy już wiesz, co budować, jak zbudować tę najmniejszą właściwą rzecz, szybko i bez marnowania roku?

Oto skrócona wersja tego, co im powiedziałem.

Pułapka, w którą wpada każdy inżynier

Budowanie daje poczucie bezpieczeństwa. Testowanie jest przerażające, bo test może powiedzieć „nie”.

Więc chowamy się w budowaniu. Dodajemy jedną funkcję, potem drugą, potem pulpit nawigacyjny, o który nikt nie prosił, i to daje poczucie postępu. Ale to nie jest postęp. Bycie zajętym to nie to samo, co posuwanie się naprzód. Widziałem, jak genialni founderzy techniczni — ludzie, którzy mogliby stworzyć wszystko — poświęcali osiemnaście miesięcy na niewłaściwy produkt tylko dlatego, że budowanie było wygodniejsze niż odkrycie, że się mylą.

Niewygodna prawda, od której zacząłem: większość startupów nie upada dlatego, że zbudowały zły produkt. Upadają, bo zbudowały za dużo dobrego produktu, za wcześnie.

Każdy pomysł opiera się na dokładnie jednym założeniu. Jeśli to założenie jest fałszywe, wszystko się sypie. Twoim jedynym prawdziwym zadaniem na początku jest znalezienie tego założenia i przetestowanie go najtaniej, jak to tylko możliwe. Cała reszta to ozdobniki.

Najtańszy test, jaki kiedykolwiek przeprowadziłem

Opowiedziałem im historię TheCloud, bo to najwyraźniejszy przykład, jaki mam.

TheCloud było wielkim pomysłem — wykorzystanie wolnych mocy przerobowych w istniejących kuchniach do prowadzenia marek delivery, sprawniej i szybciej niż ktokolwiek inny. Oczywisty plan zakładał od dwunastu do osiemnastu miesięcy budowania platformy. Zamiast tego, wystartowaliśmy w dwa dni. Bez aplikacji. Bez systemu. Zamówienia przyjmowaliśmy ręcznie przez WhatsAppa, jakby to był rok 2010.

Już po miesiącu podwajaliśmy sprzedaż co miesiąc. To był dowód — a później historia dla inwestorów. Podwajanie przychodów to fakt, z którym nikt nie może dyskutować. Ankieta ci tego nie da.

System powstał dopiero po uzyskaniu dowodu. Potem projekt przeskalował się do 26 milionów dolarów rocznie na ośmiu rynkach. Ale gdyby ci pierwsi klienci nie zapłacili i nie wrócili, kiedy trzy osoby obsługiwały wszystko z jednego telefonu, żadna piękna platforma by nas nie uratowała.

Opowiedziałem im też historię Eyewa jako kontrprzykład — moment, w którym sukces kusi cię, by zbudować coś imponującego zamiast czegoś wartościowego Kluczowa kwestia. Najważniejsza lekcja, jaką zapamiętałem: funkcjonalność, która zapewnia finansowanie, rzadko kiedy jest tą, która buduje wielkość firmy. Obserwuj, co klienci robią ze swoimi pieniędzmi, a nie to, za co prawią ci komplementy.

Aspekt, o którym nikt inny nie wspomniał: AI

I tym właśnie zdobyłem ich uwagę. Nikt przede mną o tym nie wspomniał, a to największa zmiana w sposobie, w jaki budujemy produkty, od początku mojej kariery.

Większość ludzi używa AI jak automatu sprzedającego — wpisują „zbuduj mi aplikację do X” i biorą to, co z niego wypadnie. I tu jest sedno sprawy: AI nie zawodzi dlatego, że jest głupie. Zawodzi, bo za bardzo chce cię zadowolić. Prosisz o minimum, a daje ci maksimum — dwadzieścia funkcjonalności, których nigdy nie zweryfikowałeś z rynkiem, wygenerowanych w jedno popołudnie, do których czujesz dziwne przywiązanie, zanim jeszcze choć jeden klient zdążył się wypowiedzieć. Ogólnikowy prompt to przyzwolenie, by dać ci wszystko.

Rozwiązanie jest jedno: narzuć ograniczenia. Właśnie na tym polega cała sztuka.

Pokazałem im, jak ja naprawdę używam AI — nie po to, by uzyskać odpowiedzi, ale by zaatakować własny pomysł. Nakieruj je na swój biznesplan i poproś, by wcieliło się w rolę sceptycznego inwestora. Poproś, by uszeregowało wszystkie założenia według tego, jak fatalne w skutkach okażą się, jeśli będą błędne. Poproś, by zaprojektowało najtańszy możliwy test, który udowodni ci, że się mylisz w ciągu dwóch tygodni. Zapytaj, co możesz odrzucić, a i tak wyciągnąć cenne wnioski. AI jest bezlitosne w cięciach, ponieważ — w przeciwieństwie do ciebie — nie angażuje w twój pomysł swojego ego. I właśnie dlatego jest tak użyteczne. To sparingpartner, a nie automat sprzedający.

Ta sama dyscyplina obowiązuje, gdy w końcu zaczynasz pisać kod. Polecenie „zbuduj mi aplikację” da ci cztery tysiące linijek kodu, których nie rozumiesz i nie potrafisz naprawić. Ale jeśli sprecyzujesz jedną kluczową funkcjonalność, zmusisz AI do zaplanowania pracy przed kodowaniem, będziesz tworzyć krok po kroku i testować na bieżąco — to pójdziesz do przodu pięć razy szybciej, wciąż pozostając architektem. To samo AI. Inny operator. Narzędzie jest identyczne; liczą się twoje umiejętności.

Z czym ich zostawiłem

Odprawiłem ich z trzema kluczowymi myślami i jednym zadaniem domowym.

Oto one: znajdź to jedno założenie, które może pogrążyć cały pomysł, i przetestuj je w pierwszej kolejności. Spraw, by ludzie musieli coś poświęcić — darmowe „tak” to szum. I traktuj AI jak sparingpartnera, a nie automat sprzedający.

Zadanie domowe: weź najbardziej ryzykowne założenie w swoim projekcie, zadaj mu te pytania jeszcze dziś i wróć z odpowiedzią, co może go pogrążyć i jak to najtaniej sprawdzić.

Bo oto, co jest naprawdę nowe. Kiedyś narzędzia były powolne i drogie. Dziś jedna osoba może zrobić to, co dekadę temu wymagało ośmioosobowego zespołu. TheCloud nie miało nic z tego. Ty masz. Przewagą konkurencyjną nie jest już szybkie tworzenie produktu — dziś każdy może to robić. Przewagą jest szybkie uczenie się.

Buduj mniej. Ucz się szybciej. Dostarczaj to, co naprawdę działa. Wszystko inne to tylko slajdy.


Jeśli tworzysz nowy projekt i szukasz sparingpartnera, który sam to wszystko przeszedł — zdobywał kolejne rundy finansowania, wprowadzał produkt na rynek, popełniał błędy i odnosił sukcesy — skontaktuj się ze mną. Dzielę się praktycznymi lekcjami dla founderów na blogu i podczas sesji doradczych. Zbudujmy razem coś wyjątkowego.