Czy potrzebujesz AI product discovery?

AI product discovery wykorzystuje agentów AI, by pomagać liderom produktu i biznesu przejść od problemu klienta do ocenionego przypadku użycia i działającego prototypu, przy czym na każdym etapie decyzje podejmują ludzie.

To ważne właśnie teraz, bo tworzenie oprogramowania bardzo przyspieszyło, ale wciąż nie lepiej oceniamy, co naprawdę warto budować. W lipcu 2026 roku AWS opisał przypadek, w którym zespół liderów Henry Schein One stworzył cztery działające prototypy w mniej niż 24 godziny, z dokładnością, która według firmy normalnie wymagałaby od 8 do 12 tygodni. Poniżej pokazujemy, jak działał ten proces, jaki mechanizm za nim stoi i w jakich miejscach może cię wprowadzić w błąd.

Dlaczego product discovery stało się nowym wąskim gardłem dla zespołów AI-native?

Product discovery stało się wąskim gardłem, bo AI przyspieszyło dostarczanie, ale sama decyzja o tym, co dostarczyć, pozostała w dużej mierze bez zmian. AI-Driven Development Lifecycle (AI-DLC) od AWS zastępuje sprinty „boltami”, czyli cyklami pracy liczonymi w godzinach lub dniach.

Wyżej w procesie niewiele się zmieniło. Lider produktu przez tygodnie zbiera feedback, buduje uzasadnienie biznesowe i spisuje wymagania. Potem ta wizja trafia do zespołu inżynierskiego w formie prezentacji albo specyfikacji. Henry Schein One opisało ten efekt wprost: znikały niuanse, „dlaczego” trzeba było tłumaczyć od nowa na spotkaniach, a kierownictwo nie mogło ocenić wartości pomysłu, dopóki prace nad nim już trwały.

Jeśli zestawisz to z szybkim zespołem dostarczającym oprogramowanie, ekonomia całego procesu się odwraca. Gdy budowanie zajmuje dni, najdroższym błędem staje się szybkie i pewne stworzenie czegoś, czego nikt nie potrzebował, a każde przyspieszenie po stronie inżynierii podnosi koszt słabego procesu discovery.

Co Henry Schein One zmieniło w swoim procesie product discovery?

Henry Schein One obsługuje ponad 100 000 gabinetów stomatologicznych, a jego deweloperzy już wcześniej pracowali z asystentami AI do kodowania. Zespół kierowniczy chciał podobnego wsparcia dla osób decydujących o tym, co budować, dlatego firma wspólnie z AWS wypracowała metodę nazwaną AI Product Discovery and Strategy (AI-PDS). Stosuje ona podstawową zasadę AI-DLC, „AI proponuje, ludzie decydują”, jeszcze przed etapem tworzenia oprogramowania.

Współpraca miała dwie części. Najpierw odbyła się moderowana sesja „Mob Discovery”, podczas której wszystkich 17 senioralnych liderów zdefiniowało kontekst biznesowy, nazwało problemy i ustaliło priorytety przypadków użycia, a AI porządkowało dyskusję. Następnie małe zespoły, po cztery lub pięć osób, brały po jednym priorytetowym przypadku użycia i tworzyły prototyp. AI pomagało im opisać problem, ocenić szanse według ważonych kryteriów i wygenerować specyfikację prototypu. Liderzy nie pisali kodu. Dyskutowali o priorytetach i podejmowali decyzje.

Według AWS ta sesja zaowocowała czterema działającymi prototypami w mniej niż 24 godziny, a dwa z nich zmierzają już w stronę produkcji. Ponieważ AI-PDS bezpośrednio zasila fazę Inception w AI-DLC, zespoły tworzące oprogramowanie zaczynały pracę z pełnym uzasadnieniem każdego priorytetu, a nie tylko z dokumentem przekazania.

Najbardziej wymowny szczegół dotyczy tego, jak zmieniła się rozmowa w sali. Liderzy przestali opisywać to, co sobie wyobrażali, i zaczęli mówić: „pokażę ci”.

Jak AI product discovery działa w praktyce?

AI product discovery działa tak, że zamienia każdy pomysł produktowy w tani artefakt, który da się przetestować, i zapisuje, dlaczego go zachowano albo odrzucono. To właśnie nadaje temu procesowi „naukowy” charakter: hipoteza staje się prototypem, prototyp dostarcza dowodów, a dowody prowadzą do decyzji, pod którą ktoś musi się podpisać.

AI-PDS obejmuje sześć etapów: envisioning (problemy i głos klienta), przyjmowanie przypadków użycia, priorytetyzację, prototypowanie, strategię produktową i go-to-market. Otwarta przykładowa implementacja AWS, AI-PLC na GitHubie, realizuje ten proces jako prowadzony workflow w Claude Code lub Kiro. Warto przejąć trzy jej mechanizmy, nawet jeśli nigdy nie sięgniesz po to repozytorium.

Pierwszy to bramki akceptacyjne: agent przygotowuje szkic i zadaje pytania doprecyzowujące, a człowiek odpowiada i zatwierdza wynik przed przejściem do kolejnego etapu, dzięki czemu osąd pozostaje po stronie osoby odpowiedzialnej za rezultat. Workflow zapisuje też każdą decyzję i każdy wkład do pliku audytowego. Po sześciu miesiącach możesz sprawdzić, dlaczego przypadek użycia B wygrał z przypadkiem użycia A i czy to rozumowanie się obroniło. Każdy prototyp dostaje też przenośną specyfikację w markdownie, którą może przejąć dowolny zespół dostarczający oprogramowanie, i właśnie tak kontekst przetrwa przekazanie.

W porównaniu z klasycznym procesem różnica dotyczy głównie tego, co uznajesz za dowód i ile czasu zajmuje jego zdobycie:

Jak AI product discovery wygląda poza dużą organizacją klasy enterprise?

Ten sam schemat działa także u first-time foundera bez 17-osobowego zespołu kierowniczego. Monterail współpracował z założycielem z brytyjskiej branży budowlanej nad platformą AI do analizy kosztów w finansach budowlanych, produktem, który musiał zdobyć zaufanie CFO i rad nadzorczych.

Discovery zaczęło się od warsztatów opartych na hipotezach. Każda hipoteza o tym, jak powinno działać zarządzanie kosztami budowy, stawała się funkcją prototypu, a każdy prototyp stawał się dowodem, który założyciel mógł pokazać interesariuszom. Interaktywny prototyp wspierany przez AI był gotowy dwa tygodnie po kick-offie. MVP powstało trzy miesiące później przy budżecie 500 godzin, bez poprawek po dostarczeniu, i pozytywnie przeszło pierwszą ocenę pilota na poziomie CFO oraz rady nadzorczej.

Bardziej pouczający moment przyszedł później. Podczas przygotowań do pilotażu zespół odkrył, że dane księgowe pierwszego klienta są zbyt niepełne i niespójne, by warstwa AI mogła działać na nich wiarygodnie. Zespół wstrzymał wdrożenie AI, zamiast wypuszczać wyniki, które mogłyby wprowadzić radę nadzorczą w błąd. Szybkie prototypowanie nadało produktowi właściwy kształt, a powstrzymanie AI do momentu, aż dane będą mogły je realnie wesprzeć, ochroniło wiarygodność platformy w oczach rady.

Jakie są ryzyka i ograniczenia AI product discovery?

Największym ryzykiem jest pomylenie szybkości z walidacją. Prototyp zbudowany w jeden dzień pokazuje, że da się nadać pomysłowi konkretną formę. Nie pokazuje jednak, że klienci będą chcieli za niego zapłacić, a opublikowane wyniki Henry Schein One mierzą liczbę prototypów i kandydatów do wdrożenia produkcyjnego, a nie efekty rynkowe.

Dopracowanie tworzy własny problem. Działająca aplikacja przekonuje znacznie bardziej niż slajd i właśnie dlatego może zbyt wcześnie popchnąć zespół do zgody. Zespoły przywiązują się też do rzeczy, które same zbudowały, nawet jeśli zajęło to tylko jeden dzień. Ustal kryteria odrzucenia, zanim prototyp w ogóle powstanie, i pokaż go realnym użytkownikom, zanim ktokolwiek zatwierdzi budżet.

W regulowanych branżach, takich jak stomatologia, dane i zgodność z przepisami wyznaczają twarde granice. Przykład AWS mówi wprost, że służy wyłącznie do celów eksperymentalnych i edukacyjnych oraz że wygenerowane aplikacje działają lokalnie, bez warstwy uwierzytelniania. To w porządku na warsztaty, ale nie w przypadku prawdziwych danych pacjentów ani danych finansowych. Jeśli twoje prototypy muszą korzystać z danych produkcyjnych, żeby były przekonujące, potrzebujesz zbiorów zanonimizowanych lub pozbawionych danych identyfikacyjnych, środowiska uwzględniającego wymagania HIPAA- lub RODO- oraz osoby, która bierze za tę decyzję odpowiedzialność. Jak pokazał pilotaż w finansach budowlanych, słaba jakość danych może sprawić, że funkcja AI będzie wyglądać gorzej, niż jest w rzeczywistości, albo lepiej.

Sesja Henry Schein One także była prowadzona z udziałem AWS, a jednorazowe warsztaty są łatwiejsze niż wyrobienie trwałego nawyku. Trudniejsza część polega na tym, by discovery oparte na dowodach stało się sposobem podejmowania decyzji o roadmapie w każdym kwartale, z dziennikiem decyzji, który ludzie naprawdę czytają, i zespołem dostarczającym oprogramowanie, który potrafi przejąć specyfikację prototypu i od razu z nią pracować.

Jak zespoły produktowe mogą zacząć z AI product discovery?

Zacznij od małej skali, od jednej decyzji, którą i tak musisz podjąć. Wybierz jeden problem, do którego twoje kierownictwo ciągle wraca, i przeprowadź go przez cały cykl:

1. Zapisz hipotezę, osoby, którym ma służyć, i metrykę, która mogłaby ją obalić.

2. Pozwól agentowi przygotować przypadki użycia i ocenić je według kryteriów, na które zgadza się twój zespół, a potem dyskutuj z tymi ocenami.

3. Stwórz prototyp jednego lub dwóch najlepszych pomysłów w kilka dni, nie tygodni, na danych syntetycznych lub pozbawionych danych identyfikacyjnych.

4. Pokaż je realnym użytkownikom, zanim zobowiążesz się do budowania.

5. Zapisz decyzję i jej uzasadnienie, a zespołowi inżynierskiemu przekaż pełną specyfikację zamiast podsumowania.

Otwarty workflow AI-PLC to sensowny szablon na start, bo opiera się na prostym markdownie, który możesz dostosować do własnego frameworka priorytetyzacji. Potraktuj go jak rusztowanie, a narzędzia produkcyjne buduj osobno.

Co jest potrzebne, żeby AI product discovery się przyjęło?

AI product discovery zaczyna się opłacać wtedy, gdy zmienia sposób podejmowania decyzji o roadmapie. Szybsze prototypy to tylko najbardziej widoczna część. Potrzebujesz liderów gotowych przyjąć, że prototyp może pokazać ich błąd, danych na tyle czystych, by funkcje AI były wiarygodne, oraz zespołu dostarczającego oprogramowanie, który w poniedziałek przejmie specyfikację i zachowa całe stojące za nią rozumowanie.

Monterail prowadzi warsztaty discovery i szybkie prototypowanie AI dla zespołów, które chcą przetestować pomysły przed podjęciem decyzji o pełnym budowaniu, a potem przenosi te zwalidowane do produkcji. Jeśli w twoim zespole jest decyzja produktowa, do której wciąż wracacie, porozmawiajmy o tym, jak zamienić ją w coś, co da się przetestować.