1. Zakres artykułu

Kiedy opłaca Ci się to przeczytać?

• Chcesz zrobić wystąpienie publiczne. Lub przygotować szkolenie. Lub napisać artykuł.
• Chcesz zrobić to dobrze, ale nie wiesz, co to znaczy “dobrze”. Nie wiesz, jak zareagują odbiorcy. Nie wiesz, jak zacząć.
• Chcesz ograniczyć stres związany z wystąpieniem publicznym i ryzyko, że coś się nie uda - nawet, jeśli nie uważasz się za dobrego mówcę.

Rozpatruję tematy takie jak:

• Projektowanie wystąpienia (szkolenia) pod kątem wartości dla odbiorcy
• Weryfikacja wystąpienia (szkolenia) pod kątem założeń - czy osiągnie to, co zaplanowano?
• Konstruowanie wystąpienia pod istniejący cel przy użyciu szablonu

2. Dlaczego proponuję takie podejście do budowy wystąpienia?

2.1 Dlaczego?

W ciągu ostatnich pięciu lat przeprowadziłem ponad 2500 godzin szkoleń i prezentacji w roli trenera (nie licząc czasu na przygotowanie). Technika, którą dzisiaj opisuję jest tą, którą sam wykorzystuję do projektowania własnych szkoleń.

Podczas pracy nad prezentacjami i szkoleniami mój cel jest prosty:

Jeżeli coś przygotowuję, to chcę…

• …by to co robię komuś pomogło - w innym wypadku marnuję czas odbiorców i ich nie zainteresuję.
• …by odbiorcy jak najszybciej widzieli korzyści dla siebie - jeśli odbiorcy widzą własne postępy, są bardziej zmotywowani do dalszej pracy.
• …by szkolenie przydało się w codziennej pracy odbiorców - jeśli odbiorcy widzą jak mogą natychmiast wykorzystać prezentowane techniki to są w stanie je ćwiczyć.
• …włożyć jak najmniej energii i wywołać jak największy efekt - w innym wypadku marnuję czas, energię i zasoby.
• …móc weryfikować skuteczność i przydatność szkolenia - dzięki temu mogę lepiej usprawnić swoje szkolenia.

Jest zaprojektowana pod kątem tych pięciu punktów powyżej.

2.2 Jak wykorzystać ten artykuł?

Jeżeli chcecie zrobić prezentację/ szkolenie przekazujące wiedzę:

• Punkt ‘3’ jest czystym przepisem. Jest suchą procedurą: wpierw zrób X, potem Y, potem Z.
• Punkt ‘3’ jest jedynym, do którego będziecie wracać tworząc prezentację
• Punkt ‘4’ jest przykładem, by lepiej zrozumieć punkt ‘3’. Przeczytacie go najpewniej raz.
• Punkt ‘5’ jest wyjaśnieniem dla ciekawych. Jeśli chcecie wiedzieć, czemu ‘3’ jest złożone tak jak jest, to tam są odpowiedzi. Część z Was go przeczyta.

Pozostałych punktów nie omawiam ;-).

3. Procedura budowania wystąpienia publicznego:

3.1. Projektowanie szkicu

By zbudować szkic wystąpienia odpowiedzcie na parę pytań. Najlepiej zapiszcie odpowiedzi gdzieś na kartce papieru; idealnie, chcecie 2-5 zdań na każde z pytań poniżej:

1. O czym chcę powiedzieć? Co chcę im pokazać? Czego chcę ich nauczyć? Co chcę im dać?
2. Kto jest moim odbiorcą?
   1. Kim są ci ludzie? Czym się zajmują? Jakie role pełnią?
   2. Czy da się ich podzielić na silnie zróżnicowane grupy? Jeśli tak, rozpatrujcie te grupy osobno.
   3. Czy ludzie, o których myślicie będą większością populacji na sali?
   4. Co ci ludzie robią? Jakie działania wykonują? Jakie czynności?
3. W ramach tego co moi odbiorcy robią:
   1. Gdzie zyskują korzyści (jakaś forma kapitału lub czas)? Co przyniosłoby im najwięcej korzyści?
   2. Co ich boli? Co ich denerwuje? Czego się boją? Czego nie chcą robić, a muszą? Jak bardzo dotkliwy jest to ból?
4. W jaki sposób to, co chcę powiedzieć (nauczyć, dać) sprawia, że:
   1. Uzyskują większe korzyści. Mają więcej czasu (tracą go mniej?). Mają więcej pieniędzy (tracą ich mniej?). Lepiej wyglądają w oczach innych.
   2. To, co ich boli staje się mniej dotkliwe. Boli mniej. Mają mniej powodów do strachu. Są mniej zdenerwowani. Nie muszą robić rzeczy, których nie chcą.
5. Po czym odbiorcy poznają, że warto było przyjść?
   1. Po czym poznają, że to, co powiem uśmierza ich ból? To musi być coś namacalnego i obserwowalnego.
   2. Po czym poznają, że dostarczyłem im korzyści?
   3. Jak mogą wykorzystać nowo nabytą wiedzę w codziennych działaniach?

3.2. Weryfikacja szkicu pod kątem spójności

W ramach pracy nad szkicem (punkt 3.1 “Projektowanie szkicu”) najprawdopodobniej zorientujecie się, że niektóre rzeczy do siebie nie pasują. Częste przypadki, z którymi się spotkałem:

• Nie mam pojęcia, po co ta konkretna grupa odbiorców miałaby wykorzystywać to, co chcę im pokazać. A już w ogóle jak mówimy o codziennym życiu (lub w pracy).
• Chcę opowiedzieć o czymś, co mi się podoba - ale to zupełnie nie uśmierza bólu moich odbiorców.
• Mam problemy z “obserwowalnością”. To im się przyda, ale nie będą mogli tego udowodnić.

Wtedy czeka Was przebudowanie Waszej koncepcji. Możecie przebudowywać wszystkie punkty szkicu, jak długo ostateczny wynik będzie spójny sam ze sobą.

Punkt 3.1 “projektowanie szkicu” jest zakończony sukcesem wtedy i tylko wtedy, gdy:

• Każde z tych pięciu pytań ma odpowiedzi. Odpowiedzi są spójne i logiczne.
• Istnieją obserwowalne korzyści dla odbiorców i są to korzyści, które odbiorcy potrafią wykorzystać.
• Potraficie powiedzieć, jak odbiorcy będą potrafili przełożyć Wasze wystąpienie na obniżenie bólu, podniesienie kapitału lub oszczędność czasu. Wszystko w codziennym działaniu.

Póki nie macie spełnionych powyższych punktów, wracacie do 3.1.

3.3. Szablon wystąpienia

Ta część dotyczy już raczej prezentacji i wystąpień publicznych.

Nie jest to jedyna możliwa struktura wystąpienia publicznego, ale w rękach mniej doświadczonego prelegenta silnie rekomenduję użycie struktury takiej jak ta poniżej. Ta struktura wzmacnia następujące efekty:

• Odbiorcy (ci z punktu 3.1) od samego początku wiedzą, czemu Was słuchać i są zainteresowani
• Idąc strukturą “problem -> rozwiązanie” odbiorcy nie gubią kontekstu tego, o czym mówicie
• Odbiorcy widzą, jak mogą wykorzystać to w codziennym życiu - opłaca im się Was słuchać

Sam szablon wygląda w następujący sposób:

1. Przedstawienie się
2. Zaprezentowanie korzyści
   1. Uświadomienie 2-3 punktów bólu (lub 2-3 korzyści)
   2. Pokazanie, że ból da się uśmierzyć (lub zmaterializowanie tych korzyści)
3. Agenda wystąpienia. “Spis treści”.
4. Problem -> Rozwiązanie #1
   1. Pokazanie problemu łącznie z zaznaczeniem bólu. W ramach przykładu.
   2. Skąd bierze się ból? Czemu jest to problem?
   3. Jak można ten ból rozwiązać Waszym narzędziem?
   4. Kontynuacja przykładu i uśmierzenie bólu narzędziem.
   5. Pokazanie odbiorcom jak mogą zrobić to w codziennej pracy.
5. Problem -> Rozwiązanie #2
   1. Tak samo jak w #1.
   2. Najlepiej, kontynuując przykład #1: “pojawił się nowy problem”
6. Problem -> Rozwiązanie #N (kontynuujcie zgodnie z czasem)
7. Podsumowanie
   1. Przypomnienie bólu z początku prezentacji
   2. Udowodnienie / pokazanie, że ból został zaleczony
   3. Przypomnienie, jak odbiorcy mogą tego użyć w codziennej pracy
8. Podziękowanie
   1. Ewentualnie, źródła i materiały dodatkowe

Teraz wykorzystajcie powyższy szablon i uzupełnijcie go o koncepty, które wypracowaliście w punkcie (3.1).

3.4. Wypełnienie szablonu i estymacja czasu

Pytanie: ile struktur “Problem->Rozwiązanie” wprowadzić do tego powyższego szablonu? Ile bólu uśmierzyć?

Odpowiedź kryje się w estymacji czasu prezentacji. Wyobraźmy sobie, że prowadzimy 45-minutową prezentację:

Co jest mówione	Ile to potrwa
Przedstawienie się + prezentacja korzyści + agenda	5 minut
Podsumowanie i podziękowania	5 minut
Rezerwa czasowa (spóźnienia, coś nie działa…)	5-10 minut

Zostaje nam 25-30 minut.

Spójrzmy teraz na pojedynczą strukturę typu “Problem->Rozwiązanie”:

Co jest mówione	Ile potrwa
Przykład pokazujący ból	2-5 minut
Wyjaśnienie bólu i rozwiązanie go narzędziema	5-8 minut
Wyjaśnienie, jak odbiorcy mogą wykorzystać to w praktyce	2-3 minuty

Czyli pojedyncza struktura Problem->Rozwiązanie zajmuje około 10-15 minut. Wybieramy 2-3 najważniejsze:

• Jeżeli pójdzie szybciej i lepiej, omówimy trzy.
• Jeżeli mamy mniej czasu/ idzie nam wolniej/ opóźnił się poprzedni prelegent, omówimy dwie.

3.5. Budowa slajdów / ćwiczeń i ich weryfikacja

Kolejnym krokiem jest już zbudowanie ćwiczeń lub prezentacji.

Po zrobieniu powyższego - spójrzcie na prezentację krytycznym okiem pod kątem szablonu. Czy to jest to, czego oczekują Wasi odbiorcy z punktu 3.1? Czy jest tam coś, co można usunąć? Coś, co nie przynosi odbiorcy korzyści?

Pamiętajcie, że każdy slajd/ ćwiczenie/ temat, który znajduje się poza zakresem (3.1) lub (3.3) musi zostać usunięty. Wiem, że dany temat może być Waszym ulubionym tematem. Wiem, że dany temat może być dla Was atrakcyjny.

Nie ma to znaczenia. Podczas prezentacji najważniejszy jest odbiorca, nie prelegent. Kluczem jest maksymalizacja korzyści odbiorcy, nie opowiedzenie o swoim ulubionym temacie.

4. Przykład

Pewnego razu dostałem prośbę poprowadzenia prezentacji dla średnio- i mniej doświadczonych programistów (junior, medium).

Osoby, które mnie o to poprosiły powiedziały, że chciałyby zainspirować programistów oraz usprawnić prędkość dostarczania przez nich rozwiązań technicznych. Prezentacja ma trwać 60 minut.

Przejdźmy więc przez grupę pytań (tu jest już wersja ostateczna):

4.1. Szkic:

4.1.1. O czym chcę powiedzieć?

Chcę powiedzieć o modelowaniu. W skrócie: “jeśli nie wiem co robię, nie jestem w stanie tego zrobić dobrze”. Chcę im opowiedzieć o upraszczaniu problemu, dzieleniu go na kawałki. O tym, jak programować minimalnym kosztem energii by uzyskać maksymalny zwrot z czasu. Pokazać, że “nieźle” bywa lepsze niż “perfekcyjnie” w niektórych kontekstach.

4.1.2. Kto jest moim odbiorcą?

Młodzi, niedoświadczeni (i średnio doświadczeni) programiści dowolnej technologii.

Na wysokim poziomie abstrakcji: część z nich ma jeszcze problemy z pisaniem kodu, część już opuściła ten etap i mierzą się z problemami takimi jak “jak zaprojektować komunikację w tym programie”, “jak to napisać, by inni zrozumieli” i “jak rozwiązać ten problem techniczny, którego nie opisali na Stack Overflow”.

Mam dwie różne grupy odbiorców, ale ich częścią wspólną jest “jak zacząć COŚ robić jeśli mam tylko migający kursor i problem w głowie”. Różnica taka, że dla mniej doświadczonego programisty “COŚ” oznacza mały kawałek kodu a dla bardziej doświadczonego “COŚ” to będzie spory program.

Uznałem, że w kontekście tej prezentacji mogę potraktować ich jako tą samą grupę.

Najczęściej programiści przekształcają problemy biznesowe (czy to w formie dobrze zdefiniowanych zadań czy w formie abstrakcyjnych pragnień) w kod, krystalizując procesy biznesowe.

4.1.3. W ramach tego co moi odbiorcy robią:

Główne obszary bólu, które chcę rozwiązać to:

• Marnowanie czasu na pisanie kodu, który zaraz trzeba skasować. Siedzę po nocach, daję z siebie wszystko - a szef mówi, że nie zrobiłem tego, co jest potrzebne i to trzeba skasować…
• Poczucie bycia kiepskim programistą: piszę za wolno, znowu napisałem nie to co powinienem, w ogóle nie wiem jak zacząć
• Frustracja wynikająca z zagubienia w kodzie. Zwłaszcza własnym. Odszedłem od programu na pół roku, wracam i nic nie rozumiem. Muszę być naprawdę kiepski, skoro nie rozumiem własnego kodu.
• Boję się, że jestem tak kiepski, że mnie zwolnią.

4.1.4. W jaki sposób to, co chcę powiedzieć (nauczyć, dać) pomaga:

Modelowanie i upraszczanie dają poniższe:

• Używając tych technik uzmysłowią sobie, czego jeszcze nie wiedzą, bo nie da się uprościć czegoś, czego się nie rozumie. Czas zadawać pytania i nie marnować czasu na pisanie kodu, który będzie skasowany.
• Sporo problemów da się zidentyfikować na poziomie analizy koncepcji. To sprawia, że programista nie wpakuje się w ślepy zaułek architektoniczny pisząc kod bez zobaczenia szerszej perspektywy.
• Jeśli wiem, co chcę osiągnąć to wiem, kiedy to osiągnąłem. Dzięki temu oddam pracę szybciej i nie wpadnę w pułapkę zbędnej perfekcji.
• Z uwagi na to, że modeluje się konkretny problem technikami “od góry do dołu” - zawsze wiem, jak zacząć.
• Potencjalny problem do pokonania: modelowanie wymaga myślenia i rysowania na kartce papieru. To zajmuje czas.

4.1.5. Po czym odbiorcy poznają, że warto było przyjść? Czas, ból, kapitał.

Korzyści:

• Wykorzystanie technik FAKTYCZNIE sprawi, że nie będą pisać tyle kodu.
  • Mniej pisania -> mniej czasu poświęconego na pisanie. Oszczędność czasu.
  • Mniej kodu -> mniej błędów w kodzie -> mniej czasu zmarnowanego na naprawianie błędów. Oszczędność czasu.
• Podział pracy na koncepcję i pisanie kodu daje kod czytelniejszy i pozwala uniknąć ślepych uliczek struktury kodu.
  • Unikanie ślepych uliczek -> mniej przebudowy struktur nie wnoszących korzyści -> oszczędność czasu
  • Czytelniejszy kod zgodny z modelem mentalnym -> łatwiej się połapać -> oszczędność czasu i zmniejszenie bólu.
• Jeśli wiem, kiedy skończyć pracę i czego się ode mnie oczekuje to mogę napisać TYLKO to.
  • Szybciej oddam rozwiązanie klientowi -> więcej zarobię LUB oszczędzę czas
• Zawsze wiem jak zacząć.
  • Mniej patrzenia w migający kursor z rosnącą bezradnością. Mniejsza frustracja, mniej marnowania czasu.
• Konieczne udowodnienie, że rysowanie to oszczędność czasu wobec programowania “od zera”

W jakim kontekście mogą to osiągnąć?

• Gdy dostają nieperfekcyjnie zdefiniowane zadanie z nietrywialnym dla siebie problemem (czyli “często, gdy dostają zadanie”)
• Gdy próbują zintegrować się z istniejącym kodem, który jest trudny do zrozumienia
• Gdy próbują napisać coś “od zera”, czego nie do końca jeszcze rozumieją

4.2. Szablon:

4.2.1 Wstępna estymacja czasu

Co jest mówione	Ile potrwa
rezerwa	10 minut
Prezentacja, korzyści, agenda	5 minut
Podsumowanie, podziękowanie	10 minut

Pozostaje 40 minut na struktury “Problem->Rozwiązanie”.

4.2.2 Wypełnienie szablonu właściwego

1. Przedstawienie się
2. Zaprezentowanie korzyści
   1. Uświadomienie bólu:
      1. Jak zacząć?
      2. Jak pisać SZYBCIEJ?
   2. Pokazanie, że ból da się uśmierzyć:
      1. “A gdyby ktoś mi już napisał ten początek…”
      2. “A gdybym dokładnie wiedział co napisać…”
      3. “A gdybym mógł się skupić na problemie bo nie ma nieoczekiwanych błędów w kodzie…”
3. Agenda wystąpienia. “Spis treści”.
4. Problem -> Rozwiązanie: Jak Zacząć.: 10 minut
   1. Pokazać problem, który jest pozornie bardzo trudny. “Jak to zacząć?”
   2. “Trudno to ogarnąć, bo musimy myśleć o kilkunastu rzeczach naraz, no i wszystko może pójść nie tak…”.
   3. “A gdyby myśleć tylko o rzeczach najbardziej ogólnych?”
   4. Technika Happy Path i pokazanie jak by to działało. Udowodnić “szybciej” i “wiem jak zacząć”.
   5. Pokazać, jak użyć tego w pracy codziennej. Kiedy tak. Kiedy nie.
5. Problem -> Rozwiązanie: Jak pisać szybciej: 10 minut
   1. “Przyspieszmy to. Wyobraźmy sobie, że im szybciej napiszemy, tym więcej zarobimy…”
   2. Talia kart i znaczenie rozumienia tego CO chcemy zaprogramować. Oszczędność czasu.
   3. Nawiązać do pracy codziennej w ich projektach, pokazać jak oni mogą tego użyć
6. Problem -> Rozwiązanie: Jak pisać szybciej: 10 minut
   1. Poszerzyć problem. Pokazać jak można się łatwo wpakować na minę. Pokazać, gdzie traci się czas.
   2. Modelowanie Oczami Dziecka i komunikacja na lotnisku.
   3. Nawiązać do pracy codziennej w ich projektach, pokazać jak oni mogą tego użyć
7. Problem -> Rozwiązanie: Jak pisać szybciej: 10 minut
   1. Problem bardzo trudny do zaprogramowania bez przemyślenia. Pokazać modelowanie aż do pseudokodu. Udowodnić, że to jest szybsze podczas pracy i ma mniej błędów.
   2. Nawiązać do pracy codziennej w ich projektach, pokazać jak oni mogą tego użyć
8. Podsumowanie
   1. “Jak zacząć? Jak robić szybciej? To tak naprawdę to samo pytanie…”
   2. “Pokazałem techniki X, Y, Z. Rozwiązują problem A, B w TAKIE sposoby”
   3. “Ja używam tego wtedy gdy X, unikam gdy Y.” - X i Y wykorzystane w pracy codziennej.
9. Podziękowanie
   1. Ewentualnie, źródła i materiały dodatkowe

5. Dlaczego to działa?

5.1. Dlaczego zaczynamy projektowanie od “co JA chcę powiedzieć?”

Chodzi tu o zbudowanie podstawowego zbioru narzędzi, którymi będziemy mogli rozwiązywać cudze problemy. JA mam narzędzia, TY masz problem, JA TOBIE pokażę jak tymi narzędziami rozwiążesz tamten problem.

Poza pierwszym punktem tak dużo pracujemy z odbiorcą i celami odbiorców, że bardzo łatwo wpaść w pułapkę “ja nic tej grupie nie mogę dać”. Dlatego warto sobie wpierw zapisać co w ogóle chcemy powiedzieć, jaki mamy koncept.

Tak, najprawdopodobniej będziemy musieli to zmienić w jakimś stopniu wraz z głębszym zrozumieniem naszej grupy docelowej - ale jak tego nie zapiszemy, możemy w ogóle zapomnieć co możemy dać i pokazać.

5.2. Dlaczego tyle o odbiorcach i ich działaniach?

Im więcej się dowiecie o swoich odbiorcach przed rozpoczęciem pracy nad prezentacją tym mniej włożycie energii w rzeczy dla odbiorcy niepotrzebne. Tym mniej będziecie musieli prezentację przekształcać i dostosowywać się na bieżąco, stojąc przed audytorium.

Czemu skupiłem się na działaniach odbiorców? Inne problemy mają programiści, którzy pracują nad bardzo złożonymi algorytmami w dziale R&D a inne programiści biznesowi komunikujący się z klientem na co dzień.

Dlatego “prezentacja dla programistów” to nie jest wystarczający zbiór informacji. Jeśli nie wiem jakie czynności oni wykonują to nie jestem w stanie określić jak ja mogę im pomóc.

Innymi słowy, jeśli nie wiem co robią moi odbiorcy to moje wystąpienie najpewniej nie będzie skuteczne (nie rozwiążę ich problemu).

Bezpośrednią inspiracją do tego była dość niefortunna sytuacja, która mnie spotkała dwa lata temu:

Swego czasu poproszono mnie, bym przygotował prezentację o licencjach na pewne spotkanie poza firmą. Upewniono mnie, że chodzi o licencje FLOSS - takie, które przede wszystkim dotyczą programistów. Przygotowałem się więc i poszedłem na to spotkanie… a tam było dwóch programistów i kilkanaście osób nie powiązanych stricte z pisaniem kodu…

Poradziłem sobie, bo skupiłem się na licencjach na tzw. content (obrazki z internetu, filmiki, kiedy i jak wolno ich używać) - ale obiektywnie rzecz ujmując, nie było to moje najlepsze wystąpienie publiczne ;-).

5.3. Dlaczego tylko “Ból, Czas lub Kapitał?”

Swego czasu skupiałem się na ogólnie rozumianych “korzyściach”, ale zbyt łatwo było wykombinować coś, co “dobrze brzmi” by móc przepchnąć swój ulubiony temat. By to wyeliminować, ograniczyłem się do trzech najbardziej pierwotnych elementów:

• Co boli Ciebie, konkretnie Ciebie?
• Jaką formę kapitału Ty uzyskujesz?
• W jaki sposób Ty zaoszczędzisz czas?

Można powiedzieć, że korzyści są szersze niż tylko te trzy kategorie, ale tak naprawdę większość korzyści można jakoś do tych trzech sprowadzić (np. techniką 5 Why):

Przykład: “Moi klienci będą mieli ładniejszy interfejs graficzny”:

1. Moi klienci będą mieli ładniejszy interfejs graficzny WIĘC
2. Moja aplikacja będzie sprzedawała się lepiej WIĘC
3. Będę zarabiał więcej pieniędzy -> kapitał finansowy

Oczywiście, jeśli nie było robionych badań rynku to przejście między (1) a (2) jest wątpliwe. Szczęśliwie, wymuszenie sprowadzenia wszystkiego do tych trzech obszarów zwiększa prawdopodobieństwo zauważenia takich luk.

Jeśli “ból, czas, kapitał” są niewielkie i niezbyt palące, trudniej będzie przekonać odbiorców o tym, że warto słuchać. Trzeba się będzie mocniej skupić na przykładzie. Jeśli jednak są bardzo dotkliwe i spore, to można po prostu nakreślić problem i bardziej skupić się na rozwiązaniu.

A jeśli nie ma korzyści w tej dziedzinie, najpewniej ta prezentacja nie jest przeznaczona dla tej konkretnej grupy odbiorców.

5.4. Dlaczego zacząć od prezentowania korzyści?

Gdy rozpoczynamy jakiekolwiek wystąpienie mamy efekt “nowości”. Wyszedł nowy prelegent na środek i coś mówi. To jest moment, gdy najwięcej osób Was słucha.

Przez to, że mówicie im jakie korzyści mogą osiągnąć:

1. Wiedzą, że warto Was słuchać. Są aktywnie zainteresowani prezentacją.
2. Wiedzą, pod jakim kątem słuchać Waszej prezentacji. Wiedzą, na których słowach i konceptach się skupić.

Gdy zaczynacie prezentację, odbiorcy nie wiedzą, o czym chcecie powiedzieć. Nie wiedzą, na czym się skupić i co z tego, co mówicie jest ważne. Jeśli powiecie im co Wy chcecie by oni z tego mieli, budujecie im kontekst.

Kontekst umożliwia odbiorcom osadzenie wszystkich wysyłanych przez Was sygnałów w ich dotychczasowych doświadczeniach. Wiedząc, czemu mówicie to co mówicie dajecie im pryzmat przez który mogą patrzeć na Waszą prezentację. Wiedzą, co z tego mają mieć.

Innymi słowy, Wasza prezentacja będzie odebrana lepiej.

5.5. Dlaczego “Problem->Rozwiązanie?”

“Problem” buduje kontekst i pozwala odbiorcy zobaczyć, że to jest też coś, co mogło odbiorcę spotkać. Najlepiej, jeśli problem to przypadek z którym odbiorca się spotkał wcześniej - wtedy będzie mógł wczuć się w sytuację.

W tym momencie “Rozwiązanie” staje się faktycznym rozwiązaniem problemu posiadanego wcześniej przez odbiorcę. Problem staje się “niezadanym pytaniem” odbiorcy a Rozwiązanie staje się odpowiedzią na to pytanie.

Dzięki przejściu: “Problem” -> “Rozwiązanie” -> “Wyjaśnienie” -> “Dalsze Użycie W Faktycznej Pracy” nie tylko przechodzimy przez 3/4 cyklu Kolba ale i nasze Wyjaśnienie osadzone jest w kontekście Problemu i Rozwiązania.

1. Odbiorca wpierw widzi, co było uszkodzone
2. Odbiorca widzi, jak to naprawiliśmy
3. I teraz odbiorca może zapoznać się z wyjaśnieniem bez kwestionowania “po co mi to”. Bo widział “po co mi to” przedtem.

5.6. Dlaczego musi być nawiązanie do problemów codziennych odbiorców?

Bardzo łatwo jest zbudować sobie iluzję tego, że wiemy kim są nasi odbiorcy i czym się zajmują. Zazwyczaj nie do końca to wiemy i jedynie mamy jakieś wyobrażenie na ten temat.

Skupienie się na czynnościach sprawia, że dużo łatwiej jest nam wyobrazić sobie problemy z jakimi odbiorcy mają do czynienia na co dzień.

Dużo łatwiej jest nam uzmysłowić sobie ich ból, frustrację i potencjalne korzyści. To też daje nam możliwość określenia po czym odbiorca może poznać, że coś robi lepiej.

Nawet, jeśli nie jesteśmy w stanie w 100% dowiedzieć się co robią nasi odbiorcy - sam fakt, że próbujemy o tym pomyśleć pomaga nam w zaprojektowaniu prezentacji lepiej do nich dostosowanej.

6. Inspiracje

Ta technika jest oparta na koncepcie zwanym propozycją wartości. Propozycja wartości jest narzędziem projektowania i kalibrowania produktu pod kątem konkretnego klienta. Jest czymś, co pozwala nam uniknąć problemu typu “zaprojektowałem coś i to zbudowałem… i nie było nikogo, kto tego w ogóle potrzebuje”.

Drugim źródłem inspiracji jest Pięć pytań Druckera. To narzędzie pozwala na dopasowanie naszych wartości i pragnień wpłynięcia na świat (czyli: Misji) do potrzeb i problemów posiadanych przez klienta. Dzięki temu produkt nad którym pracuje organizacja jest zgodny z jej wartościami. Co więcej, ten produkt ma jakieś powiązanie z tym, gdzie ta organizacja chce się znaleźć w przyszłości.

Nie można też zapomnieć o nieśmiertelnym cyklu Kolba. To narzędzie pozwala projektować szkolenia i prezentacje w taki sposób, by jak najwięcej osób o różnych stylach uczenia się mogły wyciągnąć korzyści z owego szkolenia czy prezentacji.

7. Podsumowanie

Nikt nie rodzi się świetnym mówcą. Jeżeli jednak mówicie o rzeczach, które interesują odbiorców, nie musicie być świetnymi mówcami. Odbiorcy i tak będą Was słuchać, bo zobaczą wartość tego, co pokazujecie.

Dobry plan i dobre przemyślenie problemu bardzo często pozwoli Wam skompensować brak umiejętności publicznych wystąpień. Bardzo często lepiej dać odbiorcy wartość nie będąc najlepszym mówcą niż mówić świetnie, ale bez żadnych korzyści dla odbiorcy.

Prosty dowód: nie jestem dobrym pisarzem, jednak dotrwaliście do samego końca, bo najpewniej zobaczyliście korzyści skierowane bezpośrednio do Was. Brak umiejętności pięknego pisania skompensowałem tym, że skupiam się na Was i Waszych potrzebach.

Podejrzewam, że zauważyliście: ten artykuł jest napisany zgodnie z technikami zawartymi w szkicu. To nie tylko pomoc w prezentacjach i szkoleniach - to pomaga także przy artykułach, produktach (np. aplikacja dla klienta)… propozycja wartości jest świetnym narzędziem, które działa w wielu kontekstach.

Pozostaje mi już tylko życzyć Wam powodzenia podczas Waszych wystąpień publicznych ;-).