Proof of concept (PoC)

Jedno z dwóch pytań, zależnie od tego, kto używa tej nazwy. W inżynierii PoC odpowiada, czy da się coś zbudować. W sprzedaży technologii i w pracy nad nowym produktem odpowiada, czy rozwiązanie spełni potrzeby odbiorcy i czy warto w nie inwestować. Polskie opracowania zwykle podają tylko pierwsze znaczenie.

Pomaga w tym podział Marty'ego Cagana na cztery ryzyka produktu: czy klienci go kupią albo użyją (wartość), czy sobie z nim poradzą (użyteczność), czy zespół zdoła go zbudować (wykonalność) i czy rozwiązanie działa dla firmy (opłacalność). Zanim zaczniesz budować PoC, nazwij, które z tych ryzyk ma rozstrzygnąć. Cagan uważa ryzyko wartości za zwykle najtrudniejsze.

Z lat 60. Oxford English Dictionary notuje najwcześniejsze użycie w 1967 r. (w dzienniku "Los Angeles Times"), a w przesłuchaniach Kongresu USA z 1969 r. o badaniach lotniczych PoC to faza, w której buduje się i testuje eksperymentalny sprzęt, żeby pokazać wykonalność nowej koncepcji. Później termin przeszedł do kilku branż i w każdej znaczy coś trochę innego:

• Technologia kosmiczna. W skali gotowości technologii NASA model PoC powstaje często na poziomie 3 z 9, na etapie badań laboratoryjnych.
• Farmacja. Według stanowiska PhRMA z 2010 r. PoC to najwcześniejszy moment, w którym dowody wskazują, że lek ma realną szansę powodzenia.
• Sprzedaż technologii. W słowniku sprzedażowym Gartnera PoC to demonstracja, która ma pokazać kupującemu, że produkt spełni jego wymagania.
• Wdrożenia w dużych firmach. Marat Oyvetsky w magazynie PMI opisuje PoC jako próbę przed wyborem dostawcy, zwykle z dwoma albo trzema dostawcami i kryteriami sukcesu uzgodnionymi z interesariuszami.
• Startupy i nowe produkty. PoC bywa też pierwszą działającą wersją pomysłu, pokazywaną pierwszym użytkownikom.

Każde z tych pojęć odpowiada na inne pytanie. PoC sprawdza, czy koncepcja się broni, prototyp pokazuje, jak rozwiązanie ma działać i wyglądać, MVP uczy, jak klienci zachowują się wobec produktu, a pilotaż sprawdza rozwiązanie w realnych warunkach, w małej skali.

Źródła nie są tu całkiem zgodne. W materiałach PMI słowa PoC i pilotaż bywają używane zamiennie, a sprawdzenie koncepcji pada jako jeden z możliwych celów pilotażu. U Cagana prototyp to pojęcie nadrzędne, a PoC techniczny jest jednym z jego rodzajów. W praktyce jedno narzędzie bywa jednym i drugim: działający prototyp, który testujesz z pierwszymi użytkownikami, pełni rolę PoC produktowego.

PoC zaczyna się od pytania i kryterium, a nie od budowy. Najpierw ustalasz, jaką hipotezę sprawdzasz i jaki wynik przesądzi, że pomysł się broni albo że nie. Dopiero potem powstaje najmniejsza wersja, która pozwoli ten wynik zobaczyć.

1. Nazwij pytanie: które ryzyko PoC ma rozstrzygnąć.
2. Ustal kryterium przed budową: z kim testujesz, co sprawdzasz i jaki wynik oznacza "tak".
3. Zbuduj tylko to, co jest potrzebne do odpowiedzi. Resztę można zasymulować albo pominąć.
4. Przetestuj z osobami, które mają ten problem, albo w warunkach, w których mechanizm ma działać.
5. Zapisz decyzję i powód: budujecie dalej, zmieniacie założenia albo odpuszczacie.

Czas zależy od pytania. Cagan pisze, że prototyp na prawdziwych danych często udaje się zbudować w parę dni do paru tygodni.

Gdy problem nie jest jeszcze potwierdzony. PoC sprawdza rozwiązanie, więc jeśli nie wiesz, czy problem istnieje i jak ważny jest dla klientów, pierwszym krokiem jest product discovery: badania i rozmowy z klientami. PoC nie wystarczy też w trzech innych sytuacjach:

• Gdy największe ryzyko dotyczy popytu, a PoC jest tylko techniczny. Alberto Savoia rozdziela pytanie "czy da się to zbudować" od pytania "czy ludzi to zainteresuje".
• Gdy sam działający produkt ma być dowodem, że pomysł ma rynek. Entuzjazm w testach nie jest jeszcze sprzedażą.
• Gdy PoC ma trafić prosto na produkcję. Budowany jest po to, żeby coś rozstrzygnąć, a nie żeby obsłużyć tysiące użytkowników.

Czas i koszt budowy. Działający PoC z bazą danych i logowaniem da się dziś zbudować w narzędziach AI w tygodniach, a nie w miesiącach, więc PoC produktowy przestał wymagać zespołu programistów. Opisuje to hasło vibe coding.

Nie zmieniło się to, co PoC ma rozstrzygnąć. Steve Blank zwraca uwagę, że skoro produkt da się zbudować bez rozmów z klientami, sam produkt nie dowodzi już, że ktoś zrozumiał problem. Szybsza budowa skraca drogę do testu, ale kryterium i rozmowy z użytkownikami dalej trzeba zaplanować.