O czym jest ten film
- Autor przerabia framework Marka Pincusa (założyciela Zyngi) na gotowy skill dla asystenta AI, który ocenia pomysły produktowe.
- Framework nazywa się „proven, better, new” — sprawdzone, lepsze, nowe.
- Podstawowa teza: produkty w całości nowe niemal zawsze przegrywają, bo zmiana sposobu myślenia rynku wymaga ogromnych pieniędzy.
- Zamiast tego buduj na rynku z udowodnionym popytem, popraw jego najsłabsze punkty i dopiero na wierzchu testuj rzeczy naprawdę nowe.
- Drugi filar frameworku: różnica między instynktem a pomysłem — instynkt ma tysiąc osób, konkretną implementację tylko kilka.
- Case study Zyngi: FarmVille i Zynga Poker jako podręcznikowe zastosowanie „proven, better, new”.
- Skill ma dwa tryby komunikacji: „blunt” (bezpośredni) i „professional” (łagodniejszy).
- Pierwszy przykład na żywo: agentowy tracker żywieniowy — analiza tego, co w tej kategorii jest już sprawdzone.
- Drugi przykład: zautomatyzowany customer success manager — i wskazanie realnej niszy typu blue ocean.
- Skill zwraca też „cmentarzysko” nieudanych prób, anty-sygnały i napięcia w koncepcji produktu.
Redakcyjne tłumaczenie
Skąd wziął się ten framework
Jest taki miliarder, nazywa się Mark Pincus. To założyciel Zyngi — jednej z najbardziej udanych na świecie firm tworzących przeglądarkowe i mobilne gry. Pincus ma sprawdzony framework do rozwijania pomysłów biznesowych. Zamieniłem ten framework w skill. W tym materiale omówimy jego założenia, a potem przepuścimy przez niego kilka realnych przykładów. Jeśli siedzisz i zastanawiasz się, czy twój pomysł ma to coś, żeby faktycznie się udać — ten materiał jest dla ciebie.
(Informacja dodatkowa: Zynga to amerykańska firma odpowiedzialna m.in. za FarmVille i Zynga Poker, która wyrosła na fali gier osadzonych bezpośrednio w Facebooku około 2009–2011 roku.)
„Proven, better, new” — sprawdzone, lepsze, nowe
Framework nazywa się proven, better, new. Jego celem jest sprawdzenie, czy pomysł, który masz, w obecnej formie w ogóle warto budować.
Teoria stojąca za tym jest taka, że wszystko, co całkowicie nowe, upada. Naprawdę trudno jest mieć coś tak niesamowitego i tak nowego, żeby poruszyło cały rynek. To zwykle wymaga gigantycznych inwestycji — bo zmieniasz sposób, w jaki ludzie myślą.
Lepsza droga wygląda tak:
Sprawdzone (proven). Jeśli wychodzisz i budujesz produkt, buduj w obszarze, który już jest sprawdzony. Coś, co już działa. Ma wbudowany popyt. Ludzie już płacą za coś takiego. Do tego masz ustalony punkt odniesienia, do którego się porównujesz.
Lepsze (better). Bierzesz to, co sprawdzone, i zastanawiasz się: które elementy tego naprawdę frustrują ludzi? Co nie jest tak płynne, jak mogłoby być? Co nie jest tak dobre, jak mogłoby być? I to poprawiasz.
Nowe (new). Dopiero na tym dokładasz rzeczy naprawdę nowe. I tu obstawiasz swoje zakłady. Te zakłady to w istocie eksperymenty. Idealnie testujesz wiele nowych kierunków nałożonych na to, co już sprawdzone i co już poprawiłeś — aż znajdziesz swój unikalny klin.
Instynkt kontra pomysł
Druga część frameworku to różnica między instynktem a pomysłem.
Większość z nas ma trafne instynkty. Potrafimy się zgodzić, że istnieje jakiś problem, który wymaga rozwiązania. Ale to, jak ten instynkt manifestuje się w twoim konkretnym pomyśle — tu ludzie zaczynają się różnić w podejściu do implementacji. I właśnie doprowadzenie pomysłu do właściwej formy, poprzez system w rodzaju „proven, better, new”, jest tym, co tworzy naprawdę rentowne, udane firmy.
FarmVille jako podręcznikowy przykład
Zynga urosła do miliardowej wyceny wtedy, gdy Facebook wbudował gry we własną platformę. Jednym z ich najpopularniejszych tytułów był FarmVille.
Jak wygląda tu „proven, better, new”?
Sprawdzone: symulatory farmy już istniały. Było ich wiele i robiły dokładnie to samo. Miałeś swoją faremkę, wytyczałeś grządki, decydowałeś, co chcesz robić, sadziłeś rośliny i je uprawiałeś. Mechanika była już zwalidowana — ludzie chcieli farmić w przeglądarce.
Lepsze: Zynga poprawiła całą grafikę. Wszystkie te rośliny, grządki, arbuzy, sama farma — sprawili, że oprawa graficzna była wyraźnie lepsza niż u konkurencji. Poprawili też matematykę tego, jak rysują się przedmioty i grządki oraz jak wrzucasz rośliny, które chcesz posadzić.
Nowe: dodali element społeczny — znajomi mogli odwiedzać twoją farmę. To stało się jednym z ich największych hitów.
Zynga Poker — to samo podejście
To samo zrobili z pokerem, i chronologicznie ta gra chyba była pierwsza.
Gier pokerowych było wtedy mnóstwo. Poker istnieje pewnie od setek lat, a hazard od tysięcy. Zynga dosłownie sklonowała układ i strukturę innej popularnej gry pokerowej. Koncept był już sprawdzony — ludzie byli gotowi wejść i zapłacić za możliwość gry w pokera.
Jak zrobili to lepiej? Ich wersja działała w przeglądarce. Wcześniej trzeba było ściągnąć klienta na komputer — żeby zagrać ze znajomymi, każdy z nich musiał ten program pobrać. To zatrzymywało mnóstwo ludzi jeszcze przed próbą zagrania. Za każdym razem, gdy prosisz użytkownika o wykonanie jakiejś czynności, dokładasz tarcie i zmniejszasz szansę konwersji. Przenosząc grę do przeglądarki, zwiększyli liczbę osób w ogóle skłonnych spróbować.
A nowe? Podłączenie znajomych do stołu i wyświetlanie ich zdjęć profilowych.
W obu przykładach było oczywiście więcej rzeczy, które poprawili, a element „nowego” był czymś, co nieustannie iterowali i testowali.
Wszyscy „mieli pomysł na Ubera”
Zanim przejdziemy do skilla, jeszcze jedna rzecz — krytyczna dla tego, jak ten skill działa: instynkt kontra pomysł.
Kiedyś słyszało się to bardzo często: każdy miał pomysł na każdą popularną rzecz, jaka się wydarzyła. Gdy pojawił się Uber, milion osób mówiło: „Boże, ja miałem dokładnie ten sam pomysł”. Nie miałeś tego samego pomysłu. Miałeś ten sam instynkt. Instynkt mówiący: skoro mam w kieszeni telefon, nie powinienem musieć wychodzić na ulicę, stać na rogu w deszczu i machać ręką, żeby złapać taksówkę. Powinienem móc użyć technologii, którą mam, żeby ściągnąć kierowców do siebie.
Implementacją tego instynktu u Pincusa była firma SMS Taxi, która nigdy nie wystartowała. Pomysł polegał na tym, że wysyłasz SMS-a do dyspozytora taksówek, a ten przysyła po ciebie samochód. Uber zrobił coś zupełnie innego: skoro każdy ma telefon, to co, gdyby każdy chętny mógł zostać tym taksówkarzem?
Wielu ludzi miało ten sam instynkt. Tylko nieliczni mieli konkretne szczegóły pomysłu, które były potrzebne, żeby to naprawdę zadziałało. A jak sprawić, by instynkt ożył we właściwej formie? Od tego jest „proven, better, new”.
Skill w praktyce: tryby i wejście
Skill wywołuję, podając mu z grubsza, o co chodzi w mojej aplikacji. Warto być tu tak konkretnym, jak się da — narzędzie idzie w research i naprawdę próbuje sprawdzić, czy to, co masz, jest sprawdzone, lepsze i czy ma elementy nowego.
Są dwa tryby: blunt (bezpośredni) i professional (profesjonalny). Zauważyłem, że modele językowe potrafią sprawić, że poczujesz się parszywie z powodu pomysłu, który uważałeś za dobry. Dlatego skill komunikuje ci wnioski albo bardzo szczerze i bez owijania, albo trochę milej.
Jedno zastrzeżenie: musisz dać modelowi wystarczająco dużo kontekstu o swoim projekcie. W moim przypadku podałem bardzo ogólną koncepcję: „agentowy tracker żywieniowy, który daje użytkownikowi pełną kontrolę nad agentem przez serwer MCP i pozwala planować złożone posiłki z języka naturalnego”. To fajne, ale prawdopodobnie dostanę odpowiedź powierzchowną — bo realnie dałem powierzchowny input.
(Informacja dodatkowa: MCP — Model Context Protocol — to standard, dzięki któremu modele językowe łączą się z zewnętrznymi narzędziami i źródłami danych.)
Przykład 1: agentowy tracker żywieniowy
Odpaliliśmy go w trybie blunt. Pierwszy element analizy to instynkt stojący za aplikacją. Tutaj brzmi on: ludzie chcą trafiać w swoje cele żywieniowe i śledzić to, co powinni śledzić, bez żmudnej pracy z ręcznym logowaniem i planowaniem.
To bardzo mocna hipoteza. Instynkt za aplikacją rozwiązującą ten problem jest silny i istnieje mnóstwo dowodów popytu. Jest firma Cal AI, niedawno kupiona przez MyFitnessPal. Nie przepadam za tym, jak ich produkt jest zrobiony, bo nie uważam go za dokładny w śledzeniu. Ale mimo to robili przy wyjściu chyba między 30 a 50 milionów dolarów rocznie — a była to aplikacja „vibe-codowana”, licząca dwa lata. Więc dla wszystkich hejterów powtarzających, że vibe coding nigdy nie da nic znaczącego: chyba się myliliście.
(Informacja dodatkowa: „vibe coding” to potoczne określenie budowania aplikacji głównie przez opisywanie zamiarów asystentowi AI, bez ręcznego pisania większości kodu.)
Wiemy więc, że instynkt jest dobry. Teraz pytanie, jak wpisujemy się w „proven, better, new”.
Co jest już sprawdzone? To są rzeczy, które — jak mówi Pincus w książce — trzeba dosłownie skopiować. W FarmVille dosłownie skopiował mechanikę gry. W Zynga Pokerze dosłownie skopiował całość, a jedyną różnicą było przeniesienie do przeglądarki i kilka modyfikacji stanowiących element „nowego”.
W kontekście logowania jedzenia sprawdzone jest:
- Główna pętla: użytkownik podaje opis w języku naturalnym („zjadłem kurczaka z ryżem i sosem buffalo”), system szacuje makroskładniki, można ten szacunek skorygować, wpis się zapisuje, a ty widzisz postęp względem celu dziennego. Taki jest kształt rozwiązania, który przyjmują dziś aplikacje w tej niszy.
- Silnik celów: prawie wszystkie te aplikacje mają jakiś mechanizm pokazujący, jak wypadasz względem celu — utraty czy przyrostu masy. MacroFactor, jeden z konkurentów, potrafi dostosowywać plan: jeśli twoim celem jest schudnąć, a po tygodniu nie chudniesz, obniża ci kalorie.
- Onboarding i paywall Cal AI: istnieje masa case studies pokazujących, że choć ludzie bez końca narzekają na ich paywall, jest on bardzo skuteczny konwersyjnie. Warto go podpatrzyć.
- Dokładność danych o żywności, a także listy zakupów i pomoc w planowaniu posiłków.
To wszystko trzeba skopiować. To table stakes — warunek wejścia do gry. Jeśli tego nie masz, po co ktoś miałby przyjść do twojego narzędzia? Raczej nie przyjdzie.
Co zrobiłoby to lepszym? Pincus opisuje to tak: co sprawiłoby, że przesiadka zasługuje na dziewiątkę lub dziesiątkę na dziesięć? Ktoś używa sprawdzonego modelu, sprawdzonego systemu, sprawdzonej aplikacji — co musiałbyś zrobić lepiej, żeby to było na tyle przekonujące, że porzuci obecne rozwiązanie?
Weźmy Cal AI. Ich premisa: robisz zdjęcie jedzenia, a aplikacja loguje je za ciebie. Problem w tym, że to skrajnie podatne na błędy. Nie wiesz, ile było w tym oleju. Nie wiesz o połowie składników, które mogą siedzieć w sosie. Stąd masa skarg — myślisz, że jesteś na drodze do utraty wagi, a w rzeczywistości przybierasz, bo polegasz wyłącznie na zdjęciu. Osobiście uważam to za bardzo głupi model — chyba że ktoś podchodzi do swoich celów wyjątkowo luźno. Ale jeśli chcielibyśmy być od nich lepsi, to zbudowanie systemów pozwalających uzyskać dokładniejsze wyniki z tych zdjęć byłoby krokiem we właściwą stronę.
Co jest naprawdę nowe? Tu widać, dlaczego naprawdę warto rozpisać, co dokładnie planujesz zbudować i jaki ma być kształt rozwiązania. Model wziął moją wzmiankę o MCP zbyt dosłownie i uznał, że budujemy wyłącznie serwer MCP — podczas gdy w rzeczywistości jest też cała aplikacja. Chodziło mi tylko o to, że produkt wystawia interfejs dla power userów. W efekcie propozycje w kategorii „nowe” są moim zdaniem trochę bezsensowne.
Przykład 2: zautomatyzowany customer success manager
Drugi przebieg dotyczy zupełnie innego produktu i uruchomiłem go w trybie professional.
Koncepcja: zautomatyzowany manager sukcesu klienta. Jeśli pracowałeś kiedyś w firmie SaaS albo w jakiejkolwiek firmie enterprise, wiesz, że customer success to ogromna funkcja. Zatrudnia się do niej całkiem duże zespoły, żeby klienci wyciągali z narzędzia lub usługi maksimum. To jest kluczowe dla retencji: ograniczania odejść, a nawet upsellingu i podnoszenia wartości życiowej klienta.
Moim zdaniem ten obszar wciąż nie został naprawdę zdysruptowany przez AI. To nadal bardzo „ludzka” funkcja. Więc: gdybym mógł dać systemowi całą wiedzę o moim produkcie, moich szkoleniach czy czymkolwiek innym — jak fajnie byłoby mieć zautomatyzowanego CSM-a? Pomyśl o tym jak o bocie wsparcia, tylko bardziej „jeden na jeden” i wytrenowanym na znacznie głębszym zbiorze informacji.
Produkty tego typu już istnieją w świecie influencerów — wgrywasz wszystkie swoje treści z social mediów, kursy i szkolenia, a ludzie mogą z tym rozmawiać jak z chatbotem.
Skill nazywa ten koncept „sellable brain”. Instynkt: ludzie, którzy kupują od eksperta, chcą osobistych odpowiedzi tego eksperta na żądanie — ale ekspert nie zawsze może poświęcić im czas.
Największym przykładem jest aplikacja Delphi — całkiem fajna. Zebrali chyba w 2025 roku 19 milionów dolarów i mają ponad 2000 ekspertów na platformie. Uważam jednak, że ich model monetyzacji jest kiepski i pewnie dlatego nie są więksi, niż mogliby być.
Ten pomysł nie jest więc nowy. To wręcz zatłoczona i dobrze dofinansowana kategoria — ale to nie znaczy, że go zabijamy. To dokładnie jest etos „proven, better, new”: chcesz obszaru, w którym popyt jest już zwalidowany, a potem wchodzisz ze swoim klinem i robisz to lepiej.
Skill przechodzi przez ten sam proces: co jest sprawdzone, co może być lepsze — przy czym potrafi też podważyć rzeczy, których nie uznaje za realnie lepsze — i co jest naprawdę nowe w tym, co opisałeś.
I to ramowanie przez customer success jest tu czymś naprawdę interesującym i nowym. Wszyscy, którzy budują takie systemy — Delphi, Kajabi, Coachvox — celują w ludzi sprzedających produkty informacyjne albo w popularnych influencerów. A moje myślenie jest takie: co gdyby coś takiego działało jako manager sukcesu klienta dla firmy? Sekwencje onboardingowe, check-iny, eskalowanie spraw do ludzi, gdy trzeba, pomoc przy upsellach i cross-sellach. Żaden z tych analogów tego nie robi.
Fundament jest solidny. Obszarem zdecydowanie sprawdzonym są dobre boty wsparcia — takie, które faktycznie dają dobre odpowiedzi i zostały dostrojone pod konkretny produkt. One są bardzo wartościowe. Więc mieć coś głębszego, co potrafi wziąć kontekst twojego klienta plus twoją bazę wiedzy i dać mu naprawdę świetne doświadczenie przy onboardingu produktu — to według mnie coś rewelacyjnego. To błękitny ocean.
(Informacja dodatkowa: „blue ocean” to określenie rynku bez istniejącej bezpośredniej konkurencji, w odróżnieniu od „czerwonego oceanu” wypełnionego walczącymi o klienta graczami.)
Cmentarzysko, anty-sygnały i napięcia
Skill daje jeszcze kilka rzeczy. Cmentarzysko: kto próbował zrobić coś na obrzeżach twojego pomysłu albo coś pokrewnego i poległ? Anty-sygnały: o czym warto pamiętać jako o ostrzeżeniu.
A element, który lubię najbardziej, to wskazywanie napięć. W tym przypadku opisałem produkt jako oparty na graph RAG. To nie jest coś, z czym użytkownik wchodzi w interakcję. Nikt nie idzie do takiego produktu, mówiąc: „o mój Boże, ten będzie o niebo lepszy, bo to graph RAG”. To byłoby sprzedawanie funkcji zamiast rezultatu. Skill wypisuje też kilka innych potencjalnych napięć.
(Informacja dodatkowa: graph RAG to technika łączenia wyszukiwania po grafie wiedzy z generowaniem odpowiedzi przez model — rozwiązanie czysto techniczne, niewidoczne dla użytkownika końcowego.)
Co dalej
Skill będzie w opisie pod filmem. Możesz go wziąć i dorzucić do niego, co chcesz. Szkielet jest gotowy, ale jeśli chcesz, żeby robił więcej przebiegów researchu albo integrował się z twoim produktem czy repozytorium kodu — to jest coś, co sam robię we własnych pluginach. Gdy idę w research, każę mu przeskanować mój kod w kontekście odpowiadania na tego typu pytania o strategię produktową.
Jeśli podobał ci się ten materiał, podlinkuję podobny, który zrobiłem o wersji tego podejścia od CEO Y Combinatora — bardziej o definiowaniu swojego klina.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Nie zaczynaj od nowego rynku, zacznij od sprawdzonego
Na czym polega: Produkty w całości nowe niemal zawsze upadają, bo zmiana sposobu myślenia rynku wymaga kapitału, którego nie masz. Buduj tam, gdzie ludzie już płacą.
Jak stosować: Zanim zaczniesz cokolwiek pisać, wypisz 3–5 firm, które już zarabiają na twoim problemie. Jeśli nie potrafisz ich znaleźć, to nie jest sygnał, że jesteś pionierem — to sygnał, że popytu nie ma.
Na co uważać: „Sprawdzony rynek” to nie to samo co „rynek, na którym coś istnieje”. Sprawdzony znaczy: są przychody, są płacący klienci, są dane. Sam fakt, że ktoś zbudował podobne narzędzie i je porzucił, niczego nie waliduje.
2.Odróżnij instynkt od pomysłu
Na czym polega: Tysiąc osób „miało pomysł na Ubera”. Mieli instynkt. Pomysł to konkretna implementacja — a różnica między SMS Taxi a Uberem to różnica między zerem a dziesiątkami miliardów.
Jak stosować: Rozpisz osobno: (a) jedno zdanie instynktu — jaka frustracja jest realna, (b) konkretny mechanizm, którym ją rozwiązujesz. Potem zapytaj, czy z tego samego instynktu da się wyprowadzić trzy zupełnie różne mechanizmy. Jeśli tak, twój wybór wymaga uzasadnienia.
Na co uważać: Silny instynkt bywa uspokajający i usypia czujność. To, że problem jest prawdziwy, nie znaczy, że twoje rozwiązanie jest właściwe.
3.Kopiuj table stakes dosłownie, bez wstydu
Na czym polega: Zynga sklonowała układ konkurencyjnej gry pokerowej. Elementy sprawdzone należy odtworzyć wiernie, a nie „ulepszać z zasady”.
Jak stosować: Zrób listę funkcji, bez których nikt nie rozważy przesiadki — w trackerze żywieniowym to pętla „opis → estymacja makro → korekta → log → postęp do celu”. Odtwórz je najpierw. Innowację zostaw na później.
Na co uważać: Kopiowanie interfejsów i mechanik to co innego niż kopiowanie kodu, brandu czy chronionych elementów. Sprawdź granice prawne, zanim odtworzysz coś jeden do jednego.
4.Test „9 lub 10 na 10 za przesiadkę”
Na czym polega: Poprawa jest realna tylko wtedy, gdy skłoniłaby obecnego użytkownika konkurencji do porzucenia działającego rozwiązania. Wszystko poniżej tego progu to kosmetyka.
Jak stosować: Weź swoją listę usprawnień i przy każdym oceń w skali 1–10, czy samo to jedno usprawnienie wystarczyłoby, żeby ktoś się przesiadł. Zostaw tylko dziewiątki i dziesiątki.
Na co uważać: Sumowanie piątek nie daje dziesiątki. Dziesięć drobnych ulepszeń rzadko przebija koszt zmiany narzędzia i przeniesienia danych.
5.Szukaj usprawnień w skargach, nie w wizji
Na czym polega: Najlepszy kandydat na „better” to konkretna, powtarzalna frustracja użytkowników konkurencji — jak niedokładność szacowania kalorii ze zdjęcia w Cal AI.
Jak stosować: Przeczytaj recenzje w sklepach z aplikacjami, wątki na Reddicie i zgłoszenia do supportu konkurencji. Skarga powtarzana setki razy jest gotowym briefem produktowym.
Na co uważać: Głośna mniejszość nie zawsze reprezentuje płacących. Cal AI narzekano na paywall i mimo to konwertował świetnie — sprawdź, czy skarga przekłada się na realne odejścia.
6.Każde dodatkowe kliknięcie kosztuje cię użytkowników
Na czym polega: Zynga wygrała pokera głównie tym, że nie trzeba było niczego instalować. Każda czynność, o którą prosisz użytkownika, obniża konwersję.
Jak stosować: Policz kroki od „pierwsze zetknięcie z produktem” do „pierwsza wartość”. Usuń wszystko, co da się usunąć — instalację, rejestrację przed pokazaniem wartości, konfigurację.
Na co uważać: Nie każde tarcie jest złe. Onboarding i paywall Cal AI to celowe tarcie, które podnosi konwersję i jakość bazy użytkowników. Rozróżniaj tarcie przypadkowe od projektowanego.
7.„Nowe” to portfel eksperymentów, nie jeden zakład
Na czym polega: Element nowości ma być polem zakładów, które testujesz seryjnie — Zynga stale iterowała warstwę społeczną, aż znalazła to, co działa.
Jak stosować: Zaplanuj kilka niezależnych hipotez „nowego” nakładanych na już działający, sprawdzony rdzeń. Uruchamiaj je po kolei, mierząc wpływ na retencję.
Na co uważać: Nie testuj „nowego” na produkcie, który nie ma jeszcze sprawnego rdzenia. Wtedy nie odróżnisz porażki eksperymentu od porażki podstaw.
8.Jakość odpowiedzi AI jest funkcją jakości twojego briefu
Na czym polega: Autor podał modelowi ogólnikowy opis trackera i dostał ogólnikową analizę — a jedna wzmianka o MCP sprawiła, że model uznał produkt wyłącznie za serwer MCP.
Jak stosować: Zanim uruchomisz taki skill, rozpisz konkretnie: kształt produktu, kto jest użytkownikiem, jaki jest główny przepływ, co dokładnie budujesz, a co nie. Podaj to jako wejście.
Na co uważać: Model nie zapyta o brakujący kontekst — po prostu wypełni luki własnym założeniem i poda wynik z taką samą pewnością siebie. Zawsze sprawdź, czy zrozumiał zakres, zanim uwierzysz we wnioski.
9.Zatłoczona kategoria to zaproszenie, nie wyrok
Na czym polega: Delphi zebrało 19 mln dolarów i ma ponad 2000 ekspertów. Autor nie porzuca pomysłu — szuka klina, jak przesunięcie z rynku influencerów na customer success w firmach.
Jak stosować: Gdy zobaczysz dobrze dofinansowaną konkurencję, potraktuj to jako dowód popytu i szukaj segmentu albo zastosowania, którego nikt z nich nie obsługuje.
Na co uważać: Klin musi być prawdziwie nieobsłużony, a nie tylko niewymieniony na stronie konkurenta. Dobrze finansowany gracz może wejść w twoją niszę szybciej, niż zdążysz się okopać.
10.Sprzedawaj rezultat, nie technologię
Na czym polega: Skill wskazał napięcie: „graph RAG” to nie jest przewaga, z którą użytkownik wchodzi w interakcję. Żaden klient nie wybiera produktu dlatego, że stoi za nim konkretna architektura.
Jak stosować: Przy każdej deklarowanej przewadze zapytaj, jak brzmi zdanie, które powie o niej użytkownik. Jeśli musi wymienić nazwę technologii, przepisz to na efekt: szybciej, dokładniej, mniej pracy.
Na co uważać: To dotyczy komunikacji, nie decyzji technicznych. Technologia może być kluczowa dla działania produktu — po prostu nie może być argumentem sprzedażowym.