TL;DR

Artinyan proponuje traktowanie przedsięwzięcia biznesowego (venture) jako job performera z własnym głównym zadaniem
Główne zadanie venture: walidacja swojego prawa do istnienia poprzez redukcję niepewności i dostarczanie dowodów na zdolność przetrwania
Venture to przede wszystkim system uczenia się przekształcający założenia w dowody, podczas gdy produkt stanowi produkt uboczny
Sub-jobs venture działają równolegle, nie sekwencyjnie, co powoduje chaos charakterystyczny dla wczesnych etapów
Typowa sytuacja: niekończące się eksperymenty produktowe przy rzadkiej walidacji modelu biznesowego z porównywalną dyscypliną
Skuteczna weryfikacja wymaga jedynie 5-10 wywiadów, obserwacja w naturalnym środowisku dostarcza lepszych danych niż deklaracje
Redukcja niepewności stanowi główną walutę w relacjach z inwestorami oraz zarządem
Operating system to nie „what to build next”, lecz „what to LEARN next”
Canvasy funkcjonują jako narzędzia dopasowania (wyrównywania założeń w zespole), nie walidacji

Dlaczego startupy nadal upadają mimo dostępu do wiedzy?

Kalbach, autor „Jobs to Be Done Playbook” i współzałożyciel Jobs to Be Done Toolkit, rozpoczyna webinar prowokacyjnym pytaniem. Zachęca uczestników: sprawdźcie w Google „why do startups fail”.

Wyniki okazują się konsekwentne. W pierwszej trójce powodów zawsze pojawia się brak zrozumienia potrzeb rynku lub całkowity brak potrzeby rynkowej. Jak zauważa prowadzący, problem dotyczy nie tylko startupów. Wprowadzenia nowych produktów na rynek ponoszą porażkę z identycznego powodu – wymyślamy rzeczy, których nikt nie potrzebuje.

Artinyan, gość specjalny wydarzenia, ma z tym problemem osobiste doświadczenie. Z wykształcenia inżynier i ekonomista, przez 10-15 lat pracował w środowisku korporacyjnym. Jednak zbyt statyczne otoczenie skłoniło go do przejścia do świata startupów. Rezultat? Jak sam przyznaje z ironią: „almost failed everything”. To właśnie seria porażek pchnęła go do poszukiwania frameworków pozwalających zakładać przedsięwzięcia bez powtarzania typowych błędów.

Problem sięga głębiej niż produkt

Po przeanalizowaniu dziesiątek raportów badawczych o porażkach startupów i innowacji, Artinyan formułuje bezkompromisową diagnozę. Większość porażek wynika z budowania rozwiązań, których nikt nie chce. Gonienie za trendami technologicznymi, innowacje bez dowodów, budowanie bez zrozumienia użytkowników.

Według jego obserwacji drugi, równie istotny problem siedzi wewnątrz samego venture. Każde przedsięwzięcie stanowi „kopalnię złota założeń”, które nigdy nie są walidowane. Brak dowodów prowadzi do miesięcy i lat spalania zasobów na nic. To kwestia ograniczania ryzyka i ślepych punktów wewnątrz organizacji.

Luka w dyscyplinie walidacji

Tu Artinyan identyfikuje kluczowy problem, który jego thought experiment próbuje zaadresować. Jak mówi wprost: prowadzimy niekończące się eksperymenty produktowe, walidujemy funkcje, użyteczność i doświadczenia użytkownika, lecz rzadko walidujemy sam model biznesowy z taką samą dyscypliną.

Jobs to Be Done daje potężne narzędzie do zrozumienia użytkowników. Artinyan to docenia, jednak widzi ograniczenie: framework jest bardzo taktyczny, nie strategiczny. Mówi wszystko o kliencie, prawie nic o zdolności venture do przetrwania.

Dlatego proponuje odwrócenie perspektywy.

Eksperyment myślowy: venture jako job performer

Artinyan stawia uczestnikom pytanie: co by było, gdybyśmy potraktowali venture jak użytkownika?

Venture ma rezultaty i aspiracje. Wykonuje określone job steps. Działa w konkretnych warunkach i zmaga się z ograniczeniami zasobowymi. Posiada też aspekty emocjonalne i społeczne. Dlaczego więc nie myśleć o nim tak samo jak o użytkownikach? To właśnie ten thought experiment prezentuje podczas sesji.

Na najwyższym poziomie głównym zadaniem (job) venture jest walidacja swojego prawa do istnienia. Nic więcej, nic mniej. Nie launch produktu, nie wykonanie roadmapy, nie shipping funkcji. To outputy, nie rezultaty.

Jak podkreśla prelegent, zadaniem venture jest redukcja niepewności. Wystarczająco szybka, żeby uzasadnić dalsze inwestycje.

Desirability kontra viability

Produkt może kreować postęp użytkownika i nadal ponosić porażkę. Można osiągnąć problem-solution fit, można mieć product-market fit. I nadal model biznesowy nigdy nie zostanie zwalidowany.

Jak ujmuje to Artinyan: desirability nie gwarantuje viability modelu biznesowego. Potrzebne są oba spojrzenia. JTBD na poziomie użytkownika dla desirability, z kolei JTBD na poziomie venture dla survivability samego przedsięwzięcia.

Sub-jobs działają równolegle

Po rozbiciu tego na części otrzymujemy listę sub-jobs venture. Artinyan pokazuje je na slajdzie, jednak zauważa coś fascynującego: wszystkie działają równolegle, nie sekwencyjnie. Nie ma możliwości walidowania ich jeden po drugim. Wszystko jest połączone, wszystko wpływa na siebie nawzajem. Dlatego praca we wczesnych etapach jest tak chaotyczna.

Zespoły uwielbiają wierzyć, że budują produkt. Ale jak twierdzi Artinyan, produkt jest produktem ubocznym. Venture to system uczenia się – system przekształcający domysły w dowody, ujawniający ukryte ryzyka, zarabiający na pozwolenie na kontynuację.

Użytkownicy wybierają produkty, aby osiągnąć postęp. Natomiast liderzy, inwestorzy, board members wybierają ventures, aby dostarczyły:

Dowodów na zdolność do przetrwania
Dowodów na zdolność do skalowania
Dowodów uzasadniających kolejną rundę zasobów

Operating system: What to LEARN next

To prowadzi do fundamentalnego przesunięcia w myśleniu o venture. Jak ujmuje to Artinyan, nie chodzi o „what should be built next” ani „what feature should we ship next”. Chodzi o najbardziej istotną rzecz, której organizacja musi się nauczyć, żeby zredukować niepewność związaną z przetrwaniem venture.

To staje się operating system. Nie pytanie „co budujemy”, lecz „czego musimy się nauczyć jako organizacja, żeby zmniejszyć niepewność związaną z przetrwaniem venture”.

JTBD Canvas dla venture – praktyczny przykład

Artinyan pokazuje, jak mogłoby to wyglądać na Jobs to Be Done Canvas dla nowego venture. Wykorzystuje job performers network – pokazuje wszystkich wykonawców zadań. Venture samo w sobie, ale też founders, product innovation team, interesariusze, customers, investors.

Desired identities? Wiarygodne, zrównoważone, strategicznie wyrównane venture oraz postrzegane jako zdolne do uczenia się i adaptacji, wykonywania w warunkach niepewności. Related jobs – zadania niekluczowe dla venture. Główna aspiracja? Validate its right to exist.

Prelegent rozbija to na job steps, struggles, current solutions i workarounds. Przyznaje szczerze: jest tu mnóstwo założeń. Jednak właśnie to jest praca startupu – dostarczanie dowodów na miejscu tych założeń.

Dyskusja: Czy grupa może być job performerem?

Kalbach zauważa problem, który czasem pojawia się w konwersacjach. Trudno różnicować job użytkownika od job venture. Który job performer? O kim mówimy?

Scott z uczestników wchodzi do dyskusji. Podnosi fundamentalną kwestię: venture nie może nic zrobić, to wyimaginowana rzecz w głowach ludzi. To ludzie są aktorami wykonującymi działania. Czy job performerem nie powinien być CEO, który musi stworzyć zrównoważony model biznesowy?

Artinyan zgadza się częściowo. Odpowiedzialności są dziś rozproszone – CEO odpowiada za financial throughput i business model, jednak wypełnienie Business Model Canvas nie wystarczy. To założenia modelu biznesowego, nie model. Żeby go zwalidować, trzeba go rozłożyć. Znajdziemy użytkowników, value proposition, kanały dystrybucji. Jeśli ten model biznesowy nie jest współpracą specjalistów, to czym w ogóle jest? Założeniem na papierze.

Dodaje ważny punkt o distributed ownership: nawet inżynier może być zaangażowany w user research, żeby zrozumieć na późniejszym etapie dla kogo buduje, dlaczego i co jest in scope, a co out of scope. Nie sekwencja abstrakcyjnych ról, gdzie każdy dba tylko o swoją część – to wszystko jest połączone.

Scott kontynuuje pytanie: czy nie powinniśmy iść krok dalej i zidentyfikować osobę odpowiedzialną za wykonanie pracy?

Artinyan daje anegdotę. W typowym startupie z pre-seed lub seed funding nie ma dużych kwot. Kilku founderów, może zatrudnisz kilka osób przy odpowiednim spalaniu gotówki. Kończy się na 5-10 pracownikach, dlatego kluczowe jest „skin in the game”. Jeśli zachowujesz się jak employee, nie będziesz działać w startupie.

Kalbach przypomina własne doświadczenie. Kiedy dołączył do swojej firmy, było tam 12 osób. CTO robił sales, wszyscy nosili różne kapelusze. Nie było zróżnicowania pracy – działali jako grupa.

Need definiuje job performera

Kalbach proponuje odwrócenie skryptu. JTBD to framework do identyfikacji niezaspokojonych potrzeb. Każda encja, która ma potrzebę, może być job performerem.

Nie musimy zaczynać od osoby, lecz od stwierdzenia: ta rzecz ma potrzebę. Mogę zrozumieć jej potrzeby przez pryzmat JTBD. Dlatego mogę nazwać grupę ludzi lub kollektyw jak venture job performerem.

Business Model Canvas: Malowanie założeń

Wolfram zgłasza inne spojrzenie. Czy venture nie jest po prostu rozwiązaniem dla job? Jest job, są underserved needs. Mam pomysł na startup/venture dostarczający rozwiązanie adresujące te needs lepiej niż konkurencja. Venture jako solution to specific job – JTBD w problem space, venture w solution space.

Artinyan odpowiada: może tak być, jednak pytanie brzmi: jak przejść od pomysłu do zwalidowanej opportunity, a potem przekazać to venture, które jest solution centerem? To też jest journey. Typowo istnieje zbyt wiele opportunities konkurujących ze sobą, zazwyczaj C-level wpływa na wszystkie te opportunities w korporacji.

Wolfram kontynuuje: jeśli oceniamy opportunities przez to, która jest najbardziej underserved, wybieram tę z największą luką. Potem muszę znaleźć rozwiązanie/venture adresujące tę opportunity lepiej niż istniejące alternatywy.

Kalbach zadaje pytanie: jak quantyfikować to podejście? Artinyan przyznaje: to jest bardzo trudne – mix własnych założeń i prób quantyfikacji przez surveys z ludźmi.

Premium ponad alternatywy

Wolfram podnosi ważny punkt: underserved need to jedno, lecz willingness to switch and pay to underserved need to drugie pytanie.

Artinyan mówi wprost: spędził mnóstwo pieniędzy i czasu w życiu na rzeczy, które myślał, że stanowią realny problem. Jednak tak nie było. Ludzie nie byli skłonni płacić i przełączać się – alternatywy były wystarczająco dobre. Musi być premium ponad alternatywy, których używają dzisiaj, żeby ktoś był skłonny się przełączyć.

Nie wystarczy być lepszym. Trzeba być wystarczająco lepszym, żeby uzasadnić koszt zmiany.

Canvasy bez walidacji nie mają wartości

Kalbach zgadza się z problemem, który Artinyan opisał wcześniej. Martwi się o ludzi wypełniających canvasy bez jakiejkolwiek investigacji, jednak rzuca duże „jednak”. Jest wartość w canvasach nawet jeśli są to założenia.

Wartość pojawia się, gdy masz więcej niż jedną osobę. Szczególnie dwóch, trzech ludzi – tam zaczyna się skala. Używanie canvasów jako narzędzia dopasowania do artykułowania tego, co ludzie mają w głowach ma realną wartość.

Czego nie chcesz: trzy osoby z trzema różnymi założeniami, które nawet nie wiedzą o istnieniu różnic. Harmonizacja, agreement na temat assumptions, nie dwa czy trzy różne domysły. W organizacji z 30, 300, 30 000 ludźmi – tym bardziej.

Artinyan zgadza się całkowicie. To dobre ćwiczenie, jako konsultant można używać tego do znalezienia wariacji różnych opinii w organizacji. Dodaje jeszcze jeden punkt: kiedy zaczynasz zapisywać założenia i próbujesz je prove i falsyfikować, może być ewolucja. Jeśli spojrzysz na canvas napisany pół roku temu, widzisz learning part za tym.

Matthias dzieli się, że spędza mnóstwo czasu na adjustowaniu języka ludzi – z „I think” na „my hypothesis is” lub „I assume that”. Kalbach i Matthias właśnie zaktualizowali swój canvas, dosłownie wstawili słowo „hypothesis”. Teraz nazywają to Jobs to Be Done Hypothesis Canvas.

Bo to wszystko, czym jest – thinking tool dla zespołu, żeby wyciągnąć założenia i pomysły na targets. Potem oczywiście wychodzisz i robisz wywiady albo jakikolwiek pierwszy krok research. I odkrywasz: ups, źle określiliśmy focus job lub musimy zmienić job performera. Jednak potrzebujesz punktu startowego jako grupa.

I tam właśnie canvasy mają realną wartość. Nie są narzędziem walidacji, lecz narzędziem dopasowania.

Krytyka popularnych narzędzi

Kalbach podnosi jeszcze jeden ważny punkt. Wspomina o Value Proposition Canvas Alexandra Osterwaldera – follow-up do Business Model Canvas. Problem? Mają tam to kółko dla jobs to be done i definiują to bardzo luźno i casualowo. Jakby: pomyśl o job i wpisz to tam.

Jak mówi prowadzący: nie ma tam żadnej naukowej precyzji, którą znamy z jobs to be done. Alexander sam tak robi w swoich video – po prostu wpisuje cokolwiek, przynajmniej z perspektywy Kalbacha.

Dlatego jobs to be done powinno być inputem do Value Proposition Canvas. Musisz zrobić własną analizę, a potem wstawić to w to pudełko, zamiast wymyślać na miejscu.

Walidacja w praktyce: Minimum wywiadów, maksimum spostrzeżeń

Kalbach wraca do głównego wątku: jak więc walidować model biznesowy po jego artykułacji przez pryzmat JTBD?

Artinyan: przede wszystkim user research. Robisz assumption, w tym przypadku dotyczący venture, jednak możesz opisać dowolnego job performera. Nie robi dużo researchu typowo – po 5-10 wywiadach zaczynasz słyszeć te same rzeczy w kółko. Jeśli nie ma wzorca, możesz być na złej ścieżce. Szukasz ludzi w szumie.

Jeśli widzisz, że ludzie struggle z tym samym tematem co twój pomysł jako founder, znajdujesz innych ludzi. Koncentracja na innovative early adopters (wcześni użytkownicy), nie na laggards. Jeśli znajdziesz ten wzorzec, jest ok – zacznij to opisywać. Może masz 5-10 interviewees, mogą być też twoimi pierwszymi early adopters później. Nie wiesz.

Matthias pyta: czy formułujesz pytania inaczej, kiedy wychodzisz robić research z tym insights canvas?

Artinyan odpowiada: stara się robić jak najmniej wywiadów. Chce widzieć ludzi w ich środowisku – osobista obserwacja, czy naprawdę struggle? I nawet to jest artificial, bo jesteś obecny jako osoba nie pracująca w tej firmie. Jednak kiedy zaczynasz interviewing, zaczynasz już wprowadzać błąd systematyczny.

Matthias zgadza się z biasami. Nie uważa, że to koniecznie minus jakiejkolwiek qualitative czy ethnographic research. Kładzie duży nacisk na wyciągnięcie tych biasów vis-à-vis canvasów jak ten, dlatego zaczynamy od assumption. Często mówi ludziom: oczywiście jako researcher będziesz mieć biases – to część profesjonalizmu branży.

Chodzi o zrozumienie: jak je artykułujesz i deklarujesz. Kiedy wypełniamy takie canvasy, ludzie z doświadczeniem sprawiają, że wygląda to bardzo łatwo i naturalnie. Realność jest taka: musisz naprawdę sprawić, żeby ludzie zobaczyli – nie chodzi tylko o wypełnienie, lecz o to, jak dostać dopasowanie przed szukaniem walidacji.

Praktyczny przykład: Capoeira i zaskakujące job performers

Artinyan dzieli się konkretnym przypadkiem z własnego doświadczenia. Był zaangażowany w grupę capoeira w Zurychu, która stanęła przed pytaniem: czy membership fee jest odpowiednie za to, co robią?

Typowe podejście? Benchmarking – sprawdzić, co robią inni w Zurychu, potem pozycjonować się nieco poniżej lub powyżej z dodatkową wartością.

Artinyan zatrzymał tę pracę. Zaproponował: może powinniśmy pomyśleć o job performers w kontekście sportu?

To, co odkryli, było fascynujące. Byli konfrontowani z ludźmi mówiącymi rzeczy typu: „Szukam mojego następnego męża robiąc sport, pomóżcie mi” albo „Pomóżcie mi zbudować social network w Zurychu, bo jestem nowy w mieście”.

Jak podkreśla prelegent: jeśli spojrzysz z tych perspektyw, przez te soczewki, możesz skończyć z totalnie innymi modelami cenowymi, a nawet innymi rozwiązaniami.

To pokazuje konkretnie, jak JTBD zmienia pricing strategy i całe podejście do business model. Nie chodzi o „sport za X złotych miesięcznie”, lecz o „hiring capoeira do znalezienia partnera” lub „hiring capoeira do integracji w nowym mieście”. Totalnie inne value propositions, totalnie inne modele cenowe.

Kiedy JTBD dla venture ma sens (i kiedy nie)

Kalbach podnosi obserwację z ostatnich 12-18 miesięcy. Wielu ludzi chce używać frameworka do mapowania ekosystemu – JTBD jako framework do sense-making i zrozumienia w tych złożonych przestrzeniach. Element tej konwersacji – myślenie o venture jako job performerze – wydaje się pasować do tej rozmowy.

Matthias pyta: czy to rezonuje? Czy używacie JTBD do zrozumienia większego ekosystemu? Czy pomocne jest używanie JTBD do definiowania job, który venture robi względem customer jobs?

Kalbach jest szczery: to właśnie tam widział JTBD zawodzące. Kiedy próbujesz aplikować to do całego ekosystemu, kończysz z pół tuzina do tuzina różnych job performerów, potem dziesiątkami różnych jobs. Staje się to zbyt trudne do ogarnięcia.

Wracając do pierwszego punktu Scotta: jedna z wartości JTBD jest to, że przynosi skupienie. Zmusza cię do powiedzenia: dla kogo tworzymy wartość i jaki problem próbujemy rozwiązać dla nich? Potem idziesz głęboko w tę rzecz. Rozumiesz ekosystem, lecz tylko po to, żeby zrobić te wybory. Używanie JTBD do mapowania całego ekosystemu – Kalbach widział tutaj ograniczenia.

Artinyan zgadza się całkowicie. To samo, to też eksperyment. Myślał, że może będzie więcej głosów mówiących: zapomnij o używaniu JTBD do mapowania business modelu. Jednak to thought experiment. Mógłby sobie wyobrazić startup, z którym pracował – typowo nie ma pieniędzy, żeby płacić wielu ludziom w ekosystemie. Potrzebujesz suppliers, potrzebujesz kogoś kodującego dla ciebie gdzieś indziej na świecie. Typowo robisz revenue share albo jakiś model, więc siedzą w łódce i to dobry aspekt – kiedy ty jesteś successful, oni też.

Możesz ich zmapować, jednak zgadza się – to trudna rzecz używać JTBD do tego. Typowo używa ecosystem mapping dwuwymiarowego, żeby widzieć kto jest zaangażowany w co.

Kluczowe wnioski

Artinyan kończy sesję prostym zaproszeniem: jeśli Jobs to Be Done jest truly universal, dlaczego ograniczać go tylko do użytkownika? Venture ma job to get done też. Kiedy zmapujesz ten job, dostajesz jaśniejszą, szybszą i bardziej uczciwą ścieżkę do redukcji niepewności w venture i szans przetrwania.

Kalbach dodaje jeszcze jeden punkt do dyskusji. Miał w głowie notację z Petera Druckera z „The Practice of Management” (1954/1955). Drucker napisał: jest tylko jedna ważna definicja business purpose – stworzyć klienta. To jest job biznesu – stworzyć wartość, dostarczyć wartość. Jednak chodzi o tworzenie klienta.

Artinyan odpowiada: Zasadniczo tam, gdzie Lean Startup zaczął. Customer development process Steve’a Blanka. Jeśli spojrzysz wąsko na Lean Startup, to solutionizing aspect – build-measure-learn, lecz budujesz rozwiązanie dla nieznanego klienta. Steve Blank jasno opisał swój customer development process: najpierw zrozum użytkownika, potem stwórz klienta.

Druga rzecz, którą Kalbach miał w głowie: używał w swojej książce figure 8 we wprowadzeniu. Dostał framework – nie pamięta autora w tej chwili. Powiedział: są cztery rzeczy, które biznes robi:

Define value – określenie wartości
Create value – stworzenie wartości
Deliver value – dostarczenie wartości
Capture value – przechwycenie wartości

Mógłby użyć tych pod validate its right to exist, bo wtedy to rozbija na bardziej zdefiniowane chunks, na których się skupić. Czy problem venture jest wokół capturing value? Czy musi create więcej value?

Artinyan: Dokładnie. To, co typowo dostajemy z Business Model Canvas z Strategizer – front end, back end, financial throughput. Ash Maurya argumentuje w tym samym kierunku – naprawdę musisz zrozumieć, która sekcja business modelu tworzy wartość, przechwytuje wartość, dystrybuuje wartość. Nie jest pewien, czy jobs canvas jest właściwym vehicle dla takiego myślenia, jednak BMC mógłby być innym narzędziem, którego używasz.

Gates, nie step-by-step

Artinyan podkreśla jeszcze jeden kluczowy punkt. Budowanie venture to nie step-by-step approach, to nie proces, gdzie robisz A, B, C, D. Jednak musisz mieć jakieś gates, które spełniasz – jak problem-solution fit.

To różnica między sekwencyjnym procesem a osiąganiem milestones poprzez learning w chaotycznym, równoległym środowisku.

Checklisty praktyczne

✅ Kiedy stosować JTBD dla venture zamiast dla produktu

Użyj JTBD dla venture, gdy:

Masz wypełniony Business Model Canvas, jednak zero dowodów na jego działanie
Zespół ma różne wizje tego, co venture próbuje osiągnąć
Spalasz zasoby bez jasnego dowodu
Nie wiesz, która część modelu biznesowego jest największym ryzykiem
Pytanie brzmi „czego musimy się nauczyć”, nie „co musimy zbudować”

Użyj JTBD dla produktu, gdy:

Masz jasność co do viability modelu biznesowego
Pytanie dotyczy konkretnych funkcji lub user experience
Znasz klienta, lecz nie wiesz jak dostarczyć wartość
Skupienie na desirability, nie viability

✅ Od założeń do dowodów – proces walidacji

1. Artykułacja założeń

Wypełnij JTBD Canvas dla venture
Wypisz kluczowe założenia dla każdego elementu
Sprawdź dopasowanie w zespole – czy wszyscy widzą to samo?
Oznacz wszystko jako „hypotheses”, nie „facts”

2. Priorytetyzacja ryzyka

Które założenie, jeśli fałszywe, zabije venture najszybciej?
Czy masz gotowość do płacenia i zmiany, nie tylko underserved need?
Czy jest premium ponad alternatywy wystarczający do zmiany?
Define, create, deliver czy capture value to największe wyzwanie?

3. Walidacja przez research

5-10 wywiadów z early adopters (nie laggards)
Priorytet: obserwacja w naturalnym środowisku > wywiad
Szukaj wzorców – czy ludzie struggle z tym samym?
Brak wzorca po 10 wywiadach = możliwa zła ścieżka

4. Iteracja i learning

Porównaj canvas sprzed 3-6 miesięcy z obecnym
Które założenia zostały sfalsyfikowane? Które potwierdzone?
Czy redukcja niepewności jest wystarczająco szybka?
Czy jesteś bliżej „validate right to exist”?

✅ Red flags – kiedy canvasy szkodzą

Uważaj, jeśli:

Canvas został wypełniony raz i nigdy nie aktualizowany
Zespół traktuje wypełniony canvas jako „zrobione”
Zero planned validation dla kluczowych założeń
Canvas jest pokazywany inwestorom jako „business plan” bez dowodów
Używasz VPC bez proper JTBD analysis jako input

Dobrze, jeśli:

Canvas to living document aktualizowany regularnie
Każde pole ma status: assumption / validating / validated / falsified
Jest plan testów dla top 3 najbardziej ryzykownych założeń
Tracking zmian pokazuje wyraźną krzywą uczenia się
Canvas służy dopasowaniu przed walidacją

✅ Operating system – What to LEARN next

Daily/Weekly:

Co najbardziej ryzykowne założenie testujesz w tym tygodniu?
Jaki dowód zdobędziecie do końca sprintu?
Czy to output (funkcja) czy outcome (dowód)?
Meeting review: co team nauczył się vs co zbudował?

Monthly:

Aktualizacja JTBD Canvas dla venture – co się zmieniło?
Review top 5 założeń – które zostały zwalidowane/sfalsyfikowane?
Czy redukcja niepewności jest wystarczająco szybka dla interesariuszy?
Co jest następną najważniejszą rzeczą do NAUCZENIA SIĘ?

Quarterly:

Czy venture ma silniejszy claim do „right to exist”?
Porównanie założeń z Q-2: jak dużo uczenia się?
Które gates osiągnęliście? (problem-solution fit? business model fit?)
Czy walidacja modelu biznesowego trzyma tempo z walidacją produktu?

Kluczowy insight

Produkt jako efekt uboczny uczenia się

Standardowo myślimy: Startup to organizacja budująca produkt. Mierzymy postęp ilością zbudowanych funkcji, wypuszczonych wersji, zaimplementowanych funkcjonalności. Roadmapa to lista rzeczy do zbudowania.

W praktyce okazuje się, że: Jak ujmuje to Artinyan, produkt jest produktem ubocznym. Venture to system uczenia się – system przekształcający założenia w dowody, ujawniający ukryte ryzyka. Liderzy i inwestorzy nie wybierają venture, żeby budowało produkty. Wybierają je, żeby dostarczały dowodów na zdolność do przetrwania i skalowania.

Dlaczego to jest istotne: To fundamentalnie zmienia operating system organizacji. Pytanie przestaje być „what to build next” i staje się „what to LEARN next”. Najbardziej krytyczne pytanie to: jaka jest następna najważniejsza rzecz, której organizacja musi się nauczyć, żeby zredukować niepewność związaną z przetrwaniem venture? Nie chodzi o shipping funkcji, lecz o redukcję niepewności wystarczająco szybką, żeby uzasadnić kolejną rundę inwestycji. Przesunięcie uwagi z budowania na uczenie się chroni przed tworzeniem funkcji, których nikt nie chce kupić.

Test na jutro: Następnym razem gdy zaplanujesz nową funkcjonalność, spróbuj znaleźć sposób na obalenie tezy o jej niezbędności i sprawdź, czy posiadasz jakiekolwiek dowody rynkowe na jej poparcie.

Lista poleceń do analizy venture przez pryzmat JTBD

Poniższe instrukcje zostały opracowane na podstawie metodyki przedstawionej przez Yetvarta Artinyana podczas webinaru.

Polecenie 1: Identyfikacja sieci wykonawców zadań (Job Performer Network)

Prompt: „Działaj jako ekspert JTBD. Na podstawie opisu mojego projektu [OPIS], zidentyfikuj wszystkich członków sieci wykonawców zadań (Job Performer Network). Uwzględnij nie tylko klientów, ale także założycieli, inwestorów i zespoły wewnętrzne. Określ, jaki postęp każdy z nich chce osiągnąć oraz jakie mają ograniczenia zasobowe i aspiracje.”

Kiedy stosować: Na początku projektu lub podczas redefiniowania strategii venture, aby zrozumieć, czyje potrzeby musisz zbalansować, żeby model biznesowy przetrwał. Szczególnie wartościowe przed wypełnieniem Business Model Canvas lub podczas identyfikacji największych źródeł niepewności w modelu.

Polecenie 2: Weryfikacja założeń przez falsyfikację

Prompt: „Przeanalizuj moją listę założeń dotyczących modelu biznesowego: [LISTA]. Działaj jak sceptyczny inwestor i zaproponuj 3 sposoby na udowodnienie, że każde z tych założeń jest błędne. Skup się na:

Alternatywach, z których klienci korzystają obecnie i czy są wystarczająco dobre
Premium, które musiałoby istnieć, aby klienci byli skłonni się przełączyć
Najszybszym i najtańszym sposobie przetestowania każdego założenia w ciągu tygodnia”

Kiedy stosować: Przed etapem budowy produktu lub przed kolejną rundą inwestycji, aby zredukować niepewność i uniknąć inwestowania w martwe punkty. Stosuj szczególnie wtedy, gdy zespół jest zbyt pewny swoich założeń lub gdy spalasz zasoby bez wyraźnych proof points.

Polecane zasoby

Wspomniane w dyskusji:

Jobs to Be Done Playbook – Jim Kalbach
Jobs to Be Done Toolkit – platforma z narzędziami i szkoleniami (Jim Kalbach, Elaine Matthias)
Business Model Canvas – Alexander Osterwalder (Strategizer)
Lean Canvas – Ash Maurya
The Practice of Management – Peter Drucker
Steve Blank Customer Development Process
Substack Yetvarta Artinyana (publikacje 2x w tygodniu)

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Jobs to Be Done Untangled (webinar listopad 2025) – dostępny przez Jobs to Be Done Toolkit.

Tag: Desirability Vs Viability

Walidacja modelu biznesowego przez pryzmat Jobs to Be Done. Venture jako job performer #EN360