Dlaczego startup nie dowozi KPI — 7 przyczyn i plan naprawy

Nowy inżynier dołącza do zespołu, a velocity spada. Roadmapa rośnie, sprint po sprincie, ale kluczowe KPI stoją w miejscu. Founder mówi „potrzebujemy więcej ludzi" — ale prawdziwy problem jest gdzie indziej.

Po 20 latach w tech i pracy z 30+ startupami zidentyfikowałem 7 systemowych przyczyn, które blokują execution. Żadna z nich nie jest problemem ludzi — to problemy systemu.

Sygnał ostrzegawczy: to samo pytanie zadawane jest na trzech różnych spotkaniach i nikt nie daje finalnej odpowiedzi.

Kiedy nie wiadomo kto decyduje, wszyscy czekają na innych. Decyzje eskalują do foundera, który jest przeciążony, więc dalej czekają. Roadmapa istnieje na papierze, ale żaden sprint nie domyka kluczowego tematu bo „jeszcze nie wiemy czy robimy to czy tamto".

Fix: jedno imię przy każdej inicjatywie i jeden deadline na decyzję. Nie komitet — jeden owner.

Sygnał ostrzegawczy: lista „priorytetów" ma 40 pozycji.

Roadmapa to nie backlog. Jeśli masz więcej niż 5 prawdziwych priorytetów, nie masz żadnego — masz listę życzeń. Przy szerokiej roadmapie każdy sprint rozmywa się na 6 równoległych wątków, żaden nie jest domknięty, postęp jest niewidoczny.

Fix: górny limit 3 inicjatyw na sprint z pełnym ownersipem. Reszta świadomie odkładana, nie zapomniana.

Sygnał ostrzegawczy: PM pisze wymagania, engineering szacuje, potem PM pyta „dlaczego to tyle trwa?"

Kiedy product i engineering pracują jako osobne organizacje z przerzucaniem się dokumentami, traci się tydzień na każdym przejściu. Inżynierzy nie rozumieją „dlaczego" featury, product nie rozumie kosztu technicznego decyzji.

Fix: wspólne discovery od początku. Engineering w rozmowach z klientami — nie jako obserwatorzy, ale jako uczestnicy.

Sygnał ostrzegawczy: „to proste, ale musimy najpierw przepisać X".

Dług techniczny staje się blokerem gdy rośnie szybciej niż jest spłacany. W pewnym momencie każda zmiana wymaga dotknięcia systemu, który jest kruchy. Release cycle rośnie z dni do tygodni. Inżynierowie są sfrustrowani, bo widzą problem ale nie mają czasu go naprawić.

Fix: dedykowany budżet na techniczny dług w każdym sprincie (min. 20%). Nie „kiedyś przepiszemy" — systematyczna spłata.

Sygnał ostrzegawczy: nowi dołączają, ale stali odchodzą lub są sfrustrowani.

Szybki hiring pod presją rundy często wprowadza ludzi którzy są technicznie dobrzy, ale operacyjnie niedopasowani — inny rytm pracy, inne oczekiwania co do ownershipu. Efekt: więcej ludzi, więcej spotkań, mniej delivery.

Fix: kultura pracy opisana explicite przed rozmowami rekrutacyjnymi. Hiring pod output i ownership, nie tylko pod CV.

Sygnał ostrzegawczy: spotkania ad-hoc, brak regularnych retrospektyw, brak weekly priorytetyzacji.

Rytm decyzyjny to nie formalizm — to mechanizm który zapobiega nawarstwianiu się nierozwiązanych pytań. Bez stałego rytmu każda decyzja jest jednorazowym projektem. Founder staje się bottleneckiem bo nie ma gdzie oddelegować decyzji operacyjnych.

Fix: tygodniowy rytm: plan (poniedziałek), egzekucja, review (piątek), retrospektywa (co 2 tygodnie). Stałe sloty, stałe agendy, stała odpowiedzialność.

Sygnał ostrzegawczy: team raportuje story points, ale nikt nie wie jak przekłada się to na KPI biznesowe.

Mierzenie velocity w story points daje złudzenie postępu bez dowodu efektu. Metryki delivery powinny łączyć się z metrykami biznesowymi: jak lead time wpływa na time-to-revenue? Jak release frequency koreluje z retencją? Bez tej linii przyczynowej, optimizujesz proxy a nie wynik.

Fix: wybierz 2-3 metryki delivery i połącz je z KPI biznesowymi. Monitoruj co tydzień — nie co kwartał.

Dni 1–30: diagnoza. Mapujesz gdzie są bottlenecki — decyzje, dług, silosy. Rozmawiasz z inżynierami, PM-ami, founderem. Szukasz wzorców, nie winnych. Efekt: lista 3 systemowych problemów z największym wpływem na KPI.

Dni 30–60: zmiany strukturalne. Ustawiasz ownership (jedno imię przy każdej inicjatywie), rytm decyzyjny (tygodniowe cadence), górny limit roadmapy (max 3 priorytety). Efekt: pierwsze widoczne przyspieszenie, mniej blokad, krótszy lead time na decyzje.

Dni 60–90: iteracja i stabilizacja. Mierzysz efekty zmian, koregujesz. Nie wszystko zadziała od razu — ważne żeby system miał mechanizm autokorekcji. Efekt: przewidywalny rytm delivery, founder nie jest bottleneckiem, KPI zaczynają rosnąć.