Product discovery

Pracujemy w kilku spotkaniach roboczych z osobami, które znają problem od strony biznesowej i operacyjnej. Kolejno: kto jest użytkownikiem i jaki ma cel, jak wygląda proces dzisiaj i gdzie się zacina, jakie są ograniczenia — prawne, techniczne, budżetowe — a na końcu co musi znaleźć się w pierwszej wersji, żeby dało się cokolwiek sprawdzić. Wynikiem jest dokument, z którym możesz iść do dowolnego wykonawcy: opis zakresu, szkice kluczowych ścieżek, rekomendacja technologiczna z uzasadnieniem, lista ryzyk i szacunek. Nie zamykamy go na siebie — jeśli po discovery zdecydujesz się budować z kimś innym, dokument nadal ma wartość.

Po Twojej stronie potrzebujemy udziału osób, które faktycznie znają proces — nie tylko przedstawiciela zarządu — oraz dostępu do danych, jeśli istnieją. Po naszej stronie jest prowadzenie warsztatów, opracowanie i rekomendacja.

To krótki etap w porównaniu z budową; jego długość zależy głównie od dostępności osób po Twojej stronie i od tego, ile jest do rozstrzygnięcia.

Zakres warsztatów to mapowanie procesu takiego, jaki jest naprawdę. Do tego business case, priorytetyzacja funkcji MVP i decyzja no-code / custom / hybryda, z rekomendacją stacku, którą potem sami realizujemy. To znaczy, że rekomendacja musi się obronić na etapie budowy, nie tylko w prezentacji. Po stronie badawczej: wywiady z użytkownikami, persony, mapowanie ścieżek i story mapping — w zakresie, który ma sens dla skali projektu, a nie dla objętości raportu.

Tak wyglądała współpraca z PadRes: od warsztatów po gotową stronę i branding dla dewelopera farm OZE.

Discovery najbardziej opłaca się przed startem developmentu — gdy zmiana kierunku kosztuje rozmowę, a nie refaktoring. Drugi typowy moment to produkt, który utknął: użytkownicy nie rosną, zespół dowozi funkcje, a nikt nie potrafi powiedzieć, czemu nie działa całość. Warsztat wyciąga na stół założenia, których od miesięcy nikt nie sprawdził.

Format jest zwarty: od kilku dni do dwóch-trzech tygodni, z jasno umówionym rezultatem. Bez otwartych końców i doradztwa na godziny.

Najcenniejszym wynikiem discovery bywa to, czego nie budujemy: funkcje, które wydawały się kluczowe, a których nikt nie potrzebuje, albo założenia, które prosty test obalił w tydzień. Weryfikujemy hipotezy najtańszym możliwym sposobem — prototypem, ankietą, rozmową z użytkownikami — zanim zamienią się w miesiące developmentu.