Rozwój złożonego produktu. Case study chatbotów Tidio

Załóżmy, że wiesz, co chcesz osiągnąć. Ryzyko zostało przeanalizowane, a pomysł został oceniony jako dobry. Co dalej? Pora przejść do rzeczy! Od czego zacząć? O czym nie zapomnieć? Na te i kilka innych pytań znajdziesz odpowiedź w poniższym artykule. Historia oparta na faktach.

Przemek Szustak. Product Manager, Chatbots w Tidio. Product Manager z mocnym doświadczeniem biznesowym. Wprowadził na rynek kilka swoich produktów, aby następnie seryjnie tworzyć nowe projekty dla jednego z polskich venture builder’ów. Obecnie związany z Tidio, gdzie zajmuje się rozwojem chatbotów. W wolnych chwilach żongluje, żegluje i gra na saksofonie.

Kilka miesięcy temu pisałem o strategii, budowie i rozwoju produktu IT, czyli jak podejmować decyzje, analizować szanse rynkowe, czym zająć się w pierwszej kolejności, jak ocenić, czy pomysł jest dobry oraz czy warto go wdrożyć. Nie byłbym sobą, gdybym poprzestał na suchej teorii i nie dostarczył czytelnikom Just Join IT prawdziwego produktowego mięsa, którym jest ten proces w praktyce 🙂

1. Nie ma jednej prostej drogi – produktowy roller coaster.
2. Eksperymenty to proces ciągły –dlaczego nie można osiadać na laurach?
3. Rola procesu Discovery –dlaczego to takie ważne?
4. Walidacja pomysłu – dlaczego im więcej potu wylanego na treningu, tym mniej krwi na ringu?
5. Wdrożenie (experimental phased release) – dlaczego czasem nie warto iść na całość?
6. Podejście iteracyjne sposobem na trudne wyzwania – czyli jak nie zwariować?

Nie ma jednej prostej drogi – produktowy roller coaster

Pod koniec zeszłego roku mieliśmy w Tidio kilka pomysłów na odświeżenie modelu rozliczeniowego za chatboty z naszymi klientami. Chcieliśmy przejść z modelu usage-based na performance-based (spoiler: i tak się to nie udało, ale nie ma tego złego! – jeszcze lepszy pomysł jest właśnie wdrażany). Nie mieliśmy jednak dokładnych danych na temat tego, w jaki sposób odwiedzający strony naszych użytkowników wchodzą w interakcje z botami. Skoro my nie wiedzieliśmy, to co mieli powiedzieć klienci? Zaczęliśmy od podstaw, czyli od Discovery. Po kilku iteracjach (powtórzeniach) udało nam się zgromadzić mnóstwo cennych danych ilościowych dotyczących działania automatyzacji. To nie koniec: przede wszystkim byliśmy w stanie zaspokoić potrzebę użytkowników, którym zależało na tym, aby dostarczane przez nas dane były w stanie pomóc jeszcze lepiej automatyzować obsługę klienta (i podkręcać sprzedaż).

Tak powstała analityka chatbotów, o której chcę opowiedzieć więcej w tym case study. To istny roller coaster. Było to dla nas spore wyzwanie, ale przede wszystkim zyskaliśmy przestrzeń na przeprowadzenie ciekawego procesu, dzięki któremu popchnęliśmy cały produkt w nowym kierunku.

Eksperymenty to proces ciągły – dlaczego nie można osiadać na laurach?

Pewnie każdy zna motyw z filmów science-fiction dotyczący podróży w czasie. Zakłada on że jeśli czas nie jest jednowymiarowy jak linia, ale dwuwymiarowy jak kartka papieru, nagle robi się wystarczająco dużo przestrzeni na skierowanie pętli czasu w przeszłość. Podobnie jest z procesem powstawania produktu. Co prawda nie cofamy się w czasie, ale na każdym etapie jesteśmy w stanie wrócić krok (lub wiele kroków) do tyłu. Zarządzanie produktem, w przeciwieństwie do zarządzania projektami, nie ma ograniczenia czasowego (chyba, że produkt upadnie), zatem proces musi być na tyle elastyczny, aby dało się po nim swobodnie poruszać.

Poprzednio prezentowałem framework oparty o Hypothesis Driven Development oparty na tablicy Kanban, która ułatwia zwinne zarządzanie produktem. Była to uproszczona forma wizualizacji tego, w jaki sposób Product Manager może zarządzać procesem powstawania nowych funkcjonalności. Zainspirowany metodą twórczego rozwiązywania problemów (Design Thinking), rozwinąłem to flow o model Podwójnego Diamentu (Double Diamond), który z jednej strony skupia się na dogłębnym zrozumieniu problemu, a z drugiej – na znalezieniu najlepszego rozwiązania.

Takie flow pozwala pracować mądrze. Odpowiednie rozpracowanie problemu użytkownika nie tylko sprawia, że zaprojektowana funkcjonalność faktycznie będzie użyteczna, ale także umożliwia odpowiednie zaplanowanie pracy, dokładniejszą wycenę, a także obniża całkowity koszt inicjatywy.

Na wstępie wspomniałem, że początkowego celu nie udało się osiągnąć. Z kolei sama funkcjonalność miała być tylko częścią większych zmian. Czy to znaczy, że ponieśliśmy porażkę? Wręcz przeciwnie! Zwinne przemieszczanie się między sferą rozwiązań a sferą problemów to klucz do sukcesu. Wpadamy na pomysł, zagłębiamy się w szczegóły, zaczynamy coś robić i weryfikujemy to. Nierzadko robimy zwrot. Tutaj przydaje się proces Discovery.

Oferty pracy z

Rola procesu Discovery – dlaczego to takie ważne?

Proces Product Discovery to iteracyjny proces zmniejszania niepewności wokół problemu lub pomysłu, aby upewnić się, że zostanie stworzony odpowiedni produkt dla właściwej grupy odbiorców. Nie jest to jednak remedium na całe zło, ani 100% gwarancja sukcesu. Dzięki niemu możesz jednak zminimalizować niepewność i skupić się na tym, co ważne.

Najważniejszym elementem powyższej definicji procesu Discovery jest powtarzalność. To ciągły proces udoskonalania, a nie jednorazowe badanie. Pomysły muszą być weryfikowane w sposób ciągły, a feedback z rynku dotyczący działających już elementów produktu powinien być analizowany, walidowany i ponownie wykorzystywany w nowych wdrożeniach. Takie informacje zwrotne powinny inspirować do odkrywania nowych koncepcji w naszym pierwotnym pomyśle. Śmiało mogę powiedzieć, że jest to wręcz kwintesencja zwinnego wytwarzania produktów, gdzie jedną z najważniejszych zasad jest inspekcja tego, co już zrobiliśmy i adaptacja do aktualnej sytuacji.

Stały kontakt z klientami zdecydowanie ułatwia i przyspiesza proces gromadzenia insightów, dzięki czemu proces Discovery może trwać 24/7. Dzięki temu wszystkie nowe inicjatywy produktowe mają szansę powstać zgodnie z oczekiwaniami użytkowników. Poniżej znajduje się przykład, który posłużył do rozpracowania problemu na początkowym etapie pracy nad analityką chatbotów.

Wdrażanie nowych funkcjonalności dla użytkowników i pozostawianie ich samym sobie może być ryzykowne. Jeszcze przed przedstawieniem go większej publiczności warto porozmawiać z wybranymi klientami na temat ich wrażeń i dalszych oczekiwań. Jak wiemy, proces Discovery polega na ciągłym udoskonalaniu, a nie na jednorazowym badaniu. Dzięki niemu mamy szansę dowiedzieć się, jak nowa funkcjonalność jest odbierana. W kontekście analityki chatbotów pomogło to w tworzeniu i przeprojektowaniu rozwiązań lepiej dopasowanych do potrzeb i oczekiwań danej grupy docelowej. Dodatkowo uchroniło przed ponoszeniem kosztów związanych z rozwojem rozwiązania, co nie byłoby atrakcyjne dla klientów. Świadczy o tym pozytywny feedback, jaki zebraliśmy w trakcie wywiadów przed zaprezentowaniem szerszej publiczności tej funkcjonalności.

Walidacja pomysłu – dlaczego im więcej potu wylanego na treningu, tym mniej krwi na ringu?

Przedstawiałem ostatnio ciekawe narzędzie, jakim jest Validation Field. Pozwala ono ustrukturyzować proces walidacji pomysłu, uwzględniając określenie metryk sukcesu oraz – także na tym etapie – podjęcia decyzji dotyczących następnych kroków (zakładając pozytywny, negatywny i neutralny scenariusz).

Jestem wielkim fanem pracy koncepcyjnej, ponieważ zmusza ona do spojrzenia na dane zagadnienie z szerszej perspektywy. Podobno jeśli nie da się zmieścić pomysłu na jednej kartce, to jest on kiepski. W tym przypadku prostota zdecydowanie jest kluczem. Naturalnie, problem może być złożony, ale na poziomie abstrakcji powinniśmy być w stanie zaprezentować go w przysłowiowej windzie w przeciągu 30 sekund.

Właśnie dlatego, jeszcze przed wykonaniem jakiejkolwiek pracy przez zespół deweloperski warto poświęcić trochę czasu na zastanowienie się nad założeniami, oczekiwanymi rezultatami oraz pomyśleć o dalszych krokach. To idealny przykład tego, że im więcej potu wylanego na treningu, tym mniej krwi na ringu

Ten i podobne szablony to świetne narzędzia, dzięki którym można szybko połączyć wszystkie kropki.

Wdrożenie (experimental phased release) – dlaczego czasem nie warto iść na całość?

Przy rozwijaniu dużych, globalnych produktów dobrą praktyką jest stopniowe udostępnianie nowych funkcjonalności użytkownikom (np.i za feature flagą). Dzięki temu możemy uniknąć niechcianych błędów na produkcji, ale przede wszystkim odpowiednio wcześnie skorygować wyznaczony kurs.

Praktyka pokazuje, że nawet najlepsze, najbardziej szczegółowe scenariusze testowe nie zawsze dają stuprocentowej gwarancji, że czegoś nie pominęliśmy. W końcu jesteśmy tylko ludźmi i błędy się zdarzają. Co więcej, jeśli produkt pozwala jego użytkownikom ingerować w logikę działania narzędzia (np. poprzez ustawienia – w naszym przypadku flow działania bota), najprawdopodobniej znajdą się tacy klienci, którzy zrobią coś, co może wprawić nas w osłupienie. Użytkownicy często nieświadomie używają funkcjonalności w inny sposób niż zamierzony (może wina leży w słabej edukacji?). Nie ma innej opcji, niż zidentyfikować takie edge case’y empirycznie.

Największą wartość ma jednak przestrzeń na wywiady z użytkownikami (o czym piszę wyżej). To w końcu dla nich budujemy produkty i wdrażamy nowe funkcjonalności. Podobno sama budowa produktu jest łatwa. To co jest trudne, to zbudować taki produkt, który ludzie pokochają, który zaspokoi ich potrzeby i rozwiąże problemy.

Do czasu dostarczenia rozwiązania do klientów końcowych poruszamy się wokół hipotez i założeń. Badania użyteczności są podstawowym źródłem informacji, czy użytkownicy bez problemu znajdą odpowiednie informacje lub ukończą określony proces. To także szansa, aby zobaczyć, jak zapoznają się z udostępnionymi im treściami, oraz w jaki sposób nawigują po nowej wersji serwisu. Z kolei wnioski pozwalają wdrażać poprawki, dzięki którym finalnie wszyscy będą zadowoleni.

Czy warto wdrażać nowe funkcjonalności w szybkim tempie? Zdecydowanie tak. Czy warto wdrażać je za wszelką cenę? Zdecydowanie nie. Dopóki widać wyraźny inkrement, a niepewności się zmniejszają, dopóty działamy w dobrym tempie.

Podejście iteracyjne sposobem na trudne wyzwania, czyli jak nie zwariować

W inicjatywach produktowych, których cel składa się często z nieprecyzyjnych założeń, a samych metod jego osiągnięcia jest bardzo wiele, istnieje tylko jeden sposób, żeby nie zwariować – niezbędne jest podejście iteracyjne. Zakłada ono, że należy stworzyć szczegółowy plan tylko na najbliższy okres czasu, czyli tzw. iterację. W niej przewiduje się osiągnięcie konkretnych celów, stworzenie pewnych części produktu.

Nie ma sztywnych zasad co do czasu trwania iteracji: może to być np. miesiąc, a samych iteracji może być wiele. Trudno jest bowiem oszacować z dużym stopniem pewności, ile będzie trwało stworzenie skomplikowanego rozwiązania, nad którym pracuje wielu programistów.

Takie podejście do zarządzania produktem sprawia, że w toku realizacji plan działania krok po kroku ulega coraz większemu uszczegółowieniu.

Każda kolejna iteracja to również szansa na wyciąganie wniosków i wdrażanie ulepszeń. A gdy użyjemy ciekawych technik, cały ten proces może być również dobrą zabawą i okazją do integracji zespołu. Warto eksperymentować z różnymi podejściami, wyciągnąć wnioski, a potem już tylko budować najlepsze, najbardziej oczekiwane przez użytkowników produkty.

Zdjęcie główne artykułu pochodzi z unsplash.com.