Przebudowa oferty konsultingu innowacji, której nikt nie umiał wytłumaczyć

TL;DR

• Kontekst: Projektant w wewnętrznym innovation labie globalnej firmy farmaceutycznej.
• Problem: Oferta była długą listą usług opisanych żargonem. Partnerzy biznesowi nie wiedzieli, co wybrać, ani na jakim etapie jest ich problem.
• Co zrobiłem: Przebudowałem ofertę na 4 fazy, które opisują etap problemu, i dodałem model wyceny w dniach pracy.
• Wynik: Nowa oferta była gotowa po ~2 miesiącach. Poprowadziłem na niej większość z ~60 warsztatów w 8 krajach.

Diagnoza

Pierwsza wersja oferty była szeroka i bardzo precyzyjna technicznie. Właśnie przez to ludzie, do których była skierowana, jej nie rozumieli. Partnerzy biznesowi (rzadko z IT) mieli wybrać z listy warsztat co-creation, budowę PoC albo badania na miejscu. Nie znali różnicy między nimi i często nie wiedzieli nawet, na jakim etapie jest ich problem. Nie skracałem więc listy. Ułożyłem ją wokół pytania, na które partner umiał sobie odpowiedzieć: „na jakim etapie jest mój problem?”. Tak powstały cztery fazy.

flowchart TD
    subgraph Przed["Przed: lista po typie aktywności"]
        M1["Warsztaty co-creation"]
        M2["Budowa PoC"]
        M3["Badania na miejscu"]
    end
    subgraph Po["Po: 4 fazy dojrzałości problemu"]
        F1["Identification"] --> F2["Iteration"] --> F3["Design"] --> F4["Verification"]
    end

    classDef good    fill:#e6f2ea,stroke:none,color:#1f4d33,rx:14,ry:14
    classDef bad     fill:#faeaea,stroke:none,color:#5f2626,rx:14,ry:14
    class M1,M2,M3 bad
    class F1,F2,F3,F4 good
    style Przed fill:#fdf5f5,stroke:#e0c3c3,stroke-width:1px,color:#5f2626,rx:14,ry:14
    style Po fill:#f2f8f3,stroke:#c2dcc8,stroke-width:1px,color:#1f4d33,rx:14,ry:14
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

Co zrobiłem

• Na podstawie kilku lat pracy z pierwszą wersją oferty nazwałem jej cztery wady: żargon, zbyt szeroki wybór, sztywne definicje i brak drogi do wdrożenia.
• Przebudowałem ofertę na 4 fazy: Identification, Iteration, Design i Verification. Każda ma domyślny zestaw aktywności, który można zmieniać.
• Zbudowałem model wyceny w dniach pracy (man-days). To szablony w Excelu oparte na danych z wcześniejszych projektów, dzięki którym szybko podawaliśmy widełki.
• Poprowadziłem większość z ~60 warsztatów w 8 krajach, które powstały na tej strukturze.

Wyniki

• Nowa oferta (v2.0) była gotowa po ~2 miesiącach pracy.
• Prawie wszystkie wcześniejsze projekty dało się przypisać do jednej z 4 faz. Dla mnie to był znak, że podział pasuje do prawdziwej pracy.
• Po premierze partnerzy przychodzili z lepiej określonymi potrzebami. Rzadziej pytali „co w ogóle oferujecie?”, częściej mówili „jestem na etapie X, co mi pomoże?”.
• Na tej strukturze powstało ~60 warsztatów w 8 krajach (USA, Niemcy, Szwajcaria, Hiszpania, Włochy, Serbia, Słowenia, Wielka Brytania). Większość z nich przygotowałem i poprowadziłem sam.
• Model wyceny w dniach pracy stał się standardowym narzędziem zespołu do szacowania kosztów nowych zleceń.

Problem

Co było nie tak z pierwszą wersją oferty?

Cztery rzeczy, które wyszły dopiero po kilku latach:

1. Język. Był zbyt specjalistyczny. Partnerzy spoza IT nie rozumieli, co dokładnie oferujemy, więc nie umieli wybrać.
2. Wybór. Warsztaty co-creation, budowa PoC i badania na miejscu były osobnymi opcjami, bez podpowiedzi, kiedy wybrać którą.
3. Sztywność. Definicje były tak ścisłe, że trudno było przekonać partnera do połączenia kilku elementów w jeden projekt.
4. Droga do wdrożenia. Przez rozdrobnienie trudno było pokazać, jak od warsztatu dojść do gotowego produktu.

Dlaczego po prostu nie skrócić listy?

Bo kłopot leżał w tym, jak lista była ułożona. Porządkował ją typ aktywności (warsztat, badanie, PoC), a partner biznesowy tak nie myśli. Myśli raczej: „mam jakiś problem, jestem gdzieś w połowie i nie wiem, co dalej”. Krótsza lista nadal mówiłaby innym językiem niż partner. Musiałem ułożyć ofertę według tego, co on sam o sobie wie.

Moja rola / zakres

• W zespole innovation labu to ja tworzyłem nową wersję oferty: od nazwania problemów, przez podział na fazy, po model wyceny.
• Model wyceny zaprojektowałem sam na danych z wcześniejszych projektów zespołu.

Proces

• Wady z prawdziwych rozmów. Po kilku latach pracy z pierwszą wersją miałem dość materiału, żeby nazwać cztery konkretne wady. Brałem je z rozmów z partnerami, a nie z domysłów.
• Wybór podziału. Podzieliłem ofertę według tego, jak daleko partner jest ze swoim problemem: „muszę znaleźć problem” → „mam problem, nie wiem, jak go rozwiązać” → „mam pomysł, muszę go doprecyzować” → „mam rozwiązanie, muszę sprawdzić, czy warto je wdrożyć”. Potem sprawdziłem ten podział na starych projektach i prawie każdy dało się do niego przypisać.
• Domyślny zestaw aktywności w każdej fazie. Dla każdej fazy opisałem typowy zestaw działań na podstawie wcześniejszych projektów.

• Model wyceny. Zebrałem dane z wcześniejszych projektów i policzyłem, ile dni pracy zajmuje każdy element: badanie, warsztat z dwoma facylitatorami, ryczałt na podróże. Na tej podstawie zbudowałem szablony w Excelu do szybkiej wyceny.

Kluczowe decyzje i trade-offy

• Podział według etapu problemu. Oferty konsultingowe zwykle układa się według tego, co zespół umie zrobić. Ja ułożyłem ją według tego, gdzie jest partner. Kosztowało to sporo pracy, bo musiałem przypisać całą historię projektów do nowych faz i sprawdzić, czy podział się broni. W zamian partner mógł sam powiedzieć, gdzie jest, bez znajomości żargonu.
• Domyślne aktywności, które można zmieniać. Każda faza miała typowy przepis, ale nie był on obowiązkowy. To wprost naprawiało trzecią wadę starej oferty, czyli sztywność. Minusem było to, że zespołowi trudniej było przewidzieć, ile osób i czasu będzie potrzebne.
• Verification ma najmniej struktury. Zrobiłem tak celowo. W tej fazie chodzi o to, żeby szybko sprawdzić pomysł w praktyce, zanim wyda się na niego duże pieniądze. Metodę trzeba więc dobrać do przypadku: raz będzie to test czasowy, raz sprawdzenie API, a raz tanie MVP.
• Wycena jako osobna część oferty. Bez widełek kosztów partnerzy wahali się, czy w ogóle zacząć rozmowę. Nieznany koszt odstraszał. Szablony w dniach pracy tę barierę usunęły.
• Nie zmierzyłem lepszego odzewu. Muszę przyznać, że „lepszy odzew” to moja obserwacja, a nie liczba. Widziałem, że partnerzy przychodzą z bardziej konkretnymi potrzebami, ale nie ustawiłem wtedy żadnej metryki, np. liczby zapytań przed i po zmianie.

Jak to się skończyło

Nowa oferta ruszyła po ~2 miesiącach i od tego czasu każde nowe zlecenie w zespole zaczynało się od przypisania go do fazy. Struktura dobrze zniosła próbę czasu. Poprowadziłem na niej większość z ~60 warsztatów w 8 krajach, a szablony wyceny zostały w zespole jako codzienne narzędzie.

Co z tego wyniosłem

• Ofertę warto układać według tego, jak myśli klient. Partner nie myśli „chcę warsztat co-creation”. Myśli „utknąłem i nie wiem, co dalej”. Według mnie oferta powinna zaczynać się od tego drugiego.
• Domyślny wybór pomaga podjąć decyzję. Ludzie dostają prosty start, a wciąż zostaje miejsce na wyjątki.
• Nawet orientacyjna cena zachęca do rozmowy. Mało kto zaczyna coś, czego nie umie choćby z grubsza wycenić.
• Następnym razem zmierzę efekt od pierwszego dnia. Tutaj została mi tylko obserwacja. Liczbę i jakość zapytań przed i po zmianie trzeba liczyć od startu, a nie odtwarzać z pamięci.