Wskazówki dla technicznych założycieli startupów | Startup School
Techniczni założyciele mogą łatwo pomylić doskonałość techniczną z postępem startupu. Dopracowana architektura, elegancka baza kodu czy ambitny plan infrastruktury mogą sprawiać wrażenie produktywnej pracy, ale żadne z nich nie dowodzi, że klienci potrzebują produktu. W tym wystąpieniu Startup School Diana Hu, opierając się na swojej drodze od CTO startupu z branży rozszerzonej rzeczywistości do stanowiska Director of Engineering w Niantic oraz na lekcjach innych założycieli Y Combinator, wyjaśnia, czego naprawdę wymaga ta rola.
Jej główny argument brzmi: techniczni założyciele muszą optymalizować działania pod kątem uczenia się. Na etapie tworzenia pomysłu oznacza to przygotowanie czegoś, na co użytkownicy mogą zareagować. Na etapie MVP oznacza to dostarczenie wąskiego, ale działającego produktu i szukanie realnego zaangażowania. Po premierze oznacza to łączenie analityki z bezpośrednimi rozmowami, szybkie ulepszanie produktu oraz akceptowanie technicznych kompromisów, gdy pomagają one firmie odkryć rentowny rynek.
Techniczny założyciel buduje firmę
Techniczny współzałożyciel nie jest po prostu osobą wyznaczoną do wdrażania planów drugiego założyciela. Hu opisuje tę rolę jako głęboko zaangażowane partnerstwo, w którym techniczny założyciel współdzieli odpowiedzialność za produkt, klientów i przetrwanie firmy.
Ta odpowiedzialność przekłada się na wyjątkowo szeroki zakres pracy. We wczesnym startupie techniczny założyciel może w tym samym tygodniu pisać kod aplikacji, konfigurować usługi chmurowe, odpowiadać na zgłoszenia wsparcia, naprawiać łączność w biurze, przeprowadzać wywiady z użytkownikami i podejmować decyzje produktowe. Wąskie opisy stanowisk należą do większych organizacji; założyciele pracują tam, gdzie znajduje się najpilniejsza niewiadoma firmy.
Dlatego właściwym wczesnym celem inżynieryjnym nie jest maksymalne zaawansowanie techniczne. Jest nim minimalna ilość technologii potrzebna do nadania sprawom rozpędu. Założyciele potrzebują wystarczającej części produktu, by przetestować kolejne ważne założenie — nie wyidealizowanego systemu przygotowanego na każdą hipotetyczną przyszłość.
Zaprototypuj pomysł, zanim zbudujesz firmę
Na etapie tworzenia pomysłu natychmiastowym celem jest nadanie konkretnej formy abstrakcyjnej propozycji. Prototyp daje potencjalnym użytkownikom coś, co mogą zobaczyć, wypróbować lub omówić, zapewniając bardziej wiarygodne informacje zwrotne niż sam ustny pitch.
Prototyp nie musi koniecznie zawierać działającego kodu produkcyjnego. Zespół tworzący oprogramowanie może użyć Figmy lub innego narzędzia projektowego, aby zasymulować doświadczenie. Startup sprzętowy może przedstawić render 3D. Gdy sama wykonalność techniczna jest niepewna, najbardziej użytecznym artefaktem może być skupiona demonstracja leżącej u podstaw technologii.
Hu wskazuje na wczesne prace stojące za firmami takimi jak Optimizely i Azure Reality, aby zilustrować różne formy walidacji. Prototyp może ujawnić interakcję wizualną, która komunikuje wartość produktu, albo dowieść, że trudna technika rozszerzonej rzeczywistości jest możliwa. Liczy się to, że odnosi się do istotnego ryzyka.
Typowym błędem jest dalsze budowanie po tym, jak prototyp stał się wystarczająco dobry, by rozpocząć rozmowę. Założyciele dodają ekrany, przypadki brzegowe i infrastrukturę, ponieważ wdrażanie wydaje się bardziej kontrolowalne niż pokazywanie użytkownikom niedokończonej pracy. To opóźnienie jest kosztowne: zwiększa inwestycję, zanim zespół dowie się, czy rozwiązuje właściwy problem.
Buduj MVP wokół zaangażowania, nie kompletności
Prototyp pomaga ocenić pomysł; MVP to użyteczny produkt przeznaczony do wydania. Hu twierdzi, że przechodząc do tego etapu, założyciele powinni zwykle myśleć w tygodniach, a nie w kategoriach długich cykli rozwoju.
Celem MVP jest uzyskanie mocniejszych dowodów niż zainteresowanie czy komplementy. Idealnie byłoby, gdyby użytkownicy demonstrowali zaangażowanie, płacąc. W zależności od rynku znaczące może być także inne kosztowne działanie — na przykład poświęcenie czasu, dostarczenie danych operacyjnych lub zintegrowanie produktu z procesem pracy. Kluczowe rozróżnienie dotyczy osoby, która mówi, że koncepcja brzmi atrakcyjnie, oraz osoby, która godzi się na rzeczywisty kompromis, by z niej korzystać.
Założyciele powinni pozostawać blisko tego procesu. Zbyt wczesne zatrudnienie dużego zespołu inżynieryjnego może zwiększyć dystans między osobami podejmującymi decyzje a użytkownikami, a jednocześnie podnieść koszty koordynacji. Wczesny zespół Justin.tv, z którego ostatecznie powstał Twitch, podzielił główne części początkowego systemu między samych założycieli. Bezpośrednia praca nad produktem pozwoliła im zrozumieć jego ograniczenia, gdy firma wciąż nabierała kształtu.
Wczesne, praktyczne zaangażowanie nie ma dowodzić, że założyciele mogą robić wszystko na zawsze. Chodzi o zachowanie krótkiej drogi między dowodami od klientów a decyzjami produktowymi, gdy każda nowa obserwacja może zmienić kierunek firmy.
Radykalnie ogranicz zakres produktu
Jedną z najbardziej użytecznych zasad Startup School jest robienie rzeczy, które się nie skalują. Techniczni założyciele są często uczeni eliminowania pracy ręcznej, jednak tymczasowe procesy manualne mogą być dokładnie tym, czego potrzebuje wczesny produkt. Osobiste wdrażanie klientów lub wykonywanie operacji za kulisami może pozwolić zespołowi wystartować, zanim automatyzacja będzie uzasadniona.
Hu przedstawia również ideę „rozwiązania 90/10”: dostarczenia ograniczonej implementacji obsługującej podstawowy przypadek użycia zamiast próby pokrycia całej przestrzeni problemu. Zakres można ograniczyć w kilku wymiarach:
Obsługuj jeden główny typ użytkownika.
Akceptuj wyłącznie najważniejszy format danych.
Działaj w jednej lokalizacji lub na jednym rynku.
Obsługuj dominujący proces pracy, odkładając przypadki brzegowe.
Zastąp przedwczesną automatyzację procesem manualnym.
Wczesny produkt DoorDash jest zapadającym w pamięć przykładem. Zaczynał jako podstawowa strona internetowa, proste narzędzia operacyjne i usługa ograniczona do niewielkiego obszaru geograficznego. Nie przypominał dojrzałej platformy logistycznej, którą firma miała później stworzyć, ale wystarczał, aby sprawdzić, czy klienci chcą tej usługi.
Duże firmy są często ograniczane przez istniejące systemy, procesy weryfikacji i szerokie oczekiwania klientów. Przewagą startupu jest zdolność do zdefiniowania mniejszego problemu i szybkiego działania. Techniczni założyciele rezygnują z tej przewagi, gdy budują tak, jakby już działali na skalę przedsiębiorstwa.
Wybieraj technologię pod kątem szybkości iteracji
Wybór stosu technologicznego może przerodzić się w rozpraszającą debatę tożsamościową. Hu zaleca zrównoważenie rzeczywistych wymagań produktu z obecnymi umiejętnościami zespołu, a następnie wybranie najprostszego zestawu, który można szybko wdrożyć i modyfikować.
Znajomość narzędzi ma praktyczną wartość. Założyciel korzystający z dobrze znanych narzędzi może szybciej diagnozować problemy i poświęcać więcej uwagi użytkownikom. Nowa technologia może być odpowiednia, gdy tworzy realną przewagę produktu, ale sama nowość nie pomaga startupowi się uczyć.
Ten sam pragmatyczny standard dotyczy usług zewnętrznych. Uwierzytelnianie, płatności, hosting, komunikacja i inne powszechne możliwości można często kupić za pośrednictwem API lub sprawdzonych frameworków. Odtwarzanie ich od podstaw pochłania czas, niekoniecznie wyróżniając produkt.
Założyciele czasem opierają się usługom zewnętrznym, ponieważ obawiają się przyszłych opłat, ograniczeń lub pracy związanej z migracją. Obawy te mogą być uzasadnione, ale trzeba je zestawić z bezpośrednim ryzykiem zbyt wolnego działania. Firma z silnym wykorzystaniem produktu może zatrudnić inżynierów, wymienić komponenty i zoptymalizować infrastrukturę. Technicznie czysty produkt bez klientów ma znacznie mniej możliwości.
Wypuść produkt, aby rozpocząć prawdziwy cykl uczenia się
Wydanie MVP nie jest końcem rozwoju produktu. To moment, w którym firma zyskuje dostęp do lepszych dowodów i może zacząć zbliżać się do dopasowania produktu do rynku.
Hu zaleca korzystanie zarówno z sygnałów ilościowych, jak i jakościowych. Prosty panel analityczny może ujawnić adopcję, retencję, konwersję oraz miejsca, w których użytkownicy porzucają proces. Rozmowy i interakcje ze wsparciem wyjaśniają motywacje, których zagregowane liczby nie są w stanie uchwycić. Żadna z tych form dowodów sama w sobie nie jest wystarczająca.
Ewolucja WePay w kierunku oferty zorientowanej na API pokazuje, jak zaobserwowane zachowanie i informacje zwrotne od klientów mogą przekierować firmę. Powtarzające się premiery Segment pokazują inny wzorzec: częste wydania stwarzają więcej okazji do testowania założeń, odkrywania popytu i rozwijania tego, co działa.
Wynika z tego, że premiery nie należy traktować jako jednorazowego, uroczystego wydarzenia. To powtarzalny rytm działania. Każde wydanie tworzy dowody; zespół je interpretuje i decyduje, co ulepszyć, usunąć lub przetestować w następnej kolejności.
Zarządzaj długiem technicznym w służbie dopasowania produktu do rynku
Gdy klienci korzystają już z produktu, założyciele stają przed konkurującymi ze sobą wymaganiami. Muszą naprawiać błędy, dostarczać zamawiane funkcje, utrzymywać system w działaniu i zajmować się skrótami nagromadzonymi podczas początkowej budowy.
Hu nie twierdzi, że dług techniczny jest nieszkodliwy. Przedstawia go raczej jako kompromis. Zaciąganie długu może być racjonalne, gdy znacząco przyspiesza uczenie się lub przybliża firmę do dopasowania produktu do rynku. Błędem jest pozwolenie, aby porządki inżynieryjne oderwały się od priorytetów biznesowych — albo ignorowanie problemów z niezawodnością, które uniemożliwiają użytkownikom otrzymywanie wartości.
Pokémon Go stanowi skrajny przykład popytu, który pojawił się wraz ze znacznym obciążeniem technicznym. Problemy podczas premiery miały znaczenie, lecz nie przekreśliły siły leżącej u podstaw reakcji użytkowników. Dla startupu jest to zwykle lepsza klasa problemu niż zbudowanie niezawodnego systemu, którego nikt pilnie nie chce.
Inżynieria powinna również ściśle współpracować ze sprzedażą i rozwojem. Zespoły mające kontakt z klientami często jako pierwsze dostrzegają pojawiające się potrzeby, podczas gdy inżynierowie rozumieją, co można tanio przetestować. Współpraca między nimi może przekształcić obserwacje rynkowe w ukierunkowane eksperymenty bez wprowadzania ciężkich procesów dojrzałej korporacji.
Przejdź od głównego twórcy do lidera inżynierii
Rola technicznego założyciela zmienia się po osiągnięciu dopasowania produktu do rynku. Wcześniej założyciel może osobiście wdrażać większość produktu. Wraz ze wzrostem użycia i zespołu inżynieryjnego praca rozszerza się o rekrutację, komunikację, kierunek techniczny i kulturę.
Ta zmiana ogranicza nieprzerwany czas na kodowanie. Więcej osób oznacza więcej zależności, decyzji i ścieżek komunikacji. Założyciel musi zapewnić, że inżynierowie rozumieją nie tylko co budować, ale także jak firma podejmuje kompromisy i jakie standardy są istotne.
Ostatecznie techniczni założyciele mogą potrzebować wyboru między dwiema szerokimi ścieżkami. Jedna polega na pozostaniu głęboko zaangażowanym architektem, kierującym najważniejszymi decyzjami technicznymi dotyczącymi systemu. Druga polega na skupieniu się na zarządzaniu ludźmi i budowaniu organizacji. Właściwy wybór zależy od firmy i mocnych stron założyciela, ale unikanie tej decyzji może sprawić, że obie odpowiedzialności będą zaniedbane.
Szersza lekcja jest taka, że rola powinna ewoluować wraz z firmą. Na początku szybkość wynika z pisania kodu i bezpośrednich rozmów z użytkownikami. Później szybkość coraz częściej wynika z tworzenia zespołu, który może podejmować trafne decyzje bez kierowania każdego szczegółu przez jednego założyciela.
Zasada działania: buduj, aby się uczyć
W prototypowaniu, tworzeniu MVP, premierze i skalowaniu Hu powraca do jednego konsekwentnego priorytetu: skracania odległości między założeniem a wiarygodnym dowodem.
Zbuduj pierwszy prototyp wystarczająco szybko, by pokazać pomysł użytkownikom. Wypuść ściśle ograniczone MVP, które może zdobyć prawdziwe zaangażowanie. Wybieraj technologię wspierającą szybkie iteracje, nawet jeśli pierwsza implementacja nie będzie trwała. Po premierze interpretuj zarówno dane o zachowaniu, jak i informacje zwrotne od ludzi. Akceptuj celowy dług techniczny, gdy wspiera odkrywanie, a następnie zajmuj się nim, gdy niezawodność i wzrost sprawiają, że taka praca staje się konieczna.
Dla technicznych założycieli najtrudniejszą dyscypliną może być uświadomienie sobie, że kod nie jest firmą. Technologia jest narzędziem, za pomocą którego zespół testuje rynek, obsługuje klientów i pomnaża zdobytą wiedzę. Najlepszy wczesny system nie jest więc tym zaprojektowanym na każdą możliwą przyszłość. Jest nim system, który pomaga startupowi dotrzeć do kolejnej ważnej prawdy.
