- Product Craft
- Posts
- Design Sprint - FAQ z praktykiem (Marcin Chyła)
Design Sprint - FAQ z praktykiem (Marcin Chyła)
Kiedy stosować, najczęstsze błędy, jak robić problem framing, jak wykorzystać AI przy Design Sprintach?
Desing Sprinty, czyli metoda do szybkiego projektowania i testowania nowych pomysłów spopularyzowana przez Google. Większość kojarzy czym są Design Sprinty, sporo „ekspertów” o nich odpowiada, ale... niewielu realnie stosuje i ma praktyczne doświadczenia.
Najpierw podzieliłem się własnym wstępem teoretycznym i moimi doświadczeniami z Design Sprintów. Potem miałem okazję porozmawiać o nich w podcaście Product Vision z ekspertem i praktykiem - Marcinem Chyłą (ma na swoim koncie ma już kilkanaście Design Sprintów).
Podczas podcastu oraz naszych rozmów z Marcinem pojawiło się tak dużo praktycznych pytań i wątków, że żebraliśmy je w formę 💬 dodatkowe FAQ o design sprintach:
Kiedy pierwszy raz wykorzystałeś Design Sprint w praktyce?
W jakich sytuacjach warto wykorzystać Design Sprint? Kiedy sam go wykorzystywałeś najczęściej?
Jak przekonywać firmę, interesariuszy do wykorzystania Design Sprintów?
Jaki najczęstszy błąd widzisz przy realizacji Design Sprintów?
Design Sprint, a Product Discovery - czy warto je łączyć?
🔐 Czy powinniśmy zakładać znalezienie rozwiązania problemu w jednym Design Sprincie, czy od razu powinniśmy planować wiele iteracji?
🔐 Jak przygotować zespół do Design Sprintu? Czy zespół powinien poznać rozwiązywany problem wcześniej?
🔐 AI przy Design Sprintach - jak wykorzystać?
🔐 Gdzie szukać więcej info o Design Sprint? Co polecasz?
ℹ️ Więcej wartościowych treści od Marcina znajdziesz na jego profilu LinkedIn oraz blogu DesignSprinter.pl
Q: Kiedy pierwszy raz wykorzystałeś Design Sprint w praktyce?
3-4 lata temu wpadła mi w ręce książka J.Knapp’a pt.: „Pięciodniowy sprint. Rozwiązywanie trudnych problemów i testowanie pomysłów”. Przeczytałem i bardzo chciałem wypróbować tę metodę.
Byłem wtedy Product Managerem. Pracowałem ze świetnym zespołem developerskim. Zaprosiłem ich do tego eksperymentu.
Dostarczaliśmy wtedy API dla pewnej usługi, ale parę razu pojawiła się sugestia stworzenia interfejsu użytkownika. Tematy UI-owe są dość wdzięcznymi tematami dla sprintów. Ale nie jedynymi.
Sprint zakończył się prototypem i testami. Aplikacja działa do dziś! Pierwszy Sprint nie był jednak idealny. Co zrobiłbym inaczej? Teraz zadbałbym o większe zróżnicowanie w zespole Sprintowym.
Q: W jakich sytuacjach warto wykorzystać Design Sprint? Kiedy sam go wykorzystywałeś najczęściej?
Kiedyś policzyłem koszt jednego ze Sprintów. Było to około 150 h. Kiedy przemnożymy to przez stawkę godzinową specjalisty IT okaże się, że Sprint nie jest tanim procesem.
Dążę do tego, że Sprint warto uruchamiać dla perspektywicznych inicjatyw, które mają potencjalnie duży IMPACT. Nowa opcja czy nowy ficzer w istniejącym już produkcie może nie być warta zainwestowanego takiego czasu.
Sprinty świetnie sprawdzają się w warunkach dużej niepewności. Dzięki zaangażowaniu wielu różnych ról pozwala holistycznie podejść do problemu czy pomysłu biznesowego. Właśnie ta mnogość ról umożliwia nam dostrzeżenie i mitygację różnych ryzyk, tych technicznych, kosztowych, użytecznościowych.
Sprinty polecam także wszystkim startupowcom - dla nich poniekąd ta metoda została przygotowana w Goole Ventures.
Q: Jak przekonywać firmę, interesariuszy do wykorzystania Design Sprintów?
Często używam argumentu, że lepiej po 4-5 dniach „zaorać” jakiś pomysł przy zaangażowaniu 6-7 osób, niż dowiedzieć się braku zasadności realizacji tego produktu po 4 czy 5 miesiącach developmentu w 2 zespołach developerskich.
Warto czasem także odwołać się do kultury naszej organizacji. Jeśli organizacja, na sztandarach niesie wartości „Eksperymentowanie”, „Szybkie uczenie się i wyciąganie wniosków” czy „Innowacyjność” to można tych fraz użyć podczas negocjacji: „Skoro to są nasze wartości, to sprinty idealnie się w nie wpisują.”
Na koniec klasyczne argumenty praktyczne - dzięki Sprintowi:
w 4-5 dni, połączymy siły różnych ról i specjalistów, aby przygotować innowacyjne rozwiązanie problemu (ko-kreacja, współtworzenie),
dzięki makiecie i badaniu szybko wyciągniemy wnioski;
i oczywiście skrócimy pętlę zwrotną od użytkowników i interesariuszy - szybciej będziemy wiedzieli czy nasz pomysł ma sens.
Q: Jaki najczęstszy błąd widzisz przy realizacji Design Sprintów?
Wskazałbym tutaj to, że największym błędem jest nietraktowanie Sprintu z należytą powagą. Sprint odniesie sukces tylko, gdy zespół będzie w 100% zaangażowany w ten proces. Oznacza to pełną dostępność w te 4 czy 5 dni. Dotyczy to także osób zaproszonych w charakterze ekspertów.
💬 Komentarz od Tomka:
Dodałbym, że jednym z najczęstszych błędów, który obserwuję przy realizacji Design Sprintów, oprócz braku pełnego zaangażowania, jest niewłaściwe określenie celu sprintu.
👉 Często zespoły wchodzą w proces Design Sprintu bez jasno zdefiniowanego, konkretnego celu, co zwykle prowadzi do rozmycia naszej pracy i braku efektów.
👉 IMHO kluczowe jest, aby przed rozpoczęciem sprintu (lub pierwszego dnia) zrobić problem framing - precyzyjnie określić, co chcemy osiągnąć, jakie pytanie badawcze ma być rozwiązane, lub jakie konkretne wyzwanie stojące przed produktem ma być adresowane.
👉 Bez wyraźnego celu, zespół Design Sprintowy może łatwo zboczyć z kursu, tracąc cenny czas na dyskusje i zadania, które nie przyczyniają się bezpośrednio do rozwiązania właściwego problemu.
Q: Design Sprint, a Product Discovery - czy warto je łączyć?
Przypomnijmy sobie co na temat discovery mówi Marty Cagan:
First, you need to discover whether there are real users out there that want this product… Second, you need to discover a product solution to this problem that is usable, useful, and feasible.
Wg mnie, Sprint jest idealnym narzędziem, które może w procesie product discovery wykorzystać:
Realni klienci i ich feedback o potencjalnym produkcie lub usłudze na podstawie makiety? Checked ☑️.
Zaadresowanie ryzyk pilności, wykonalności, użyteczności poprzez multidyscyplinarny zespół, poprzez rozmowy z ekspertami? Checked ☑️.
Więcej o swoich doświadczeniach z łączeniem Design Sprintów z Discovery i pracą Scrumową pisał Tomek:
Reply