Zarządzanie produktem, gdy budowanie trwa godziny

Zarządzanie produktem, gdy budowanie trwa godziny, oznacza, że efektem pracy product managera są weryfikowalne intencje, a nie tickety: plik intent.md z mierzalnym wynikiem i kryteriami akceptacji, które — zanim agent napisze kod — stają się czerwonymi, jeszcze nieprzechodzącymi testami. Roadmapa to uszeregowane zakłady o wynik z bramkami dowodowymi, a prototypy żyją w osobnym torze, który nie trafia na produkcję.

W poniedziałek projektantka razem z agentem zbudowała w trzy godziny klikalny przepływ „wstrzymaj subskrypcję”. W środę prezes zobaczył go na demo dla całej firmy i zapytał, dlaczego jeszcze nie działa na produkcji. Roadmapa wciąż wymienia funkcje według sprintów, spotkanie priorytetyzacyjne wciąż kłóci się o story pointy, a nikt nie zapisał, co przepływ ma zrobić, gdy otworzy go klient z planem rocznym.

Ta strona jest dla członków zarządu odpowiedzialnych za organizację produktową i dla tech leadów, którzy pracują obok product managerów na poziomie 4 drabiny autonomii.

Co możesz wdrożyć w zarządzaniu produktem z agentami

• Produktowy szablon intent.md z wynikiem, kryterium wycofania, kryteriami akceptacji i proponowaną klasą ryzyka, razem z wypełnionym przykładem.
• Trzy prompty do skopiowania, które product manager uruchamia w Claude Code, Codex lub Cursorze: szkic intencji, krytyczne sprawdzenie kryteriów i prototyp do wyrzucenia.
• Format roadmapy wyników, w którym jednostką przepustowości są sloty na review i wdrożenie, a nie tygodnie pracy inżynierów.
• 45-minutową agendę priorytetyzacji i regułę punktacji, w której koszt budowy zastępują koszt weryfikacji i koszt utrzymania.
• Listę bramek od prototypu do produkcji ze strażnikiem CI do wklejenia w GitHub Actions.
• Pięć definicji metryk, które pokazują, czy produktowa część systemu działa.

Dlaczego discovery staje się wąskim gardłem, gdy budują agenci?

Kiedy agent potrafi w jedno popołudnie wyprodukować działającą funkcję, powolnym krokiem staje się decyzja, co warto budować, określenie, co znaczy „poprawnie”, i sprawdzenie, czy wynik pomógł użytkownikowi.

Mówią o tym ludzie najbliżej narzędzi. W podsumowaniu Sequoia Ascent 2026 (2026-04-30) Andrej Karpathy z aprobatą cytuje zdanie: „I am becoming the bottleneck of even knowing what we are trying to build, why it is worth doing, and how to direct my agents”. W opisie poziomu 4 u Dana Shapiro człowiek ma „write a spec”, potem „leave for 12 hours, and check to see if the tests pass”, pracując jako „more of an engineering manager or product/program/project manager” (The Five Levels, 2026-01-23). Model AI Capabilities opracowany przez DORA (Google Cloud, 2025-09-23) wymienia user-centric focus, czyli skupienie na użytkowniku, wśród siedmiu zdolności, które wzmacniają korzyści z AI: szybsze budowanie opłaca się tylko tam, gdzie ktoś pilnuje związku pracy z wynikiem dla użytkownika.

Więcej budowania nie znaczy więcej wdrożeń. Telemetria Faros AI z własnej platformy (dane dostawcy), obejmująca 22 000 deweloperów (AI Engineering Report 2026, kwiecień 2026), pokazuje wzrost ukończonych epików na dewelopera o 66,2%, przy spadku wdrożeń tygodniowo o 11,7% i wzroście incydentów na pull request o 242,7%. Praca zbudowana, ale niewydana, albo wydana i zaraz zepsuta, to zapas magazynowy. Zarządzanie produktem decyduje, ile takiej pracy w ogóle się zaczyna.

Tanie budowanie zwiększa ilość pracy opcjonalnej. W wewnętrznym badaniu Anthropic (2025-12-02, deklaracje 132 inżynierów i badaczy dostawcy) „27% of Claude-assisted work consists of tasks that wouldn’t have been done otherwise”. Część jest cenna, ale każda wymaga decyzji, weryfikatora i właściciela.

Czego z tego nie wyciągać

Żadne z tych źródeł nie mierzy produktywności product managerów i żadne nie uzasadnia tezy „jeden PM poprowadzi teraz dziesięć zespołów”. Traktuj deklaracje o zatrudnieniu w rolach produktowych tak, jak projekt organizacji traktuje mnożniki inżynierskie: jako opinie, dopóki twoje własne dane nie powiedzą inaczej.

Co pisze product manager, gdy budowaniem zajmują się agenci?

Product manager przestaje pisać tickety, które inżynierowie interpretują, i zaczyna pisać artefakty, które da się sprawdzić maszynowo. Łańcuch artefaktów nazywa pliki; tabela pokazuje, które z nich należą do produktu.

Artefakt	Rola produktu	Rola inżynierii	Dlaczego taki podział
intent.md: problem, dowody, wynik, kryterium wycofania	Pisze i akceptuje	Ocenia wykonalność, proponuje klasę ryzyka	Produkt odpowiada za „dlaczego” i za miarę sukcesu
Kryteria akceptacji (Given/When/Then, z identyfikatorami)	Pisze pierwszą wersję, zatwierdza ostateczny zestaw	Zamienia je w czerwone testy, wskazuje linie nietestowalne	Kryteria stają się wyrocznią, więc obie strony muszą się na nie zgodzić
spec.md: projekt, dane, interfejsy	Czyta i zgłasza konflikty produktowe	Pisze i akceptuje	Architektura decyduje, jak bezpiecznie zespół może przyspieszyć
Implementacja i plan.md	Brak	Budują agenci; inżynierowie ich obsługują i robią review	Ludzka decyzja to akceptacja, nie autorstwo
Wydanie i pomiar	Czyta metrykę i decyduje: zostawić czy wycofać	Wydaje za flagą, instrumentuje, cofa zmiany	Rozdział obowiązków przetrwa tę zmianę

Największa pojedyncza zmiana to drugi wiersz. Product manager, który pisze „użytkownicy mogą wstrzymać subskrypcję zamiast ją anulować”, zapisał życzenie. Product manager, który pisze pięć ponumerowanych kryteriów Given/When/Then z konkretnymi datami i kwotami, zapisał kontrakt, którego test może pilnować w pracy agenta. Jak inżynierowie zamieniają ten kontrakt w zablokowane, czerwone testy, opisuje strona o wykonywalnych kryteriach akceptacji.

Produktowy szablon intent.md do przyjęcia bez zmian

Szablon rozszerza wzór z łańcucha artefaktów o cztery pola, za które na poziomie 4 odpowiada produkt: dowody, metrykę wyniku, kryterium wycofania i kryteria akceptacji. Nazwy sekcji zostają po angielsku, żeby pasowały do promptów i strażnika CI poniżej. Liczby w przykładzie są ilustracyjne; zastąp każdą wartość własną.

# Intent: Pause a subscription instead of cancelling
Author: Maria Nowak (Product, Billing). Status: proposed. Record: BILL-412

## Problem
Monthly customers who want a short break have only one option: cancel.
Exit-survey answer "temporary break" is the top cancellation reason this quarter.

## Evidence
- Exit survey export, 2026-07-01 to 2026-09-20 (link)
- Six customer calls, notes in research/pause-calls.md

## Outcome and metric
Share of accounts that open the cancel flow and are still paying 60 days later.
Baseline: measured from the last full quarter. Read on day 30 and day 60 after release.

## Kill criterion
If the 60-day metric does not move, or paused accounts resume at a lower rate than
cancelled accounts return, remove the pause option.

## Acceptance criteria
AC-1 Given an active monthly plan billed on the 5th, when the owner pauses for one
     month on 2026-10-01, then no invoice is issued on 2026-10-05 and the next
     invoice is issued on 2026-11-05.
AC-2 Given a paused subscription, when any team member signs in, then the workspace
     is read-only and a banner shows the resume date.
AC-3 Given an annual plan, when the owner opens the cancel flow, then pause is not offered.
AC-4 Given an account that paused in the last 12 months, when the owner opens the
     cancel flow, then pause is not offered.
AC-5 Given a paused subscription, when the owner clicks Resume on 2026-10-20, then
     billing restarts that day and the invoice is prorated to the 5th.

## Out of scope
Pausing annual plans. Pauses longer than one month. Changes to the dunning flow.

## Proposed risk class
Critical (money movement). Engineering lead confirms.

## Open questions
Does a paused workspace keep its API tokens active?

Dwa pola wykonują większość pracy. Kryterium wycofania powstaje, zanim cokolwiek zostanie zbudowane, więc „przecież już to zbudowaliśmy” nigdy nie staje się powodem, dla którego funkcja zostaje. Proponowana klasa ryzyka korzysta z czterech klas (niska, średnia, wysoka, krytyczna) zdefiniowanych na stronie „Jedna mapa” i przypisywanych według polityki z zarządzania autonomią agentów. Rozliczenia to przepływ pieniędzy, więc są klasą krytyczną nawet przy małym diffie. Od początku wiadomo więc, że ta funkcja potrzebuje imiennie wskazanego właściciela i drugiej osoby zatwierdzającej przy bramce produkcyjnej.

Jak product manager przygotowuje intencję z agentem?

Agent musi czytać tracker i nie dotykać kodu aplikacji. Podłącz tracker raz, a potem prowadź sesję w trybie planowania.

Claude Code

Podłącz Jirę i Confluence przez serwer MCP Atlassian Rovo, a potem uruchom sesję w trybie planowania, w którym Claude może czytać, ale nie edytuje kodu aplikacji:

# Terminal, w repozytorium produktu
claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp
claude --permission-mode plan

W sesji uruchom /mcp, aby dokończyć logowanie OAuth. Dla Lineara adres serwera to https://mcp.linear.app/mcp. Wyjdź z trybu planowania (Shift+Tab) dopiero po to, żeby zapisać gotowy plik intent/*.md. Flagi sprawdzone w Claude Code 2.1.283 w dniu 2026-09-26.

Codex

Dodaj ten sam serwer i zaloguj się, a potem użyj /plan, żeby Codex zaproponował plik zamiast zmieniać produkt:

# Terminal (Codex CLI 0.157.1)
codex mcp add atlassian --url https://mcp.atlassian.com/v2/mcp
codex mcp login atlassian
codex

Zacznij rozmowę od /plan. Gdy szkic jest gotowy, wyjdź z trybu planowania i poproś Codex o zapisanie go w katalogu intent/. Dla Lineara użyj --url https://mcp.linear.app/mcp. Codex czyta AGENTS.md, więc dopisz tam jedną linię: „Files under intent/ are written by product; do not edit application code in intent sessions.”

Cursor

Zainstaluj wtyczkę Atlassian z marketplace’u Cursora albo dodaj zdalny wpis do .cursor/mcp.json:

{ "mcpServers": { "atlassian": { "url": "https://mcp.atlassian.com/v2/mcp" } } }

Otwórz agenta w Plan Mode, który „creates detailed implementation plans before writing any code”, i dołącz notatki z badań lub zrzuty ekranu obok promptu. Na tryb Agent przełącz się dopiero po to, żeby zapisać gotowy plik markdown. Szczegóły Cursora sprawdzono w jego dokumentacji 2026-08-28.

Prompt do skopiowania: ticket i notatki zamienione w intent.md

Read Jira ticket BILL-412 and the notes in research/pause-calls.md.
Interview me, one question at a time, until you can state: the problem in the
customer's words, the evidence we have, the outcome metric with a baseline source,
and a kill criterion that would make us remove the feature.

Then write intent/pause-subscription.md with these sections: Problem, Evidence,
Outcome and metric, Kill criterion, Acceptance criteria, Out of scope,
Proposed risk class, Open questions.

Write 3-7 acceptance criteria as numbered Given/When/Then lines (AC-1, AC-2 ...)
with concrete dates, amounts and plan types. Include at least two unhappy paths.
Propose a risk class: low (docs, copy, internal tooling), medium (feature logic behind
a flag), high (public API, data model, tests or CI), critical (auth, money movement,
production data migrations, secrets). Do not edit any file outside intent/.

Prompt do skopiowania: sprawdź kryteria pod kątem luk, zanim zobaczy je inżynieria

Read intent/pause-subscription.md. Do not modify it.
For each acceptance criterion, answer:
1. Could two engineers implement it differently and both claim it passes? Show how.
2. Is every value concrete (date, amount, plan, role), or is something left to judgment?
3. Is the result observable at a boundary a test can reach (API response, UI state,
   invoice record), or only inside the code?
Then list the unhappy paths the criteria do not cover (failed payment during a pause,
plan change during a pause, time zones on the billing date) and the questions I must
answer before engineering turns these criteria into tests.
Output a table: AC ID | ambiguity | missing value | proposed rewrite.

Jeśli zamiast promptu wolisz wielokrotnego użytku „przesłuchującego”, skill grill-me z mattpocock/skills zadaje pytania po jednej decyzji naraz i nie pisze kodu (około 1,2 mln instalacji na skills.sh, odczyt z 2026-09-26, źródło wtórne). W Claude Code zainstalujesz go poleceniem claude plugin install mattpocock-skills, a dla Codex i Cursora poleceniem npx skills add mattpocock/skills --skill grill-me grilling setup-matt-pocock-skills -a codex -a cursor. grill-me deleguje pracę do grilling, dlatego potrzebne są obie nazwy, a setup-matt-pocock-skills uruchamiasz raz na repozytorium, żeby zapisać, z jakiego trackera korzystasz. Zainstaluj jedno albo drugie, nie oba naraz: wtyczka i kopia ze skills.sh rejestrują zdublowane skille. Konfigurację opisuje strona o skillach Matta Pococka.

Gdzie mieszczą się prototypy i które bramki trzymają je z dala od produkcji?

Klikalny prototyp w jedno popołudnie odpowiada na pytanie, na które dokument odpowiadał w dwa tygodnie. Ryzyko polega na tym, że wygląda na skończony: nie ma testów akceptacyjnych, działa na fałszywych danych i nikt nie wybrał dla niego klasy ryzyka. Utrzymuj dwa tory i jednokierunkowe drzwi między nimi.

	Tor prototypów	Tor produkcyjny
Cel	Odpowiedzieć na pytanie produktowe	Dostarczyć zaakceptowany wynik
Punkt wyjścia	Pytanie z sekcji Open questions w intent.md	Zaakceptowany intent.md z zatwierdzonymi kryteriami
Gdzie działa	Gałąź prototype/*, środowisko lokalne lub jednorazowe, dane fałszywe albo testowe	Zwykłe gałęzie, CI, pipeline wydań
Poświadczenia	Żadnych poświadczeń produkcyjnych ani danych klientów	Zakres według klasy ryzyka
Rezultat	Wnioski zapisane w intent.md; kod jest usuwany	Scalona zmiana z pakietem dowodów
Kto uznaje pracę za skończoną	Product manager	Właściciel kodu; przy klasie krytycznej imiennie wskazany właściciel i druga osoba zatwierdzająca

Prompt do skopiowania: prototyp do wyrzucenia, który nie wycieknie

Build a throwaway prototype to answer one question from intent/pause-subscription.md:
"Do owners understand that a paused workspace is read-only?"
Work only on a new branch named prototype/pause-banner. Use seeded fake accounts,
never real customer data, and do not read or use any production credentials or .env files.
Build the smallest clickable flow that answers the question.
Do not open a pull request to main.
When done, write PROTOTYPE.md on the branch with: the question, how to run it,
what you faked, and three things a user test should watch for.

Skill prototype z tej samej kolekcji mattpocock/skills zamyka to zachowanie w gotowym skillu („Build a throwaway prototype to answer a design question”); zainstalujesz go poleceniem npx skills add mattpocock/skills --skill prototype -a codex -a cursor albo przez wtyczkę mattpocock-skills w Claude Code.

Bramki od prototypu do produkcji

Prototyp nigdy nie jest scalany. Do toru produkcyjnego przechodzą wnioski, jako zmiany w intent.md, a budowa zaczyna się od nowa od zatwierdzonego kontraktu. Agenci sprawiają, że ponowna budowa jest tania, i właśnie dlatego tę zasadę da się dziś utrzymać, choć wcześniej była za droga.

1. G1: intencja zaakceptowana. Product manager oznacza intent.md jako zaakceptowany, a wnioski z prototypu trafiają do sekcji Evidence.

2. G2: kontrakt zatwierdzony. Inżynieria zamienia kryteria akceptacji w czerwone testy z pasującymi identyfikatorami AC, a product manager zatwierdza je, gdy są jeszcze czerwone. Potem testy zostają zablokowane poza zakresem edycji agenta, który implementuje zmianę.

3. G3: klasa ryzyka potwierdzona. Lider inżynierii potwierdza albo podnosi proponowaną klasę. Przy zmianie krytycznej wskazuje z imienia właściciela i drugą osobę zatwierdzającą, którzy autoryzują wydanie w G5.

4. G4: dowody kompletne. Pull request zawiera pakiet dowodów: przebieg testów akceptacyjnych, bramki typów i lintera, skan bezpieczeństwa i wyniki agenta recenzującego, a do tego ludzkie review wymagane dla danej klasy ryzyka.

5. G5: wydanie odwracalne. Zmiana trafia na produkcję za flagą funkcji, stopniowo, w trybie progressive delivery, z instrumentacją metryki wyniku i przetestowaną ścieżką wycofania.

6. G6: pomiar i decyzja. W terminach zapisanych w intent.md product manager odczytuje metrykę, porównuje ją z kryterium wycofania i zapisuje decyzję: zostawić albo usunąć.

G1–G3 i G6 to decyzje ludzi; G4 i G5 egzekwują narzędzia (testy w CI, pakiet dowodów, flaga funkcji i wycofanie). Najprostsza mechaniczna bramka po prostu odrzuca gałęzie prototypów. Zapisz poniższy plik jako .github/workflows/prototype-guard.yml i ustaw zadanie block-prototypes jako wymagany status check na main:

name: prototype-guard
on:
  pull_request:
    branches: [main]
    types: [opened, synchronize, reopened, edited, labeled, unlabeled]

permissions: {}

jobs:
  block-prototypes:
    runs-on: ubuntu-latest
    steps:
      - name: Refuse prototype branches and labels
        if: startsWith(github.head_ref, 'prototype/') || contains(github.event.pull_request.labels.*.name, 'prototype')
        run: |
          echo "Prototype work does not merge. Record the learning in intent/*.md and build from the approved contract."
          exit 1
      - name: Require a linked intent
        if: github.actor != 'dependabot[bot]'
        env:
          BODY: ${{ github.event.pull_request.body }}
        run: |
          printf '%s' "$BODY" | grep -Eq 'intent/[a-z0-9-]+\.md' || {
            echo "Link the accepted intent/*.md file in the pull request description."
            exit 1
          }

Workflow czyta tylko dane zdarzenia, więc działa z permissions: {}, nie pobiera kodu i przekazuje opis pull requesta przez zmienną środowiskową zamiast wklejać go do skryptu. Drugi krok w lekki sposób egzekwuje G1: każda zmiana wskazuje intencję, której służy. Wyłącz z niego pozostałe konta botów i zmiany czysto infrastrukturalne, tak jak wymaga tego twoje repozytorium. Blokadę testów akceptacyjnych, która egzekwuje G2, opisuje strona o wykonywalnych kryteriach akceptacji.

Jak wygląda roadmapa na poziomie 4?

Lista funkcji z datami zakłada, że budowanie jest zasobem rzadkim, a zbudowana funkcja zostaje na zawsze. Na poziomie 4 żadne z tych założeń nie jest prawdziwe. Budowanie jest tanie, weryfikacja i utrzymanie nie są, a część wydanych zakładów powinna zostać usunięta. Roadmapa staje się uszeregowaną listą zakładów o wynik, z których każdy ma swój intent.md i widoczną bramkę.

Horyzont	Zakład o wynik	Metryka i data odczytu	Intencja	Bramka	Właściciel	Sloty review
Teraz	Mniej dobrowolnych rezygnacji z planów miesięcznych	Retencja 60-dniowa po przepływie anulowania; 2026-12-15	intent/pause-subscription.md	G2: kontrakt zatwierdzony	M. Nowak	1 slot klasy krytycznej
Teraz	Szybszy pierwszy eksport faktur dla administratorów finansowych	Mediana czasu do pierwszego eksportu; 2026-11-30	intent/csv-export.md	G5: za flagą	J. Kowal	—
Następnie	Samodzielne zmniejszanie liczby miejsc	Zgłoszenia do supportu z tagiem „seats” miesięcznie	intent/seat-reduction.md	G1: prototyp odpowiedział na dwa pytania	M. Nowak	1 slot klasy krytycznej
Później	Dodatek rozliczany według użycia	Do ustalenia	jeszcze brak	Discovery	—	—

Trzy zasady sprawiają, że ten format działa:

• Przepustowość to sloty na review i wdrożenie, a nie tygodnie inżynierów. Zespół, który może zarezerwować czas review na jedną zmianę klasy krytycznej naraz, prowadzi jeden taki zakład naraz, niezależnie od tego, jak szybko budują agenci. Jak zmierzyć tę przepustowość, pokazuje projekt organizacji.
• „Teraz” zawiera tylko pozycje po G1. Pomysł bez zaakceptowanej intencji to discovery, a discovery jest widoczne jako osobny wiersz, a nie ukryte jako funkcja z datą.
• Każdy wiersz „Teraz” ma datę odczytu. Zobowiązaniem wobec zarządu jest data odczytu, a nie data wydania.

Jak zmienia się spotkanie priorytetyzacyjne?

Gdy szacunki pracochłonności przestają dominować, spotkanie przestaje być negocjacją o story pointy. Staje się cotygodniowym forum decyzji o dowodach, kontraktach i przepustowości. Przyjmij tę agendę na 45 minut z udziałem product managera, lidera inżynierii i właściciela ewaluacji dla danej domeny.

Minuty	Punkt	Zapisana decyzja
0–10	Odczyty. Zakłady, których data odczytu minęła: metryka wobec kryterium wycofania	Zostawić, iterować albo usunąć, dla każdego zakładu
10–20	Wyniki prototypów. Na co odpowiedział każdy prototyp	Zaktualizować intent.md, zrobić kolejny prototyp albo porzucić
20–30	Kontrakty. Intencje, których kryteria akceptacji są gotowe	Zatwierdzić do G2 albo zwrócić z nazwanymi brakami
30–40	Przepustowość. Wolne w tym tygodniu sloty na review i wdrożenie według klasy ryzyka	Które zatwierdzone kontrakty startują i w jakiej kolejności
40–45	Lista do wycofania. Wszystko w „Teraz”, co nie ruszyło się przez dwa cykle	Usunąć albo uzasadnić na nowo

Kontrakty konkurujące o sloty szereguj według reguły, którą każdy na sali potrafi zastosować:

priority = (expected outcome impact × confidence in the evidence)
           ÷ (verification cost + ongoing ownership cost)

Koszt budowy celowo w niej nie występuje. Koszt weryfikacji to minuty review wymagane dla jego klasy ryzyka plus testy i ewaluacje, które trzeba dodać. Koszt utrzymania to cena utrzymania funkcji w poprawnym stanie: dyżury, support, zależność, ścieżka danych regulowanych. Funkcja tania w budowie, która przy każdym wydaniu wymaga recenzenta dla klasy krytycznej, spada w rankingu poniżej trudniejszej, która zostaje w klasie niskiej. Oceniaj każdy czynnik w skali od 1 do 5 i wpisuj wynik do wiersza roadmapy, żeby na następnym spotkaniu było widać, skąd się wziął.

Kto co zatwierdza

Product manager podpisuje G1 i G6. Lider inżynierii podpisuje G3. Właściciel ewaluacji, a jeśli go nie ma, tech lead, współpodpisuje G2 razem z product managerem. Właściciel kodu podpisuje G4, a przy zmianie krytycznej imiennie wskazany właściciel i druga osoba zatwierdzająca autoryzują wydanie w G5. Model operacyjny układa te role w macierz RACI dla całego łańcucha.

Jak poznać, że zarządzanie produktem działa na poziomie 4?

Te pięć metryk pochodzi z historii gita, trackera i narzędzia analitycznego. Żadna nie wymaga nowej platformy.

Metryka	Definicja	Źródło	Właściciel	Zdrowy kierunek
Czas do akceptacji intencji	Dni od pierwszego commita intent.md do statusu „accepted”	Historia gita katalogu intent/	Szef produktu	W dół, bez wzrostu poprawek kontraktu
Wskaźnik poprawek kontraktu	Odsetek zmian, w których testy akceptacyjne zmieniły się po zatwierdzeniu w G2	Historia gita zablokowanych ścieżek testów	Lider inżynierii	Niski i stabilny; skok oznacza nieprecyzyjne kryteria
Wskaźnik odczytów	Odsetek wydanych zakładów, których metrykę odczytano w terminie i zapisano decyzję	Roadmapa i status intent.md	Szef produktu	W stronę 100%
Wskaźnik wycofań	Odsetek odczytanych zakładów usuniętych zgodnie z kryterium wycofania	Status intent.md	Szef produktu	Powyżej zera; zero oznacza, że kryteria wycofania są fikcją
Liczba wycieków prototypów	Zmiany scalone do main, które pochodzą z gałęzi prototype/* albo ominęły G1–G2	Logi strażnika CI i audyt pull requestów	Tech lead	Zero

Czytaj je razem z metrykami dostarczania zespołu ze strony o frameworkach metryk. Malejący czas do akceptacji intencji przy rosnącym odsetku nieudanych wdrożeń (change failure rate) oznacza, że produkt zasila pipeline szybciej, niż inżynieria potrafi weryfikować.

Co się psuje, gdy intencję piszą product managerowie?

Awaria	Co widzisz	Jak naprawić
Demo staje się zobowiązaniem	Prototyp pokazany zarządowi ma być na produkcji w przyszłym tygodniu	Pokazuj prototypy tylko ze statusem bramki na ekranie; odpowiedź na „kiedy” brzmi „po G2”, razem z datą odczytu
Kryteria pisane prozą	Inżynierowie przy każdej intencji zadają te same pytania; rośnie wskaźnik poprawek kontraktu	Uruchamiaj prompt sprawdzający kryteria przed przekazaniem; w punkcie o kontraktach odrzucaj intencje bez konkretnych wartości
Product manager pisze rozwiązanie	intent.md wymienia tabele, endpointy lub komponenty	Przenieś szczegóły projektu do spec.md; w intencji zostaw problem, wynik i obserwowalne zachowanie
Przesuwanie wyroczni, żeby przeszło	Po G2 ktoś edytuje kryteria akceptacji, żeby build agenta przeszedł	Każda zmiana zatwierdzonych kryteriów wraca do punktu o kontraktach i wymaga ponownego zatwierdzenia; blokada w CI opisana w ochronie wyroczni czyni ją widoczną
Zalew roadmapy	„Teraz” rośnie co tydzień, bo budowanie wydaje się darmowe	Ogranicz „Teraz” liczbą slotów review; egzekwuj listę do wycofania
Kryteria wycofania, które nigdy się nie uruchamiają	Wskaźnik wycofań wynosi zero przez dwa kwartały	Na każdym odczycie pytaj, jaki wynik usunąłby funkcję; jeśli nikt nie umie odpowiedzieć, przepisz kryterium
Kolejka review się zapycha	Kontrakty czekają przy G4, a intencje wciąż napływają	Wstrzymaj zatwierdzanie nowych kontraktów, dopóki kolejka się nie rozładuje; zobacz prowadzenie kolejki review

Pytania do szefa produktu i do CTO

1. Które z ostatnich dziesięciu wydanych funkcji miały zapisane kryterium wycofania i ile z nich usunęliśmy?
2. Kto dziś pisze kryteria akceptacji i czy dla każdego z nich test mógłby nie przejść?
3. Co mechanicznie, a nie na mocy umowy, powstrzymuje gałąź prototypu przed scaleniem do main?
4. Ile zmian klasy krytycznej potrafimy zweryfikować tygodniowo i czy roadmapa respektuje tę liczbę?
5. Do czego zobowiązuje nas roadmapa: do dat wydań czy do dat odczytu?

Dokąd dalej w zarządzaniu produktem

Wykonywalne kryteria akceptacji Jak inżynieria zamienia kryteria product managera w zablokowane, czerwone testy.

Plan: zapisz intent.md Krok po kroku, jak dowolny autor pomysłu zapisuje intencję.

Backlog gotowy dla agentów Potnij zaakceptowaną intencję na tickety, które agent dokończy, a check zweryfikuje.

Oprogramowanie budowane poza inżynierią Co się dzieje, gdy zespoły produktowe i biznesowe same budują narzędzia z agentami.

Jak zmieniają się zespoły, role i zatrudnienie Przepustowość review, nowe role i przesunięcie granicy między produktem a inżynierią.

Ekonomia oprogramowania budowanego przez agentów Koszt zaakceptowanej zmiany, czyli liczba stojąca za regułą priorytetyzacji.