Paul Katsen z Blockspring
Odcinek 025 Founder Coffee
Jestem Jeroen z Salesflare, a to jest Founder Coffee.
Co dwa tygodnie piję kawę z innym założycielem. Rozmawiamy o życiu, pasjach, wnioskach i nie tylko — w kameralnej rozmowie poznajemy osobę stojącą za firmą.
W tym dwudziestym piątym odcinku rozmawiałem z Paulem Katsenem, współzałożycielem Blockspring — narzędzia do automatyzacji, które pobiera dane z różnych API, aby automatyzować raporty, listy i strony docelowe.
Blockspring początkowo był narzędziem do wizualizacji danych, które po dołączeniu do YCombinator i rozmowie ze współzałożycielem tego programu, Paulem Grahamem, przekształciło się w platformę bezserwerową. Około rok później, gdy Amazon wszedł dokładnie w tę samą przestrzeń, musieli wykonać kolejny pivot. Po wielu iteracjach stworzyli platformę Blockspring, którą znamy dzisiaj.
Wreszcie, kilka miesięcy temu, Blockspring zostało przejęte przez Coinbase. Rozmawiamy o tym, o ich epizodzie w branży restauracyjnej podczas pivotowania, o tym, jak wygląda praca dla dużej firmy, i o tym, dlaczego gry mogą być lepsze od rzeczywistości.
Witamy w Founder Coffee.
Gdzie słuchać?
Tego odcinka możesz posłuchać na:
Transkrypcja
Jeroen: Cześć, Paul. Miło gościć cię w Founder Coffee.
Paul: Cześć, dziękuję. Jak leci?
Jeroen: Dobrze. Jesteś jednym z założycieli Blockspring. Dla tych, którzy jeszcze nie wiedzą, czym się zajmujecie: co robicie?
Paul: Historia Blockspring jest bardzo długa. Zaczęliśmy właściwie w 2014 roku, ale dzisiaj pomagamy marketerom, handlowcom i rekruterom łączyć się z różnymi API oraz usługami danych, aby automatyzować raportowanie, wzbogacać listy i tworzyć listy potencjalnych klientów. A na koniec pobierać wszystkie te dane do stron docelowych i działających stron internetowych. Zasadniczo indeksujemy mnóstwo API i ułatwiamy ludziom biznesu korzystanie z nich oraz uzyskiwanie do nich dostępu.
Jeroen: Czy możesz, bo to brzmi trochę abstrakcyjnie, podać konkretny przykład tego, co można zrobić?
Paul: Jasne. Automatyzacja raportowania to jeden z przypadków użycia. Marketerzy spędzają zasadniczo mnóstwo czasu, logując się do Facebook Ads Managera, do całego tego interfejsu, do Google Analytics, Google Ads, YouTube Ads i tym podobnych usług, a następnie co tydzień lub co miesiąc eksportując z nich dane do tego samego pulpitu nawigacyjnego. To jest raportowanie ręczne. Zajmuje mnóstwo czasu.
Paul: Mamy integracje ze wszystkimi tymi różnymi usługami oraz wtyczki do narzędzi takich jak Excel, Google Sheets czy Tableau. Dzięki temu osoba może wybrać kilka różnych źródeł danych, kliknąć „pobierz dane”, a raport będzie automatycznie aktualizowany. Działa to tak, że korzysta z tej samej platformy API, którą opracowaliśmy, ale ma interfejs wtyczki działający wewnątrz narzędzi do raportowania, w odróżnieniu od niektórych naszych przypadków użycia związanych ze sprzedażą. W tych przypadkach korzysta się z tej samej platformy, ale podłącza ją do innych narzędzi.
Jeroen: Powtarzając to, co powiedziałeś: można zasadniczo pobrać informację na przykład z reklam na Facebooku, z YouTube i skądkolwiek indziej, a następnie zebrać ją w jednym arkuszu Google. To coś, do czego mógłbym wykorzystać Blockspring.
Paul: Tak. To zdecydowanie jeden z bardzo częstych przypadków użycia. Innym przypadkiem, z którego korzystają handlowcy i rekruterzy, jest tworzenie listy potencjalnych klientów. Wiele z tych danych pochodzi jednak z Clearbit, Hunch.io, Google Maps albo innych nowych usług danych, które mogą być dobrym źródłem informacji przydatnych w sprzedaży lub rekrutacji, choć nie zawsze od razu się to zauważa. Mogą więc chcieć pobrać te dane również do Arkuszy Google albo innego narzędzia. Wspólnym mianownikiem całej tej platformy jest ułatwianie dostępu do API i danych z poziomu narzędzia biznesowego. Przypadki użycia obejmują jednak zarówno automatyzację raportowania, jak i tworzenie list potencjalnych klientów oraz wiele innych zastosowań.
Jeroen: Rozumiem. To znacznie ułatwia zebranie danych w jednym miejscu.
Paul: Tak.
Jeroen: Wspomniałeś, że historia Blockspring z ostatnich pięciu lat jest długa. Co dokładnie się wydarzyło?
Paul: Kiedy zaczynaliśmy w 2014 roku, moi współzałożyciele tworzyli produkt do wizualizacji danych, który bardzo różnił się od tego, czym zajmujemy się dzisiaj. Etapy rozwoju tej firmy zaczęły się, jak wiem, od produktu do wizualizacji danych, następnie doszło do wejścia do YC i całej serii innych szalonych wydarzeń, które ostatecznie skierowały nas w stronę jednego z pierwszych produktów do obliczeń bezserwerowych. Później nadszedł etap, w którym Amazon mocno nas przycisnął i przeszliśmy przez długą serię pivotów, próbując znaleźć właściwą drogę. W końcu dotarliśmy do momentu, w którym pomyśleliśmy: hej, to jest firma inna od tej, z którą zaczynaliśmy. Ale to dobry biznes, zarabia pieniądze i rozwijamy go. Ostatecznie doprowadziło to do tego, że wykorzystaliśmy wiele elementów, które ten produkt zbudował i których nas nauczył, a następnie dołączyliśmy z nimi do Coinbase.
Paul: Tak, było więc kilka różnych etapów. W rzeczywistości zaczęliśmy w zupełnie innym miejscu niż to, w którym skończyliśmy — a wiem, że wielu założycieli przechodzi przez coś podobnego. Chętnie opowiem szerzej o poszczególnych częściach tej historii, bo była to naprawdę ogromna lekcja.
Jeroen: Tak. Które części tej historii były szczególnie interesujące albo wymagające?
Paul: Cóż, na każdym etapie pojawiają się inne wyzwania. Na początku po prostu zakochaliśmy się w pomyśle wizualizacji danych. Jak to się właściwie zaczęło? Byłem wtedy w Chicago i pamiętam, że wybrałem się na YC Startup School — jednodniową konferencję, na której można było zobaczyć wszystkie te niesamowite osoby ze świata technologii, takie jak Marc Andreessen, Jack Dorsey, Balaji Srinivasan i inni. Pamiętam, że wyszedłem stamtąd z myślą: cholera, jestem kompletnie zainspirowany. Chcę założyć własną firmę.
Paul: Pomyślałem: o, ja też mogę to zrobić. Ci ludzie są przecież zupełnie normalni. Akurat tego samego wieczoru jadłem kolację z dobrym przyjacielem w San Francisco i obaj zdaliśmy sobie sprawę, że wizualizacja danych jest trudna. Zbudujmy po prostu łatwą w obsłudze aplikację. Może nie przerodzi się to w firmę, ale przynajmniej powstanie coś, co ułatwi sprawę.
Paul: Ostatecznie zbudowaliśmy coś bardzo prostego: przesyłasz plik csv albo arkusz kalkulacyjny i otrzymujesz interaktywną wizualizację — coś, nad czym sami spędzaliśmy długie godziny w naszych poprzednich miejscach pracy. Chcieliśmy jednak to uprościć. W pewnym momencie zadzwonił do nas wiceprezes ds. danych w jednym z największych wydawnictw na świecie. Powiedział: słuchajcie, wasz produkt jest beznadziejny, ale od sześciu miesięcy próbujemy zbudować coś takiego. Możecie przylecieć do Nowego Jorku, popracować z nami przez kilka tygodni, a potem zostaniemy waszym pierwszym klientem enterprise?
Paul: Tak właśnie zaczęła się historia tego produktu. Jedną z najważniejszych rzeczy, których się wtedy nauczyłem, było po pierwsze to, że kiedy coś budujesz, warto pisać dobre treści, żeby ludzie rozumieli, co robisz i jaka jest twoja misja, bo dzięki nim mogą cię znaleźć. Po drugie, jeśli klient zaprasza cię do pracy ze swojego biura i jest tobą niesamowicie podekscytowany, mimo że twój produkt jest w tej chwili beznadziejny, to prawdopodobnie jesteś na dobrym tropie. Te kilka tygodni było chyba jednym z najbardziej ekscytujących okresów w tamtej firmie. Budowanie dla klienta i otrzymywanie natychmiastowego feedbacku było naprawdę ekscytujące. To była jedna z naszych pierwszych ważnych lekcji wyniesionych z pracy nad tym produktem, a później właśnie dzięki niemu dostaliśmy się do YC na lato 2014 roku.
Jeroen: Tak. Zbudowaliście więc coś i dość szybko zdobyliście pierwszego klienta. Dlaczego nie kontynuowaliście dokładnie tego biznesu, tylko zajęliście się czymś innym?
Paul: To naprawdę dobre pytanie. W pierwszym tygodniu YC budowaliśmy ten produkt, mieliśmy klienta i wielu innych użytkowników, którzy nie byli klientami enterprise, ale płacili za produkt w modelu freemium. Próbowaliśmy ustalić, co dalej, więc poszliśmy na kolację YC — cotygodniowe wydarzenie, podczas którego można spotkać innych założycieli i posłuchać prelegentów. Na tej pierwszej kolacji był Paul Graham, choć nie kierował już wtedy YC. Spojrzałem na mojego współzałożyciela i powiedziałem: słuchaj, podejdźmy do niego. Uwielbiamy wszystkie jego eseje, to bardzo inteligentny facet. Opowiedzmy mu o naszym biznesie.
Paul: Przechodził wzdłuż kolejki założycieli, którzy przedstawiali mu swoje pomysły, a on dawał im feedback — 60 sekund i następna osoba. Opowiedzieliśmy mu o naszym biznesie. O tym, że zauważyliśmy jeszcze inny problem: zbudowaliśmy to narzędzie na własne potrzeby, ale praktycznie każda wizualizacja danych, której potrzebowaliśmy, wymagała odrobiny obliczeń. Wyobraź sobie na przykład wykres słupkowy, który musi wykonać trochę grupowania albo segmentacji. Nie chcieliśmy za każdym razem, gdy trzeba było wykonać takie obliczenia, wysyłać ich do EC2 i Amazon, a zrobienie tego w JavaScript po stronie front-endu było naprawdę trudne.
Paul: Ostatecznie zbudowaliśmy narzędzie, które pozwalało nam pisać kod, kliknąć „publikuj” i otrzymać API. Dzisiaj nazywa się to serverless. Amazon ma takie rozwiązanie, a teraz również Google i Microsoft. Opowiedzieliśmy mu o nim podczas pitchu, a on nagle wygłosił dwudziestominutowy monolog o tym, jak coś takiego może zmienić przyszłość programowania. Powiedział: jeśli uważacie, że w końcu chcecie to zrobić, powinniście zająć się tym już dzisiaj. To była rzecz, w którą naprawdę wierzę do dziś. Jeśli prowadzisz startup i dziesięć kroków dalej widzisz coś wielkiego, to dlaczego nie zacząć od tego od razu? Nie próbuj być zbyt — sam nie wiem — nie próbuj być w tym wszystkim geniuszem. Jeśli coś jest możliwe, zrób to dzisiaj.
Paul: Wróciliśmy więc do domu i przeżyliśmy moment kompletnego olśnienia, który można podsumować słowami: „Po prostu to zróbmy”. To był tak wielki pomysł, że byliśmy nim niesamowicie podekscytowani — i ostatecznie rzeczywiście się za to zabraliśmy.
Jeroen: Ale nie udało wam się zbudować dużego biznesu opartego na usługach. Jak rozumiem, inni zaczęli robić to, co wy?
Paul: Tak. W skrócie: uruchomiliśmy to rozwiązanie dla tysięcy deweloperów. Wystartowaliśmy tuż przed zakończeniem YC. Jednym z problemów było to, że nie wiedzieliśmy, jak sprzedawać serverless computing przedsiębiorstwom. Byliśmy na to za wcześnie, bo wiązało się to z tak dużą zmianą paradygmatu programowania. Z drugiej strony byliśmy też spóźnieni, ponieważ spotkaliśmy się z CTO Amazon. Wydawało nam się, że sprzedajemy mu ten pomysł i próbujemy sprzedać produkt firmie Amazon, żeby zaczęła go używać. W rzeczywistości chyba tylko pomyślał: co to za pajace i co oni kombinują? Trzy albo cztery miesiące później uruchomili dokładnie to samo rozwiązanie, nad którym pracowali zresztą od lat.
Paul: Myślę, że byliśmy jednocześnie za wcześnie i za późno, bo dla AWS był to kolejny element ich wielkiej drogi ku przyszłości. My byliśmy tylko małym startupem, który zorientował się, że coś takiego w ogóle ma sens. Oni natomiast mieli już odpowiednie relacje i całą resztę. W ciągu kilku miesięcy od ich premiery zrozumieliśmy, że nie mamy w tym biznesie przyszłości. To przyszłość wszystkich dużych platform cloud computing. Nie będziemy w stanie z nimi konkurować. Amazon ostatecznie to wdrożył, podobnie jak Microsoft, Google, IBM — można by wymieniać dalej.
Paul: To był kolejny trudny etap, przez który musieliśmy przejść. Zrozumieliśmy, że ten biznes nie zadziała. Musieliśmy więc zwolnić sporą część osób z zespołu, ograniczyć firmę do samych założycieli i zacząć ustalać, jaki będzie następny krok oraz w jakim biznesie właściwie chcemy działać.
Jeroen: Ile osób było w zespole, zanim go zmniejszyliście?
Paul: Jeśli dobrze pamiętam, było nas około sześciu–ośmiu osób, a do tego trzy–cztery osoby pracujące na kontraktach. Łącznie mniej więcej dziesięć. To nie był ogromny zespół. Ale do tego momentu pozyskaliśmy już finansowanie, przedstawiliśmy tę wizję wielu różnym osobom i naprawdę wszystkich polubiliśmy. Wszyscy byli świetni, więc odwrócenie tej sytuacji było niezwykle trudne. Myślę jednak, że wiedzieliśmy, iż musimy to zrobić, bo bardzo trudno ustalić, co dalej, kiedy ma się w zespole osoby, które niekoniecznie są założycielami. Przyszły do firmy z konkretnego powodu i mogą nie chcieć zajmować się czymś zupełnie innym. Trudno wejść w tryb poszukiwań, kiedy ludzie czekają i pytają: dobrze, co mam teraz robić? Zdecydowanie istnieje różnica między osobami, które z tobą pracują, a założycielami gotowymi wspólnie ustalić: w porządku, to może być dowolny biznes, więc sprawdźmy, jaki.
Jeroen: Uznaliście więc, że najlepszym sposobem na wykonanie kolejnego kroku będzie zwolnienie wszystkich i poświęcenie czasu na zastanowienie. Ile czasu wam to zajęło?
Paul: Zdecydowanie kilka miesięcy. Próbowaliśmy różnych pomysłów, a część tej sytuacji wyglądała tak: dobrze, teraz zostali już tylko założyciele. Poza tym powiedzieliśmy sobie: w porządku, ograniczmy nasze wydatki tak bardzo, jak to możliwe, żeby móc testować różne rzeczy i ustalić, jaka będzie dalsza droga dla biznesu. To był zdecydowanie jeden z najtrudniejszych etapów — kiedy masz firmę, ale w pewnym momencie nie wiesz już, w jakim właściwie jesteś biznesie.
Paul: To był bardzo, bardzo trudny czas, bo biegasz wtedy jak kurczak z uciętą głową i próbujesz ustalić, jak w ogóle rozpoznać problem. Nie da się położyć z tym spać i przestać o tym myśleć.
Jeroen: Tak. Czy do tego momentu przyjęliście już jakieś finansowanie?
Paul: Tak. Pozyskaliśmy finansowanie w oparciu o wielką wizję: ruszamy konkurować z AWS i przejmujemy przyszłość. A teraz wyobraź sobie, że musisz całkowicie zmienić ten kierunek. Mieliśmy naprawdę świetny zespół, a inwestorzy zainwestowali właśnie w ten zespół, ale my chcieliśmy teraz znaleźć coś innego do zrobienia — i sprawić, żeby było równie wielkie.
Jeroen: Dlaczego nie wróciłeś do pomysłu wizualizacji danych?
Paul: To dobre pytanie. Myślę, że w tamtym momencie nie wiedzieliśmy, czy się wyróżniamy. Chcieliśmy coś zrobić. Wtedy trochę zmieniliśmy też zakres tego, co chcieliśmy osiągnąć. Widzieliśmy wszystkie te inne firmy. Przenieśliśmy się do San Francisco i poznaliśmy mnóstwo ludzi, którzy byli niezwykle ambitni i pracowali nad produktami realizującymi wielkie wizje. Myślę, że wtedy uznaliśmy: dobrze, ten produkt do wizualizacji danych jest ekscytujący, daje frajdę i był pierwszą rzeczą, na którą wpadliśmy, a do tego mamy już klientów. Ale chcemy zrobić coś, co wpłynie na miliony ludzi — zarówno deweloperów, jak i użytkowników końcowych. Bardzo interesował nas pomysł udostępnienia użytkownikom końcowym tych niezwykle technicznych rzeczy, które deweloperzy robią na co dzień, albo przynajmniej znacznego uproszczenia ich realizacji.
Paul: Byliśmy w takim stanie emocjonalnym, w którym po prostu byliśmy gotowi na coś innego. Mieliśmy już zamknięty temat wizualizacji danych. Próbowaliśmy więc ustalić: dobrze, jaka wizja mogłaby być równie wielka jak ta, którą mieliśmy w przypadku tej platformy, a jednocześnie pozwoliłaby nam szybko wypuścić produkt? Co mogłoby być nowe i równie duże?
Jeroen: Czyli szukaliście nowej, wielkiej wizji. Co wtedy zobaczyliście?
Paul: Ostatecznie próbowaliśmy wielu różnych rzeczy i testowaliśmy wiele różnych procesów wyszukiwania kolejnych pomysłów. Z perspektywy czasu wiele z nich okazało się naprawdę, naprawdę trudnych. Mam wielu znajomych, którzy właśnie przez to przechodzą — jak znaleźć pomysł na kolejny startup? Nigdy nie opracowaliśmy niezwykłego procesu, który by nam to umożliwił. Mogę opowiedzieć o kilku pomysłach, które wydawały nam się naprawdę wielkie i które ostatecznie zaczęliśmy realizować, zwłaszcza o jednym, który moim zdaniem był szczególnie interesujący.
Paul: Zasadniczo zrozumieliśmy, że jedyne pomysły, które naprawdę potrafiliśmy rozkręcić i sprawić, żeby działały, musiały łączyć kilka rzeczy: jak nabrać przekonania, że to coś ekscytującego i że chcemy nad tym pracować? Po przejściu przez wszystkie te pomysły trudno było nabrać przekonania. Myślę, że w pewnym momencie po prostu dopisało nam szczęście i odkryliśmy Blockspring, który już wykorzystywał 80% zbudowanej przez nas bazy kodu. Sami doświadczyliśmy tego problemu. Doskonale wiedzieliśmy, że rozwija się wielki trend polegający na braniu narzędzi zwiększających produktywność i integrowaniu ich ze wszystkimi innymi narzędziami zwiększającymi produktywność, które powstają. Wokół wszystkiego pojawiało się więc coraz więcej SaaS-ów, a ten trend miał wykładniczy charakter.
Paul: Myślę, że udało nam się w ten trend wpasować. Dopisało nam szczęście: trafiliśmy na ten trend, a wszystkie gwiazdy ułożyły się wokół problemu, przekonania i potencjalnie wielkiego rynku. Teraz musieliśmy już tylko ustalić, jak powinien wyglądać produkt, żeby to zrealizować. Po drodze pojawiło się jednak wiele innych pomysłów. Stworzyliśmy AWS dla jedzenia w Chicago. Przez trzy miesiące naprawdę rozwijaliśmy ten pomysł i budowaliśmy rozwiązanie, a moim zdaniem może z tego powstać naprawdę ogromna firma. Po prostu okazało się, że to nie jest coś dla nas.
Jeroen: Co masz na myśli, mówiąc „AWS dla jedzenia”?
Paul: Pewnego dnia nadal byłem kompletnie spanikowany i zastanawiałem się: co zrobimy dalej, na czym się teraz skupimy? Siedziałem wtedy w Chipotle. Z perspektywy czasu brzmi to głupio, ale siedzieliśmy w Chipotle i pomyślałem: wow, takich firm jak ta będzie nieskończenie wiele — chodzi o restauracje typu fast casual. Powinna istnieć platforma, która pozwoli im skalować działalność w całym kraju bez konieczności budowania własnej infrastruktury. Moja analogia była taka: nieruchomość i personel są jak moc obliczeniowa, a kod to przepis i składniki.
Paul: Ostatecznie poszliśmy do wielu restauracji śniadaniowych w Chicago i przekonaliśmy ich, żeby za bardzo niewielkie pieniądze udostępnili nam swoje kuchnie na czas kolacji, kiedy były zamknięte. Następnie odwiedziliśmy wiele popularnych restauracji typu fast casual i przekonaliśmy je, żeby nauczyły naszych pracowników przygotowywania swoich dań. Potem uruchomiliśmy je jako kuchnie widma w całym mieście, na UberEats, Postmates, DoorDash i każdej możliwej platformie dostaw, dzięki czemu te restauracje zyskały pełne pokrycie rynku, a płaciły tylko za godziny pracy. Nie musiały więc zatrudniać żadnego personelu ani zajmować się niczym podobnym. Skalowały się wyłącznie w oparciu o swój pomysł.
Jeroen: Czyli nie były to restauracje, do których można było przyjść coś zjeść, tylko lokale obsługujące wyłącznie dostawy?
Paul: Tak, wyłącznie dostawy. To rozwiązanie faktycznie zaczęło na siebie zarabiać, tylko że nie było dobrym interesem dla restauracji i na tym etapie, przy tej skali, nie było dla nich zrównoważone. Mieliśmy też dość szaloną sytuację: do kuchni przyjeżdżali Uber Eats, Amazon i przedstawiciele wszystkich tych różnych platform dostaw, pytając: dobrze, co tu się właściwie dzieje? Okazało się, że ten model naprawdę ma sens. Wiem, że wraz z trwającym trendem dostaw ich wykładniczy rozwój już się dzieje i myślę, że będzie postępował. Wiem też, że współzałożyciel Ubera właśnie zaczął robić coś podobnego, tylko podszedł do tego nieco inaczej.
Paul: Tak więc w pewnym momencie budowaliśmy oprogramowanie, siedząc do późna w nocy w kuchniach, i zastanawialiśmy się: czy tylko my pracujemy nad tym pomysłem? Straciliśmy przekonanie. Myśleliśmy: pewnie zwariowaliśmy i tylko my pracujemy nad pomysłem platformy kuchni widm. Czy to naprawdę przyszłość, czy resztę życia spędzimy w kuchniach, tocząc nieustanną i z góry przegraną walkę? Myślę więc, że w tym przypadku znaleźliśmy naprawdę wielką wizję i produkt, który mógł ją urzeczywistnić. Nie sądzę jednak, żeby to było właściwe rozwiązanie dla nas — i tyle.
Jeroen: Tak, brzmi jak naprawdę interesujący pomysł. Istnieją firmy zbudowane na Airbnb, ponieważ Airbnb jest tak ogromną platformą. Początkowo chodziło w nim o to, że spało się w czyimś mieszkaniu. Potem jednak ludzie zaczęli kupować nieruchomości wyłącznie pod Airbnb. W tym sensie przypomina to wasz pomysł: masz usługi takie jak Uber Eats czy Deliveroo i inne tego typu platformy, które mają klientów, a ty możesz łatwo dostarczyć im coś nowego.
Paul: Tak, nową podaż. W stu procentach. To zupełnie prawda. Kiedy pojawiły się urządzenia mobilne, zaczęły powstawać aplikacje projektowane przede wszystkim z myślą o urządzeniach mobilnych. Kiedy pojawiło się Airbnb, mogły zacząć powstawać nieruchomości projektowane przede wszystkim z myślą o Airbnb, a także firmy zarządzające nieruchomościami.
Jeroen: Jasne.
Paul: Ciekawe w przypadku dostaw jest to, że kiedy wchodzisz do restauracji i widzisz mnóstwo rowerzystów albo kierowców czekających w kolejce, tłoczących się w środku, podczas gdy kuchnie są zalewane zamówieniami. To fundamentalna kwestia projektowa. Czy powinniśmy budować restaurację dla naszych klientów, czy raczej zakład produkcyjny, który również obsługuje dostawy? Okazuje się, że większość restauracji nie jest przystosowana do dostaw. Dlatego wiele z nich uruchamia osobne kuchnie, które zajmują się wyłącznie dostawami, poza właściwymi restauracjami. Problem w tym, że jest to dla nich ogromny wysiłek. Kiedy przedstawiliśmy ten model, właściciele restauracji od razu mówili „tak”, co bardzo mnie zaskoczyło, bo nie miałem pojęcia o jedzeniu ani o restauracjach. Zatrudniliśmy menedżera, który był naprawdę, naprawdę dobry. Pomógł nam zacząć wdrażać ten pomysł. Ale każdy właściciel restauracji mówił: tak, chcę to zrobić.
Paul: Było więc jasne, że istnieje popyt. Myślę, że ten model ostatecznie zrealizuje ktoś, kto będzie w stanie zebrać mnóstwo pieniędzy, żeby buy the real estate, i dzięki temu zaoferować jeszcze lepszy interes, albo ktoś, kto kontroluje cały popyt. Uber Eats i Deliveroo już to robią. Wiedzą, co ludzie chcą kupować, i przekazują te informacje różnym restauracjom, żeby te zaczęły tworzyć nowe dania. Firmy takie jak Deliveroo już uruchamiają kuchnie i wynajmują nieruchomości, żeby to realizować. Myślę, że właśnie w tę stronę pójdzie rynek, ale to był jeden z tych pomysłów, w przypadku których zaczęliśmy od podstawowych założeń i zobaczyliśmy coś, co moim zdaniem było naprawdę wielkie — tylko ostatecznie okazało się, że to nie jest coś dla nas.
Jeroen: Rozumiem. Dlaczego uważasz, że to nie było coś dla was?
Paul: Częściowo poszliśmy w złym kierunku: staliśmy się pośrednikiem między firmą dostawczą a restauracją. W rzeczywistości powinniśmy byli stworzyć inteligentniejszą infrastrukturę nieruchomościową, ale nigdy tego nie spróbowaliśmy. Myślę, że w pewnym momencie zaczęliśmy się zastanawiać: czy po prostu nie zwariowaliśmy? Straciliśmy przekonanie, bo ten pomysł był tak odmienny od wszystkiego, czego kiedykolwiek próbowaliśmy. Nadal byliśmy w trybie: dobrze, musimy znaleźć właściwy pomysł. Być może zbyt wcześnie go więc skreśliliśmy, ale myślę, że nie był dla nas, bo szczerze mówiąc wydawał nam się tak dziwaczny, że prawdopodobnie po prostu szukaliśmy szczęścia w niewłaściwym miejscu.
Jeroen: Czy czułeś się swobodnie w branży restauracyjnej?
Paul: Nie w branży restauracyjnej, ale zdecydowanie w operacjach. Wcześniej właściwie nigdy nie robiłem podobnych rzeczy. I naprawdę świetnie się bawiłem. Były w tym konkretne elementy, takie jak tworzenie oprogramowania dla rzeczywistych scenariuszy, żeby usprawniać workflow, prowadzenie biznesu, o którym z łatwością można opowiedzieć każdemu, i świadomość, że wszyscy twoi znajomi mogą zacząć z niego korzystać. Jeśli tworzysz coś, co przechodzi test szczoteczki do zębów i sprawdza się w codziennym użyciu, możesz zbudować biznes, który będzie istniał przez setki i setki lat. To długo. Ale odkryliśmy zupełnie nowy sposób działania, a odpowiedź na pytanie „dlaczego teraz?” zaczęła mieć sens. Trend wykładniczy też zaczął mieć sens. Wszystko się ze sobą zgrało. I właśnie dlatego ta część, w połączeniu ze wszystkim innym, była tak ekscytująca.
Paul: Siedzenie w restauracji i obserwowanie, jak spływają zamówienia z dostawą, radzenie sobie z ludźmi, których dopiero co zatrudniłeś, a którzy coś kradną, zarządzanie relacjami z ludźmi — szczególnie przy takim poziomie dochodów i przy tym, jak szybko zatrudnialiśmy kolejnych pracowników — to zupełnie szalony świat. Bardzo różni się od SaaS. Ma własny zestaw problemów, które musisz naprawdę dobrze opanować, do tego stopnia, że myślisz w kategoriach wielkich chmur o tym, jak ogromna może stać się ta firma, a jednocześnie na co dzień zmagasz się z tymi wszystkimi kwestiami. Cały czas myślisz: jak to kiedykolwiek będzie miało jakiś wpływ?
Jeroen: Czy w tamtym czasie pracowaliście jeszcze nad jakimiś innymi pomysłami?
Paul: Było kilka naprawdę ekscytujących. Myślę jednak, że najważniejsze było to, że zaczęliśmy wykonywać zapytania dotyczące niektórych naszych starszych produktów. Właściwie znalazłem bardzo prosty problem produktowy: próbuję przeprowadzić analizę danych w Google Sheets, ale wszystkie moje dane znajdują się w bazie danych albo w jakimś API, więc muszę zacząć pisać skrypty, żeby integrować te informacje.
Paul: To przypomniało mi o mojej pierwszej pracy, czyli konsultingu. Pamiętam ten pomysł, nad którym spędzałem dużo czasu. Byłem inżynierem i studiowałem. Nauczyłem się programować, ale karierę zacząłem w konsultingu i bardzo dużo czasu spędzałem w arkuszach Excela. Zdałem sobie sprawę, że wszyscy, których znałem, pracowali w Excelu. W rzeczywistości po prostu programowali za pomocą API. Wprowadzasz kilka liczb jako dane wejściowe i otrzymujesz wynik. Wiele osób, szczególnie w konsultingu, spędza mnóstwo czasu, przechodząc do różnych stron internetowych i aplikacji, zbierając dane, a następnie przenosząc je w jedno miejsce.
Paul: Wiele z tych usług, które pobierały dane, zaczynało oferować API. Zacząłem więc dostrzegać szerszy obraz: dlaczego poświęcam tyle czasu na kopiowanie i wklejanie rzeczy z jednego miejsca do drugiego oraz utrzymywanie ich synchronizacji, skoro w rzeczywistości wszystkie te narzędzia będą miały API? Narzędzi SaaS będzie coraz więcej. Powinny być jakoś ze sobą synchronizowane i połączone. Szersza wizja to informatyka dla użytkownika końcowego. Ludzie w biznesie dochodzą do momentu, w którym rozumieją, jak korzystać z API i jak przenosić dane z jednego miejsca do drugiego — powinien więc istnieć prosty sposób, żeby to robić.
Paul: Przyjrzeliśmy się istniejącym produktom i znaleźliśmy IFTTT oraz Zapier. Wszystkie działały w oparciu o zdarzenia, przenosiły niewielkie fragmenty danych tam i z powrotem, ale nie rozwiązywały problemu. Na przykład: jak wejść do Google Sheet, pobrać raport Google Analytics, utrzymywać go aktualnym, a następnie uruchomić algorytm widzenia komputerowego albo algorytm NLP za pośrednictwem innego API, przepuścić przez to swoje dane, a na koniec po prostu używać API do programowania w sposób, w jaki robiłby to deweloper, pisząc skrypt?
Paul: Właściwie był to weekendowy hackathon: zbudowaliśmy wtyczkę do Google Sheets, która integrowała się z bezserwerową platformą, jaką stworzyliśmy, i wywoływała wszystkie te różne API, z którymi pracowali ludzie. Potem pokazałem ją moim współzałożycielom i powiedziałem: to jest naprawdę szalone. Wszyscy się zgodziliśmy, że problem ma sens, a wizja była już częściowo zarysowana. Sedno sprawy polegało na tym, jak przekształcić to w produkt, z którego ludzie będą mogli zacząć korzystać. Otwartym pytaniem było: jakie są wszystkie kluczowe przypadki użycia, w których ludzie faktycznie chcieliby tego używać? Nad tym pracowaliśmy i stopniowo dochodziliśmy do odpowiedzi, aż mieliśmy coś w rodzaju: oto trzy przypadki użycia, tak będziemy zarabiać — i wtedy wszystko naprawdę zaczęło rosnąć.
Jeroen: Jak wam poszło? Do ilu pracowników udało wam się ostatecznie rozrosnąć?
Paul: Ostatecznie uruchomiliśmy produkt, nie mając dobrego rozeznania w przypadkach użycia. Zajęło to trochę czasu, ale zaczęliśmy po prostu wypuszczać go na rynek, wpuszczać kolejnych ludzi, słuchać, co próbują osiągnąć, a następnie ustalać, czym właściwie miała być ta platforma.
Paul: Nie wiem, czy to najlepszy model dla nowych platform, ale właśnie taki ostatecznie przyjęliśmy. Pojawiali się wcześni użytkownicy. Robili coś związanego ze wzrostem i mówili: hej, chcę pobrać listę naszych użytkowników z Salesforce, a potem wysłać im wszystkim pocztówki przez Lob, a do tego jeszcze to. Oto mój przypadkowy projekt. Nagle pojawiał się zupełnie inny projekt: hej, jestem marketingowcem cyfrowym i próbuję utrzymywać aktualny raport w Google Sheets albo Tableau. Jak mogę sprawić, żeby działało to z waszym produktem? Nie macie reklam na Facebooku — możecie je dodać? Nie macie tego — możecie dodać tamto?
Paul: Zrozumieliśmy więc, że kluczem do tej platformy było to, że zbudowaliśmy rozwiązanie bezserwerowe w taki sposób, aby można było po prostu szybko napisać skrypt, kliknąć „publikuj” i nagle mieć nową integrację skonfigurowaną we wszystkich naszych produktach. Dzięki temu mogliśmy działać naprawdę, naprawdę szybko i upewniać się, że kolejny przypadek użycia zgłoszony przez użytkownika da się zrealizować. Wtedy zaczęliśmy zapraszać ludzi, którzy pomagali nam budować te integracje i rozwijać platformę, tak abyśmy mogli realizować część tych przypadków użycia i dojść do miejsca, w którym wiedzieliśmy już, że automatyzacja raportowania jest czymś, czego ludzie potrzebują.
Paul: Dzisiaj istnieje sporo startupów skupiających się na tym segmencie. Wzbogacanie danych potencjalnych klientów polega na pobieraniu informacji z wielu różnych API. Nie ma jednak startupu, który robiłby to naprawdę dobrze, więc ludzie korzystają obecnie z niezliczonej liczby pojedynczych usług do wzbogacania danych potencjalnych klientów i próbują ustalić, która z nich jest lepsza. My zebraliśmy wszystkie te API w jednym miejscu. Jest jeszcze kilka innych przypadków użycia, ale te dwa są zdecydowanie najważniejsze.
Paul: Wielu naszych użytkowników musiało naprawdę się namęczyć, żeby samodzielnie robić takie rzeczy i ustalać, co w ogóle jest możliwe. Pomogło nam to dojść do momentu, w którym powiedzieliśmy: oto dwie albo trzy najważniejsze rzeczy, które powinniśmy udostępnić, wdrożyć dla nich użytkowników i przekształcić w prawdziwe produkty. Firma zaczęła rosnąć. Wyrosła na dobry, dochodowy biznes. W pewnym momencie w zeszłym roku byliśmy na etapie, na którym powiedzieliśmy: dobrze, to rozwijający się biznes, ale zaczynaliśmy z wizją: zdetronizujmy AWS i stwórzmy firmę wartą wiele miliardów dolarów.
Paul: To właśnie zapoczątkowało wiele rozmów o tym, gdzie ten produkt mógłby trafić w kontekście przejęć i podobnych tematów. Okazało się, że istniało sporo firm, które potrzebowały przyspieszyć rozwój swoich API, platformy API i wszystkiego, co się z tym wiąże — a potrzeba ta była bezpośrednio związana z tym, co zbudowaliśmy w Blockspring i w samym produkcie. Wtedy zaczęliśmy prowadzić część tych rozmów.
Paul: Okazało się, że wszystko zatoczyło pełne koło. Człowiek, który uruchomił AWS Lambda w 2014 roku, był wiceprezesem ds. inżynierii w Coinbase. Znaliśmy Balajiego Srinivasana, który jest teraz CTO w Coinbase. Mają tam wielu różnych założycieli, a ich kultura jest naprawdę świetna. Bardzo, bardzo dobrze do siebie pasowaliśmy. I właśnie tam ostatecznie trafił Blockspring.
Jeroen: Rozumiem. Żeby mieć pewne wyobrażenie, co Coinbase planuje zrobić z tym, co zbudowaliście?
Paul: Niewiele z tego jest jeszcze publicznie dostępne, ale zajmujemy się tam API i platformą — zarówno wewnętrznymi, jak i zewnętrznymi. Wkrótce pojawi się wiele ekscytujących rzeczy. Tak, jesteśmy naprawdę podekscytowani. Myślę, że osobiście wierzę w to, że jeśli cofniemy się do Facebooka z 2007 roku, miał on dziesiątki milionów użytkowników. Media społecznościowe były wtedy zupełnie nowym zjawiskiem i sami twórcy Facebooka nie wiedzieli jeszcze, co okaże się ważne poza feedem. Czego będą chcieli ludzie? W jaki sposób będą chcieli wchodzić w interakcje? Wykorzystali platformę, żeby pomóc odkryć wszystkie kolejne przełomowe aplikacje.
Paul: Jeśli w 2007 roku byłeś na studiach i coś budowałeś, to zaraz po uruchomieniu Facebooka prawdopodobnie spędziłeś cztery albo pięć nocy, próbując stworzyć setkę różnych rzeczy, które wykorzystywałyby ich sieć społecznościową, pozwoliły znaleźć użytkowników i zbudować duży produkt. Myślę, że właśnie w takim miejscu znajduje się dzisiaj świat kryptowalut: istnieje kilka przełomowych aplikacji, takich jak Coinbase, ale obecnie służą one głównie do spekulacji. Potencjalnie istnieje jednak całkiem duża szansa platformowa, która mogłaby pomóc wprowadzić nas w kolejną falę ogromnego wzrostu. Deweloperzy są tym zainteresowani, użytkownicy są tym zainteresowani. Myślę, że jest tu duża szansa.
Paul: Jesteśmy tym naprawdę podekscytowani. W przypadku wielu tych nowych paradygmatów kolejne przełomowe aplikacje są odkrywane przez deweloperów i strony trzecie, za pośrednictwem platformy. Tak więc zdecydowanie cieszymy się z tego potencjału.
Jeroen: Super. Co ostatnio nie daje ci spać po nocach?
Paul: Co ostatnio nie daje mi spać po nocach? Cóż, myślę, że teraz wygląda to zupełnie inaczej niż przez ostatnie cztery lata. Przez ostatnie cztery lata dosłownie na nowo analizowaliśmy każdą decyzję: czy robimy właściwą rzecz? Czy to najlepsze, co możemy robić? Czy to największa rzecz, jaką możemy robić? Chcemy mieć jak największy wpływ na świat. Czy nie marnujemy czasu? Czy działamy w odpowiedniej branży? Wszystkie te pytania krążyły nam po głowach, a kluczowe było sprowadzenie tego wszystkiego do jednego pytania i skupienie się na tym, co jest tą jedną kolejną rzeczą, którą muszę zrobić, żebyśmy mogli odnieść sukces. I zazwyczaj odpowiedź brzmiała: dobrze, czego chcą użytkownicy i jak możemy się rozwijać?
Paul: Teraz myślę, że wszystko wygląda zupełnie inaczej, bo jestem częścią tej wielkiej maszyny, która porusza się naprzód siłą własnego rozpędu, podczas gdy jako założyciel startupu to ty jesteś tym rozpędem. Jeśli się zatrzymasz, maszyna zasadniczo też się zatrzymuje. Dla mnie to teraz zupełnie inny świat i naprawdę świetnie jest zacząć się uczyć, spotykać mnóstwo niesamowicie inteligentnych ludzi. Myślę, że mój drugi pobyt w San Francisco to zmiana o 180 stopni w porównaniu z tym, jak było, kiedy byłem tu jako założyciel, wariowałem i próbowałem zrozumieć, jak dobrze wykonywać swoją pracę.
Paul: Teraz myślę, że to zdecydowanie spokojniejszy okres nauki, spotykania świetnych ludzi, pracy nad wielkimi rzeczami, czerpania z tego energii i po prostu korzystania z tego etapu.
Jeroen: Super. Powoli zmierzamy do końca — jaką dobrą książkę ostatnio przeczytałeś i dlaczego akurat ją wybrałeś?
Paul: O, dobre pytanie. Ostatnia dobra książka. Dobrze, polecił mi ją jeden z przyjaciół. Spróbujmy sobie przypomnieć, jaki był jej tytuł. Ups, przepraszam. Sekundkę. To była książka o projektowaniu gier, zatytułowana Reality is Broken. Jej główne pytanie brzmiało: dlaczego ludzie spędzają tak dużą część życia w grach? Jak możemy wykorzystać to, czego uczymy się z projektowania gier, żeby wywierać wpływ na świat? Przeczytałem ją, ponieważ naprawdę mocno wierzę, że główne elementy składające się na grę wyewoluowały i zostały odkryte, a można je zastosować do wszystkiego.
Paul: Jeśli więc tworzysz aplikację randkową i w jakiś sposób nie wykorzystujesz w niej projektowania gier, poniesiesz porażkę, a ci, którzy z niego korzystają, w końcu budują Tinder. Myślę, że wszystko staje się coraz bardziej grą, a wszystkie gry tak naprawdę coraz bardziej przypominają tradycyjne produkty software’owe, społecznościowe i komunikacyjne oraz całą resztę tego typu rzeczy. Wszystko to się zbiega, więc przeczytałem tę książkę, żeby spróbować to zrozumieć. Grałem przez całe życie, ale chciałem lepiej zrozumieć stojącą za tym naukę, to, co mówi ona o nas samych, oraz to, jak może mi pomóc ulepszać sposób, w jaki tworzę produkty. To była naprawdę niesamowita książka. Zdecydowanie polecam ją każdemu.
Jeroen: Jaka była najbardziej szalona rzecz, o której tam przeczytałeś?
Paul: Ostatecznie zrobiłem przy tej książce mnóstwo notatek, ale co było najbardziej szalone? To dobre pytanie. Najbardziej szalone było dla mnie uświadomienie sobie, że zasadniczo istnieje tu pętla sprzężenia zwrotnego: projektanci gier próbują tworzyć gry, które sprawiają, że chcesz grać dłużej, czerpać z nich większą wartość i tak dalej. Zasady obowiązujące w tych wirtualnych światach gier są w rzeczywistości odbiciem ludzi i tego, co ich motywuje. Tego, co skłania ich do działania i do chodzenia do pracy, a jednocześnie sprawia, że chcą wrócić do domu i spędzać tyle czasu na graniu.
Paul: Chyba jednym z najbardziej szalonych wniosków jest to, że książka nosi tytuł Reality is Broken, ponieważ sposób, w jaki zaprojektowaliśmy gry, daje nam w rzeczywistości lepsze doświadczenia niż te, które czekają na nas w pracy i na co dzień. W realnym świecie idziesz do pracy. Wiele rzeczy pozostaje niewiadomych. Nie dostajesz żadnej informacji zwrotnej. Nie wiesz, czy wygrywasz, czy przegrywasz. Po prostu posuwasz się naprzód, mając nadzieję, że w jakiś sposób robisz postępy. W grach są jednak jasne zasady. Istnieje jasna pętla sprzężenia zwrotnego. Wiesz, czy odniosłeś zwycięstwo, czy poniosłeś porażkę. To wszystko są rzeczy, których chcemy w życiu, dlatego ludzie grają — w grach dostają to, czego nie otrzymują w prawdziwym życiu.
Paul: Myślę, że rzeczy, które odkrywamy w grach, nie dotyczą wyłącznie tego, jak sprawić, żeby ludzie dłużej grali w Super Smash Bros. Tak naprawdę odkrywamy rzeczy związane z ludzką naturą, naszymi emocjami i tym, czego chcemy od życia — i myślę, że właśnie dlatego tak wiele z tych światów się zbiega. W Stanach Zjednoczonych możesz zbudować tylko jedno społeczeństwo, ale w grach możesz zbudować mnóstwo społeczeństw, zmieniać zasady i robić całą masę tego typu rzeczy. To po prostu kambryjska eksplozja pomysłów na to, jak zarządzać społeczeństwami i czego możemy się o nich dowiedzieć. Myślę, że wykorzystanie tego w innych aplikacjach, produktach i w codziennym życiu to naprawdę wielka sprawa.
Jeroen: Racja. Super.
Paul: Tak.
Jeroen: Ostatnie pytanie. Jaka jest najlepsza rada biznesowa, jaką kiedykolwiek dostałeś?
Paul: Najlepsza rada biznesowa. Myślę, że to połączenie dwóch rzeczy. Pierwsza jest taka sama, jak ta, którą daje YC: twórz coś dla siebie, buduj coś, czego ludzie chcą, rozmawiaj z użytkownikami — ta cała pętla naprawdę działa. Sam wielokrotnie zawodziłem na różnych etapach tego procesu, ale jeśli będziesz się tego trzymać, ostatecznie zbudujesz coś, co w jakiś sposób może zadziałać, przynosić pieniądze albo zapewnić ci dobry styl życia.
Paul: Odwrotna rada brzmi zasadniczo tak: kiedy skończą ci się pomysły, kiedy uznasz, że nadszedł czas, żeby się zresetować albo spróbować zająć czymś większym, ale jeszcze nie wiesz czym, po prostu się zresetuj. Nie myśl, że poniosłeś porażkę czy coś w tym rodzaju. Ludzie po prostu przechodzą przez różne etapy życia w różnym czasie. Dlatego najważniejsza rada jest taka: jeśli wiesz, nad czym chcesz pracować, idź i pracuj nad tym. Jeśli nie wiesz, idź i poszukaj odpowiedzi. Ucz się i odkrywaj kolejne problemy, żyjąc, rozmawiając z ludźmi i robiąc całą resztę tego typu rzeczy.
Paul: Jeśli jesteś w tej trzeciej grupie — chcesz założyć startup i próbujesz dopiero znaleźć problem, którym warto się zająć — to bardzo trudny świat do funkcjonowania i zdecydowanie nie chciałbym przechodzić przez to ponownie.
Jeroen: Dobrze.
Paul: Tak.
Jeroen: Jeszcze raz dzięki, Paul, że wystąpiłeś w Founder Coffee.
Paul: Tak.
Jeroen: Naprawdę wspaniale było cię gościć.
Paul: Świetnie było tu być. Dzięki za zaproszenie.
Podobało ci się? Przeczytaj wywiady Founder Coffee z innymi założycielami. ☕
Mamy nadzieję, że spodobał ci się ten odcinek. Jeśli tak, oceń nas w iTunes!
Aby być na bieżąco z naszym podcastem Founder Coffee i przy okazji dowiedzieć się więcej o startupach, growth marketingu i sprzedaży:
👉 Zapisz się do naszego newslettera, wysyłanego co 2 tygodnie:
👉 Obserwuj @salesflare na Twitterze, LinkedIn lub Facebooku
