o czym jest ten wpis. spojrzenie na jeden projekt w formule build-in-public. zespół produktowy fintechu po rundzie serii b miał funkcję ai, która świetnie prezentowała się na demo i nie chciała wejść na produkcję. przebudowaliśmy ją w funkcję produkcyjną w 5 tygodni. trafiła do 100% użytkowników, a zgłoszenia supportowe dotyczące tej funkcji spadły o 60% po wdrożeniu.
prototyp już istniał. product manager zbudował go w lovable w jeden weekend. wyglądał realistycznie. świetnie zaprezentował się na spotkaniu all-hands. potem leżał odłogiem przez cztery miesiące, bo wyglądanie realistycznie i bycie niezawodnym to dwie różne sprawy.
ujawnienie przed publikacją: klient jest zanonimizowany. 5-tygodniowe wdrożenie i spadek zgłoszeń o 60% to zrealizowane wyniki projektu, nie prognozy. nie podajemy nazwy, bo tak stanowi umowa. tu liczy się sam proces budowy, nie logo.
#dlaczego dobry prototyp utyka przed produkcją?
bo prototyp odpowiada na inne pytanie niż produkcja. prototyp dowodzi, że pomysł może zadziałać raz, na czystych danych wejściowych, z założycielem za sterami. produkcja musi działać na chaotycznych danych wejściowych, o drugiej w nocy, bez nikogo, kto patrzy, i musi dać się obronić, gdy klient zakwestionuje to, co funkcja mu powiedziała. w tej luce umiera większość projektów z v0 i lovable. nie dlatego, że pomysł był zły. dlatego, że nie było drogi od dema do czegoś, pod czym można się podpisać.
jak przenieść prototyp ai na produkcję?
zacznij od prawdziwego problemu, nie od interfejsu dema. przebuduj funkcję wewnątrz własnego produktu ze streamingiem odpowiedzi, zestawem testów sprawdzającym odpowiedzi względem znanych, poprawnych przypadków, logowaniem audytowym i przeglądem przez człowieka tam, gdzie to ważne. dla tego zespołu fintechowego ta droga zajęła 5 tygodni i obniżyła liczbę zgłoszeń dotyczących funkcji o 60%.
#co właściwie zbudowaliśmy?
nie zaczęliśmy od okna czatu z prototypu. zaczęliśmy od kolejki supportu. trzy najczęstsze typy zgłoszeń dotyczących tej funkcji wskazywały na to samo: użytkownicy nie mogli uzyskać jasnej odpowiedzi bez pisania do supportu. więc zbudowaliśmy funkcję, żeby najpierw odpowiadała na te trzy pytania, wewnątrz ich własnego produktu i własnego systemu projektowego, a nie jako doczepiony widget.
- streaming odpowiedzi, dzięki czemu funkcja wydaje się natychmiastowa zamiast pokazywać kółko ładowania. odpowiedź pojawia się na bieżąco, w miarę jak powstaje.
- zestaw testów, który przy każdej zmianie sprawdza funkcję względem znanych, poprawnych odpowiedzi, więc poprawka jednego promptu nie może po cichu zepsuć innego przypadku.
- logowanie audytowe przy każdej odpowiedzi, więc gdy klient zakwestionuje to, co powiedziała funkcja, support może wyciągnąć dokładne dane wejściowe i wyjściowe.
- ux wbudowany w produkt, zbudowany wewnątrz ich systemu projektowego, więc czyta się to jak część produktu, a nie jak doczepione okno czatu.
we are
przebudowaliśmy utknięty prototyp w wdrożoną funkcję ze streamingiem, zestawem testów, logowaniem audytowym i natywnym ux wbudowanym w produkt.
we aren't
nie umieściliśmy generycznego okna czatu na produkcie i nie nazwaliśmy tego funkcją ai.
#dlaczego zgłoszenia supportowe spadły o 60%?
bo zbudowaliśmy funkcję wychodząc od zgłoszeń, a nie od pomysłu. trzy pytania, które generowały najwięcej zgłoszeń supportowych, to teraz trzy pytania, na które funkcja odpowiada wewnątrz produktu, zanim użytkownik musi do kogokolwiek napisać. log audytowy pokazuje nam, na które pytania funkcja odpowiada, a które wciąż trafiają do człowieka. ten sam log pozwolił nam stwierdzić, że spadek o 60% jest realny, a nie sezonowy. zmierzono go dla każdego typu zgłoszenia osobno, w porównaniu do ośmiu tygodni przed wdrożeniem.
zestaw testów to powód, dla którego spadek się utrzymał. przed wdrożeniem każda zmiana była sprawdzana względem znanych, poprawnych odpowiedzi. poprawka promptu, która naprawiała jeden przypadek, a psuła dwa inne, była wychwytywana, zanim dotarła do użytkownika. to różnica między demem, które działa raz, a funkcją, która działa za każdym razem. zespoły produktowe nazywają to wdrożeniem. zgadzamy się. więcej o naszym podejściu do pracy produktowej znajdziesz tutaj.
#ile czasu zajęło wdrożenie?
pięć tygodni, od prototypu do 100% użytkowników. tydzień pierwszy to log audytowy i zestaw testów, bo nie da się poprawić czegoś, czego nie da się zmierzyć. tygodnie drugi i trzeci to przebudowa trzech najczęstszych odpowiedzi wewnątrz produktu. tydzień czwarty to ux w systemie projektowym i streaming. tydzień piąty to stopniowe wdrożenie, po dziesięć procent użytkowników na raz, z obserwacją logu audytowego pod kątem wszystkiego, co umknęło testom. bez wielkiej premiery. bez przebudowy trwającej kwartał.
z rzeczy, którą demonstrowaliśmy, stała się rzeczą, którą wdrożyliśmy, a kolejka supportu pokazuje nam, że zadziałało.
to wspólny mianownik większości naszych studiów przypadków w formule build-in-public. wygrana to nie model. to nudne elementy dookoła niego: zestaw testów, log audytowy, bramki przeglądu, wdrożenie, które można obserwować. właśnie to zamienia prototyp w coś, co można postawić przed każdym użytkownikiem. jeśli masz projekt z v0 albo lovable, który utknął na etapie dema bez dalszej drogi, to dokładnie ta luka, którą zamykamy. powiedz nam, co budujesz.