DBAdmin/inbox/How to Build a Company OS in Claude Code with Jiaona Zhang, CPO at Laurel.md at master

dexter/DBAdmin

Fork 0

Files

T

Paweł Domański b0c712c4e8 Aug 7, 2026, 3:29 PM

2026-08-07 13:29:13 +00:00

21 KiB

Raw Permalink Blame History

title, source, author, published, created, description, tags

title

source

author

published

created

description

Dzisiejszy odcinek

Pisałem o budowaniu systemu zarządzania projektami i systemu zespołowego w kodzie Claude. To moje dwa najpopularniejsze prace 2026 roku.

Dziś jest aktualizacja: system operacyjny firmy, który pozwala nawet CSM w twojej firmie na produkcję produkcyjną.

I to nie jest teoria.

Jiaona Zhang "JZ" jest CPO w Laurel – która zebrała 100 milionów dolarów w serii C – a jej firma faktycznie działa na systemie operacyjnym firmy. Napotkali problemy i niedociągnięcia. Wygładzili je. Teraz pokazują, co działa.

JZ nie jest jakimś "purystą AI". Prowadziła produkty w Airbnb, Dropbox, Webflow i WeWork. Jest realistką AI.

A w tym odcinku nic nie ukrywa:

System operacyjny firmy, który to wszystko umożliwia
Jak PM-owie przechodzą od pomysłu na produkt do wysłanej funkcji z agentami
Jak prowadzi rozmowy kwalifikacyjne z AI PM w tej epoce i jak je osiągać na wysokim poziomie

To jeden z najgęstszych odcinków, jakie kiedykolwiek nagrałem.

Mam nadzieję, że oglądanie tego będzie Ci się podobało tak samo, jak mnie nagrywając.

Aby uzyskać dostęp do mojego zestawu narzędzi AI – Dovetail, Arize, Linear, Descript, Reforge Build, Relay.app, Magic Patterns, Speechify, Bolt.new i Mobbin – zostań rocznym subskrybentem (150 USD) i pobierz pakiet Aakasha.
Aby uzyskać dostęp do moich personalizacji AI PM – PM OS, Job Search OS i Prompt Library – zostań założycielem (250 USD).

Witamy w pierwszym przewodniku internetowym, który pokazuje, jak liderzy produktu mogą stworzyć system operacyjny firmy, aby przyspieszyć wdrażanie kodu Claude w całej organizacji:

Jak zbudować system operacyjny firmy
- Jak rozszerzyć adopcję AI poza inżynierię
Nowa rola PM w zespole natywnym dla AI
Jak zostać zatrudnionym jako PM natywny w AI-

1. Jak zbudować system operacyjny firmy

System operacyjny firmy może odblokować produktywność w całej organizacji. Wykorzystuje moc koncepcji takiej jak system operacyjny PM poza pojedynczych PM-ów czy zespoły produktowe.

W Laurel nawet CSM wysyłają do produkcji.

Oto jak zbudować własną:

Architektura jest prostsza, niż myślisz

Jedno repozytorium na GitHub. Każdy zespół w firmie ma własny folder. Każdy folder odpowiada aktywnościom prowadzonym przez daną drużynę. Każda aktywność ma swój plik umiejętności. Pliki umiejętności trafiają bezpośrednio do ustawień organizacji Claude'a. Każdy, kto otwiera Claude'a, ma już załadowane odpowiednie umiejętności.

Podczas dema JZ udostępniał na żywo pełną strukturę GitHub Laurel. Sukces klienta, data science, projektowanie, inżynieria, finanse, prawo, marketing, wszystko to:

Oryginalny system operacyjny firmy, a następnie JZ at Laurel

Są trzy warstwy, które pozwalają zbudować własne.

Warstwa 1 – Zacznij od ontologii

Projektowi budują system operacyjny, a potem zastanawiają się, dlaczego nikt go nie używa. Pomylili się w kolejności.

Zacznij od ontologii, jak JZ. Przypisuj pracę każdej funkcji do kategorii, a następnie do zadań w obrębie każdej kategorii. Co powinna robić sprzedaż? Co powinno robić CS? Co powinien robić produkt? Ta mapa pracy kształtuje strukturę folderów. System operacyjny jest zbudowany na podstawie ontologii:

Jak wygląda ontologia firmy

W Laurel ontologia znajduje się obok systemu operacyjnego. Dla każdej funkcji pokazuje, które aktywności powinny wzrosnąć (więcej czasu ludzkiego), a które zmniejszyć (automatycznie). Jeśli chodzi o produkty, analizy konkurencyjne, briefy interesariuszy oraz syntezę badawczą należą do kolumny "przestań robić ręcznie". Prace nad funkcjami, kontrola jakości oraz bezpośredni kontakt z klientem są w kolumnie "spędzaj tu więcej czasu". Oznaczone kolorami. Widoczne dla każdego lidera.

To jest część, którą większość firm pomija. Instalują narzędzia, zanim zdecydują, która praca faktycznie ma znaczenie.

Warstwa 2 - Architektura plików umiejętności

Gdy już masz ontologię, rozwijaj umiejętności.

Plik umiejętności to dokument Markdown, który koduje, jak wykonać konkretną pracę. To nie jest zwykła podpowiedzi. Konkretny, opiniotwórczy przewodnik, który odzwierciedla, jak Twoja firma to robi. Jak napisać e-mail o odnowieniu w swojej firmie? Jak wygląda dobra prośba o funkcjonalność, gdy pochodzi od przedstawiciela obsługi klienta? Jakie pytania zadajesz przed segregacją eskalacji wsparcia?

Plik umiejętności wyjaśnia to wszystko. Prześlij go do ustawień organizacji Claude'a i stanie się dostępny dla wszystkich. Umiejętność jest wywoływana, gdy jest potrzebna. Dzięki temu prostemu ustawieniu najlepszy workflow dla jednej osoby staje się domyślnym dla wszystkich.

Warstwa 3 - Warstwa dostarczająca

W Laurel każdy członek zespołu z kontaktem z klientem otrzymuje codzienną poranną wiadomość w Slacku. Kalendarz, spotkania, kontrole, sesje wdrożenia – wszystko się pojawiło. A obok każdego przedmiotu wbudowana jest umiejętność do użycia. Masz telefon o odnowieniu o 10:00. Oto umiejętność odnowienia. Masz sesję wdrożenia o 14:00. Oto umiejętność wdrożenia. System operacyjny spotyka ludzi tam, gdzie już są.

Ten 1% zawsze to rozgryzie. System operacyjny firmy to sposób, w jaki sprawiasz, że ich workflow jest domyślny dla wszystkich.

Jak rozszerzyć adopcję AI poza inżynierię

Gdy adopcja AI jest odpowiedzialnością wszystkich, to nie jest odpowiedzialnością nikogo. Osoba, która miała budować workflow obsługi klienta, prowadzi też odnowienia, zajmuje się eskalacją i wdraża trzy nowe konta. Workflow nigdy nie jest budowany. To prowadzi do ogromnej luki.

Naprawa ↓

Krok 1 – Poświęć temu osobę

W Laurel ta rola nazywa się operacjami AI. Jedna osoba, na pełen etat na zlecenie, której cała praca polega na znajdowaniu efektywności, budowaniu przepływów pracy i rozprzestrzenianiu tego, co działa, na każdą funkcję.

JZ opisuje to jako nowy BizOps:

AI ops to nowy BizOps. Wcześniej BizOps robiły naprawdę znaczące rzeczy, ale często były to bardzo wysokie poziomy, różne role, wiele rzeczy na poziomie rynku. Jeśli przekształcisz pomysł BizOps, który w wielu aspektach jest znowu szwajcarskim scyzorykiem, na znalezienie osób niesamowicie ciekawych, majsterkujących przy najnowszej technologii i nieustannie dążących do osiągania efektywności, to właśnie tego DNA naprawdę szukam.

Laurel zaczęła od jednej osoby, Sashy. W ciągu kilku miesięcy każda inna impreza chciała mieć swoją własną Sashę. To właśnie ten popyt pozwala na uzyskanie budżetu. Pokazujesz wartość jednej osobie, a potem pozwalasz, by przyciąganie pojawiło się naturalnie.

Jeśli czytasz to jako lider, który jeszcze nie może zatrudnić na to stanowisko, to osoba najbliższa temu już istnieje w twoim zespole. To oni wymyślili automatyzację Slacka, której nikt im nie kazał budować. Znajdź ich. Daj im oficjalny mandat.

Krok 2 - Zorganizuj firmowy hackathon

Założenie, które blokuje adopcję AI w funkcjach nietechnicznych, jest proste: trzeba być technicznym, by coś zbudować.

Jeden hackathon przełamuje to założenie szybciej niż jakikolwiek program szkoleniowy.

Laurel zorganizowała firmowy hackathon na ich offsite około trzy miesiące temu. Każda drużyna wzięła udział. Nie tylko inżynieria. Wyraźnym celem było pokazanie, że każdy może budować. Gdy menedżer ds. sukcesu klienta wysyła coś w ciągu jednego dnia, historia się rozprzestrzenia. Ta historia robi więcej dla adopcji niż jakiekolwiek nakazy odgórne.

Jeśli cała praca poza miejscem pracy wydaje się poza zasięgiem, jedno popołudnie też się sprawdza. Wybierz jedną funkcję. Daj im cztery godziny i jasny problem do rozwiązania. Trzymaj niską poprzeczkę, spraw, by nawet działająca automatyzacja Slacka się liczyła. Szablon promptu, który oszczędza 30 minut dziennie, się liczy. Celem jest pierwsze zwycięstwo nad idealnym rozwiązaniem.

Krok 3 – Spraw, by kultura była widoczna

Niektóre firmy mają wartość slajdu, którego nikt nie czyta po zakończeniu prezentacji.

Laurel przekształciła swoją wartość "nierozsądnej gościnności" w sposób pracy. Gdy menedżer ds. sukcesu klienta ma nadchodzącą wizytę i od jakiegoś czasu nie miał kontaktu osobistego z tym klientem, system operacyjny to ujawnia. Czerpie z transkrypcji Gong to, co klient uwielbia. Sugeruje ten gest. Zajmuje się logistyką. Jeśli widzisz, teraz wartość nie jest już tylko slajdem.

To właśnie część większości liderów pomija. Kultura rozprzestrzenia się przez systemy, które czynią właściwe zachowania domyślnym. Nie musisz mieć wewnętrznej motywacji, by okazywać gościnność. Potrzebujesz systemu, który ułatwi to wszystkim i tak robić.

Ta sama logika dotyczy adopcji AI. Czekanie, aż 99% Twojej firmy samo zainteresuje się AI, to ryzykowna stawka. Postaw odpowiednią umiejętność w odpowiednim momencie, a ciekawość sama się załatwi.

2. Nowa rola PM w zespole natywnym dla AI

Na Reddicie właśnie toczy się taka rozmowa. Prywatny menedżer pyta, czy jego praca znika. Dostałem 200 odpowiedzi, połowa spanikowana, a druga zbywająca. Szczerze mówiąc, żadna z tych grup nie ma racji.

Ta praca nie znika. Jego kształt zmienia się szybciej, niż większość ludzi chce przyznać.

Oto jak wygląda nowy kształt.

Model kapitana

Zapomnij o starym łańcuchu przekazywania. PM pisze specyfikację, wysyła do projektanta, projektant wysyła do inżyniera, inżynier odsył, projektant mówi, że to nie jest to, co zaprojektował. Ta pętla dzieje się w zespołach natywnych dla AI.

Zastępcą jest model kapitana. Każda funkcja ma jedną osobę, która ją posiada od początku do końca.

Kapitan to osoba, która ma najważniejszą umiejętność do najtrudniejszego problemu danej cechy:

Kapitan inżynierii – zmiany architektoniczne, przebudowy systemów, wszystko, gdzie ryzyko bazy kodu jest największą zmienną.
Kapitan projektanta – Funkcje z dużą ilością interakcji, gdzie doświadczenie jest wszystkim, a inżynieria prosta.
Kapitan PM – Funkcje, gdzie najtrudniej jest dobrze zrozumieć klienta i kontekst biznesowy. Puste stany. Onboarding przebiega. Wszystkie, gdzie treść i wgląd użytkownika są ważniejsze niż kod.

To jest pełny model.

Recenzje produktów z dwoma ścieżkami

Prędkość bez ustawienia to po prostu krążenie w kółko. Model kapitana potrzebuje barier.

W Laurel są dwa tory:

Ścieżka 1 - Szybko.

Małe cechy, jeden kapitan, całkowite posiadanie. Korzysta z kanału Ask Devin recenzentów na Slacku. Inżynier przegląda PR. Projektant sprawdza to w razie potrzeby. Nie było formalnego spotkania przeglądowego produktu.

Utwór 2 – pełna recenzja.

Wymagane są radykalne zmiany w kluczowych interakcjach z użytkownikami, decyzjach architektonicznych, myśleniu na poziomie systemowym. To właśnie JZ nazywa przeglądem strategii produktu. "Jesteśmy pewni, że to właściwy kierunek dla całego produktu?" Dodatkowo osobna recenzja architektoniczna – "Czy system faktycznie będzie wspierał to, co chcemy osiągnąć?"

Pytanie, które większość zespołów rozwiązuje źle, brzmi: na którym torze należy dany obiekt.

Test jest prosty. Jeśli zmiana dotyczy kluczowej interakcji użytkownika, która dotyka całego produktu, jest to Track 2. Jeśli jest ograniczony do jednego workflow, a najtrudniejszym problemem jest wykonanie, to jest to Track 1. Inicjatywy tymczasowe, mimo że były funkcją frontendu i backendu, były Ścieżką 1. Przeprojektowaniem sposobu, w jaki Laurel wyświetla czas przez cały dzień, byłby Track 2.

Omówiłem mechanikę wysyłania PM do produkcji w moim przewodniku PM dotyczącym wysyłki pierwszego pull requesta. Model kapitana sprawia, że żegluga jest zrównoważona na dużą skalę, a nie jednorazowym eksperymentem.

Na zakończenie powiedziałbym...

Podstawy świetnego zarządzania produktem nigdy się nie zmieniały. Zmieniło się to, że nie można już ukrywać się za procesami, spotkaniami i liczbą pracowników.

Praca jest pracą teraz.

3. Jak zostać zatrudnionym jako PM z natywną inteligencją AI

Zapytaj kogoś z zespołu, czy korzysta z AI. Wszyscy mówią tak. Poproś ich, żeby ci pokazali. I tu właśnie zmienia się odpowiedź.

Istnieje rama, która natychmiast przebija się przez szum. Cztery poziomy. Każda osoba, każdy zespół, każda firma znajduje się gdzieś na tej skali.

Poziom 1 – Tryb czatu.

Otwierasz Claude'a lub ChatGPT. Wpisujesz pytanie, żeby uzyskać konkretną odpowiedź.

To jest AI jako nieco mądrzejsze Google. Większość ludzi tu jest. Jeśli zamykasz zakładkę po każdej sesji i zaczynasz od nowa następnym razem, jesteś na poziomie 1.

Poziom 2 – Automatyzacja przepływu pracy.

Przestajesz wykonywać zadanie ręcznie i budujesz coś, co robi to za ciebie.

Automatyzacja Slacka, która sortuje żądania funkcji. Szablon, który automatycznie zapełnia się z twojego CRM. Poranne spotkanie, które wyciąga z kalendarza i pokazuje priorytety. Jeden workflow. To jest punkt wejścia. Jeśli nie znasz, opisałem, jak zacząć budować te elementy w moim przewodniku AI Agents for PMs.

Poziom 3 – Tworzenie aplikacji.

Identyfikujesz coś na tyle żmudnego, że zasługuje na prawdziwe narzędzie, i tworzysz aplikację.

Coś z interfejsem, logiką i stanem. To tutaj mieszkają projektowi deweloperzy. Mahesh Yadav wyjaśnił dokładnie, jak do tego dojść w naszym odcinku o zostaniu budowniczym PM.

Poziom 4 – Współdzielone aplikacje i wysyłka do klientów.

Budujesz rzeczy, których używają inni. Twój zespół Customer Success udostępnia funkcję. Twój PM składa PR, który trafia do produkcji. Jesteś w pełnym cyklu życia produktu. To tutaj działają zespoły natywne dla AI.

W większości organizacji zespół inżynierów jest podzielony na poziom 2 i poziom 3. Sprzedaż i Customer Success to głównie poziom 1. Finanse i prawo często są na poziomie 0, co nawet nie jest na skali.

Test udostępniania ekranu

Oto jak JZ wykorzystuje ten framework w praktyce. W każdej rozmowie kwalifikacyjnej prosi kandydata o udostępnienie ekranu.

W ciągu 60 sekund dokładnie wiesz, gdzie ktoś jest. Osoba na poziomie 1 ma otwarte kilka zakładek czatu Claude'a z jednorazowymi pytaniami. Osoba na poziomie 3 ma strukturę folderów, zestaw zapisanych workflowów, może aplikację, którą stworzyła w zeszłym tygodniu.

Ten sam test działa w twoim zespole. Wybierz pięć osób z różnych funkcji. Poproś ich, żeby pokazali ci, jak korzystają z AI. Nie proś ich o opis. Patrz, jak się dzieje. Za mniej niż godzinę będziesz mieć jasną mapę faktycznego miejsca pracy Twojej firmy.

Oto najważniejsze wnioski z jednej infografiki:

Gdzie znaleźć Jiaonę Zhang

SONDAŻ

Co sądzisz o dzisiejszym wpisie?

Super - 5/5

Dobrze - 3/5

Źle - 1/5

Powiązane treści

Podcasty:

Biuletyny:

PS. Prosimy o subskrypcję na YouTube oraz śledź na Apple i Spotify. To pomaga!

21 KiB Raw Permalink Blame History Unescape Escape