O czym jest ten wpis. Ilustracyjny przykład praktyczny, nie wynik klienta. Zespół fintech, jego produkt i każda liczba to założenia. Pokazuje, co trzeba zrobić, by prototyp AI, który dobrze wypada w demo, zamienić w funkcję, którą można pokazać wszystkim użytkownikom.
Załóżmy zespół produktowy fintechu z serii b. Product manager zbudował w weekend w lovable prototyp funkcji AI. Wygląda prawdziwie i dobrze wypadł na all-hands. Potem leży, bo wyglądanie na prawdziwy i bycie niezawodnym to dwie różne roboty.
o tym przykładzie: zespół jest ogólny i nie stoi za nim żaden klient. Nic tutaj nie jest dostarczonym wynikiem ani prognozą. Chodzi o projekt, nie o 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 wprowadzić prototyp AI na produkcję?
Zacznij od prawdziwego problemu, nie od interfejsu demo. Zbuduj funkcję od nowa wewnątrz własnego produktu, ze strumieniowaniem odpowiedzi, zestawem testów porównującym odpowiedzi ze znanymi dobrymi przypadkami, rejestrowaniem audytowym i przeglądem człowieka tam, gdzie to ważne. Potem zmierz zgłoszenia do supportu dotyczące funkcji przed i po.
#Co obejmuje projekt produkcyjny?
Nie zaczynaj od okna czatu w prototypie. Zacznij od kolejki supportu. Załóżmy, że trzy zgłoszenia o największym wolumenie dotyczące tej funkcji wskazują na to samo: użytkownicy nie mogą dostać jasnej odpowiedzi bez pisania do supportu. Zbuduj funkcję tak, by najpierw odpowiadała na te trzy pytania, wewnątrz własnego produktu i systemu projektowego zespołu, a nie jako doklejony widżet.
- 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
Przebudowujemy zablokowany prototyp w wdrożoną funkcję ze strumieniowaniem, zestawem testów, rejestrowaniem audytowym i natywnym UX w produkcie.
We aren't
Nie kładziemy ogólnego okna czatu na produkt i nie nazywamy tego funkcją AI.
#Skąd wiedzieć, że funkcja zmniejsza liczbę zgłoszeń do supportu?
Buduj funkcję od końca, od zgłoszeń. Pytania generujące najwięcej ruchu w supporcie to te, na które funkcja odpowiada w produkcie, zanim ktokolwiek musi pisać. Dziennik audytowy pokazuje, które pytania funkcja obsługuje, a które nadal trafiają do człowieka. Ten sam dziennik pomaga odróżnić prawdziwy spadek od sezonowego: porównaj wolumen każdego typu zgłoszenia z oknem odniesienia sprzed startu.
Zestaw testów sprawia, że każda poprawa się utrzymuje. Przed startem każda zmiana jest uruchamiana na znanych dobrych odpowiedziach. Zmiana promptu, która naprawia jeden przypadek i psuje dwa inne, zostaje wyłapana, zanim dotrze do użytkownika. Na tym polega różnica między demo, które działa raz, a funkcją, która działa za każdym razem. Zespoły produktowe nazywają to wdrożeniem. My też. Więcej o tym, jak podchodzimy do pracy produktowej, tutaj.
#W jakiej kolejności to budować?
Najpierw dziennik audytowy i zestaw testów, bo nie da się poprawić tego, czego nie można zmierzyć. Potem odbudować w produkcie odpowiedzi na najczęstsze zgłoszenia. Następnie UX w systemie projektowym i strumieniowanie. Na końcu etapowe wdrożenie dla rosnącego udziału użytkowników, z obserwowaniem dziennika audytowego pod kątem tego, co przeoczyły testy. żadnego startu na raz.
Test do zastosowania: ma przejść od czegoś, co pokazałeś, do czegoś, co wdrożyłeś, a kolejka supportu mówi ci, że zadziałało.
To łączy nasze przykłady praktyczne. Nie model jest tu zyskiem. Zyskiem są nudne elementy wokół: zestaw testów, dziennik audytowy, bramki przeglądu, wdrożenie, które można obserwować. To zamienia prototyp w coś, co można pokazać wszystkim użytkownikom. Jeśli masz build z v0 lub lovable utknięty na demo bez drogi naprzód, to dokładnie ta luka, którą zamykamy. powiedz nam, co budujesz.
