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 konsultingowa była szerokim, żargonowym menu — partnerzy biznesowi nie wiedzieli, co wybrać ani na jakim etapie jest ich problem.
• Co zrobiłem: Przebudowałem ofertę na 4 jasne fazy dojrzałości problemu + model wyceny w man-days.
• Wynik: Nowa oferta gotowa po ~2 miesiącach; poprowadziłem nią później większość z ~60 warsztatów w 8 krajach.

Diagnoza

Oferta pierwszej wersji była szeroka i technicznie precyzyjna — i dokładnie dlatego niezrozumiała dla ludzi, dla których była pisana. Partnerzy biznesowi (rzadko z IT) mieli wybrać właściwy element z listy warsztatów co-creation, budowy PoC czy badań on-site — nie znając różnicy między nimi i nie wiedząc nawet, na jakim etapie właściwie jest ich problem. Zamiast skracać listę, przeorganizowałem ją wokół pytania, na które partner faktycznie umiał sobie odpowiedzieć: „na jakim etapie jest mój problem?”. Cztery fazy dojrzałości — nie cztery typy usług.

flowchart TD
    subgraph Przed["Przed: menu po typie aktywności"]
        M1["Warsztaty co-creation"]
        M2["Budowa PoC"]
        M3["Badania on-site"]
    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:transparent,stroke:#a1a1aa,stroke-width:1px,rx:14,ry:14
    style Po fill:transparent,stroke:#a1a1aa,stroke-width:1px,rx:14,ry:14
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

Co zrobiłem

• Zdiagnozowałem cztery konkretne wady pierwszej wersji oferty (żargon, zbyt szeroki wybór, sztywność, brak ścieżki do wdrożenia) na podstawie kilku lat użycia.
• Przeprojektowałem ofertę na 4 fazy dojrzałości problemu — Identification / Iteration / Design / Verification — każda z domyślnym, ale nie sztywnym zestawem aktywności.
• Zbudowałem model wyceny w man-days — szablony Excel oparte na danych z poprzednich współprac, do szybkiego podawania widełek ofertowych.
• Poprowadziłem większość z ~60 warsztatów w 8 krajach, które powstały na tej strukturze.

Wyniki

• Nowa oferta (v2.0) gotowa po ~2 miesiącach pracy.
• Niemal wszystkie dotychczasowe współprace dały się czysto zmapować na 4 nowe fazy — sygnał, że podział trafił w rzeczywisty kształt pracy, nie był sztuczny.
• Po premierze partnerzy biznesowi zaczęli przychodzić z jaśniej sprecyzowanymi potrzebami — mniej pytań „co w ogóle oferujecie”, więcej „jestem na etapie X, co mi pomoże”.
• Struktura napędziła ~60 warsztatów w 8 krajach (USA, Niemcy, Szwajcaria, Hiszpania, Włochy, Serbia, Słowenia, Wielka Brytania) — większość poprowadzona osobiście, od przygotowania po realizację.
• Model wyceny w man-days stał się standardowym narzędziem zespołu do szybkiego kosztorysowania nowych zleceń.

Problem

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

Cztery rzeczy, widoczne dopiero po kilku latach użycia: (1) zbyt specjalistyczny język — partnerzy spoza IT nie rozumieli, co dokładnie oferujemy, więc nie mogli wybrać właściwego elementu; (2) zbyt szeroki, rozdrobniony wybór — warsztaty co-creation, budowa PoC, badania on-site jako osobne, równoległe opcje bez wskazówki, kiedy co wybrać; (3) zbyt sztywne definicje — trudno było przekonać partnera do połączenia kilku elementów w jedną współpracę; (4) brak jasnej ścieżki do wdrożenia — rozdrobnienie utrudniało pokazanie, jak od warsztatu dojść do konkretnego produktu.

Dlaczego po prostu nie skrócić listy?

Bo problem nie był w długości listy — był w osi, wokół której była zbudowana. Lista organizowała się wokół typu aktywności (warsztat, badanie, PoC), a partner biznesowy nie myśli w tych kategoriach. Myśli: „jestem na jakimś etapie z jakimś problemem i nie wiem, co dalej”. Skrócenie listy nie naprawiłoby tego niedopasowania — trzeba było przełożyć ofertę na oś, którą partner faktycznie rozumiał.

Moja rola / zakres

• Byłem główną osobą tworzącą nową wersję oferty wewnątrz zespołu innovation lab — od diagnozy problemów, przez podział na fazy, po model wyceny.
• Po premierze osobiście prowadziłem większość z ~60 warsztatów w 8 krajach — pełna odpowiedzialność za przygotowanie i realizację.
• Model wyceny (szablony man-day) zaprojektowałem samodzielnie na bazie danych z wcześniejszych projektów zespołu.

Proces

• Diagnoza z danych użycia. Kilka lat pracy na pierwszej wersji oferty dało wystarczająco sygnału, żeby nazwać cztery konkretne wady — nie zgadywanie, tylko wzorce z rzeczywistych rozmów z partnerami.
• Wybór osi podziału. Zamiast dzielić po typie aktywności, podzieliłem po dojrzałości problemu partnera: „muszę zidentyfikować problem” → „mam problem, nie wiem jak go rozwiązać” → „mam pomysł, muszę go sprecyzować” → „mam zaprojektowane rozwiązanie, muszę zweryfikować sens wdrożenia”. Sprawdziłem tę oś wstecznie na wcześniejszych projektach — niemal wszystkie dały się do niej czysto przypisać.
• Domyślny, nie sztywny zestaw aktywności per faza. Dla każdej fazy zdefiniowałem typowy zestaw działań na podstawie analizy poprzednich inicjatyw.

• Model wyceny. Zebrałem dane z wcześniejszych współprac i oszacowałem liczbę dni roboczych (man-days) na każdy typ elementu — badanie, warsztat z dwoma facylitatorami, ryczałt na podróże — i zbudowałem szablony Excel do szybkiego wyceniania.

Kluczowe decyzje i trade-offy

• Dziel po dojrzałości problemu, nie po typie usługi. Kontrintuicyjne, bo to nie jest oś, wokół której naturalnie organizuje się oferta konsultingowa (zwykle organizuje się wokół tego, co zespół umie zrobić). Trade-off: trzeba było przeklasyfikować całą historię projektów, żeby sprawdzić, czy oś się broni. Payoff: partner mógł się sam zidentyfikować bez znajomości żargonu.
• Domyślne, nie obowiązkowe zestawy aktywności. Każda faza miała typowy przepis, ale nie sztywny wymóg — to bezpośrednio naprawiało wadę #3 pierwszej wersji (zbyt sztywne założenia). Trade-off: mniej przewidywalności w planowaniu zasobów zespołu, więcej elastyczności dla partnera.
• Verification jako najluźniej ustrukturyzowana faza — celowo. Ta faza miała najmniej ustalonej struktury ze wszystkich czterech, bo cel — szybkie zderzenie pomysłu z „rynkiem”, zanim wyda się duże pieniądze — wymagał dopasowania metody do konkretnego przypadku (test czasowy, sprawdzenie API, tanie MVP), nie jednego stałego procesu.
• Model wyceny jako osobny deliverable, nie dodatek. Bez widełek kosztowych partnerzy wahali się zacząć rozmowę — nieznany koszt to ukryta bariera wejścia. Szablony man-day usunęły tę barierę.
• Szczerze: „lepszy odzew” był sygnałem jakościowym, nie zmierzonym. Widziałem, że partnerzy przychodzą z bardziej sprecyzowanymi potrzebami i mniej pytają „co w ogóle oferujecie” — ale nie ustawiłem wtedy twardej metryki (np. liczba zapytań przed/po).

Jak to się skończyło

Nowa oferta ruszyła po ~2 miesiącach pracy i stała się domyślnym sposobem scopowania każdego nowego zlecenia w zespole. Niemal cała historia współprac dała się czysto przypisać do czterech faz, co potwierdziło, że podział odzwierciedlał rzeczywisty kształt pracy, a nie sztuczną kategoryzację. Struktura przetrwała próbę czasu: napędziła większość z ~60 warsztatów, które poprowadziłem w 8 krajach, a szablony wyceny w man-days stały się standardowym narzędziem zespołu do szybkiego kosztorysowania.

Co z tego wyniosłem

• Dopasuj strukturę oferty do sposobu myślenia klienta, nie do wewnętrznej taksonomii usług. Partner nie myśli „chcę warsztat co-creation” — myśli „utknąłem na jakimś etapie”. Zaprojektuj oś wokół tego drugiego.
• „Domyślne, nie obowiązkowe” zabija paraliż decyzyjny bez zabijania elastyczności. Można dać ludziom prosty start i wciąż zostawić miejsce na wyjątki.
• Szybka, orientacyjna wycena usuwa ukrytą barierę. Nikt nie zaczyna czegoś, czego nie potrafi z grubsza wycenić.
• Nie każdy dobry efekt jest zmierzony w danym momencie — i to jest lekcja sama w sobie. Następnym razem: metryka adopcji (liczba/jakość zapytań przed i po) ustawiona od pierwszego dnia, nie rekonstruowana z pamięci.