Pogłębiając ostatnio obszary związane z obszarem product discovery, zdecydowałem się przeczytać książkę “Sprint”, napisaną przez Jake’a Knapp’a, który spędził 10 lat pracując w Google oraz z Google Ventures.

Zanim pomyślisz “Ileż można o tych Sprintach! Ten Wieczorek już kompletnie zatracił się w tych swoich labiryntach…”, poczekaj chwilę :)

W tym wpisie, będę się posługiwał zwrotem “Design Sprint”, mając na myśli Sprint w rozumieniu książki Jake’a Knapp’a, a nie Sprint, będący częścią frameworka Scrum.

Co to jest “Design Sprint” wg. Jake’a Knapp’a?

W dużym uproszczeniu, Design Sprint to koncepcja, która pozwala w pięć dni rozwiązać dowolny problem biznesowy.

Jakie rozwiązania mam na myśli? Przykładowo: robot obsługujący gości hotelowych, klinika medyczna przyjazna dzieciom czy raport pozwalający specjalistom onkologii podejmować decyzje dotyczące leczenia pacjenta, to przykładowe prototypy rozwiązań opisanych w książce.

Jak widać są to prototypy rozwiązujące problemy zróżnicowanych branż, co jest mocnym atutem Design Sprintu. Podobnie jak dzisiaj Scrum, Design Sprint promowany jest jako narzędzie działające niezależnie od tego, co jest naszym produktem.

Z czego składa się Design Sprint?

Rozkładając Design Sprint na konkretne dni, wygląda to następująco:

Na początku tygodnia definiujemy problem, pracujemy nad nim przez kolejne dni, aby w piątek testować prototyp z potencjalnymi klientami naszego rozwiązania.

1. W poniedziałek definiujemy problem biznesowy
2. We wtorek przygotowujemy potencjalne rozwiązania problemu
3. W środę definiujemy plan działania i realizacji prototypu
4. W czwartek budujemy prototyp rozwiązania
5. W piątek przeprowadzamy wywiady z użytkownikami, którym pokazujemy prototyp

Dlaczego trafia do mnie “Sprint”?

Nie muszę chyba pisać stałym czytelnikom, jak bardzo rezonują ze mną tego rodzaju koncepcje. Krótkie iteracje, szybkie dostarczanie wartości, product discovery to obszary, na które zwracam szczególną uwagę w swojej codziennej pracy z klientami.

Przykładowo — ostatnio, w ciągu jednego dnia pracy z top-managementem firmy kompletnie nie związanej z IT, zrealizowałem trzy 120-minutowe Sprinty. Była to odpowiedź na potrzebę “praktycznego doświadczenie Scruma na realnym przykładzie”. W efekcie pracy uzyskaliśmy przyrost realnego produktu, który na koniec dnia został omówiony z pracownikami firmy (interesariuszami) na sesji Przeglądu Sprintu.

Dlaczego podałem ten przykład? Propozycja twórcy “Sprintu” brzmiąca: “w pięć dni przejdź od problemu do testu prototypu rozwiązania z klientem” nie jest dla mnie wywróceniem świata do góry nogami. Jest jednak dla mnie świetnym uzupełnieniem sposobu myślenia oraz posiadanego wachlarza technik oraz podejść. Ilość przykładów, metafor oraz głębia omówienia tego, jak budować prototypy zaciekawiła mnie na tyle, że zdecydowałem się napisać ten krótki artykuł.

Nie będę opisywał krok po kroku treści książki. Zainteresowanych jak działa Design Sprint w detalach (dzień po dniu, krok po kroku) odsyłam na stronę książki. Dodam tylko, że oprócz samej idei Design Sprintu, autorzy przemycają masę wskazówek moderacyjnych, które można od ręki wykorzystać w pracy. Jeśli na codzień wchodzisz w rolę facylitatora, na przykład jako Scrum Master, Agile Coach czy lider — zdecydowanie polecam przeczytać.

No dobrze, to co z tymi prototypami?

Wracając do tematu prototypów. Moje trzy najważniejsze lekcje, które wynoszę w tym temacie po przeczytaniu książki to:

1. Konieczna jest zmiana mentalna i oduczenie się “starego” sposobu myślenia. Zbudowanie prototypu rozwiązania wymaga zmiany tego, jak myślimy o wykonywaniu pracy. Minimalizm zamiast perfekcji. Tymczasowe rozwiązanie zamiast docelowego. Myślenie “tu i teraz” zamiast myślenia długofalowego. W ten oto sposób “nie da się” w praktyce zamieniamy na “da się”. Przykładowo, klikalny prototyp aplikacji można sprawnie przygotować w PowerPoincie/Keynocie, produkty fizyczne można na szybko wydrukować w 3D, a prototyp fizycznej przestrzeni (np. biuro, sklep, lobby) można niedużym kosztem czasowym prowizorycznie przygotować, modyfikując istniejącą przestrzeń.
2. Iluzja produktu jest wystarczająca, aby przeprowadzić test z użytkownikami. Budynki w westernach z zewnątrz wyglądają na prawdziwe, ale tak naprawdę to tylko fasada: zwykle wyłączanie imitacja ściany frontowej. Pomimo tego, wciągamy się w scenariusz, a wrażenie budowane przez fasady jest wystarczające na potrzeby filmu. Podobnie jest z naszym produktem — potrzebujemy do testów wyłącznie fasady, iluzji oraz pozorowania, które sumarycznie zbudują wystarczające dobre wrażenie realizmu, pozwalające nam przeprowadzić test z użytkownikiem. Zbyt mało realistyczny prototyp nie wystarczy, żeby przekonać użytkowników, że to prawdziwy produkt. Zbyt mocno szczegółowy prototyp to z kolei zbyt duża inwestycja czasowa. Szukamy czegoś po środku, co będzie wystarczająco dobre i nic ponad to.
3. Szybkie budowanie i testowanie prototypów chroni nas przed emocjonalnym związkiem z potencjalnym rozwiązaniem. Im dłużej pracujemy nad prototypem rozwiązanie, tym bardziej czujemy się z nim związani. Ma to negatywny wpływ na percepcję rezultatów z testów. Nasza mentalność zmienia się wraz z upływem czasu — im dłużej spędzamy czas nad rozwiązaniem, tym bardziej prawdopodobne jest myślenie, że to nie rozwiązanie jest błędne/do poprawy, tylko “nasi klienci tego nie rozumieją”.

Podsumowanie

Przygotowanie prototypu rozwiązania problemu biznesowego pozwala szybko przekonać się, czy pomysł jest właściwy. Umożliwia w krótkim czasie i niewielkim kosztem zdobyć wiedzę, która pomaga podjąć decyzję, czy warto realizować pomysł.

Zdecydowanie jest to wiedza, którą warto zdobyć, w szczególności, gdy pracujemy w rolach produktowych (Product Manager, Product Owner), a także gdy jesteśmy osobami decyzyjnymi w dowolnego rodzaju biznesie.

Photo by José Alejandro Cuffia on Unsplash