Lekcje i praktyki nauczone podczas zwiększania wzrostu Logto z programistami.
Logto jest produktem open-source, skupionym na programistach. Oto nasza linia czasowa wprowadzania na rynek:
Mając doświadczenie w rozwoju produktów zorientowanych na wzrost dla narzędzi zwiększających produktywność, zespoły i ja próbowaliśmy różnych strategii wejścia na rynek dla Logto. Po dwóch latach zreflektowałem się nad tymi działaniami oraz krokami, które podjęliśmy. Chcę podzielić się częścią tej podróży i wyjaśnić, dlaczego niektóre rzeczy nie działały wtedy. To nie są "błędy", ale cenne lekcje z naszego doświadczenia. Mam nadzieję, że te spostrzeżenia pomogą innym pracującym nad podobnymi projektami lub startupami.
Kiedy pierwszy raz wypuszczasz swój produkt, zwłaszcza z myślą o rozwoju produktu lub pewnym doświadczeniu, łatwo jest pomyśleć o wszelkiego rodzaju ekscytujących pomysłach: wymyślne procesy wdrażania, świetne demo na stronie, fajne sposoby na zwrócenie uwagi użytkowników na wartość i szybkie osiągnięcie momentu "aha". Aby wydawać nasz produkt na bardziej wypolerowany i gotowy do komercjalizacji, wdrożyłem dwie strategie aktywizacji:
Te strategie były bardzo skuteczne w moim wcześniejszym doświadczeniu. Więc kiedy Logto wypuściło swoją wersję chmurową, natychmiast je zastosowałem. Jednak napotkałem pewne nieporozumienia i wyzwania:
W przypadku produktów dla programistów, trudno jest rozwiązać problem w krótkim czasie, nawet jeśli jest to możliwe do samodzielnego wykonania. Nawet dla pojedynczego programisty, proces ten obejmuje kilka etapów: integrację z odpowiednim stosu technologii, stworzenie proof of concept, testowanie w środowisku deweloperskim, a następnie przejście do produkcji. Na każdym etapie tej podróży, użytkownicy mogą się wycofać. "Zadanie do wykonania" nie jest prostym, jednorazowym zadaniem. Potrzeby programistów są często złożone, wymagające szeregu funkcji lub scenariuszy technicznych, które potrzebują starannego projektowania wykorzystując nasze istniejące możliwości. Rozwiązywanie takich problemów wymaga czasu i nie można go przyspieszać.
Patrząc wstecz, jest jasne, dlaczego to podejście nie odniosło sukcesu. Kiedy po raz pierwszy wystartowaliśmy, nasze codzienne zapisy i organiczny ruch były dość niskie. Większość naszego ruchu pochodziła z społeczności open-source, która naturalnie nie przynosiła większych klientów. Nic dziwnego, że nie widzieliśmy większych klientów umawiających się na rozmowy na tym etapie. Niski ruch i źródło naszych użytkowników sprawiły, że oczekiwanie znaczących rezerwacji rozmów na początku było nierealistyczne.
Wybierz model, który pasuje do twojego produktu, w oparciu o czas potrzebny na aktywację użytkownika. Nie pozwól, aby normy branżowe cię ograniczały.
Kiedy budujesz produkt SaaS, jednym z kluczowych pytań związanych z wprowadzeniem na rynek (GTM) jest wybór pomiędzy freemium lub darmową wersją próbną. Powszechna prawda sugeruje:
Początkowo wybraliśmy model freemium dla szybkiego startu, umieszczając mocne ograniczenia między planami darmowymi i płatnymi. Jednak programiści nie mogli mieć dostępu do zaawansowanych funkcji jak SSO czy Organizacja w darmowej wersji.
Chociaż jest mnóstwo debaty online na temat tego, który model jest lepszy, kluczowe jest, aby cofnąć się i rozważyć linię czasową aktywacji twojego produktu. W przypadku Logto, zaobserwowaliśmy, że w rzeczywistym świecie, faza testowania może trwać nawet 6 miesięcy. Nie jest to spowodowane złożonością Logto, ale raczej harmonogramem pracy inżyniera, planowaniem projektów, przepływami pracy zespołu i innymi czynnikami, których nie przewidzieliśmy.
Ze względu na ten długi okres aktywacji, ważne jest, aby zapewnić programistom pełny dostęp do wszystkich funkcji dla testów. Dlatego w pełni wykorzystujemy najemcę deweloperskiego, aby odblokować pełne możliwości produktu. To jest powszechna praktyka dla narzędzi dla programistów, ale warto to zauważyć, ponieważ wyjaśnia, dlaczego tradycyjne strategie freemium lub darmowej wersji próbnej mogą nie działać dla nas.
Wybór powinien być zgodny z naturą twojego produktu i jego linią czasową przyjęcia. Zrozum unikalne cechy twojego produktu i wybierz model, który pasuje—nie taki, który zbyt szybko przepycha użytkowników przez twój lejek konwersji.
Wykonanie GTM z strategią oddolną często obejmuje SEO, marketing produktu i marketing treści. Wszyscy wiemy, jak ważne jest rozpoczęcie wcześnie, więc zaczęliśmy tworzyć treści zaraz po uruchomieniu wersji open-source. Ale kiedy po raz pierwszy postanowiliśmy pisać artykuły, miałem jedno duże pytanie: O czym pisać?
Jako projektant produktu, moim instynktem było pisanie o tym, dlaczego zaprojektowaliśmy pewne funkcje, wyjaśniając proces myślowy i filozofię stojącą za nimi.
"W tym artykule omówimy historię doświadczenia logowania, w tym jej powstanie, decyzje projektowe i kompromisy produktowe. Uzyskasz także lepsze zrozumienie, jak skonstruować udane i bezproblemowe doświadczenie logowania lub rejestracji." - Nasz post na blogu sprzed 2 lat Rozważania projektowe dla bezproblemowego doświadczenia logowania (Pierwszy rozdział)
Byłem chętny do dzielenia się moimi przemyśleniami na temat naszych funkcji i projektu, ponieważ włożyłem w to tyle wysiłku. Ale patrząc wstecz, zdaję sobie sprawę, że to, co napisałem, to tzw. "egocentryczne" treści. To częste w dobrze ugruntowanych firmach z silną kulturą EPD (Inżynieria, Produkt, Projektowanie).
Jeśli robisz wzrost oparty na produkcie (PLG), zwłaszcza gdy twój produkt jeszcze nie osiągnął etapu, w którym "ludzie o tobie mówią", konieczne jest, aby twoje treści miały klarowną wartość i cel dla twojej publiczności. Unikaj bycia zbyt skoncentrowanym na sobie.
Na przykład, zamiast skupiać się na tym, dlaczego funkcja została zaprojektowana, twórz edukacyjne artykuły, które wyjaśniają konkretne pojęcia lub tutoriale, które pokazują, jak zintegrować fajną technologię lub narzędzie, aby rozwiązać powszechny problem techniczny.
W miarę jak uczysz się więcej o swoim produkcie i klientach, naturalnie rozwijasz silne przekonania o tym, co naprawdę ma znaczenie dla twojej publiczności. Zachowanie "podejścia zorientowanego na klienta" pomoże ci poprawić jakość treści. Z czasem będziesz w stanie pisać treści, które rezonują z twoją publicznością. W przeciwnym razie twoje treści ryzykują, że będą wydawały się egocentryczne.
Tradycyjny marketing często podkreśla "najlepsze praktyki" lub "rozwiązania" przy sprzedaży do firm lub osób, opierając się na pomyśle, że produkty SaaS przede wszystkim zwiększają wydajność i produktywność. Wiele strategii skupia się na liczbach, przedstawiając oszczędności finansowe, aby podkreślić korzyści. Choć może to działać dobrze dla dojrzałych firm z szeroką bazą klientów, może być zniechęcające dla programistów.
Dwa lata temu koncentrowałem się mocno na budowaniu propozycji wartości i tworzeniu szerokiego obrazu narracyjnego dla naszego produktu. Jednak takie podejście nie zawsze łączyło się z programistycznym audytorium.
Spójrz na stronę, którą mieliśmy 2 lata temu—"Kształtujemy przyszłość"… Wow!
Jeśli chodzi o zadowalanie programistów i rozwiązywanie ich problemów, musisz być bardzo praktyczny i realistyczny. Programiści nie są przekonani przez wzniosłe korzyści; interesują ich dostępność i elastyczność funkcji—konkretnie, jak łatwo twój produkt może zintegrować się z ich istniejącym stosu technologii. Jeśli nie może, nie próbuj go sprzedawać.
Teraz nasza strategia dotycząca treści jest znacznie bardziej skoncentrowana. Podkreślamy konkretne funkcje, które dostarczamy, umożliwiając użytkownikom szybkie zrozumienie, co oferujemy z pierwszego ekranu, bez polegania na sloganach czy ogólnych przekazach.
Kiedy po raz pierwszy wprowadziliśmy naszą hostowaną wersję komercyjną, w zespole zawsze trwała gorąca dyskusja: czy open-source zaszkodzi naszej hostowanej wersji, skoro jest darmowa, a naszym docelowym odbiorcą są programiści? Również debatowaliśmy, czy ograniczyć niektóre z naszych zaawansowanych funkcji w wersji open-source.
Jak dotąd, utrzymaliśmy rdzenne funkcje obu wersji open-source i hostowanej prawie takie same. Wzrost naszej społeczności open-source zbudował znaczącą zaufanie ze strony potencjalnych klientów korporacyjnych, a coraz więcej większych firm przyłącza się. Co ciekawe, niektóre z tych przedsiębiorstw zaczęły jako programiści w naszej społeczności. To dało nam wiele pewności. Dopóki nadal budujemy świetne produkty, zapewniamy doskonałe usługi i pomagamy programistom rozwiązywać ich problemy, sukces przyjdzie naturalnie, czy to poprzez wzrost samodzielny, czy bezpośrednią sprzedaż dla przedsiębiorstw.
W końcu chodzi o rozwiązywanie problemów programistów, niezależnie od tego, czy to przez produkt, czy usługę. Zachowaj cierpliwość i skupienie, a wszystko ułoży się naturalnie.
Dziękuję za przeczytanie i czekam na wasze doświadczenia i przemyślenia, jeśli pracujecie nad czymś podobnym!