Poniższy tekst stanowi notatki z podcastu Shreyasa Doshi, wygenerowanego przez NotebookLM na bazie jego prywatnych i publicznych materiałów. Wszystkie przemyślenia, obserwacje i wnioski prezentowane w artykule pochodzą od autora oryginalnego materiału.

TL;DR

Zaledwie 4.6% zespołów optymalizuje pod realny wpływ biznesowy, podczas gdy 52% koncentruje się na szybkości wypuszczania funkcji.
Firmy przekonane, że optymalizują pod shipping, w rzeczywistości często optymalizują pod czas do pierwszej linii kodu, co paradoksalnie spowalnia dostarczanie.
Każda stworzona funkcja staje się długoterminowym obciążeniem, ponieważ dług techniczny, supportowy i dokumentacyjny kumulują się w tle.
Efekt IKEA w produktach sprawia, że bronimy własnych kreacji nawet wtedy, gdy dane pokazują ich nieskuteczność.
Rady wyjątkowych liderów („just build”, „move fast”) okazują się toksyczne dla przeciętnych zespołów, gdyż pomijają kluczowy składnik: wyjątkowy osąd.
Sukces produktu zależy nie od kilku wielkich decyzji strategicznych, lecz od tysięcy codziennych mikro-decyzji.
Porażki produktowe są systematycznie błędnie diagnozowane jako problemy egzekucji, choć prawdziwą przyczyną pozostaje przeciętny osąd.

Kontekst

Shreyas Doshi to uznany ekspert product managementu, wcześniej związany z Google, Twitter i Stripe. Materiał, który posłużył za podstawę tego artykułu, powstał na bazie jego prywatnych i publicznych analiz. Jak sam zaznacza, jest to „najbardziej autorytatywne źródło” na temat przyczyn porażek produktów, jakie może udostępnić.

Iluzja prędkości: co naprawdę oznacza „move fast”

Mantra „move fast” jest wszechobecna w świecie technologii. Brzmi energicznie i zdecydowanie. Doshi zadaje jednak fundamentalne pytanie: gdy firma deklaruje szybkie działanie, pod co faktycznie optymalizuje?

Wyniki ankiety przeprowadzonej wśród builderów okazują się wymowne:

Czas do podjęcia decyzji: 27%
Czas do napisania pierwszej linii kodu: 16.6%
Czas do wypuszczenia funkcji: 51.9%
Czas do maksymalnego wpływu: 4.6%

Mniej niż 5% respondentów wskazało, że ich organizacja optymalizuje pod to, co faktycznie ma znaczenie dla biznesu i klienta. Doshi określa to jako „masowy systemowy rozjazd”.

Skąd taka dysproporcja? Wpływ jest powolny, chaotyczny i trudny do przypisania jednemu zespołowi w kwartalnych wynikach. Shipowanie funkcji jest natomiast namacalne. Można je odhaczyć na liście, wygląda dobrze na slajdzie i w ocenie rocznej.

Zarządzanie wrażeniem wewnętrznym

Analiza Doshi idzie głębiej i odsłania zjawisko, które można nazwać „zarządzaniem wrażeniem wewnętrznym”. Wiele firm przekonanych, że optymalizuje pod shipping (opcja C), w rzeczywistości optymalizuje pod czas do pierwszej linii kodu (opcja B). Priorytety są więc ustalane tak, aby zadowolić kierownictwo, a nie przynieść korzyść klientowi. Właśnie to stanowi prawdziwą pułapkę.

Mechanizm działa następująco: PM lub lider inżynierii jest pod presją, żeby wykazać postęp. Najszybszym, najbardziej widocznym sygnałem aktywności okazuje się informacja, że inżynierowie już kodują. W momencie zakomunikowania tego presja ze strony przełożonych zelżeje.

U podstaw leży fałszywe założenie: jeśli inżynier nie pisze kodu, jego drogi czas jest marnowany. W rezultacie planowanie ulega skróceniu, research zostaje pominięty, a trudne myślenie na starcie zastępuje skok w egzekucję z niedopracowanym planem.

Przez tydzień lub dwa wszyscy czują się świetnie. Potem zespół uderza w ścianę. Okazuje się, że wymagania były błędne, a zależność została przeoczona. Czas zaoszczędzony na planowaniu zamienia się w tygodnie chaotycznego przerabiania kodu. Początkowa prędkość była iluzją.

Dwa rodzaje porażek

Doshi zwraca uwagę na asymetrię widoczności dwóch typów porażek:

Porażka widoczna: trzytygodniowe opóźnienie w dacie wypuszczenia. Wszyscy to widzą: marketing, sprzedaż, leadership.
Porażka niewidoczna: fakt, że funkcja była złym pomysłem od początku. Oczywiste może dla PM-a i paru seniorów, lecz dla reszty organizacji wygląda to jak sukces.

W efekcie organizacja uczy się unikać porażki widocznej, nawet jeśli niewidoczna jest znacznie bardziej destrukcyjna. Jak ujmuje to Doshi: opóźnienie to czkawka, zła funkcja to powolna trucizna.

Źle przemyślana funkcja staje się kotwicą. Rozdyma produkt, nie rozwiązuje prawdziwego problemu i tworzy długoterminowe zobowiązanie ciągnące zespół w dół przez lata.

Stąd paradoksalna konkluzja: jeśli widzisz zespół trafiający w każdy deadline idealnie co do dnia, powinieneś nabrać podejrzeń. Prawdopodobnie nadmuchują estymaty i optymalizują pod wewnętrzne pozory, nie pod realny wpływ produktowy.

Dwa życia przeciętnego buildera

Doshi wprowadza koncepcję „dwóch żyć buildera”. Choć może brzmieć jak framework dla product managerów, wzorzec jest uniwersalny. Dotyczy founderów, designerów, inżynierów, słowem każdego, kto coś tworzy.

Pierwsze życie: czysta kreacja

Mentalność pierwszego życia to „po prostu buduj”. Jest niesamowicie energetyzująca: rozwiązujesz problemy, shipujesz funkcje, a sukces mierzony jest prędkością. To miesiąc miodowy startupu.

Problem polega na tym, że dla przeciętnego buildera to życie jest nie do utrzymania. Transformacja następuje, gdy builder internalizuje dwie brutalne prawdy.

Prawda pierwsza: staniesz się przykuty do wszystkiego, co stworzysz

Kajdany to ograniczenia strukturalne. Dług techniczny jest ich częścią: zły kod, chwiejna architektura. Jednak to także dług supportowy (wspieranie klientów używających funkcji) oraz dokumentacyjny (tłumaczenie nowym pracownikom, na zawsze).

Koszty te kumulują się w ciszy. W pierwszym życiu widzisz tylko koszt zbudowania czegoś raz. W drugim dostrzegasz koszt wspierania tego przez całe istnienie produktu.

Rzeczy, z których byłeś dumny, stają się klatką ograniczającą przyszłe możliwości. Płyniesz z kotwicą hamującą, którą sam zbudowałeś. Decyzja sprzed pięciu lat, która wydawała się szybka i łatwa, jest teraz powodem, dla którego nie możesz adoptować nowoczesnej technologii ani zintegrować się z kluczowym partnerem. Jesteś zamrożony przez własną historię.

Prawda druga: staniesz się emocjonalnie przywiązany do swoich kreacji

To efekt IKEA dla produktów. Im więcej wysiłku wkładasz w budowanie czegoś, tym bardziej je przeceniasz. To twoje dziecko, jak chwiejąca się półka złożona własnymi rękami, która wydaje ci się arcydziełem.

W konsekwencji stajesz się największym obrońcą swojej funkcji. Racjonalizujesz jej wady i walczysz o jej przetrwanie, nawet gdy dane pokazują, że nie działa. Szukasz powodów uzasadniających jej istnienie, zamiast obiektywnie pytać, czy powinna jeszcze tam być.

Tak powstają zombie features: rzeczy, które wszyscy wiedzą, że powinny zostać zabite, ale trwają, bo emocjonalny koszt przyznania się do porażki jest zbyt wysoki. Builder przestaje być osobą rozwiązującą problemy i staje się politykiem broniącym własnego dziedzictwa.

Jak wyjątkowi builderzy unikają tej pułapki?

Różnica leży w ich osądzie. Ich smak i intuicja są na zupełnie innym poziomie, więc początkowe wybory okazują się znacznie lepsze. Rzeczy, do których się przywiązują, są faktycznie dobre, a kajdany, które budują, mniej krępują, bo architektura była solidna od początku.

Dla przeciętnego buildera, czyli większości z nas, konieczna jest świadoma ewolucja poza pierwsze życie. Bez tego gwarantowany jest produkt rozdęty, skomplikowany i strategicznie zakopany w błocie.

Dlaczego rady wyjątkowych liderów szkodzą przeciętnym zespołom

Gdy zaakceptujesz, że przeciętny builder wplącze się w przywiązania i kajdany, zobaczysz, dlaczego tak wiele rad w świecie produktowym to ogromne wprowadzenie w błąd. Co ciekawe, misdirection pochodzi z góry, od najbardziej udanych ludzi.

Doshi wyjaśnia: rady są szkodliwe, bo działają tylko dla ich autorów. Gdy słynny founder mówi „po prostu buduj, działaj szybko, wypuszczaj i iteruj”, jest szczery. To właśnie zrobił. Pomija jednak najważniejszą część.

Sukces nie tkwił w samym szybkim działaniu. Tkwił w wyjątkowym osądzie, który zapewniał, że rzecz, ku której się szybko poruszał, była właściwą rzeczą.

Przeciętna osoba słyszy tę radę i kopiuje widoczną część: prędkość. Nie ma jednak niewidocznej części: osądu. W rezultacie ponosi porażkę. Porusza się szybko, podejmując przeciętne decyzje, przywiązuje się do złych rzeczy i zostaje skuta złą architekturą. Potem zastanawia się, dlaczego podążanie za najlepszymi praktykami nie zadziałało.

Doshi przywołuje trafną analogię: to jak arcymistrz szachowy mówiący początkującemu „po prostu ufaj swojej intuicji”. Intuicja arcymistrza została wytrenowana przez miliony wzorców, podczas gdy intuicja początkującego to zgadywanie. Rada jest technicznie prawdziwa dla osoby, która ją daje, lecz staje się trucizną dla osoby, która ją otrzymuje.

Pułapka mikro-decyzji

Rozwój produktu nie polega na trzech czy czterech wielkich, dramatycznych decyzjach strategicznych rocznie. Polega na tysiącach drobnych, pozornie nieistotnych mikro-decyzji podejmowanych każdego dnia.

Czy dodać jedno dodatkowe pole do formularza rejestracji? Czy domyślny komunikat błędu jest wystarczająco dobry dla tego przypadku brzegowego? Czy poświęcić dzień na refaktoryzację tego kawałka kodu teraz, czy później? Czy ten przycisk powinien być niebieski czy zielony?

Rzeczy te w danym momencie wydają się trywialne, lecz agregują się w całe doświadczenie użytkownika.

Właśnie dlatego wielkie mantry typu „fail fast” czy „just build” są bezużyteczne w praktyce. To filozofia, nie narzędzie. Funkcjonują na poziomie rezultatu i nie pomagają podjąć ani jednej z tych decyzyjnych mikro-wyborów.

Product manager czuje, że ma strategię, bo ma fajny slogan. Jednak gdy staje przed prawdziwym, niejednoznacznym wyborem, slogan oferuje zero wskazówek. Zostaje sam ze swoim własnym, często przeciętnym osądem.

Różnica między wyjątkowym builderem a przeciętnym jest niewidoczna na poziomie sloganu, lecz krystalicznie jasna w finalnym produkcie zbudowanym z tysięcy drobnych wyborów.

Siedem błędów myślenia w budowaniu produktów

Doshi dokumentuje siedem specyficznych błędów poznawczych. Kluczowe jest zrozumienie, że to nie są przypadkowe pomyłki do naprawienia checklistą. Stanowią nieuniknione symptomy głębszych sił: presji na widoczność, przywiązania do własnych kreacji i przeciętnego osądu pod stresem.

1. Pułapka orientacji na egzekucję

Strategia produktowa dyktowana przez to, w czym zespół jest dobry teraz, zamiast przez to, czego rynek faktycznie potrzebuje. Przykład z analizy: firma, której prawdziwa szansa leży w produkcie desktopowym dla profesjonalistów, ale ma świetny zespół mobilny. Co robi? Buduje niekończące się funkcje do aplikacji mobilnej. W rezultacie wygodność struktury zespołu dyktuje całą strategię rynkową. Wygrywają małą bitwę na mobile, przegrywając wojnę o rynek.

2. Skłonność do budowania

Kompulsywna potrzeba ciągłego ruchu oraz poczucie, że jeśli kod nie jest pisany, czas jest marnowany. Przykład: startup fintechowy spędził trzy miesiące budując funkcje płatnicze. Po wypuszczeniu okazało się, że klienci mają już świetne rozwiązania płatnicze. Prawdziwy problem to raportowanie i uzgadnianie transakcji. Znacznie mniej atrakcyjne, znacznie bardziej złożone. Wymagało głębokiego myślenia na starcie, lecz skłonność do budowania sprawiła, że zespół skoczył do kodu i rozwiązał problem, którego nikt nie miał.

3. Efekt IKEA w produktach

Decyzje oparte na poniesionych kosztach, nie na aktualnej wartości. Przykład: zespół spędził sześć miesięcy budując panel administracyjny. Dziś używa go trzech nieistotnych klientów. Racjonalny ruch to zabicie go. Jednak pamięć włożonego wysiłku uniemożliwia decyzję. PM broni panelu, inżynierowie wciąż naprawiają bugi. Przeszły wysiłek staje się kajdanami zamrażającymi zasoby, które powinny innowować.

4. Iluzja skupienia

Przecenianie wagi problemu tylko dlatego, że akurat się na nim skupiasz. Sam akt badania problemu tworzy zniekształcenie. Przykład: zespół przeprowadza wywiady o wolno ładujących się stronach. Klient przez 20 minut narzeka, więc wydaje się to najkrytyczniejszym problemem. Zespół optymalizuje i wypuszcza poprawkę. Metryki się nie ruszają, bo prawdziwy powód odchodzenia klientów był zupełnie inny. Może mylący onboarding. Fokus wywiadu stworzył martwy punkt.

5. Młotek Maslowa

Nadużywanie znajomego narzędzia do każdego problemu. Przykład: Facebook i obsesja na punkcie metryk. Kultura „najpierw metryki” działała świetnie dla wczesnego wzrostu, potem jednak stała się zinstytucjonalizowanym młotkiem używanym do wszystkiego. Nawet do problemów niuansowych: jakość treści, zdrowie platformy, prywatność. Prowadziło to do systemowych problemów, bo nie potrafili zobaczyć, kiedy młotek przestał być właściwym narzędziem.

6. Skłonność do akceptacji autorytetu

Budowanie dla poklasku szefa, nie dla klienta. Projektowanie pod wewnętrzną politykę. Przykład: CEO jest podekscytowany AI, więc każdy PM w firmie zaczyna wtłaczać funkcję AI do roadmapy. Nawet jeśli problem klienta mógłby być rozwiązany prostą zmianą interfejsu. Nie rozwiązują dla klienta, lecz dla akceptacji ze strony zarządu.

7. Rosyjska ruletka produktowa

Ignorowanie ryzyk o niskim prawdopodobieństwie, ale katastrofalnych skutkach. Skupienie na szybkim poruszaniu się i trafianiu w krótkoterminowe cele kosztem myślenia o najgorszych scenariuszach. Przykład: aplikacja społecznościowa budująca viralowe funkcje bez myślenia o nękaniu. Pędzą, żeby maksymalizować wzrost, ignorują projektowanie defensywne. Gdy katastrofa następuje, są nieprzygotowani i obwiniają złych aktorów. Prawdziwa porażka to jednak decyzja podjęta miesiące wcześniej, żeby zignorować ryzyko.

Błędna diagnoza porażek

Doshi podkreśla, że sama znajomość tych zniekształceń nie wystarczy do ich naprawienia. Nie są bugami w systemie, lecz cechami bycia normalnym człowiekiem pod presją. Nie można po prostu zdecydować, że nie będzie się czuło efektu IKEA, gdyż będzie wpływał na twoje mikro-decyzje niezależnie od intencji.

Co gorsza, nawet po porażce organizacje systematycznie ją błędnie diagnozują. Typowe wymówki w postmortem: „nie mieliśmy wystarczających zasobów”, „timing rynkowy był zły”, „engineering był za wolny”. Zawsze coś zewnętrznego, zawsze coś o egzekucji. Bezpieczne, bezosobowe powody.

Niekomfortowa prawda brzmi: każda z tych porażek jest porażką myślenia i osądu. Niewystarczające zasoby? To porażka właściwego określenia zakresu i priorytetyzacji. Zły timing rynkowy? Porażka przewidywania. Wszystko wraca do jakości początkowych wyborów.

A jednak w oficjalnym raporcie nigdy nie zobaczysz przyczyny porażki opisanej jako „nasz kolektywny osąd był przeciętny”. Powód? Osąd jest niewidoczny i abstrakcyjny. Można wskazać na arkusz z budżetem lub datę wypuszczenia produktu przez konkurenta. Nie można wskazać na zły proces myślowy. Dodatkowo dla lidera przyznanie, że „myśleliśmy o tym problemie źle”, to bezpośredni cios w jego własne kompetencje. Znacznie bezpieczniej jest obwiniać rzeczy poza kontrolą.

To prowadzi do błędnego koła: błędna diagnoza → zła wyciągnięta lekcja („potrzebujemy więcej inżynierów” lub „potrzebujemy nowego narzędzia”) → naprawa symptomów, nie przyczyn → ten sam zespół z nieco lepszym procesem podejmuje te same 50 złych mikro-decyzji każdego dnia → kolejny przeciętny produkt → cykl się powtarza.

Checklist: sygnały ostrzegawcze przeciętnego osądu

Na podstawie analizy Doshi można zidentyfikować sygnały, że zespół wpadł w pułapkę przeciętności:

Zespół trafia w każdy deadline idealnie co do dnia
Presja, żeby inżynierowie „już kodowali” zanim problem jest zrozumiany
Roadmapa dyktowana przez umiejętności zespołu, nie potrzeby rynku
Funkcje bronione na podstawie włożonego wysiłku, nie aktualnych danych
Ten sam framework stosowany do każdego problemu
Priorytety zmieniają się w zależności od tego, czym ekscytuje się leadership
Brak dyskusji o najgorszych scenariuszach przed wypuszczeniem funkcji
Postmortem skupia się na zewnętrznych czynnikach
Nikt nie pyta: „czy ta funkcja powinna w ogóle istnieć?”

Checklist: pytania przed podjęciem decyzji produktowej

Czy buduję to, bo rynek tego potrzebuje, czy bo mój zespół potrafi to zrobić?
Czy rozumiem problem wystarczająco głęboko, czy skaczę do kodowania zbyt wcześnie?
Czy bronię tej funkcji, bo jest wartościowa, czy bo włożyłem w nią wysiłek?
Czy ten problem wydaje mi się ważny, bo faktycznie jest, czy bo akurat się na nim skupiam?
Czy używam właściwego narzędzia do tego problemu, czy mojego ulubionego?
Czy buduję to dla klienta, czy dla akceptacji przełożonych?
Co może pójść nie tak? Jakie są najgorsze scenariusze?
Gdybym zaczynał od zera, czy podjąłbym tę samą decyzję?

Co z tego wynika?

Doshi ostrzega przed ostatnią pułapką. Jeśli „buduj szybko” jest złe, to nie znaczy automatycznie, że „buduj wolno” jest dobre. „Buduj mniej”, „działaj wolno”, „bądź przemyślany” to po prostu nowe slogany. Nie działają z tego samego powodu, co stare: wciąż są filozofią na poziomie rezultatu.

Dają zero wskazówek, gdy wpatrujesz się w ekran, próbując podjąć tę jedną konkretną, niejednoznaczną mikro-decyzję. Wciąż szukasz skrótu, żeby uniknąć ciężkiej pracy faktycznego osądu.

Prawdziwa praca to rozgryzanie tego dla swojej specyficznej sytuacji: zespołu, rynku, problemu. To opieranie się komfortowi jakiejkolwiek łatwej odpowiedzi. To akceptowanie, że efekt IKEA jest realny: nie możesz przestać go czuć, ale możesz nauczyć się rozpoznawać to uczucie, zatrzymać się i podjąć bardziej racjonalną decyzję mimo wszystko.

Chodzi o rozwijanie niuansowanego, kontekstowego osądu przez brutalnie szczerą ocenę tego, co dzieje się po podjęciu decyzji. Nie tylko celebrowanie daty wypuszczenia.

Dla liderów i founderów zrozumienie tego frameworku to klucz do unikania katastrofalnych błędów wynikających ze złego myślenia. Jak podkreśla Doshi, wartość przesunięcia fokusa z procesu na jakość codziennego osądu może być warta miliony w perspektywie całego życia produktu.

Końcowe przesłanie jest proste, choć niewygodne: jeśli naprawdę chcemy wyjść poza przeciętny wpływ, musimy przestać obwiniać nasze narzędzia i okoliczności. Zamiast tego trzeba podjąć trudną, niekomfortową pracę nad poprawą tego, jak myślimy.

Budowanie produktów nie jest jakimś specjalnym, magicznym procesem. Podlega tym samym regułom talentu i osądu jak wszystko inne: od szachów po inwestowanie.

Prompty do wykorzystania

Wykrywanie „cichych porażek”

Działaj jako krytyczny doradca produktowy. Analizuję pomysł na funkcję: [OPIS FUNKCJI].


Oceń ryzyko wystąpienia "cichej porażki" na podstawie zasad Shreyasa Doshi:

1. Dług operacyjny: Jakie stałe koszty wsparcia wygeneruje ta funkcja?
2. Efekt kotwicy: Czy ta funkcja zablokuje nam w przyszłości zmianę kierunku?
3. Realny wpływ: Czy optymalizujemy czas do wydania kodu, czy wpływ na użytkownika?

Wskaż, czy ta funkcja za 2 lata będzie aktywem, czy "rozdyma" produkt i stanie się obciążeniem.

Kiedy stosować: Przed dodaniem nowej funkcji do roadmapy. Szczególnie przydatny, gdy czujesz presję, żeby „coś wypuścić” lub gdy funkcja wydaje się oczywista, ale nikt nie przeprowadził głębszej analizy.

Symulacja porażki myślenia (pre-mortem)

Wyobraź sobie, że projekt [NAZWA PROJEKTU] upadł. 

Zakazuję używania wymówek o braku zasobów czy złym timingu. Opisz scenariusz porażki wynikający wyłącznie z wadliwego osądu i złych mikro-decyzji (np. źle dobrane pola formularza, zignorowanie sygnałów od użytkowników, optymalizacja pod wewnętrzne KPI zamiast pod klienta).

Skup się na błędach w procesie myślowym zespołu, nie na okolicznościach zewnętrznych.

Kiedy stosować: Na początku projektu lub przed kluczowymi decyzjami. Zmusza do uczciwej refleksji nad jakością myślenia, zanim będzie za późno.

Kluczowy insight

Szybszy start oznacza wolniejsze dostarczanie

Standardowo myślimy: Im szybciej inżynierowie zaczną kodować, tym szybciej wypuścimy funkcję. Każdy dzień spędzony na planowaniu to dzień stracony. Presja na „już kodujemy” to znak zdrowego tempa pracy.

W praktyce okazuje się, że: Firmy optymalizujące pod czas do pierwszej linii kodu dostarczają wolniej niż te, które inwestują w zrozumienie problemu. Prawdziwa prędkość jest mierzona brakiem konieczności poprawiania raz podjętych decyzji. Zespół, który przez tydzień analizuje mikro-decyzje, porusza się szybciej niż zespół, który w tym samym czasie napisał tysiąc linii kodu wymagających późniejszego przepisywania.

Dlaczego to jest istotne: Pośpiech na starcie to dług zaciągnięty u przyszłości na bardzo wysoki procent. Każda linia kodu napisana bez pewności co do jej wpływu to nowa kotwica, która spowolni zespół w kolejnych kwartałach. Organizacje nieświadomie tworzą system, w którym wykazanie postępu („inżynierowie już kodują”) jest ważniejsze niż faktyczny postęp.

Test na jutro: Następnym razem gdy poczujesz presję, żeby zespół „już zaczął kodować”, zamiast otwierać edytor kodu spróbuj spędzić dodatkowe 4 godziny na dopracowaniu jednego niejednoznacznego warunku w wymaganiach. Sprawdź, o ile mniej pytań technicznych pojawi się w trakcie realizacji i ile razy zespół będzie musiał wracać do przerabiania kodu z powodu błędnych założeń.

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: Shreyas on Why Products Fail

Tag: Move Fast

Dlaczego produkty zawodzą: anatomia przeciętności według Shreyasa Doshi #EN373