Skip to main content

Błędy, które kosztowały — lekcje z 20 lat budowania produktów

TL;DR: Błędy w budowaniu produktów dzielą się na trzy kategorie: zarządcze (zatrudnianie "brilliant jerks", promowanie specjalistów na menedżerów), produktowe (budowanie bez walidacji, ego CEO zamiast user research) i techniczne (overengineering, cięcie rogów przy refaktorze). Każdy błąd to nauka, a firmy bez błędów po prostu jadą za wolno. Kultura debriefu jest tu kluczowa.

TL;DR

Błędy w budowaniu produktów dzielimy na trzy kategorie: zarządcze (zatrudnianie "brilliant jerks", promowanie specjalistów na menedżerów), produktowe (budowanie bez walidacji, ego CEO zamiast user research) i techniczne (overengineering, cięcie rogów przy refaktorze). Każdy błąd to nauka -- firmy bez błędów "za wolno jadą". Kultura debriefu jest kluczowa.

Kluczowe koncepcje

Kategoria 1: Błędy w zarządzaniu zespołami

"Brilliant Jerks" -- genialni dupkowie

Historia: firma ściągnęła seniora z Big Tech. Świetne CV, imponujące doświadczenie techniczne. Efekt: katastrofa.

"Okazało się, że ten człowiek jest absolutnym dupkiem. [...] Kosztowało mnie to tone stresu i kosztowało mnie to dwóch seniorowych inżynierów."

Objawy:

  • Duża arogancja w komunikacji
  • Pisanie kodu "pod siebie" -- jeden plik, zawile funkcje, nikt inny nie mógł z tego korzystać
  • Łamanie ustalonych paradygmatów (np. Domain Driven Design)
  • Odmowa dostosowania się do zespołu

Konsekwencje:

  • Dwóch seniorów odeszło z firmy
  • Zespół "w strzępkach" -- rok dochodzenia do siebie
  • 6 miesięcy sprzątania po incydencie

"We don't want to work with brilliant jerks. [...] Firma jest gra zespołowa."

Lekcja: Nie zachłystywać się dużymi brandami w CV. Reference check to za mało. Trzeba:

  • Pogłębione rozmowy o dopasowaniu kulturowym
  • Spotkania kandydata z zespołem przed zatrudnieniem
  • Płatne dni/tygodnie próbne -- kandydat pracuje z zespołem na realnym problemie

Omijanie procesu rekrutacji

Druga historia: kandydat z "dobrej polskiej firmy" obszedł proces rekrutacji -- pobieżna rozmowa z CTO, dobre CV, oczytany człowiek. Zatrudniony na stanowisko seniorskie.

"Bardzo szybko się okazało, że na tej pozycji seniorskiej zestaw umiejętności był bardziej juniorski, co zaczęło od razu demoralizować zespół."

  • Brakował kompetencji na poziomie seniora
  • Odmawianie pewnych zadań ("to nie jest w moim job description")
  • Demoralizacja zespołu -- widzieli, że nie można na nim polegać, a brał seniorska pensje

Lekcja: Nigdy nie omijać procesu. Zawsze:

  • Zadanie domowe / test techniczny
  • Pogłębiona rozmowa z różnych perspektyw
  • Cultural fit oceniany przez osobę, która nie miała wcześniej styczności z kandydatem

Promowanie specjalistów na menedżerów

"Ścieżka niby wygląda: junior -> mid -> senior -> team lead. I to nie zawsze oznacza, że jesteś dobrym menedżerem."

  • Senior promowany na Team Leada -- po 3 miesiącach sfrustrowany, chciał wrócić
  • Zamiast rozwijać ludzi, skupiał się na tym jak piszą kod
  • Kompetencje menedżerskie (komunikacja, zarządzanie stakeholderami) są INNE niż specjalistyczne

Jak rozpoznać zalążki dobrego Engineering Managera:

  • "Step up" -- kiedy coś się dzieje, nie pozostaje obojętny
  • Autorytet naturalny -- "ktoś wstaje, zaczyna mówić i nagle sala milknie"
  • Zakaswanie rękawów przy outage'ach -- "siedzę z zespołem, jestem na pierwszej linii"

Ego menedżerów

"Bardzo wiele błędów zarządczych wynika z ego menedżerów. [...] Sami lepiej wiedzieli, co jest lepsze dla użytkowników od samych użytkowników."

Objawy:

  • Syndrom zbawcy -- próba rozwiązania wszystkich problemów samodzielnie
  • Mikromanagement -- pozbawianie zespołu szans na rozwój i impact
  • Przekonanie o własnej nieomylności

Kategoria 2: Błędy produktowe

CEO projektujący dla siebie

Historia: CEO, który "projektował produkty dla siebie" zamiast dla użytkowników.

"Siadał na spotkaniach i mówił: logo do lewej, troszeczkę większe, zrób tak, żeby było ładnie."

  • Nie był docelowym użytkownikiem
  • Ignorował feedback od prawdziwych userów
  • Przebłyski poprawy -- kiedy w końcu porozmawiali z użytkownikami, efekty były dobre
  • Ale nie replikowano tego później

LMS + NFT -- 150-200k EUR w błoto (case study)

Najdroższy błąd produktowy z . Produkt LMS (Learning Management System) z 2 mln użytkowników.

Sytuacja wyjściowa:

  • Użytkownicy sygnalizowali problemy z logowaniem, zarządzaniem contentem, systemem rol
  • Zespół przygotował roadmapę napraw -- CEO ja skreślił

"To są nudne rzeczy, tymi nie będziemy się zajmować. To nie wyróżnia naszej aplikacji. Musimy zrobić coś, co nas spozycjonuje zupełnie inaczej na rynku."

Decyzja CEO: integracja z MetaMask, certyfikaty NFT. Dlaczego? CEO wcześniej zbudował startup krypto -- miał "słabości" do technologii blockchain.

Efekt:

  • 6 miesięcy developmentu, 1 z 3 zespołów pełny etat
  • Koszt: 150 000 - 200 000 EUR
  • Nikt nie skorzystał. Zero użytkowników.

"Programiści przez pół roku pracowali nad czymś, z czego nikt nie skorzystał. [...] Całkowita demoralizacja zespołu."

Dodatkowy absurd: cele nie były nastawione na adopcje, tylko na PR -- "ile gazet o nas napisze".

Lekcja -- Shiny New Things Syndrome: Nie wepchać nowej technologii kolanem w produkt, w którym użytkownicy jej nie chcą. NFT, grywalizacja, blockchain -- jeżeli user research tego nie potwierdza, to strata czasu i pieniędzy.

Piękno nudnych rzeczy

"Jest pewnego rodzaju piękno w robieniu nudnych rzeczy, o które proszą użytkownicy."

  • "Silver bullet" (jeden wielki strzał) vs "lead bullets" (dużo małych poprawek)
  • Quality of life improvements -- suma małych zmian podnosi retencje
  • Dywersyfikacja portfolio: min. 1 zespół na innowacje, min. 1 na "naprawianie tego co nie działa"

Kategoria 3: Błędy techniczne

Overengineering -- architektura, z której nikt nie korzystał

"Budowanie niesamowitych architektur i infrastruktur pod rozwiązania, które nie wymagają niesamowitych architektur i infrastruktur."

  • Mikroserwisy, DDD, event sourcing, CQRS -- "wszystkie trudne słowa"
  • Motywacja: "będzie co opowiadać na konferencjach i w CV"
  • Użytkownicy nie stwierdzili, że produkt jest wybitny
  • Zmarnowane miesiące (kilka-kilkanaście)

Przykład Data Science: rekomender kanału obsługi klienta. Prosta wersja (drzewko decyzyjne) działała świetnie. Zespół wymyślił "architekturę predykcyjna" -- dokumentacja 40 stron. Development trwał tak długo, że PM został przeniesiony do innego działu zanim ukończono projekt.

"Jeżeli projekt ma 40 stron dokumentacji i nie dotyczy migracji całego serwisu, to raczej nie powinieneś mieć 40 stron dokumentacji."

Cięcie rogów przy przepisywaniu checkoutu

Historia: zespół przepisywał checkout "na nowszy stack". Cięcie rogów, brak testów, "dobra, to jest edge case" — aż do momentu awarii na produkcji.

"Okazało się, że była dosyć duża szansa, że użytkownicy się w to władują. Każda godzina kosztowała nas dziesiątki tysięcy dolarów."

Sweet spot: Istnieje balans między tempem dostarczania a stabilnością. Jeżeli rozwiązanie jest niestabilne, użytkownicy nie będą mieli z niego wartości.

Kultura błędów i debriefu

"Jeżeli nie popełniasz błędów, to po prostu za wolno jedziesz, za mało robisz."

"Świat bez błędów to świat, w którym ludzie kłamią albo ukrywają."

Kultura debriefu (z armii USA):

  • Po każdej operacji -- zbieramy się i analizujemy co poszło tak, co nie
  • Środowisko, w którym ludzie nie boją się przyznawać do błędów
  • Błędy to "błogosławieństwo" -- można się z nich nauczyć

Jak to wdrożyć

Rekrutacja

  • Wdrożyć płatne dni próbne dla stanowisk senior+ (1-5 dni pracy z zespołem na realnym problemie)
  • Cultural fit oceniany przez osobę spoza procesu rekrutacyjnego
  • Nigdy nie omijać procesu -- niezależnie od CV i brandów
  • Oddzielne ścieżki kariery: specjalistyczna (senior -> principal -> distinguished) vs menedżerska

Produkt

  • Każda decyzja produktowa poparta user research -- zero "bo CEO tak chce"
  • Dywersyfikacja zespołów: innowacje + quality of life improvements
  • Metryki sukcesu = wartość dla użytkownika, nie PR coverage
  • Walidacja przed budową -- "kto będzie z tego korzystał i na jakiej podstawie tak twierdzimy?"

Technologia

  • Start simple, scale later -- prosta architektura na początek, rozbudowa po potwierdzeniu product-market fit
  • Dokumentacja projektu > 10 stron = red flag (chyba że migracja)
  • Nigdy nie "cięcie rogów" na checkout / płatności / krytycznych ścieżkach
  • Regularne spłacanie długu technicznego -- nie odkładać "po releasie"

Kultura

  • Wdrożyć culture debriefu -- post-mortem po każdym większym projekcie
  • Stworzyć bezpieczne środowisko do przyznawania się do błędów
  • Dokumentować lekcje z porażek -- wiki wewnętrzne

Powiązane tematy

  • 01-agile-ewolucja -- dlaczego Scrum nie gwarantuje sukcesu produktowego
  • 03-kultura-ai -- jak AI może pomoc unikać błędów produktowych (szybsza walidacja)
  • 02-pl-vs-bigtech -- różnice w kulturze eksperymentacji Polska vs Big Tech