W produkcie AI wykonalność należy do discovery

Discovery produktowe, tak jak uprawia je większość zespołów, dotyczy tego, czy produkt jest potrzebny. Czy ludzie mają ten problem, czy zmienią sposób pracy, żeby go rozwiązać, czy ktoś za to zapłaci. Wykonalność trafia do inżynierii jako wycena: tak, da się zbudować, zajmie mniej więcej tyle.

Ten podział pracy działa, gdy oprogramowanie robi to, co w nim napisano. W produkcie AI jest odwrotnie. Niemal każdą funkcję da się pokazać w tydzień. Czy da się ją doprowadzić do poziomu „wystarczająco dobrze” — na Waszych dokumentach, dla Waszych użytkowników, za koszt, który uniesiecie — nie rozstrzygnie się przy tablicy. A właśnie to pytanie decyduje, czy w ogóle jest produkt.

Dlaczego zwykły podział zawodzi

Pokaz odpowiada na inne pytanie. Pokaz dowodzi, że model potrafi dać dobrą odpowiedź. Produkt musi dawać akceptowalną także w gorsze dni: przy dwuznacznym zapytaniu, krzywo zeskanowanym załączniku, kliencie piszącym w dwóch językach naraz. Pokazy są selekcjonowane przez tego, kto je prowadzi — zwykle bez niczyjej złej woli.

Inżynieria nie wyceni tego uczciwie. Pytanie, ile potrwa dojście do akceptowalnej jakości, nie ma rzetelnej odpowiedzi, dopóki ktoś nie przepuści prawdziwych przypadków. Zespół i tak podaje liczbę, bo roadmapa jej potrzebuje, a plan staje na zgadywaniu przebranym za wycenę.

Badania z użytkownikami testują szczęśliwą ścieżkę. Pokażcie ludziom prototyp, który zawsze ma rację, a spodoba im się. Nie mówi to nic o tym, czy będą z niego korzystać po trzeciej pewnej siebie, błędnej odpowiedzi — a to ten moment naprawdę rozstrzyga o adopcji.

Dwa tory w tych samych tygodniach

Discovery aplikacji AI-native biegnie dwoma torami równolegle i żaden nie może skończyć się pierwszy.

Czy warto to mieć? Klasyczne pytanie, tylko zadane precyzyjniej: ile zadanie kosztuje dziś, zmierzone, a nie opisane, i co człowiek zrobi z wynikiem, który zwykle jest trafny, a czasem — wiarygodnie — błędny?

Czy da się to zrobić dość dobrze? Weźcie próbkę prawdziwych wejść — powiedzmy sto, dobranych łącznie z niewygodnymi, zanim ktokolwiek zobaczy wynik — i przepuśćcie je przez najprostsze sensowne podejście. Nie produkt: skrypt i arkusz. Ktoś, kto na co dzień wykonuje tę pracę, oznacza każdy wynik jako dobry, do poprawki albo błędny.

Ile tu kosztuje błędna odpowiedź? Tu oba tory się spotykają. Błędne streszczenie wewnętrznego spotkania kosztuje minutę czyjegoś czasu. Błędna kwota w ofercie dla klienta kosztuje marżę albo klienta. Ten sam odsetek błędów bywa produktem w jednym miejscu i zobowiązaniem w innym, więc wynik próby nic nie znaczy, dopóki nie zostanie wyceniony.

Infografika

Discovery z torem wykonalności

1. 01Zmierzyć zadanieJak praca wygląda dziś, zmierzone, a nie opisane.
2. 02Prawdziwe wejściaZ niewygodnymi przypadkami, dobrane, zanim ktoś zobaczy wynik.
3. 03Prosta próbaNajprostsze sensowne podejście. Skrypt, jeszcze bez interfejsu.
4. 04Ocena z ekspertemKażdy wynik: dobry, do poprawki albo błędny.
5. 05Wycena pomyłekIle w tym konkretnym zadaniu kosztuje błędna odpowiedź.
6. 06DecyzjaDalej, przycięcie zadania albo stop, póki stop jest tani.

Trzy wyniki, każdy użyteczny

Idziemy dalej. Z orientacyjnym poziomem jakości, listą kategorii, które zawodzą, i kosztem pomyłki, który projekt jest w stanie zamortyzować. Oceniona próbka staje się pierwszą wersją zestawu ewaluacyjnego, więc nic z tej pracy nie idzie do kosza.

Przycinamy zadanie. Wynik najczęstszy: model dobrze radzi sobie z połową zadania. Produktem staje się ta połowa — szkicowanie zamiast wysyłania, sortowanie zamiast decydowania — i często jest przez to lepszym produktem, bo człowiek zachowuje część, w której liczy się osąd.

Zatrzymujemy. Tanio. Dwa tygodnie i arkusz zamiast dwóch kwartałów i wdrożenia, z którego nikt nie korzysta. To jest wynik, dla którego discovery w ogóle istnieje — a zespół, który z każdego discovery wychodzi z odpowiedzią „tak”, tak naprawdę go nie robi.

Kto musi być w pokoju

Próba wymaga osoby, która wie, jak wygląda dobra odpowiedź, a nie kogoś, kto ją zastępuje. Product manager przeczyta wyniki i wyrobi sobie wrażenie; tylko ktoś, kto wykonuje tę pracę, zauważy odpowiedź gładką, wiarygodną i błędną.

Zarezerwujcie jej godziny, zanim discovery ruszy. Drugi tor najczęściej znika po cichu nie z powodu sceptycyzmu, tylko dlatego, że ta osoba miała swoją normalną pracę i nigdy nie była naprawdę dostępna.

Gdzie wchodzi projektowanie

W projektowaniu aplikacji AI-native pierwszym krokiem jest obejrzenie obecnego zadania z pomiarem czasu, a prototyp, który powstaje potem, ma w środku realistycznie błędne odpowiedzi — bo prototyp pokazujący wyłącznie dobre wyniki nie testuje niczego istotnego. Prowadzony równolegle z próbą na prawdziwych danych pozwala odpowiedzieć na oba pytania, zanim zostanie zaangażowany budżet inżynierski.