Eksperci startupowi o robieniu rzeczy, które się nie skalują
- Aisha Washington

- 1 dzień temu
- 7 minut(y) czytania
Założycielom firm na wczesnym etapie często radzi się, by od początku myśleli o skalowaniu. Pyta się ich, jak ich systemy obsłużą miliony użytkowników, jak pozyskiwanie klientów stanie się powtarzalne i jak działalność będzie się rozwijać bez wzrostu kosztów w tym samym tempie. To uzasadnione pytania — ale eksperci startupowi biorący udział w tej dyskusji Y Combinator twierdzą, że zbyt często padają one za wcześnie.
Prelegenci wracają do wpływowego eseju Paula Grahama „Do Things That Don’t Scale” i wyjaśniają, dlaczego jego przesłanie wciąż ma kluczowe znaczenie dla budowania firmy od zera. Na przykładach Airbnb, Fleek, Stripe, Algolia, Instacart i DoorDash przekonują, że ręczny wysiłek nie jest jedynie akceptowalnym, tymczasowym kompromisem. Stosowany świadomie jest skutecznym sposobem na testowanie popytu, zrozumienie klientów i odkrywanie, które elementy działalności naprawdę warto skalować.
Dlaczego świat startupów potrzebował innego podejścia
Według prelegentów entuzjazm Doliny Krzemowej wobec skalowalnych systemów częściowo wynikał z obserwacji niezwykle odnoszących sukcesy firm internetowych. Google pokazał, że oprogramowanie i dystrybucja online mogą docierać do ogromnej liczby odbiorców przy relatywnie niewielkim dodatkowym nakładzie pracy. Założyciele i inwestorzy naturalnie zaczęli szukać podobnie powtarzalnych modeli wzrostu.
Z czasem ta ambicja stała się ograniczeniem. Przedsiębiorcy czuli presję, aby przedstawić skalowalne rozwiązanie, zanim udowodnili, że ktokolwiek go potrzebuje. Mogli spędzać miesiące na projektowaniu zautomatyzowanych systemów dla hipotetycznego popytu, pozostając jednocześnie daleko od prawdziwych klientów.
Esej Paula Grahama podważył tę kolejność. Jak wyjaśniają paneliści, większości młodych startupów nie zagraża nadmierny popyt ani załamanie infrastruktury. Ich bezpośrednie ryzyko jest znacznie prostsze: mogą nigdy nie przyciągnąć wystarczającej liczby użytkowników albo stworzyć coś, czego ludzie nie cenią.
Praktycznym priorytetem jest więc bezpośrednie rozwiązanie problemu, nawet jeśli pierwsza metoda wymaga intensywnej pracy. Skalowalność w końcu będzie istotna, ale dopiero wtedy, gdy firma znajdzie coś wartego skalowania.
Najpierw trzeba przejść od zera do jednego
Dyskusja przedstawia postęp startupu jako serię bezpośrednich ograniczeń. Na początku wyzwaniem nie jest efektywna obsługa milionowego klienta. Jest nim zdobycie pierwszego klienta, dostarczenie pierwszego udanego rezultatu i zrozumienie, dlaczego ta osoba wybrała produkt.
To zmienia sposób, w jaki założyciele powinni oceniać wczesną pracę. Zadanie, które w dojrzałej firmie wygląda na nieefektywne, może być całkowicie racjonalne, gdy szybko odpowiada na kluczowe pytanie. Osobiste wdrożenie klienta, ręczne złożenie usługi czy improwizowanie wewnętrznego przepływu pracy może ujawnić więcej niż tygodnie spędzone na budowaniu infrastruktury w odosobnieniu.
Prelegenci przywołują Airbnb jako kluczowy przykład. Jego założyciele potrzebowali lepszych ofert, więc pomagali gospodarzom tworzyć zdjęcia wyższej jakości. Jeżdżenie do nieruchomości i indywidualne ulepszanie ofert nigdy nie mogło być stałym modelem działania. Rozwiązało jednak pilny problem firmy: uczyniło marketplace bardziej atrakcyjnym i wygenerowało wystarczającą aktywność, aby wzrost mógł się rozpocząć.
Wniosek nie jest taki, że każdy założyciel powinien odtwarzać taktykę Airbnb. Chodzi o to, by założyciele bezpośrednio zidentyfikowali przeszkodę stojącą przed nimi i byli gotowi ją rozwiązać, nie czekając na elegancki system.
Fleek poznał rynek, zanim go zbudował
Fleek stanowi szczególnie wyrazisty przykład uczenia się poprzez ręczne działania operacyjne. Firma zaczynała bez gotowej strony internetowej, bez zapasu odzieży i bez zaawansowanej infrastruktury marketplace. Zamiast tego jej założyciele udawali się do londyńskich hurtowników, budowali relacje i bezpośrednio łączyli podaż ze sklepami.
Panel opisuje, jak zespół nawet przewoził ubrania między hurtownikami a sprzedawcami detalicznymi. Z perspektywy konwencjonalnej efektywności założyciele samodzielnie noszący towar wyglądają jak oznaka porażki procesu. Z perspektywy uczenia się sytuowało ich to jednak wewnątrz transakcji.
Uczestnicząc w tej pracy, Fleek mógł obserwować, czego chcą sprzedawcy detaliczni, jak zachowują się hurtownicy, jakie ceny się sprawdzają i jak popyt reaguje na zmiany. Nie były to abstrakcyjne odpowiedzi z ankiet. Były to wnioski zebrane podczas pomagania prawdziwym kupującym i sprzedającym w realizacji prawdziwych zakupów.
Po około czterech miesiącach ręcznej działalności założyciele mieli wystarczającą wiedzę, by przenieść aktywność do internetu. Marketplace opierał się na zachowaniach, które zespół już zaobserwował, a nie na założeniach dotyczących tego, jak rynek powinien funkcjonować.
Bezpośrednie wdrażanie tworzy lepsze produkty
Prelegenci wskazują Stripe i Algolia jako kolejne przykłady założycieli zmniejszających dystans między rozwojem produktu a rzeczywistością klienta. Założyciele Stripe pomagali w instalacji swojego oprogramowania płatniczego pierwszym użytkownikom, zamiast jedynie wysyłać dokumentację i czekać. Algolia podobnie wspierała Product Hunt we wdrożeniu wyszukiwania.
Bezpośrednie wdrożenie daje więcej niż tylko aktywowanie nowego konta. Ujawnia niejasne kroki konfiguracji, ukryte zależności techniczne oraz różnice między tym, czego klienci mówią, że potrzebują, a tym, z czym rzeczywiście mają trudności.
Może także zmienić relację. Klient, który pracował u boku założyciela, z większym prawdopodobieństwem podzieli się szczerą opinią niż ktoś, kto wysyła zgłoszenie do działu wsparcia nieznanej firmy. To zaufanie daje startupowi dostęp do trafniejszych wniosków dotyczących produktu.
Paneliści opisują tę osobistą uwagę — „FaceTime” ze strony założyciela — jako przewagę, której ugruntowane firmy często nie są w stanie dorównać. Duży konkurent może dysponować większymi zasobami, ale zazwyczaj nie może zapewnić osobistego zaangażowania swoich założycieli w sukces każdego drobnego klienta. W przypadku startupu z niekompletnym produktem i ograniczoną wiarygodnością widoczna troska może stać się częścią propozycji wartości.
Optymalizuj wczesną pracę pod kątem uczenia się
Główny argument dyskusji jest taki, że założyciele powinni optymalizować wczesną fazę pod kątem uczenia się, a nie elegancji operacyjnej. Ręczne dostarczanie usługi pomaga ustalić, czy obiecany rezultat jest rzeczywiście wartościowy, zanim zespół zakoduje ten proces w oprogramowaniu.
Tę zasadę można przełożyć na prostą sekwencję:
Zidentyfikuj najważniejszą niewiadomą w biznesie.
Zaprojektuj najszybszy wiarygodny sposób jej przetestowania z prawdziwymi klientami.
Wykonaj pracę ręcznie, gdy automatyzacja opóźniłaby uzyskanie odpowiedzi.
Zapisuj, co wielokrotnie tworzy wartość lub powoduje tarcia.
Buduj systemy dopiero wtedy, gdy wzorzec stanie się jasny.
Nie oznacza to traktowania każdego improwizowanego procesu jako dowodu na istnienie rentownego biznesu. Ręczna praca jest użyteczna, gdy generuje dowody. Założyciele nadal muszą ustalić, czy popyt się powtarza, czy klienci zapłacą oraz czy podstawowa usługa może ostatecznie wspierać atrakcyjny model biznesowy.
Powinni natomiast unikać mylenia technicznego dopracowania z walidacją. Pięknie zaprojektowana platforma nie zrekompensuje niechcianego produktu.
Instacart i DoorDash testowały popyt improwizowanymi narzędziami
Historia Instacart pokazuje, jak założyciele mogą testować marketplace, zanim zdobędą wszystkie partnerstwa, których wymagałaby dojrzała wersja. Jak opisano w nagraniu, firma wystartowała bez formalnych relacji ze sklepami spożywczymi. Zespół kupował produkty w Trader Joe’s, fotografował je i umieszczał online, aby sprawdzić, czy klienci będą zamawiać dostawę zakupów spożywczych.
Takie podejście ominęło potencjalnie długi cykl negocjacji partnerskich. Zamiast prosić sprzedawców detalicznych o wsparcie niezweryfikowanej koncepcji, założyciele najpierw zebrali dowody, że konsumenci chcą tej usługi.
DoorDash obrał podobnie pragmatyczną drogę. Prelegenci opisują jego wczesny produkt jako coś złożonego w jeden dzień przy użyciu zwykłych narzędzi, w tym Google Drive i Find My Friends. Celem nie było natychmiastowe stworzenie trwałej platformy logistycznej. Chodziło o sprawdzenie, czy lokalni konsumenci będą zamawiać dostawy z restauracji i czy założyciele będą w stanie realizować te zamówienia.
Eksperymenty te wykorzystywały prawdziwą przewagę startupów: małe zespoły mogą tymczasowo koordynować pracę w sposób niepraktyczny dla dużych organizacji. Mają mniej procesów do ochrony, mniej infrastruktury do zintegrowania i większą swobodę zmiany kierunku po każdym wyniku.
Niedoskonałe systemy przyspieszają adaptację
Ręczne wykonywanie zadań pozwala zespołowi zmieniać doświadczenie bez przebudowy całego produktu. Jeśli klienci nie lubią danego kroku, założyciele mogą zmienić go przy następnym zamówieniu. Jeśli założenie okaże się fałszywe, mogą je porzucić, zanim zostanie utrwalone w miesiącach pracy inżynieryjnej.
Prelegenci argumentują także, że założyciele nie powinni nadmiernie obawiać się wczesnych błędów operacyjnych. Problemy wynikające z rosnącego popytu często tworzą silną motywację do szybkiego znajdowania rozwiązań. Kiedy startup ma wreszcie więcej użytkowników, niż może obsłużyć jego improwizowany proces, potrzeba automatyzacji staje się konkretna, pilna i łatwiejsza do zdefiniowania.
Dlatego startupy rzadko ponoszą porażkę dlatego, że przyciągnęły zbyt wielu klientów i nie potrafiły się skalować. Problemy z przepustowością są bolesne, ale towarzyszą im dowody popytu. Brak użytkowników jest znacznie groźniejszy, ponieważ nie przynosi ani przychodów, ani jasnego powodu, by dalej budować.
Wniosek dla inżynierii jest istotny: odkładanie infrastruktury może być formą szybkości, a nie zaniedbaniem, pod warunkiem że skróty są rozumiane i nie tworzą niedopuszczalnego ryzyka dla klientów.
Kiedy zacząć budować z myślą o skali
Nieskalowalna praca jest metodą odkrywania, a nie trwałą filozofią. Gdy startup rozumie powtarzające się zadanie, widzi utrzymujący się popyt i napotyka ręczne wąskie gardła, musi zacząć przekładać zdobytą wiedzę na powtarzalne systemy.
Panel zauważa, że doświadczeni doradcy i inwestorzy mogą pomóc założycielom rozpoznać ten moment przejścia. Zbyt wczesne skalowanie marnuje zasoby na niezweryfikowane założenia. Zbyt późne skalowanie może pogorszyć jakość usługi, wyczerpać zespół i uniemożliwić firmie wykorzystanie popytu.
Użytecznym sygnałem jest powtarzalność. Jeśli założyciele wciąż rozwiązują ten sam problem w mniej więcej taki sam sposób, oprogramowanie może być w stanie ustandaryzować proces. Innym sygnałem jest koszt alternatywny: gdy ręczne dostarczanie usługi pochłania czas, który mógłby przynieść cenniejszą naukę lub wzrost, automatyzacja staje się coraz bardziej atrakcyjna.
Celem nie jest eliminowanie udziału ludzi dla samego eliminowania. Chodzi o automatyzowanie części, które są już zrozumiane, przy jednoczesnym zachowaniu bliskiego kontaktu tam, gdzie klienci wciąż uczą firmę czegoś ważnego.
Konsulting może być pomostem, ale nie celem
Prelegenci omawiają także granicę między startupem programistycznym a firmą konsultingową. Młoda firma może osiągać przychody, świadcząc praktyczne usługi dla biznesów, a jej pierwszy produkt może po prostu sprawiać, że ta usługa jest szybsza lub bardziej niezawodna.
Może to być produktywny punkt wyjścia. Praca konsultingowa wystawia założycieli na realne środowiska operacyjne i daje im szczegółową wiedzę o problemach klientów. Może również finansować wczesny rozwój.
Panel ostrzega jednak, że same przychody z usług nie tworzą szybko rosnącej firmy programistycznej. Praca dostosowana do potrzeb klienta rozwija się przede wszystkim przez dodawanie ludzi, podczas gdy skalowalny produkt może obsługiwać znacznie więcej klientów bez proporcjonalnego wzrostu zatrudnienia. Ambitne cele wzrostu pomagają wymusić to rozróżnienie: jeśli biznes ma wzrosnąć dziesięciokrotnie, założyciele muszą ostatecznie przekształcić powtarzalną wiedzę ekspercką w produkt, zamiast bez końca sprzedawać pracę szytą na miarę.
Trwała przewaga wysiłku założyciela
Końcowe przesłanie nagrania brzmi: gotowość do wykonywania niezręcznych, ręcznych lub pozornie drobnych zadań jest jedną z najsilniejszych przewag startupu nad ugruntowanymi konkurentami. Taka praca przybliża założycieli do klientów, przyspiesza eksperymenty i stwarza okazje do zapewnienia wyjątkowo uważnej obsługi.
Głębsza zasada nie jest pochwałą nieefektywności. To zdyscyplinowane zachowanie właściwej kolejności. Najpierw dowiedz się, czego ludzie potrzebują. Następnie udowodnij, że podejmą działanie w odpowiedzi na tę potrzebę. Dostarcz rezultat dowolną odpowiedzialną dostępną metodą, przeanalizuj powtarzający się wzorzec, a dopiero potem zainwestuj w uczynienie go powtarzalnym.
Skalowalność staje się wartościowa, gdy popyt na nią zasłuży. Przed tym momentem najskuteczniejszym systemem założyciela może być po prostu ciekawość, poczucie pilności i gotowość do osobistego wykonania pracy.


