STRATEGIA PRODUKTU I WERYFIKACJA POMYSŁÓW
Strategia produktu i technologii, szybkie prototypowanie wspierane przez AI oraz niezależna ocena techniczna, po to by ograniczyć niepewność, zanim padnie decyzja o pełnym developmencie.
OBSZARY DZIAŁANIA
Ustalenie, co produkt naprawdę ma robić, dla kogo, i czy w ogóle warto go budować.
Zamiana koncepcji w działający prototyp na tyle szybko, by przetestować ją, zanim stanie się większym zobowiązaniem inżynieryjnym.
Niezależne, neutralne wobec dostawców spojrzenie na projekt systemu, istniejącą architekturę albo cudzą propozycję.
Generatywna AI i agenci tam, gdzie realnie rozwiązują problem, a nie dlatego, że roadmapa wymaga gdzieś obecności AI.
PUNKTY WYJŚCIA
PODEJŚCIE
Zaczyna się od problemu, kontekstu biznesowego, użytkowników i ograniczeń, a nie od wybranej z góry technologii.
Najbardziej ryzykowne założenie jest identyfikowane wcześnie. To zwykle ono decyduje, czy projekt się uda.
W zależności od pytania oznacza to prototyp, analizę systemu albo przegląd architektury, cokolwiek faktycznie na nie odpowiada.
Założenie jest testowane na czymś realnym: użytkownikach, danych albo działającym systemie, a nie na opiniach z sali konferencyjnej.
Efektem jest decyzja: budować, zmienić zakres, poczekać albo zrezygnować. Każda z nich może być tą właściwą.
WYBRANE DOŚWIADCZENIE
Celowo zanonimizowane: bez nazw klientów i poufnych liczb. Opisy pokazują rodzaj pracy i rodzaj dostarczonej wartości.
Founder miał jasny pomysł i dobre rozeznanie w rynku, ale poza tym tylko prezentację. Rozmowy z potencjalnymi inwestorami i partnerami utykały zawsze w tym samym miejscu: co to właściwie robi.
Skoncentrowany prototyp jednego, najważniejszego przepływu, zbudowany z pomocą AI w kilka dni zamiast tygodni, na realistycznych danych przykładowych zamiast prawdziwego backendu.
Pomysł zamienił się w coś, co dało się przeklikać i skomentować. Znacząco skrócił się też pierwotny zakres: nie każda funkcja z pierwszego planu przetrwała kontakt z działającą wersją.
Dwie osoby w tej samej organizacji nie zgadzały się co do podejścia technicznego dla nowego pomysłu na produkt. Obie strony miały sensowne argumenty i żadna nie zamierzała ustąpić wyłącznie na słowo.
Zbudowanie małych, działających wersji obu podejść okazało się szybsze niż dalsza dyskusja. Jedna z wersji w kilka dni pokazała kompromisy nie do przegadania. Decyzja, która zapadła, bardziej odpowiadała jednej stronie niż drugiej, ale opierała się na czymś konkretnym.
Organizacja zaplanowała dość duży produkt wokół jednej flagowej funkcji, opierając się głównie na wewnętrznym przekonaniu, a nie na dowodach od użytkowników.
Czy ta flagowa funkcja rzeczywiście była powodem, dla którego ludzie mieliby korzystać z produktu, czy tylko powodem, dla którego łatwo się ją prezentowało wewnątrz firmy.
W praktyce użytkownicy w większości ignorowali flagową funkcję i wracali do mniejszego, drugorzędnego przepływu.
Zakres został mocno zredukowany wokół tego mniejszego przepływu. Część tej zmiany była niewygodna dla osób, które zdążyły się już zaangażować w pierwotny plan, ale nowa wersja była czymś, z czego ludzie rzeczywiście korzystali.
Organizacja szykowała się do podpisania wielomiesięcznego kontraktu developerskiego na podstawie propozycji dostawcy, która wyglądała solidnie i odpowiednio kosztowała.
Niezależny przegląd techniczny podważył proponowaną architekturę, rozłożył wycenę na czynniki pierwsze i uszeregował ryzyka, zamiast przyjąć propozycję w ciemno.
Kilka pozycji w wycenie po bliższym sprawdzeniu okazało się słabo uzasadnionych. Kontrakt przebudowano na etapy z jaśniejszymi punktami kontrolnymi przed kolejną płatnością.
O MNIE
Większość produktów cyfrowych nie przegrywa przez kod. Przegrywa, bo biznes i inżynieria oprogramowania nigdy nie ustaliły, co produkt właściwie ma robić.
Znam obie strony tego rozdźwięku: pisałem oprogramowanie, prowadziłem zespoły inżynierskie i odpowiadałem za biznesową stronę projektów technologicznych w organizacjach międzynarodowych. Z tego połączenia wzięło się minicki consulting.
Większość pracy dzieje się na wczesnym etapie, zanim padnie decyzja o poważnym budżecie na kierunek, który może się okazać błędny: zdefiniowanie problemu, sprawdzenie najbardziej ryzykownego założenia i, tam gdzie to najszybsza droga do odpowiedzi, zbudowanie prototypu.
Development wspierany przez AI, łącznie z agentami kodującymi, jest dziś częścią tego procesu. Zmienia głównie czas: prototyp w kilka dni zamiast kilku miesięcy, a nie rodzaj podejmowanej decyzji.
LAB
To eksperymenty i prototypy budowane po to, by się uczyć, a nie gotowe produkty.
ZASADY
KONTAKT
Zwykle wystarczy krótki, konkretny opis sytuacji: pomysł na produkt, decyzja o tym, czy coś budować, propozycja od dostawcy albo pomysł na AI, który wciąż jest mglisty.