Jeśli zajrzymy do podręczników i teorii strategii biznesowej to, w zależności od perspektywy, możemy powiedzieć, że AI zmienia się wszystko… albo nic. Mamy bowiem nową rewolucję technologiczną zwiększającą efektywność części gospodarki. Ale ta rewolucja idzie w ślady swoich starszych sióstr zarówno w obszarze zaawansowanych technologii (Internet, komputer, układ scalony, telefon) jak i innych dziedzin życia (samoloty, samochody, kolej, silnik parowy).
AI jest kolejną warstwą abstrakcji, która pozwala nam lepiej manipulować kodem, który wpływa na fizyczną i cyfrową rzeczywistość. Od asemblera przez języki wysokiego poziomu, frameworki, zarządzane bazy danych i usługi chmurowe kolejne warstwy abstrakcji pozwalały osiągać coraz więcej bez konieczności rozumienia całej złożoności znajdującej się pod spodem. LLM-y idą o krok dalej: pozwalają operować systemem za pomocą języka naturalnego.
Wcześniejsze warstwy abstrahowały złożoność techniczną, ale LLM-y robiąc coś znacznie poważniejszego: zaczynają abstrahować także pracę poznawczą, co do tej pory było czysto ludzką kompetencją.
W związku z tym mam kilka wniosków z którymi chcę się z Wami podzielić.
Discovery i Delivery to za mało
Pracę produktową dzieli się tradycyjnie na dwie przeplatające się fazy: Discovery i Delivery. Pierwsza jest o zrozumieniu, co jest do zrobienia, a druga o odpowiednim tego zrobieniu („Doing the right thing right”). Dzięki AI możemy obydwie fazy tej pracy przyśpieszyć wielokrotnie zaczynając od zrozumienia problemu i sformułowania zadania do wykonania przez sam proces tworzenia designu, kodu, QA i dokumentacji oraz wdrożenia.
To właśnie te elementy zazwyczaj powodowały frustrację interesariuszy narzekających, że oni chcą tylko zmienić coś na stronie, albo dodać prostą funkcję w produkcie. Każda z tych zmian wymagała ludzkiej atencji, weryfikacji i koordynacji. Wraz z pojawieniem się AI część tych narzutów znika, istotnie zwiększając produktywność zespołów.
To jednak stanowi wyzwanie. Jeśli wszystko można szybko zrobić, skąd wiedzieć, co tak naprawdę ma sens? To podnosi poprzeczkę produktowcom, którzy nie mogą się już zasłaniać hasłami w postaci „nie mamy zasobów”, „nie mamy jak tego sprawdzić”, czy „potrzebujemy dostępu do konkretnych technologii”.
Wcześniej mieliśmy prosty proces: ograniczone zasoby dyktowały kolejność działań i priorytetów. Nie możemy rzucać się na wszystko, bo ryzyko błędu oznaczało poważne obniżenie ROI całej organizacji. Ergo zespoły próbowały zwiększać swoją pewność wywiadami z użytkownikami, analityką produktową, lepszą definicją wyzwania, konkretniejszymi wymaganiami biznesowymi, dzieleniem projektu na iteracje, testami, tworzeniem POCów, MVPs itd. Wszystko to w celu ograniczenia ryzyka nietrafionego strzału. Było to rozsądne, uświęcone leanową tradycją działanie.
Ale teraz, skoro koszt budowy gwałtownie spada to pojawia się pytanie: why choose? Może zastosować produktowy brute force, zbudować wszystko i zobaczyć, co faktycznie przylgnie i zweryfikuje się pozytywnie na rynku?
To jednak prowadzi do mnożenia się bytów i ujawnienia wąskiego gardła: zdolności organizacji do uczenia się. Fajnie, że wyprodukujemy 10x więcej funkcji w tym samym czasie, ale czy jesteśmy w stanie zrozumieć, które z nich faktycznie wnoszą wartość? Czy potrafimy je wdrożyć w procesy organizacyjne, zapewnić im wszystkim odpowiednie skalowanie, ekspozycję i support? I z drugiej strony: czy użytkownicy potrzebują kolejnych fajerwerków na swojej ścieżce?
Clayton M. Christensen w „Competing Against Luck” ostrzegał, że nawet ogrom danych może pozostawić nas na poziomie korelacji. A korelacja nie odpowiada na najważniejsze pytanie innowacji: dlaczego klient wybiera właśnie to rozwiązanie?
AI tworzy podobną pułapkę: możliwość wytworzenia rozwiązania nie jest dowodem, że istnieje przyczyna, dla której użytkownik je „zatrudni”.
AI zwiększa naszą zdolność do generowania odpowiedzi szybciej, niż rośnie nasza zdolność do zadawania właściwych pytań.
Można nawet pójść dalej i powiedzieć, że najważniejsze jest to, czego nie chcemy robić. Bo im więcej możemy zrobić, tym większe znaczenie ma selekcja. Użytkownik nie potrzebuje stu ficzerów tylko dlatego, że ich stworzenie stało się tanie.
W związku z tym w świecie, w którym zarówno Discovery, jak i Delivery tanieją, rośnie znaczenie trzeciego elementu: Decision making. To zdolność organizacji do wyboru, czego nie robić, staje się jednym z jej najważniejszych wewnętrznych ograniczeń.
Ale nawet Decision Making nie jest ostatnim ograniczeniem systemu.
Prawdziwe wąskie gardło
Patrząc statycznie można by pomyśleć, że skoro największy problem produktowy (szybkość wytwarzania) został radykalnie zmniejszony, to nic nie stoi na przeszkodzie, aby wszyscy byli bogaci i szczęśliwi. To jest oczywiście niemożliwe, ponieważ zgodnie z obserwacjami Eliyahu Goldratta usunięcie jednego wąskiego gardła odkrywa kolejne, które do tej pory było ukryte.
Goldratt najlepiej opisał to w książce „Cel„: w celu przyśpieszenia produkcji do fabryki wprowadzono roboty, które były znacznie efektywniejsze niż dotychczasowe rozwiązanie. Można było się pochwalić nowoczesnymi rozwiązaniami, pokazać innowacyjność w świetle kamer. Ale! Na pytanie czy dzięki tym robotom firma sprzedaje więcej okazało się, że odpowiedź jest negatywna.
Dlaczego? Roboty zwiększyły lokalną efektywność, ale nie throughput całego zakładu. Co gorsza, presja na ich pełne wykorzystanie powodowała produkowanie półproduktów szybciej, niż reszta systemu była w stanie je wykorzystać, zwiększając zapasy i tym samym koszty całego procesu wytwórczego.
AI przyspiesza etap wytwarzania, więc spada koszt zaangażowania zespołu w budowę niewłaściwego rozwiązania. Przenosząc logikę Goldratta na software: samo zwiększenie przepustowości produkcji kodu nie musi zwiększyć throughputu całej organizacji.
Prawdziwe wąskie gardło jest dalej w procesie. Więc produkowanie nowych funkcji szybciej i sprawniej odsłania większy problem, który zawsze wszyscy mieliśmy, ale mógł być mniej widoczny, gdy poprzeczka jakościowa naszych hipotez była wyższa ze względu na koszt błędu: jak spowodować, żeby ludzie faktycznie korzystali z tego, co zrobiliśmy.
To pomaga wyjaśnić pozorny paradoks AI: ogromny wzrost możliwości na poziomie pojedynczego zadania może mieć znacznie mniejsze przełożenie na wyniki całej organizacji. AI zwiększa przepustowość jednego fragmentu systemu znacznie szybciej, niż reszta systemu jest w stanie tę zmianę zaabsorbować.
Odpowiedzialność, ostateczna kompetencja
Clayton M. Christensen ostrzegał przed outsourcowaniem zdolności, które organizacja będzie musiała posiadać, aby móc odnieść sukces w przyszłości. To samo dotyczy obecnej rewolucji AI.
Jeśli AI sprawia, że wykonanie można oddać do sztucznej inteligencji, warto zapytać: jakiej zdolności nie możemy oddać, aby zabezpieczyć sukces w przyszłości? Stawiam tezę, że tą fundamentalną kompetencją jest odpowiedzialność.
AI to ciągle narzędzie. Chętnie je antropomorfizujemy, bo mówi do nas naszym językiem, ale zasadnicza różnica polega na tym, że nie poczuje konsekwencji swoich decyzji. AI może przygotować argumenty za i przeciw, rekomendować decyzję, a nawet podjąć ją operacyjnie. Nie może jednak ponieść za nią odpowiedzialności.
AI po prostu nie ma „skin in the game” w sensie, w jakim tego pojęcia używa NN Taleb. W najgorszym przypadku przeprosi i przyzna się do błędu.
Decyzja produktowa nie jest tylko przewidywaniem przyszłości. Jest także zobowiązaniem organizacji do wydania pieniędzy, zużycia czasu użytkownika, zmiany procesów i poniesienia konsekwencji pomyłki. Ktoś musi powiedzieć „robimy to” i zaakceptować konsekwencje.
Powierzchowny kryzys tożsamości
Skoro AI może zrobić wszystko, to po co my tutaj jesteśmy? Z tego samego powodu, dla którego zawsze tu byliśmy!
Rola dobrych produktowców zawsze sprowadzała się do tego samego: podejmowania właściwych decyzji w warunkach niepewności. Dobrzy inżynierowie zawsze chcieli budować wydajne i skalowalne rozwiązania. Dobrzy sprzedawcy (i support) zawsze chcieli rozwiązywać problemy swoich klientów. AI pozwala im poświęcić coraz większą część czasu na tę właściwą pracę, przejmując busy work.
AI odbiera wymówki pozwalające siedzieć przed komputerem: spisywać user stories w Jirze, przesuwać piksele w Figmie czy klepać kod w IDE. Kończy się czas, w którym samo sprawne produkowanie tych artefaktów stanowiło istotną część naszej wartości.
Stawiam więc ostatnią tezę: czeka nas renesans tego, o co zawsze chodziło, zanim skomplikowaliśmy sobie produktowy świat: wartość jest w głębokim zrozumieniu prawdziwego problemu. Wygrają ci, którzy są bliżej użytkownika niż ekranu.
