Jak korzystać z Business Model Canvas, nie traktując założeń jak faktów

Business Model Canvas opisuje, w jaki sposób firma tworzy, dostarcza i przechwytuje wartość. Jego dziewięć bloków obejmuje segmenty klientów, propozycje wartości, kanały, relacje z klientami, strumienie przychodów, kluczowe zasoby, kluczowe działania, kluczowych partnerów i strukturę kosztów. Oficjalne wskazówki Strategyzer dotyczące Business Model Canvas (https://www.strategyzer.com/library/the-business-model-canvas) zalecają opisywanie jednego modelu biznesowego, opatrywanie go datą i numerem wersji oraz ponowne tworzenie go w miarę napływu dowodów.

Zacznij od jednego proponowanego modelu dla jednej jasno określonej grupy klientów. Na przykład zespół badający narzędzie do przekazywania projektów może skupić się na małych agencjach projektowych, w których projektanci przekazują pracę menedżerom projektów. Umieszczenie na tym samym canvasie agencji, niezależnych projektantów i dużych przedsiębiorstw utrudniłoby ustalenie, których klientów dotyczą poszczególne dowody.

Wpisz w blokach krótkie stwierdzenia, a następnie dodaj identyfikatory założeń. „Miesięczna subskrypcja zespołowa — A-04” pozwala prześledzić pomysł na przychody. „Samodzielna konfiguracja — A-05” ujawnia założenie dotyczące dostarczania produktu, które może wpływać na relacje z klientami, działania i koszty.

Nie ukrywaj niewiadomych. Pusty blok partnerstw z jasno sformułowanym pytaniem jest bardziej użyteczny niż wpisanie dostawcy, z którym zespół nigdy się nie kontaktował. Zgodność podczas warsztatu wyznacza wspólny punkt wyjścia; dowody potwierdzające założenia powinny znaleźć się w osobnym zapisie.

Zastąp ogólne opisy twierdzeniami, które określają klienta, sytuację i obserwowalne zachowanie. „Łatwe wdrożenie” jest zbyt nieprecyzyjne, by je przetestować. Bardziej użyteczne twierdzenie brzmi: „Menedżer projektu w małej agencji projektowej może utworzyć projekt i zaprosić projektanta bez pomocy na żywo”. Planując eksperyment, dodaj wersję produktu i warunki testu.

Rozdziel twierdzenia wymagające różnych dowodów. „Agencje tego potrzebują i będą płacić co miesiąc” zawiera co najmniej dwa założenia. Dowody na powtarzający się problem z przekazywaniem pracy nie potwierdzają gotowości do zapłaty za konkretne rozwiązanie.

Dla każdego istotnego twierdzenia zapisz:

Stosuj niewielki zestaw jasno określonych statusów: nieprzetestowane, w trakcie testu, poparte w określonych warunkach, podważone w określonych warunkach i niejednoznaczne. To zalecane etykiety procesu, a nie dodatkowe oficjalne bloki canvasa. Unikaj nieograniczonego statusu „udowodnione”: na przykład wynik uzyskany przy wsparciu podczas konfiguracji nie potwierdza, że działa konfiguracja samoobsługowa.

Ustal priorytety założeń, zadając dwa pytania: Czy pomyłka istotnie zmieniłaby najbliższą decyzję dotyczącą rozwoju? Ile mamy odpowiednich dowodów? Zacznij od założeń o dużych konsekwencjach i słabych dowodach. Wskazówki Strategyzer dotyczące hipotez krytycznych (https://www.strategyzer.com/library/how-to-test-your-idea-start-with-the-most-critical-hypotheses) rozróżniają założenia dotyczące pożądaności, wykonalności i opłacalności, pomagając zespołom sprawdzać popyt klientów, zdolność dostarczenia rozwiązania i ekonomię działania.

Zadbaj o czytelność canvasa, zapisując szczegółowe uzasadnienia w powiązanym rejestrze. Poniższa tabela pokazuje, jak taki rejestr mógłby wyglądać w przypadku hipotetycznego narzędzia do przekazywania projektów. Wszystkie obserwacje i liczby wymyślono na potrzeby przykładu; nie są to wyniki badań ani zalecane wielkości prób. Identyfikatory dowodów oznaczają zapisy, które prawdziwy zespół utworzyłby i podlinkował, a nie istniejące dokumenty.

W rzeczywistym rejestrze powiąż każdy identyfikator dowodu z odpowiednimi notatkami, nagraniami zadań, eksportami zdarzeń lub dziennikami czasu. Jeśli to możliwe, wskaż odpowiednią sekcję lub znacznik czasu. Slajd prezentacji z informacją „klientom się podobało” trudno zweryfikować, bo pomija obserwacje i ich kontekst.

Każdy zapis dowodów powinien określać metodę, sposób rekrutacji, kwalifikujących się uczestników lub zdarzenia, liczbę zebranych obserwacji, wersję produktu, udzielone wsparcie oraz wykluczenia. Zachowuj sprzeczne wyniki obok korzystnych. Jeśli kilka podsumowań powtarza tę samą rozmowę, pozostaw jej pierwotny identyfikator dowodu, aby powtórzenie nie wyglądało na niezależne potwierdzenie.

Zapisz plan testu przed zapoznaniem się z wynikami. Karta Test Card Strategyzer (https://www.strategyzer.com/library/validate-your-ideas-with-the-test-card) jasno określa cztery elementy: hipotezę, test, pomiar i próg. Dodaj osobę odpowiedzialną, limit czasu i działanie przypisane do każdego możliwego wyniku.

Przykładowy plan dla A-02 mógłby wyglądać tak:

Próg w tym przykładzie to warunek przejścia do kolejnego, ograniczonego etapu, wybrany przez zespół. Nie jest to statystyczne oszacowanie wyników rynkowych. Wybierz własny próg w zależności od decyzji i kosztu pomyłki; nie traktuj zasady „cztery z pięciu” jako uniwersalnego sposobu potwierdzania założeń.

Dobierz metodę do twierdzenia. Wykorzystaj opisy niedawnej pracy, aby zbadać problem, obserwację zadań, aby sprawdzić użyteczność, konkretną płatną ofertę, aby zbadać zachowania zakupowe, a dzienniki operacyjne, aby sprawdzić nakład pracy związany ze wsparciem. Ogranicz wnioski do tego, co rzeczywiście mierzy dana metoda: kliknięcie w newsletter nie potwierdza regularnego korzystania z produktu.

Z góry określ, co oznaczają niejednoznaczne wyniki. Jeśli zbyt mało kwalifikujących się uczestników ukończy test, zapisz, dlaczego wynik jest niejednoznaczny. Jeśli w połowie testu zmienisz grupę odbiorców, zadanie, ofertę lub próg, utwórz nową wersję testu i zachowaj pierwotną. W przeciwnym razie zmieniony eksperyment może po cichu stać się korzystną odpowiedzią na inne pytanie.

Po każdym teście zapisz trzy osobne stwierdzenia: co się wydarzyło, co to może sugerować i co zespół zamierza zrobić. Wskazówki GOV.UK dotyczące analizy sesji badawczych (https://www.gov.uk/service-manual/user-research/analyse-a-research-session) wyraźnie rozdzielają obserwacje tego, co ludzie powiedzieli lub zrobili, od wniosków i późniejszych działań.

W przykładowym teście konfiguracji te stwierdzenia mogłyby brzmieć:

Jest to również zgodne ze strukturą Learning Card Strategyzer (https://www.strategyzer.com/library/capture-customer-insights-and-actions-with-the-learning-card): określ hipotezę, zapisz obserwacje, wyciągnij wniosek i zdecyduj, jak działać.

Gdy dowody są sprzeczne, przed połączeniem wyników przeanalizuj warunki. Doświadczeni użytkownicy mogą wykonać zadanie, z którym nowicjusze sobie nie poradzą. Prototyp może zachowywać się inaczej niż udostępniony produkt. Jeśli te różnice wpływają na decyzję, podziel założenie. Zawęź potwierdzone stwierdzenie tak, by inny członek zespołu potrafił dokładnie wyjaśnić, w jakich warunkach ma ono zastosowanie.

Zapisz opatrzoną datą migawkę canvasa, gdy dowody zmienią istotną decyzję. Zachowaj identyfikatory założeń, odnotowując zmiany w ich brzmieniu. Jeśli twierdzenie znacząco się zmieni, utwórz nową wersję lub powiązane założenie, aby wcześniejsze dowody nadal były przypisane do stwierdzenia, które faktycznie testowały.

Przydatny wpis w dzienniku zmian zawiera poprzednie i zmienione stwierdzenie, identyfikatory dowodów będących przyczyną zmiany, powiązane bloki canvasa, osobę odpowiedzialną za decyzję i następne działanie. W przypadku hipotetycznego wyniku testu konfiguracji mógłby brzmieć tak:

Canvas v0.3 → v0.4. Założenie A-05 zmieniono z „Żadna agencja nie potrzebuje więcej niż 20 minut wsparcia przy konfiguracji” na „Wymagany zakres wsparcia różni się między agencjami importującymi i nieimportującymi danych”. Przyczyna: E-05. Zaktualizuj kluczowe działania, relacje z klientami i strukturę kosztów. Następne działanie: przetestuj osobno proces importowania danych.

Sprawdzaj powiązane bloki za każdym razem, gdy zmienia się twierdzenie. Dodanie wspieranego wdrożenia wpływa na pracę niezbędną do dostarczenia produktu oraz powiązane założenia dotyczące kosztów. Wskazówki Strategyzer dotyczące canvasa (https://www.strategyzer.com/library/the-business-model-canvas) podkreślają te zależności: zmiana jednej części modelu może wymagać zmian w innych miejscach.

Ustal zarówno daty, jak i warunki ponownego przeglądu. Wróć do założeń, gdy zmieni się docelowy klient, cena, kanał pozyskiwania, proces pracy z produktem lub układ z dostawcą. Zachowaj stare dowody, ale ponownie oceń, czy warunki ich uzyskania nadal odpowiadają obecnemu modelowi.

Mały zespół może zacząć od krótkiego, cotygodniowego przeglądu skupionego na decyzjach:

Na koniec podejmij konkretną decyzję: kontynuuj ograniczony pilotaż, zmień proces, zawęź segment klientów, zbierz brakujące dowody lub wstrzymaj prace zależne od niepotwierdzonego twierdzenia. Przydatnym rezultatem jest możliwe do prześledzenia powiązanie tego, w co wierzy zespół, co zaobserwował i co postanawia zrobić dalej.