Case Studies

Beta testy jako kampania product launch platformy SaaS

beta testy

 

Z tego case study dowiesz się:

  • Na czym polegają beta testy produktu?
  • Po co je robić?
  • Jak się przygotować do udostępnienia użytkownikom produktu w wersji beta?
Klient:
polski start-up tworzący platformę SaaS
Cel:
zbadanie odbioru platformy SaaS wśród użytkowników, zebranie feedbacku, konfrontacja produktu z rynkiem
Okres współpracy:
2021
Liczba sprintów:
5
Liczba osób w projekcie:
3

Kontekst projektu

W 2020 roku przeprowadziliśmy proces product discovery dla klienta tworzącego platformę SaaS. Ustaliliśmy wtedy, jakie problemy i potrzeby mają użytkownicy narzędzi powiązanych z wiedzą domenową klienta. Dzięki temu wypracowaliśmy wytyczne na temat platformy, która mogłaby te problemy rozwiązać. Mówiąc najprościej: ustaliliśmy, jakiego produktu, który można wytworzyć, wykorzystując technologię klienta, potrzebują potencjalni odbiorcy. Przez kolejne miesiące zespół klienta pracował nad minimalną wersją produktu, która dostarczyłaby planowaną wartość (MVP). Po tym, jak narzędzie przeszło niezbędne testy, wprowadziliśmy je w fazę beta. 

Czym są beta testy produktu?

Testy produktu w wersji beta polegają na udostępnieniu na jakiś czas grupie użytkowników wczesnej wersji narzędzia. Tacy odbiorcy, nazywani wczesnymi użytkownikami (ang. early adopters), są gotowi na to, że produkt nie jest im prezentowany w ostatecznej wersji. I właśnie to jest dla nich wartością: fakt, że mogą przetestować narzędzie jako pierwsi. Beta testy służą zebraniu feedbacku od użytkowników i wprowadzeniu na tej podstawie w szybkim tempie zmian w produkcie. Takie modyfikacje mogą dotyczyć zarówno naprawy błędów czy wprowadzenia usprawnień, jak i zmiany modelu biznesowego. To kolejny etap walidacji pomysłu na produkt – tym razem bezpośrednio na rynku.

Beta testy mogą być otwarte lub zamknięte – otwarte to takie, do których może dołączyć każdy – oczywiście po rejestracji. Zamknięte testy oznaczają, że do grupy testerów mogą zostać przyjęci tylko nieliczni i wybrani – na przykład na podstawie punktacji czy czasu oczekiwania.

Testy, o których przeczytasz dalej, miały formułę otwartą.

Jakie były cele beta testów?

Przeprowadzane przez zespół Project: People beta testy miały dwa główne cele:

  • weryfikację produktową – ustalenie, czy forma produktu odpowiada przyjętym założeniom i realizuje cele projektowe;
  • weryfikację biznesową – ustalenie, czy opracowana po product discovery propozycja wartości jest wystarczająca do osiągnięcia Product-Market Fit.

Klientowi zależało ponadto na tym, by beta testy stanowiły formę wstępnego product launchu. Dlatego postanowiliśmy do naszych celów dopisać także aspekty związane bezpośrednio z kwestiami marketingowymi, czyli takie jak:

  • pozyskiwanie i aktywizacja użytkowników, którzy docelowo mają zostać klientami platformy;
  • budowa świadomości marki.

Pozostałymi celami były:

  • zebranie od użytkowników feedbacku na temat narzędzia,
  • jak najszybsze znalezienie jak największej liczby błędów w oprogramowaniu,
  • weryfikacja założeń komunikacji marketingowej.

Przygotowanie do beta testów

Na kilka tygodni przed oficjalnymi beta testami przystąpiliśmy do zaprojektowania tego procesu. 

Beta tester journey map

Na podstawie naszych benchmarków i znajomości grupy docelowej zaprojektowaliśmy ścieżkę beta testera. Zrobiliśmy to po to, by usprawnić pozyskiwanie wczesnych użytkowników skłonnych do testowania innowacji – oraz opracować plan komunikacji marketingowej i onboardingu w procesie beta testów. Ścieżka beta testera (beta tester journey map) pozwoliła nam też wskazać etapy, „gdzie coś może pójść nie tak”, a dana osoba – zniechęcić się do korzystania z platformy SaaS naszego klienta. Dzięki temu zawczasu zapobiegliśmy problemom, które dało się przewidzieć

beta tester journey map
Ścieżka beta testera

Elementy ścieżki testera, które uwzględniliśmy:

  • etapy procesu i akcje testera,
  • punkty styku z wspomnianym narzędziem SaaS,
  • czynniki sprzyjające pozytywnemu, negatywnemu i neutralnemu odbiorowi,
  • etapy, na których określone grupy użytkowników prawdopodobnie zrezygnują z udziału w beta testach,
  • rekomendowane zaangażowanie ze strony twórców narzędzia na każdym etapie (swego rodzaju skrócony service blueprint, czyli mówiąc najprościej: informacje o tym, co dzieje się po stronie organizatorów beta testów, kiedy potencjalny tester wykonuje określony krok, jakie działania są podejmowane „od kuchni”).

Propozycja wartości beta testów

Co zrobiliśmy, by zachęcić wczesnych użytkowników do udziału w beta testach? Wczesny dostęp, jak sama nazwa wskazuje, oznacza, że narzędzie nie jest jeszcze w pełni dopracowane. W jaki sposób przekonać więc użytkowników, jeśli nie możemy od razu pochwalić się pełną listą imponujących funkcjonalności?

Musieliśmy pokazać użytkownikom, jakie korzyści osiągną w zamian za dołączenie do testów i podzielenie się feedbackiem. Wskazaliśmy:

  • współudział w procesie budowania narzędzia, bezpośredni kontakt z twórcami,
  • przynależność do kameralnej społeczności osób nastawionych na innowacje i poszukujących nowych trendów,
  • możliwość networkingu i zdobycia nowej wiedzy (np. o prowadzeniu beta testów, o prowadzeniu prac developerskich lub szerzej – produktowych, zdobycie wiedzy o wczesnym etapie tworzenia produktów),
  • zniżkę na płatny pakiet narzędzia/darmowy dostęp do narzędzia przez określony czas po zakończeniu fazy beta testów, kiedy inni użytkownicy nie będą już mogli korzystać z narzędzia za darmo.

Automatyzacja komunikacji z testerami

Po zaprojektowaniu ogólnej ścieżki użytkownika i propozycji wartości mogliśmy przystąpić do szczegółowych planów. Jednym z nich był przepływ maili transakcyjnych, jakie powinien otrzymywać użytkownik.

beta testy onboarding
Schemat onboardingu w beta testach i automatycznej komunikacji mailowej z uczestnikami

Podobne plany i scenariusze umożliwiły nam bardzo szczegółowe rozpisanie wszystkich zadań, co nastąpiło w późniejszej, właściwej fazie beta testów. 

Ostatnimi zadaniami, które czekały na nas na etapie przygotowania do beta testów, były:

  • zaprojektowanie landing page’a, za pomocą którego użytkownicy mogli zapisać się na wczesny dostęp do produktu, 
  • ustalenie szczegółów dotyczących pozyskiwania feedbacku (o tym procesie piszemy szerzej dalej),
  • przetestowanie samych… beta testów, czyli alpha testy.

Alpha testy

Beta testy możemy uznać za rodzaj badania, więc konieczne było przetestowanie i zwalidowanie ich jako narzędzie badawcze. W tym celu zorganizowaliśmy w małej skali alpha testy. 10 użytkowników, których zaprosiliśmy do udziału, miało za zadanie zarejestrować się do udziału w beta testach na przygotowanym landing page’u. Dzięki temu sprawdziliśmy, czy wszystko jest zrozumiałe, czy nie występują żadne problemy techniczne. Pominięcie tego etapu i niewprowadzenie usprawnień związanych z onboardingiem w beta testach sprawiłoby, że nawet bardzo zaciekawione nowym produktem osoby mogłyby zrezygnować z testowania go.

Faza właściwych beta testów

Od fazy alpha i opracowania planu testów do uruchomienia wczesnej wersji narzędzia minęło jeszcze kilka tygodni. W tym czasie zespół produktowy rozwijał produkt i przeprowadzał testy obciążeniowe (ang. load tests). Dzięki nim ustalono, jaka maksymalna liczba użytkowników może korzystać z narzędzia w tym samym czasie. Kiedy zespół osiągnął satysfakcjonujący wynik, mogliśmy wystartować z beta testami.

Sprint 1: kick-off oraz plan taktyczny etapu kampanii

Każdy projekt zaczynamy od warsztatu kick-offowego, podczas którego:

  • wspólnie z klientem omawiamy cele naszych działań i wzajemne oczekiwania;
  • analizujemy kompetencje oraz zakres obowiązków każdego członka zespołu;
  • ustalamy sposób komunikacji odpowiadający wszystkim zaangażowanym w projekt (w tym przypadku były to: bieżąca komunikacja i codzienny status podawany na kanale na Slacku, cotygodniowe godzinne spotkanie);
  • podejmujemy wstępne decyzje związane z kolejnością najbliższych działań.

Te beta testy nie stanowiły wyjątku. Choć pracowaliśmy już wcześniej z tym klientem, zmiana zakresu współpracy i pojawienie się nowych osób w naszym zespole projektowym były wystarczającymi powodami do przeprowadzenia takich warsztatów po raz drugi. 

Team Canvas

W czasie warsztatu kick-offowego tradycyjnie skorzystaliśmy z Miro, które posłużyło nam do zdalnej współpracy przy uzupełnianiu naszego Team Canvas.

Team Canvas

Takie spotkanie dało nam solidną podstawę do dalszych prac. W tym przypadku był to etap szczegółowego planowania i podziału zadań na bazie wypracowanej wcześniej ścieżki wędrówki beta testera. 

Dywersyfikacja kanałów

Ważnym założeniem, które przyjęliśmy, była jak największa dywersyfikacja kanałów i sposobów pozyskiwania beta testerów. Dlaczego? Byliśmy na początku procesu i nie mogliśmy przewidzieć odpowiedzi odbiorców na zaproszenie do udziału w beta testach. Z jednej strony chcieliśmy napędzać jak największy ruch, a z drugiej zadbać, by każdy zdobyty w ten sposób beta tester „zaraził” ciekawością do naszego narzędzia innych. Stąd wykorzystywaliśmy w komunikacji z testerami kontakty pozyskane w fazie product discovery, kanały klienta, kanały partnerów, social media, newsletter, działania PR-owe. O szczegółach tych działań piszemy dalej.

Plan taktyczny

Narzędziem, które pomagało nam zarządzać wszystkimi zadaniami, był plan taktyczny. To dokument, w który spisaliśmy: 

  • poszczególne zadania,
  • ich kategorię,
  • etap beta testów, do którego się odnoszą,
  • ostateczny termin,
  • osoby odpowiedzialne za realizację zadania,
  • oraz status – czy zadanie zostało wykonane, czy też jeszcze nie.
Plan taktyczny

Wśród zadań w planie taktycznym naszych beta testów znalazły się więc m.in.:

  • stworzenie niezbędnego contentu (postów na profile w SM, treści do maili transakcyjnych, treści do reklam, grafik do reklam itd.),
  • prace researcherskie (przykładowo: utworzenie bazy czasopism potencjalnie zainteresowanych publikacją notek prasowych lub przygotowaniem dłuższych treści),
  • prace techniczne (konfiguracja systemu marketing automation, przygotowanie kampanii reklamowych opartych o wybrane systemy, jak np. Facebook Ads czy Google Ads),
  • prace analityczne i automatyzujące (związane ze zliczaniem poszczególnych metryk, co przyspiesza i ułatwia bieżącą optymalizację kampanii),
  • inne prace organizacyjne (np. dopracowanie sposobu agregowania i przetwarzania feedbacku).

Priorytetyzacja zadań

Po tak szczegółowym rozpisaniu planu nie pozostało nam nic innego, jak odpowiednio priorytetyzować działania. Podzieliliśmy więc je na takie kategorie:

  • jednorazowe zadania, które powinny być wykonane przed startem kampanii, a które są niezbędne, jeśli chcemy osiągnąć cele projektu,
  • jednorazowe zadania, które mogą być wykonane w trakcie trwania kampanii i które wniosą dodatkową wartość dla klienta
  • zadania ciągłe, konieczne do realizacji w trakcie kampanii.

W sytuacjach, kiedy musieliśmy dokonywać wyboru między zadaniami, wspomagaliśmy się matrycą zależności wysiłku od przewidywanego wyniku

Warto dodać, że bieżąca komunikacja i wymiana informacji na temat postępu prac były gwarancją tego, że nie poświęcamy czasu na zadania mało istotne oraz że nieustannie popychamy prace do przodu.

Zarządzanie feedbackiem

Na tym etapie zaktualizowaliśmy też założenia dotyczące zarządzania feedbackiem, które zostały wypracowane w fazie alpha testów.

Informację zwrotną zdecydowaliśmy się zbierać od beta testerów następująco:

  • bezpośrednio w narzędziu za pomocą wtyczki Usersnap, która przenosiła komentarze testerów i wykonane przez nich screeny do Asany, w której kategoryzowaliśmy feedback i centralizowaliśmy wszystkie informacje na jego temat,
  • poprzez formularz zgłoszeniowy w Google Forms, do którego dostęp testerzy otrzymywali w jednym z maili w trakcie onboardingu do bety i narzędzia,
  • poprzez zamkniętą grupę na Facebooku, gdzie mieliśmy aktywnie animować grupę wczesnych użytkowników i wchodzić z nimi w interakcję, budować społeczność,
  • poprzez kanały prywatne, jeśli beta testerzy decydowali się dzielić feedbackiem tą drogą.

Istotna była też kategoryzacja oraz ścieżka przetwarzania feedbacku. W końcu zależało nam na tym, by zespół produktowy otrzymywał odfiltrowane i zwalidowane informacje na temat tego, jakie zmiany należy wprowadzić w narzędziu. Stąd kategoryzacja feedbacku na:

  • błędy/bugi,
  • feedback dotyczący UX/UI,
  • sugestie związane z rozwojem produktu i kolejnymi funkcjonalnościami.

Taka kategoryzacja leżała po stronie Project: People. Natomiast priorytetyzacja feedbacku zgodnie z roadmapą produktu była po stronie Product Ownera.

Sprint 2: start kampanii

Zmasowane uderzenie i wykorzystanie efektu świeżości

Pierwsze wrażenie można zrobić tylko raz – i nie inaczej sprawy mają się, gdy wychodzimy do użytkowników z produktem. Stąd nasze działania już od samego początku były zintensyfikowane i zakładały jak najszybsze dotarcie do jak największej grupy przychylnych odbiorców.

Aby to osiągnąć, zaczęliśmy od mailingu do grup odbiorców, którzy uczestniczyli w procesie product discovery, na przykład prowadzonych przez nas warsztatach, oraz w alpha testach. Skontaktowaliśmy się też z użytkownikami, którzy zapisali się na powiadomienie o beta testach na landing page’u, który był elementem eksperymentu we wcześniejszej fazie product discovery.

Wykorzystaliśmy zasięgi zbudowane przez klienta oraz skorzystaliśmy z siły rekomendacji jego partnerów. Czerpaliśmy też z kanałów personal brandingowych osób zaanganżowanych w tworzenie produktu. Dzięki aktywnemu PR-owi pozyskaliśmy też publikacje w dużych mediach branżowych.

Jednak najważniejsze na tym etapie było zaangażowanie samych beta testerów, którzy dzielili się wrażeniami z korzystania z narzędzia w swoich kanałach na mediach społecznościowych i tym samym przyciągali innych wczesnych użytkowników. 

Dodatkowo docieraliśmy do testerów dzięki płatnym kampaniom Google Ads i Facebook Ads. 

Testy kreacji reklamowych

Podjęte w tym czasie działania płatne były traktowane przez nas jako dodatkowe źródło pozyskiwania beta testerów. Chcieliśmy zdobyć pierwsze informacje na temat skuteczności poszczególnych kreacji oraz tego, jak zachowują się poszczególne grupy docelowe.

W przypadku Facebooka prowadziliśmy równolegle 4 eksperymenty związane z grupami docelowymi takimi jak:

  • osoby zainteresowane nowymi technologiami z branż IT/HR/konsultacje – była to najliczniejsza grupa;
  • wcześni użytkownicy, czyli osoby, które Facebook identyfikuje jako chętne do korzystania z nowych rozwiązań / nowinek technicznych i którym sam Facebook wyświetla w formie testów A/B nowe rozwiązania w obrębie swojej platformy. Tę grupę zawęziliśmy dodatkowo do osób zainteresowanych tematyką startupową i będących na stanowisku CEO;
  • lookalike (grupa podobnych odbiorców definiowanych na podstawie zbliżonych zainteresowań i zachowań) osób, które wypełniły formularz na landing page;
  • remarketing do osób, które były na landing page, na którym można było dokonać zapisu do beta testów, ale nie przeszły stamtąd do samego narzędzia.

Dzięki temu mogliśmy też ustalić, która z tych grup najchętniej zostaje beta testerami i w zależności od wyniku modyfikować komunikację.

Kolejne tygodnie upłynęły nam pod znakiem regularnej obsługi beta testów. Składały się na nią:

  • nieustanna komunikacja z testerami – za pomocą mediów społecznościowych oraz mailingu,
  • regularne zarządzanie feedbackiem,
  • tworzenie contentu do publikacji w różnorodnych kanałach,
  • eksperymentowanie z nowymi formami zaangażowania testerów.

Pod względem formalnym ten czas można byłoby przyrównać do marketingowej obsługi abonamentowej, która jest jednym z elementów naszej oferty. 

Angażowanie społeczności

Członków zamkniętej grupy beta testerów animowaliśmy na kilka sposobów. Przede wszystkim regularnie zachęcaliśmy ich do dzielenia się opinią, pytając o doświadczenia z konkretnymi funkcjami narzędzia. Komentarzy nie pozostawialiśmy bez odpowiedzi i wchodziliśmy z w dłuższe rozmowy ze wczesnymi użytkownikami. Staraliśmy się im pokazać, jak bardzo doceniamy ich wkład w rozwój narzędzia.

Inicjowaliśmy dyskusje na temat ich doświadczeń związanych z domeną klienta – pracą zdalną. Jako że beta testy trwały w czasie kolejnej fali pandemii Covid-19, wniosków nie brakowało. 

A ponieważ społeczność rodzi się też wokół wspólnego poczucia humoru, dzieliliśmy się z testerami gifami i memami dopasowanymi oczywiście do stylu komunikacji marki.

Regularny kontakt z zespołem developerów

Jednak jeden z najważniejszych elementów komunikacji w czasie beta testów był możliwy tylko dzięki regularnemu kontaktowi z zespołem developerów rozwijających produkt. Informacje o kolejnych releasach nowych funkcji, wprowadzanych poprawkach, którymi dzielili się z nami, przekazywaliśmy beta testerom. Dzięki temu mogliśmy krok po kroku pokazywać im, jaki jest ich realny wpływ na narzędzie. Gdybyśmy pominęli ten element, nasze beta testy mogłyby stać się dla nich bezwartościowe.

Jakie były wnioski i następne kroki po beta testach?

W toku beta testów pozyskaliśmy feedback wskazujący na to, że:

  • propozycja wartości obiecywana przez narzędzie jest dla użytkowników atrakcyjna, nie znajdują jej jednak we wczesnej wersji produktu,
  • użytkownicy chętnie korzystają z narzędzia po raz pierwszy, testują je, ale później do niego nie wracają,
  • nie wszystkie elementy narzędzia są dla użytkowników intuicyjne. 

Brakowało nam jednak odpowiedzi na pytanie: dlaczego tak jest? Dlatego zdecydowaliśmy się na zadaniowe i moderowane testy użyteczności, dzięki którym zdobyliśmy pogłębione odpowiedzi na te pytania bezpośrednio od użytkowników. Opowiemy o nich w kolejnym case study.

200

beta testerów

4

kanały pozyskiwania opinii

500

otrzymanych zgłoszeń z feedbacku

Narzędzia wykorzystane w projekcie

  • Beta tester journey map
  • Team Canvas
  • Mailchimp
  • Usersnap
  • Asana
  • Miro

Case study to za mało?

Chcesz poznać cały proces i dowiedzieć się, jak mógłby wyglądać w Twojej organizacji?

Umów się na bezpłatną konsultację

Zespół projektowy, czyli kto za co odpowiadał

Autor Case Study

Sylwia Paszyna Lean Marketing Consultant & Strategist
Język nie ma przed nią tajemnic. Pracuje z tekstem pod różnymi kątami, zarówno projektując komunikację, jak i redagując i poprawiając treści. Współpracowała m.in. z wydawnictwem Czarnym. Absolwentka edytorstwa na Uniwersytecie Jagiellońskim i UX & Business Design na Wyższej Szkole Europejskiej im. Józefa Tischnera.

Rozwija wiedzę w zakresie badań UX, by u źródła poznawać potrzeby wyrażające się w języku. Projektuje strategie marketingowe, przeprowadza badania i analizy. Wszystkie te doświadczenia wykorzystuje, by tworzyć lepszą komunikację.

Pozostali członkowie zespołu

Kamil Cupial Lean Marketing Consultant & Strategist
Dotychczasowe doświadczenie zbierał w organizacjach NGO, start-upach i agencjach kreatywnych, dzięki czemu z łatwością potrafi zrozumieć wiele - często pozornie sprzecznych - perspektyw. W Project: People pomaga klientom znaleźć swoje miejsce na rynku poprzez kreowanie i wdrażanie strategii marketingowych, biznesowych i produktowych. Uwielbia nieszablonowe rozwiązania, eksperymenty i nieustające testy.

W swoim życiu zawodowym koordynował prace zespołów zarówno kreatywnych, jak i technologicznych. I w tym właśnie dostrzega największą wartość: w holistycznym spojrzeniu na sytuację, na organizację, na człowieka.

Wolne chwile spędza najchętniej na świeżym powietrzu, z książką w jednej ręce i parującą yerba mate w drugiej. Umiarkowany kontestator, dla którego nie istnieje status quo. Wie, że zawsze można zrobić coś inaczej (lepiej?), ucząc się nowego. Wierzy, że świat rzadko jest czarno-biały - Kamil dostrzega w nim na co dzień setki odcieni szarości.
Katarzyna Harmata Lean Marketing Manager & Strategist
Od lat z powodzeniem łączy marketing i biznes. Obecnie specjalizuje się w zarządzaniu projektami i Content Marketingu. W swoim dorobku ma już zarządzanie kilkunastoosobowym zespołem marketingowym, kreowanie cyklu wydarzeń biznesowych, współtworzenie firmy i kierowanie nią.

Pomaga firmom w odnalezieniu własnego „ja” w biznesie i komunikowaniu tego na zewnątrz (strategia marketingowa & personal branding).

Zaangażowana w liczne działania społecznościowe. Jest certyfikowanym Trenerem Biznesu. Prowadzi warsztaty z pogranicza strategii i marketingu. Autorka tekstów dla portali branżowych, m.in. Nowy Marketing, Marketing w Praktyce, E-commerce & Digital Marketing.