+25 do ekwipunku warsztatowca, czyli lista 25 narzędzi do prowadzenia warsztatów zdalnie

Zamów e-booka

Bogusz Pękalski – sekret udanych beta testów. Project: People Podcast 21

Project: People Podcast

Sylwia Paszyna i Bogusz Pękalski rozmawiają na temat sekretu udanych beta testów, czyli końcowej fazie przed wypuszczeniem produktu w pełnej formie. Mówią o tym, kiedy warto je wdrożyć, a w przypadku jakich działań nie mają zastosowania. Rozmawiają na temat budowanie zainteresowania produktem i tworzeniu zaangażowanej społeczności, która jako pierwsza będzie chciała sprawdzić dany produkt.

Słuchając tego odcinka dowiesz się:

  • czym są beta testy;
  • kto powinien się nimi zainteresować;
  • jak je zaplanować i przygotować;
  • co zrobić, żeby beta testy przyniosły wartość zarówno właścicielom produktu, jak i pierwszym użytkownikom;
  • jakie wyzwania mogą się pojawić w czasie beta testów;
  • jakie błędy można popełnić;
  • jaka jest rola społeczności w przebiegu beta testów.

Zapisz się do naszego newslettera i pobierz checklistę z pytaniami do tworzenia beta testów.

Daj znać, pod jakim adresem możemy się z Tobą kontaktować!



    Zgadzam się na przetwarzanie moich danych osobowych przez Project: People Sp. z o.o. w celu komunikacji marketingowej, a tym samym wysyłania mi newslettera, informacji o usługach, promocjach lub nowościach zgodnie z Polityką prywatności.

     

    Odcinek prowadzi:

    Sylwia Paszyna

    Gość odcinka:

    Bogusz Pękalski


    Słuchaj też na:

     

    Transkrypcja

    Sylwia: Bogusz, co Twoim zdaniem jest sekretem udanych beta testów?

     

    Bogusz: Budowa społeczności, bazy pierwszych klientów i załatanie naszego produktu, poprzez działania aktywnych końcowych użytkowników.

     

    Sylwia: Właśnie o tym będziemy dzisiaj rozmawiać. 

    Cześć, słuchasz Project: People Podcast, czyli audycji biznesowej w której spotykają się stratedzy i praktycy, omawiając zagadnienia związane m.in. z modelami biznesowymi. 

    Jako leanowa agencja strategiczna, z ponad czteroletnim doświadczeniem na rynku polskim i zagranicznym, zajmujemy się tworzeniem strategii biznesowych i marketingowych, badaniami oraz z designem. 

    Do każdego odcinka przygotowujemy materiały dodatkowe, które są uzupełnieniem tej rozmowy. Wystarczy, że wpiszesz w pasku przeglądarki projectpeople.pl/21, tam znajdziesz transkrypcję odcinka, oraz specjalną listę, dzięki której samodzielnie zaplanujesz beta testy.

     

    Sylwia: Cześć, z tej strony Sylwia Paszyna, w Project: People jestem konsultantką marketingową i dzisiaj porozmawiam z Boguszem Pękalskim, przedsiębiorcą, programistą i podcasterem ze Startup My Way. Bogusz, miło Cię poznać.

     

    Bogusz: Dziękuję serdecznie za zaproszenie.

     

    Sylwia: Dzisiaj opowiemy o tym, czym są beta testy, kto powinien się nimi zainteresować, jak je zaplanować i przygotować. Zastanowimy się też, co zrobić, żeby beta testy przyniosły wartość zarówno właścicielom produktu, jak i pierwszym użytkownikom. Będziemy też mówić o tym, jakie wyzwania mogą się pojawić w czasie beta testów i jakie błędy można popełnić, a także jaka jest rola społeczności w przebiegu beta testów.

     

    To sporo pytań, ale zanim zaczniemy, przedstaw się naszym słuchaczom.

     

    Bogusz: Cześć, nazywam się Bogusz Pękalski. Od młodych lat byłem zainteresowany budowaniem swoich produktów i programowaniem i tak to potem szło. Były studia programistyczne, informatyczne, a potem praca jako etatowy programista. Zawsze poza etatem budowałem swoje produkty i nadszedł taki czas, że udało mi się odejść z etatu, budując swoją pierwszą aplikację SaaS, Polisa w Chmurze.

    To taki system do obsługi agentów i agencji ubezpieczeniowych, który postawiliśmy w chmurze. Następnie zająłem się też budową kursów i edukacji online.

    A obecnie dużo czasu poświęcam na mój nowy projekt, AchieveGuru.com, który ma służyć do projektowania swojego życia, to również jest forma produktu cyfrowego, jako aplikacji.

     

    Sylwia Co łączy Ciebie i Project: People? Możemy powiedzieć, że efektywność i beta testy. Bo my prowadzimy beta testy narzędzia do efektywnych wideokonferencji, Confly, a Ty swojego narzędzia, AchieveGuru, które wspomaga osiąganie celów. Dzięki temu możemy zderzyć różne spojrzenia na beta testy. Na czym w AchieveGuru, polegają beta testy i czym są dla Ciebie?

     

    Bogusz: Chciałbym rozróżnić produkty cyfrowe. My się będziemy zajmowali dzisiaj aplikacjami, jak AchieveGuru, czy Confly.

    Zacznijmy od tyłu, czyli kiedy nie warto robić beta testów? Ponieważ moim drugim obszarem działań jest budowa kursów online, to tam beta testy nie są potrzebne.

    Po prostu budujemy coś, robimy przedsprzedaż i sprzedajemy. Oczywiście warto później ten produkt rozwijać i ulepszać, ale beta testy, o których porozmawiamy, najlepiej działają w aplikacjach, czy startupach technologicznych, w których cały czas musimy otrzymywać feedback od użytkowników.

    Zawsze, kiedy wypuszczam nowy produkt/aplikację, staram się dostarczać wartość i funkcjonalność dla użytkownika. Robiłem tak z Polisą w Chmurze i teraz, z AchieveGuru. Już od pierwszego dnia informowaliśmy, że budujemy produkt, a jeszcze nie mieliśmy ceny, można się było się zapisać na listę oczekujących. Jest to popularny zabieg, bo kiedy planujemy coś wypuścić, to warto już zgromadzić społeczność, która może być darmowymi konsultanta.

    Testy beta to końcowa faza przed wypuszczeniem produktu w pełnej formie. 

    Możemy sobie wziąć na przykład np. Gmaila, który był w fazie beta testów przez jakieś 5 lat. Warto zderzać produkt z użytkownikami od fazy MVP, czyli tzw. alpha testów. Beta testy są wtedy, kiedy produkt jest prawie gotowy, ale jeszcze występują jakieś błędy.

    W AchieveGuru jesteśmy w fazie alpha i potrafią pojawić się dość krytyczne błędy, pewnych rozwiązań nie ma. Ale warto już od tego momentu skupić się na pokazywaniu produktu użytkownikom. 

    Tylko trzeba to zrobić sprytnie. Czyli zbudować zainteresowanie tematem, u mnie to osiąganie celów i budowanie społeczności, która będzie chciała zostać pierwszym użytkownikiem, którego problem zostanie rozwiązany. Obecnie w AchieveGuru jest to 100 osób, które dostały dostęp do pierwszej wersji niedoskonałego systemu i z którą mogę konsultować rozwój produktu.

     

    Co ważne, to nie jest grupa randomowych testerów, Oni faktycznie chcą być wczesnymi użytkownikami i rozwiązać swój problem poprzez nasz produkt. Czują się wyróżnieni i chętnie pomagają w rozwoju funkcjonalności.

     

    Sylwia: Wspomniałeś o niedoskonałościach produktu. Wśród osób, które wypuszczają swoje produkty do beta testów, mogą się pojawić takie obawy, że to za wcześnie, że nieidealnie. A jakie Ty masz podejście, kiedy jest dobry moment?

     

    Bogusz: Jest takie słynne powiedzenie: „Jeżeli nie jesteś zawstydzony pierwszą wersją swojego produktu, wypuściłeś go zbyt późno” (Reid Hoffman). Jestem podobnego zdania. Dodam, że nie warto wypuszczać czegoś, co nie działa. 

    Warto wypuścić produkt minimalny, MVP, który wywoła jakąś radość użytkownika pomimo błędów. UX i UI możemy zrobić dzisiaj małym kosztem, a dostarczymy wartość biznesową i użytkownik już wie, co go czeka. 

    Taką drogą idziemy z AchieveGuru. Użytkownicy wchodzą i jeszcze wiele się nie da tam zrobić, ale jest ładne i działa szybko.

    Nie bójmy się, że użytkownicy powiedzą „beznadziejne i nigdy nie wrócę”. Wyobraźmy sobie to na przykładzie dziurawego wiadra, przez które przepuszczamy nasz produkt. Ono ma różne luki i błędy. Użytkownicy wchodzą i odchodzą, ale widzimy te dziury i możemy je załatać, aż użytkownicy zostaną.

    Jak będziemy za długo zwlekać z pokazaniem produktu, to nie będziemy mieli tej fazy próbnej i użytkownicy wyczują, że coś jest nie w porządku, a też stracimy dużo czasu. Im szybciej możesz wypuścić MVP dla użytkownika, tym lepiej. Od tego warto zacząć budowę produktu.

     

    Sylwia: Wspomniałeś o użytkownikach, którzy będą cierpliwi wobec produktu i jego niedoskonałości. Myślę, że ta cierpliwość zależ od tego, do kogo się skierujemy z komunikatami o testach produktu. Jak wybrać taką grupę do testów?

     

    Bogusz: Jestem zdania, że Early Adopters wybierają się sami. Jak ja to zrobiłem? Otworzyłem grupę na Facebooku związaną z osiąganiem celów i produktywnością. Zbudowałem bazę kilkuset osób i poinformowałem, że budujemy aplikację i jest do niej dostęp, tylko trzeba się zgłosić. Ludzie pisali sami w komentarzach. Ja nikogo nie wybrałem, tylko odesłałem do zamkniętej grupy dla wczesnych użytkowników.

    Czuli się wyróżnieni, chcieli dawać feedback, lub dawali go, kiedy poprosiłem.

     

    Te osoby się znajdą, tylko musimy o tym głośno powiedzieć wśród ludzi, którzy się tym tematem interesują, lub mają ten problem. Ważnym krokiem jest stworzenie takiej wspólnej przestrzeni dla osób skupionych wokół tej idei, z której utworzy się naturalna społeczność beta testerów.

    Warto mieć kanał dotarcia do takich „idealnych klientów”. Ja na przykład prowadzę swój podcast, mejling i udzielam się w społecznościach, gromadzę wokół siebie ludzi z IT. Często są to programiści, którzy chcą budować jakieś własne produkty, aplikacje, chcą odejść z etatu. To są osoby, które bardzo przypominają mnie, jesteśmy na podobnej ścieżce, dlatego jestem w stanie budować dla nich produkty.

    Na pewno warto się skupić na konkretnej niszy. Jeżeli budujemy jakiś produkt, to ten produkt musi rozwiązywać realny problem jakiejś grupy ludzi. W moim przypadku to jest osiąganie celów.

    Założyłem grupę, zaprosiłem znajomych, wystąpiłem w podcastach, napisałem teksty. Ludzie zaczęli się pojawiać. Ja też animowałem tę grupę, np. poprzez cykl postów AchieveMeet Monday, żeby się podzielić najważniejszą rzeczą, którą chcemy zrobić w tym tygodniu, pytałem ludzi o ich nawyki, angażowałem ich do działania, informowałem o budowie aplikacji, o czym ona będzie, pytałem, czy korzystają z podobnych aplikacji. Trochę treści ogólnych, a trochę o produkcie. Te osoby reagowały i były zainteresowane. Jak poinformowałem o beta testach, to część osób była gotowa od razu dołączyć.

    Dowiadujemy się z tego, że warto budować społeczność i zainteresowanie produktem w danej niszy, żebyśmy mieli grupę, która na ten produkt czeka.

     

    Sylwia: Z tej grupy wyłoniłeś beta testerów. Wartość produktu to jedno, a dodatkową wartością może być sam udział w beta testach. Jak wypracować wartość dla beta testerów, Early Adopterów i przekonać ich do tego przedsięwzięcia?

     

    Bogusz: Będą pierwsi na naszej platformie, więc zadziała jakaś reguła niedostępności. Poczucie wyjątkowości i realnego wpływu na wygląd produktu. Dzięki uwagom produkt będzie lepiej dostosowany do ich potrzeb. 

    Dodatkową wartością jest bycie częścią społeczności, która jest interesująca i skupia się na tej niszy. Poczucie misji i wspólnego celu łączy ludzi i pomaga w rozwoju swojego produktu. Warto oczywiście podziękować swoim beta testerom, za ich czas i wkład w budowę produktu.

     

    Sylwia: Tutaj myślę, że działa ta waluta społeczna, przynależność i możliwość pochwalenia się przed innymi. Czy to się sprawdzi przy każdym produkcie? Czy są takie produkty, w których ta reguła niedostępności, np. jak w przypadku Clubhouse, nie zadziała?

     

    Bogusz: Ciężko tak generalizować. W większości przypadków testowania aplikacji, to zadziała. To można zobaczyć na przykładzie starej, polskiej aplikacji, grono.net, które miało taki mechanizm dołączenia na zaproszenia i w momencie, kiedy ten mechanizm został wyłączony, okazało się, że tych użytkowników przychodzi mniej niż wcześniej, a wcześniej ta dostępność była limitowana.

    Reguła niedostępności działa w większości przypadków, jeżeli jest to produkt kierowany do sieci.

    A jeżeli kierujemy system do klientów biznesowych, to działa to zdecydowanie gorzej. Jeżeli prosimy użytkownika, żeby zaprosił 3 inne osoby, to w biznesie się za bardzo nie sprawdza, ale w B2C jak najbardziej.

    Beta testy są zamknięte i limitowane, żeby były tam tylko te osoby, które bardzo chcą z niej skorzystać. Łatwiej z nimi pracować i rozwiązywać błędy.

     

    Sylwia: Wspomniałeś o grupie docelowej produktu, a także, że do grupy B2B nie wybierałbyś zamkniętych beta testów.

    Zapytałam o to, bo w Confly zrobiliśmy przeciwnie. Każdy mógł dołączyć do beta testów, kto zarejestrował się na stronie narzędzia. Doszliśmy do wniosku, że konkurencyjność podobnych rozwiązań jest tak duża, że zamykanie zadziała na naszą niekorzyść.

    Zależało nam, żeby dotrzeć do szerszego grona odbiorców, a tym, czym ich przyciągamy, to zupełnie inne spojrzenie na samą produktywność spotkań. Czyli otwieramy beta testy i dajemy wartość. Ale powiedz, tak od strony technicznej, jak zaplanować beta testy?

     

    Bogusz: U nas to działa tak, że od samego początku jest prosta strona landing page, na której mamy możliwość zostawienia maila. To buduje bazę tych wczesnych użytkowników, którzy są zainteresowani dostępem do testów. Oczywiście zacząłem zbierać chętne osoby na grupach facebookowych, była grupa ogólna, później dedykowana, a beta testerzy byli wpuszczani na platformę za pomocą specjalnego linka, w którym był kod zaproszenia, a także za pomocą strony. 

    Kolejną rzeczą jest zbieranie feedbacku, tutaj dobrze działa nasza grupa facebookowa, na której pytam o opinie. Oczywiście, nie każdy siedzi na Facebooku, ale mamy adres mailowy, na który możemy wysłać prośbę o feedback.

     

    Ostatnio właśnie poruszyliśmy wątek, jak w ogóle stwierdzić, czy idziemy w dobrym kierunku. Zbudowaliśmy podstawowy produkt, zebraliśmy beta testerów, ale czy w ogóle ma to sens? Więc okazuje się, że im więcej użytkownicy będą narzekać, tym lepiej, bo oznacza to, że z niego korzystają. Najgorszy byłby brak feedbacku, bo produkt byłby niedopasowany do ich potrzeb. Jeżeli użytkownicy są aktywni, to dobry znak.

    Kolejnym krokiem jest forma różnych ankiet. Możemy poprosić te osoby o głosowanie na funkcję, która jest dla nich istotna.

    Możemy zapytać o cennik. Możemy też spojrzeć na pewne funkcje, które są szczególnie często używane przez naszych wczesnych użytkowników w aplikacji i uczynić je płatnymi. Z tych pierwszych użytkowników możemy zbudować tak zwany model wartości, Value Metric, czyli za co użytkownicy będą skłonni płacić w naszej aplikacji, bo jeżeli użytkownicy z czegoś korzystają aktywnie, to warto taką rzecz ograniczyć, jeżeli wybieramy model subskrypcyjnych i chcemy na tym produkcie zarabiać. Beta testy dobrze to zweryfikują. 

     

    Sylwia: Ja opowiem o tym, jak rozwiązaliśmy kwestię kanałów pozyskiwania feedbacków w Confly. Postawiliśmy na trzy kanały. Jednym jest grupa na Facebooku, drugim ankieta udostępniana w mailingu on-boardingowym dla narzędzia, a trzecie, najbardziej efektywne narzędzie, to jest wtyczka bezpośrednio w narzędziu, Usersnap. Użytkownicy mogą nam zgłosić, które konkretny element chcą ocenić. 

    Możemy taki formularz zgłaszania spersonalizować, czy to zgłoszenie to sugestia, czy bug, a potem wrócić do tych użytkowników, jeśli wyrażą zgodę.

    To jest też kolejny sposób, żeby zaopiekować się feedbackiem, bo beta testerzy poświęcają o wiele więcej uwagi naszemu produktowi, niż zwykli użytkownicy. Powinniśmy ich za to doceniać, dziękować za czas i traktować ich feedback, jako prezent. 

    To źle, kiedy nie mamy żadnego feedbacku, ale czasami zgłoszeń może być bardzo dużo i wtedy trzeba priorytetyzować, od czego zacząć. 

    Wspomniałeś, że można to rozwiązać np. za pomocą ankiety, która wskazuje, co jest najważniejsze dla naszych użytkowników. Czy masz jeszcze jakieś swoje inne sposoby jak wprowadzać zmiany? 

     

    Bogusz: Podstawą budowy dobrych aplikacji jest proces, przez który przechodzi nasz użytkownik. Użytkownik jest miejscu A, a chce być w miejscu B. I nasza aplikacja go tam prowadzi. Przykładowo, użytkownik chce zrobić Live Stream na YouTube’a Facebooka i LinkedIna, ale nie umie. No i jest w miejscu “nie umiem robić Live’a”. Miejsce docelowe to “robię Live’a”. Korzystam z narzędzia Streamyard  i przechodzę ten proces, robię liva. Czyli w bardzo szybki sposób przechodzę z miejsca A, do miejsca B. 

    W każdej aplikacji warto wyróżnić, jaki proces przechodzimy i go opisać. Wszystko, co powinno być priorytetem, to jest ulepszanie tego procesu i dochodzenia do celu, wartości, przy jak najmniejszej liczbie kliknięć.

    Zacznijmy więc od ulepszania procesu corowego, a resztę odłóżmy na później. Ten problem mieliśmy w Polisie w Chmurze. Często użytkownicy mówią “zróbcie tutaj przycisk czerwony, na środku, niech robi to i to”. Ale wtedy trzeba zapytać, jaki problem ma rozwiązywać? Bo potem okazuje się, że to nie jest potrzebne, tylko użytkownikowi się wydawało.

    My, twórcy aplikacji, musimy znaleźć problem i szybkie, proste rozwiązanie.  Często zgłoszenia użytkowników dotyczą umiejscowienia konkretnych funkcji, a to jest naszym zadaniem.

     

    Sylwia: Przekładanie feedbacku 1:1, bez interpretacji i weryfikacji, to jeden z wielu błędów, które można popełnić. Jakich jeszcze błędów radziłbyś unikać?

     

    Bogusz: Kierowania beta testów do złej grupy docelowej. Jeżeli te osoby nie są zainteresowane tym, co mamy do pokazania, to mamy testerów, którzy nie będą naszymi końcowym klientami. Zapraszanie swoich znajomych do beta testów też może się nie sprawdzić, oni zawsze powiedzą miłe słowa. 

    Warto też rozróżnić takich amatorskich testerów, od zawodowych, którzy szukają błędów w aplikacji. Oni zajdą pewne rzeczy, których nie znajdą inni, ale najważniejsi są ci testerzy, które będą finalnie korzystać z projektu.

    Jeżeli mamy dobrze dobraną grupę docelową, nawet 5 osób, to warto utrzymywać z nim kontakt, rozmawiać, jak używają aplikacji, jak ona działa. Nie bójmy się tego robić, to działa. 

     

    Sylwia: Ja dodam od siebie taki błęd w beta testach, czyli bardzo emocjonalna, personalna reakcja na rozwojowy feedback, gdzie ktoś wskazał jakiś błąd. Bo jeśli damy odczuć naszą personalną reakcję na wytknięcie błędu, to beta testerzy zaczną się bać zgłaszać nam prawdziwe usterki i stracimy ich na tym etapie. 

    Dlatego zastanawiam się, czy jest tu istotne, kto takie beta testy przeprowadza? I jak Ty się czujesz, odbierając feedback na temat AchieveGuru?

     

    Bogusz: Często jako twórcy mamy jakąś wizję w głowie, która nie jest do końca zgodna z rzeczywistością. To, co wymyśliliśmy, nie daje użytkownikom tej wartości. 

    Tutaj jest dylemat innowatora. Czasami rzeczy, które są na początku odrzucane, potem okazują się przełomem w technologii. Tak było ze Snapchatem, którego twórca wymyślił zdjęcia, które znikają po dziesięciu sekundach. Ludzie się po prostu pukali w głowę, bardzo doświadczeni przedsiębiorcy i inwestorzy też. A potem z aplikacji korzystały setki tysięcy nastolatków, Instagram i inne platformy wprowadziły dokładnie to samo. Więc mamy dylemat, czy faktycznie ci pierwsi użytkownicy mają rację. 

    A kto powinien przeprowadzać te beta testy, żeby nie było czynnika emocjonalnego? Czynnik emocjonalny zawsze jakiś będzie. 

    Warto słuchać użytkowników i nie krytykować. Często ich opinie wynikają z  niezrozumienia pewnych procesów w naszym produkcie. A to z kolei oznacza, że User Experience jest zbyt skomplikowane dla naszego użytkownika. Nie warto się złościć, każdy użytkownik ma swoje doświadczenia i inaczej patrzy na produkt. 

    Trzeba mieć swoją wizję i pamiętać, że może się okazać, że dla części użytkowników to nie będzie ok. Warto ten skrajny feedback odłożyć gdzieś na półkę i skupić się na mniej skrajnych opiniach, bo to one będą definiowały nasz produkt.

    Może się zdarzyć, że przyjdzie ktoś, żeby nas gnębić, bo mu się nie podoba, że coś budujemy. Albo ktoś, uwielbia wszystko, co budujemy i zawsze powie, że super. Te opinie nie są miarodajne.

    Myślę, że twórca aplikacji powinien być zaangażowany w takie beta testy, przeprowadzać je i dyskutować z użytkownikami, jeśli ich skala nie jest ogromna. Można robić takie beta testy lokalnie, porozmawiać z użytkownikiem. Tej przewagi nie ma duża firma. 

     

    Sylwia: Więc twórca powinien być zaangażowany w testy, ale jednocześnie dystansować się emocjonalnie od tego, co może usłyszeć?

     

    Bogusz: Ja uważam, że nie trzeba się strasznie forsować na tym konkretnym produkcie o którym sobie myślimy. Warto wybrać tę grupę ludzi, do której chcemy dotrzeć, rozwiązać ich problemy i zaproponować jakieś rozwiązanie. Bo potem może się okazać, że ostateczna wizja może być zupełnie inna od tej początkowej. Musimy szukać tego, co da użytkownikom największą wartość. Nie warto kurczowo trzymać się pierwotnej wizji, która często jest błędna. 

    Sylwia: A kiedy kończyć beta testy? 

     

    Bogusz: To jest trudne pytanie. Widząc światowych graczy, z ogromnymi zespołami, gdzie ich produkty siedzą w beta testach przez lata, to myślę, że jest to kwestia indywidualna, zależna też od modelu biznesowego. 

    W Polisie w Chmurze mieliśmy tylko zaproszenie do tego, że poinformujemy o tym, że coś robimy.

    Później weszliśmy w fazę zamkniętej bety. Mieliśmy już część produktu i wartość dla użytkowników. Użytkownik miał konto i mógł się zalogować, były pewne funkcje, które pomagały w jego biznesie, ale konta były tworzone ręcznie. Później dokładaliśmy te wszystkie klocki i dopiero wtedy uruchomiliśmy publiczną betę, która oferowała kilka miesięcy za darmo. Jak usunęliśmy błędy i wszystko było gotowe, to wypuściliśmy produkt. Mieliśmy proces, który przechodzi użytkownik od punktu A, do punktu B, opcję rejestracji, nie było krytycznych błędów, to można wyjść z bety i działać na szerszą skalę. Oczywiście warto ciągle poprawiać produkt i wchodzić w kolejną betę 2.0. i dać szansę na przetestowanie jej użytkownikom. 

    Sylwia: No  tak, usprawnienie produktu nigdy się nie kończy.

    Zbierzmy najważniejsze wskazówki dla naszych słuchaczy, którzy rozważają przeprowadzenie własnych beta testów. 

    Taką wskazówką byłoby:

    •  budowanie społeczności
    • dobranie odpowiedniego modelu beta testów do grupy docelowej
    • dystans i filtrowanie feedbacku
    • priorytetyzacja wprowadzanych zmian

    A jak to wygląda z Twojej perspektywy?

     

    Bogusz: Pamiętajmy, że kiedy budujemy społeczność wokół produktu, tematu, to nie musimy się ograniczać do tego, że tylko te osoby będą korzystały z aplikacji, którą budujemy.

    One mogą być chętne do zakupu kursów o tym samym temacie, lub do zakupu książki, czy wszystkich rzeczy w tym obszarze. Warto też wykorzystać tę przewagę budowania społeczności, a społeczność jest rzeczą kluczową. 

    Zgadzam się z filtrowaniem feedbacku, żeby emocje nie brały góry nad rozsądkiem.

    Trzeba pamiętać, że nasza wizja może się zmienić i finalny produkt będzie trochę inny, niż sobie wymyśliliśmy.

    Warto od samego początku mówić o naszym produkcie, zapraszać ludzi. To przyniesie więcej korzyści dla wszystkich, niż budowanie produktu w piwnicy i wyjście z niej z gotowym rozwiązaniem. Bo może się okazać, że jest po prostu za późno, to się zmienia tak szybko, że warto już na samym początku wychodzić do pierwszych użytkowników i zobaczyć, jak pozytywny wpływ ma to na nasz produkt. 

    To że ktoś z tego korzysta, daje nam motywację, żeby ulepszać i naprawiać. Jeżeli ktoś na to czeka i jest chętny za to zapłacić, to motywacja idzie maksymalnie w górę i po prostu wtedy siadamy i robimy, a dzięki temu szybciej dowozimy produkt. Wszyscy są zadowoleni i świat idzie trochę do przodu. 

    Sylwia: Nie pozostaje nam nic innego, jak zaprosić naszych słuchaczy do beta testów w praktyce i dołączenia do testów Confly i AchieveGuru. Wszystkie linki podamy na stronie.

    Bogusz, bardzo dziękuję za rozmowę i za ogrom praktycznych wskazówek. 

    Bogusz: Bardzo miło było z Tobą porozmawiać. Mam nadzieję, że nasi słuchacze wyciągną z tego odcinka sporą dawkę wiedzy, którą mogą wdrożyć w praktyce. A to jest najważniejsze. 

    Sylwia: Raz jeszcze zapraszam Was do wejścia na stronę www.projectpeople.pl/21, tam czekają na was materiały do pobrania. 

    Znajdziecie tam transkrypcję, a także listę z praktycznych wskazówek, dzięki którym sami zaplanujecie i przeprowadzicie beta testy. Śledźcie też social media Project: People, gdzie niebawem opublikujemy artykuł na temat beta testów z komentarzami Bogusza. Artykuł pierwotnie ukazał się w Nowym Marketingu, a jeżeli słuchacie nas po publikacji artykułu, to link czeka na Was w materiałach z odcinka. 

    To już wszystko na dzisiaj, dzięki i do usłyszenia.

     

    Zapisz się do naszego newslettera i pobierz checklistę z pytaniami do tworzenia beta testów.

    narzędzia Project: People
    Marketing i promocja

     

     

     

    Artykuły 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ę
    Sylwia Paszyna
    Język nie ma przed nią tajemnic. Pracuje z tekstem pod różnym kątem. Doświadczenie zbierała między innymi w agencji contentmarketingowej, gdzie tworzyła strategie oraz prowadziła serwisy i blogi klientów. Jest również korektorką. Rozwija wiedzę w zakresie badań UX, by u źródła poznawać potrzeby wyrażające się w języku. Wszystkie te doświadczenia wykorzystuje, by tworzyć lepszą komunikację.

    Uwielbiamy ciasteczka!

    Nie wierzysz? Odwiedź nas w naszym biurze i sprawdź! Ciasteczka serwujemy z pyszną kawą. Dowiedz się więcej

    Zgoda