How top PMs increase their leverage with AI

Analyzováno: 1 dokument / cca 2 610 slov čistého textu + 27 obrázků v Gmail HTML exportu
Datum extrakce: 2026-06-30
Zdroj: Lenny's Newsletter, guest post od Colina Matthewse
Pokrytí: Vše dostupné v lokálním HTML exportu. Sekce za paywallem není rekonstruovaná mimo to, co bylo vidět v diagramech.

Executive Summary

Colin Matthews rámuje práci AI-native PM přes tři druhy leverage: personal, product a systems. Personal leverage pomáhá odbavovat vlastní úkoly; product leverage zkracuje cestu od nápadu k validaci nebo PR; systems leverage vytváří opakovatelné postupy, ve kterých AI dělá práci podle rubrik, subagentů a plánovaných tasků.

Hlavní posun pro PM není "psát lepší texty s AI", ale umět správně vybrat úroveň delegace. Někdy stačí nechat AI napsat první draft. Jindy má AI vytvořit artefakt, připojit se přes MCP k nástrojům, analyzovat data, připravit prototyp v reálném codebase nebo poslat omezený PR k review.

Nejvyšší rung neznamená nulovou kontrolu. Autor opakovaně říká, že lidský review zůstává; vyšší leverage jen přesouvá víc mezikroků na AI a uvolňuje PM na práci, kterou má dělat člověk.

Kontext zdroje

• E-mail přišel z Lenny's Newsletter 30. června 2026 v 15:31.
• Viditelný článek je guest post od Colina Matthewse.
• Colin Matthews podle zdroje trénoval přes 30 000 PMs v používání AI, učil AI a technické dovednosti v firmách jako OpenAI, Google, Stripe, Figma a Microsoft, byl product leader/founder a solo shipnul víc než 10 SaaS produktů.
• Newsletter zároveň promuje kurz "Become an AI-Native Builder", který Colin spoluvytvořil s Lennym. První cohort má start 13. července 2026. Roční předplatitelé Lenny's Newsletter mají podle e-mailu slevu 600 USD, Insiders 1 000 USD.
• Kurz má učit PMs a další netechnické role používat Codex, Claude Code, Cursor, skills, MCPs, reálný codebase, GitHub workflow a evals.
• Kromě kurzu jsou zmíněné bezplatné workshopy s lidmi z OpenAI, Cursor, Linear, Replit a Lovable pro placené předplatitele newsletteru.
• E-mail zmiňuje Product Pass balíček nástrojů: Google AI, Cursor, Lovable, Notion, Manus, Replit, Gamma, n8n, Canva, ElevenLabs, Factory, Wispr Flow, Fin, Supabase, Bolt, Linear, PostHog, Framer, Railway, Granola, Warp, Gumloop, Magic Patterns, Mobbin, Stripe Atlas a ChatPRD.

Core Knowledge

1. Role PM se posouvá od koordinace k AI-native exekuci

Autor tvrdí, že starší verze PM role byla hodně o koordinaci a alignmentu. V roce 2026 se u nejlepších PMs ve špičkových firmách posouvá k tomu, že PM:

• prototypuje s reálným kódem,
• dotazuje se na data konverzačně přes MCP,
• umí sebevědomě řídit coding agents,
• používá AI na zvýšení vlastního leverage, ne jen na produktivitu v textu.

Matthews popisuje změnu očekávání u executives: dřív stačilo základní prototypování a obecná produktivita, nově roste očekávání, že zaměstnanci budou pomocí AI dokončovat celé tasky. Dvě hlavní mezery, které po školeních produktových a design ICs vidí:

• lidé nevědí, jakou úroveň AI zapojení zvolit pro danou práci,
• chybí jim technické dovednosti, aby AI nástroje použili naplno.

2. Rámec: tři žebříky leverage

Framework má tři paralelní žebříky:

Žebřík	K čemu slouží	Rung 1	Rung 2	Rung 3
Personal leverage	Odbavování vlastního to-do listu	Write text	Create artifacts	Complete a full to-do
Product leverage	Rychlejší cesta od nápadu k validaci nebo změně v produktu	Web-based prototypes	Code-based prototypes	Ship PRs to production
Systems leverage	Opakované delegování práce AI při vyšší kvalitě	Use subagents	Write rubrics	Schedule tasks

Princip: s každým rungem roste leverage přibližně o řád. Na první úrovni AI asistuje, na druhé přebírá task a člověk reviewuje výstup, na třetí AI dokončuje vícekrokové úkoly a část kontroly dělá sama. Člověk stejně dělá finální review.

Důležité pravidlo: ne každý task, workflow nebo firma potřebuje nejvyšší rung. Správná úroveň se vybírá podle práce před tebou.

Personal Leverage Ladder

Rung 1: AI píše text

Typické použití:

• PRDs,
• Jira tickets,
• e-maily,
• první drafty dokumentů.

Charakteristika:

• PM "mluví s AI" a nechává si pomáhat s textem.
• AI má málo kontextu o firmě a o tom, jak má dobrý výstup vypadat.
• Výsledek často vzniká iterací v chatu a pak copy-paste do Google Docs, Wordu, Jira nebo jiného nástroje.
• Autor říká, že většina lidí je na této úrovni nebo ještě níž.

Příklad ze screenshotu: jednoduchý dotaz v Claude žádá o pomoc s PRD pro porovnání Claude managed agents proti vlastnímu běhu agentů na infrastruktuře typu EC2. To je čistý textový draft, ne hotový pracovní artefakt.

Rung 2: AI vytváří artefakty

Typické artefakty:

• slides,
• základní Excel/Sheets modely,
• malé prototypy.

Rozdíl proti Rung 1: AI neprodukuje text k překopírování, ale rovnou soubor nebo artefakt. Autor uvádí příklad finančního modelu, který porovnává náklady self-hosted agentů proti managed agent service.

Zachycený prompt pattern:

• porovnat build-and-host ourselves vs. managed agents,
• prozkoumat úsporu engineering time,
• porovnat compute costs pro self-hosted vs. managed,
• zahrnout vendory typu Cloudflare, Vercel a E2B,
• ukázat cost pilotu a cost ve scale scénáři,
• počítat s 5M+ agent instances ročně,
• definovat agent instance jako jednu hodinu běhu.

Screenshot modelu ukazuje příkladovou tabulku "Infrastructure cost per agent-hour". Hodnoty ber jako výstup modelu k validaci, ne jako kanonické ceny:

Option	USD / agent-hour	Billing model	Hours covered by 1 USD
Claude Managed Agents	0.0400	Active runtime only	25.0
Cloudflare Sandboxes, self-built harness	0.0713	Active CPU; provisioned memory	14.0
Vercel Sandbox, self-built harness	0.1496	Active CPU; provisioned memory	6.7
E2B, self-built harness	0.1822	vCPU-hour + GB-hour, full uptime	5.5
AWS Fargate, full self-host	0.1580	vCPU-hour + GB-hour, provisioned wall-clock	6.3
AWS EC2, full self-host	0.0711	Provisioned, packed/reserved	14.1

Screenshot také říká, že token cost je v modelu vynechaný, protože by byl identický napříč možnostmi. I na této úrovni autor očekává výraznou revizi výstupu.

Rung 3: AI dokončí celý to-do item

Nejvyšší personal leverage nastává, když PM deleguje celý pracovní úkol. AI se připojí k reálným nástrojům a sama tahá/pushuje informace.

Předpoklady:

• LLM je připojené přes MCP nebo connectors k nástrojům, které PM běžně používá.
• Zdroje mohou být Amplitude, PostHog, Pendo, Google Drive, Notion, Canva, Figma a další.
• Claude Code, Codex a Cursor se podle zdroje umí přes MCP napojit na nástroje jako Figma, Amplitude, PostHog nebo Pendo.
• Uživatel nastaví connector jednou a pak ho může opakovaně používat.

Příklad Stride / PostHog:

• Stride je fiktivní Strava-like produkt pro atlety.
• Úkol: zjistit, jestli uživatelé, kteří sdílejí aktivity s fotkou, mají vyšší 30denní retention než uživatelé bez fotky.
• AI má použít PostHog, udělat analýzu a dodat HTML dokument s vizualizací kohort a zdroji k ověření.
• Autor doporučuje explicitně chtít citace/zdroje, aby šla validovat správnost.

Zachycený výstup z obrázku:

• Verdikt: "Not supported (small, inconsistent signal)".
• AI výstup tvrdí, že není jasný retention lift ze sharingu.
• Shareři mají ve 4. týdnu 91,3 %, non-shareři 86,3 %, gap +4,9 pp.
• Retention curves se ale kříží; non-shareři vedou ve week 2 a week 5.
• Průměrný gap týdny 1-8 je jen +0,1 pp, 86,7 % vs. 86,6 %.
• Výstup proto netlačí falešný závěr z jednoho pozitivního bodu.

Příklady tasků po nastavení connectors:

• analyzovat launch pomocí posledních customer tickets a online sentimentu,
• zkontrolovat použití feature přes produktové analytics eventy,
• shrnout customer call recording a vytvořit prototyp podle feedbacku,
• upravit další sprint podle změny roadmap priorities.

Autor očekává, že první výsledky budou zklamání, protože model ještě nezná standardy týmu. Doporučení: iterovat s modelem, dokud výstup není dobrý, a pak workflow zamknout do skillu, který vznikne ve stejném chatu.

Product Leverage Ladder

Product leverage řeší vzdálenost mezi "víme, co chceme postavit" a "umíme to rychle validovat nebo dostat do produktu", i když PM není silný designer nebo engineer.

Rung 1: Web-based prototypes

Použití:

• rychlé prototypy v nástrojích jako Lovable, Replit a Magic Patterns,
• komunikace konceptu stakeholderům, zákazníkům nebo internímu týmu,
• rychlejší validace, jestli solution řeší customer problem.

Limit:

• prototyp komunikuje myšlenku, ale kód obvykle nemá hodnotu pro produkční produkt,
• prototyp nepoužívá existující codebase,
• nástroj často nezná reálné komponenty, stránky, datové modely a design patterny,
• po validaci je potřeba práci přeložit do skutečného produktu.

Příklad Stride:

• Profilová stránka ukazuje atleta Alex Carter, 182 followers, 210 following, 14 activities, 397 km distance a 5 667 m elevation.
• Customer problem: uživatelé si stěžují, že nemají jasnou cancellation path a nerozumí subscription statusu po free trialu.
• Web prototyp přidává stránku "Your training, at a glance" s tlačítkem "Manage plan & billing". Slouží k testu, jestli navržené řešení srozumitelně adresuje billing/cancellation problém.

Rung 2: Code-based prototypes

Další krok je prototypovat s reálným produktem. PM použije Claude Code nebo Codex nad codebase, ne jen screenshoty a dlouhé prompty.

Požadavky:

• PM potřebuje základní technické dovednosti,
• nemusí být expert engineer,
• nemusí rozběhnout celý produkční backend,
• potřebuje safe repo nebo codebase obsahující UI bez plného backendu.

Doporučený engineer setup:

• vytvořit separátní repo z hlavního codebase,
• zahrnout base UI elements, styles, routes, pages a components pro vybrané části produktu,
• vytvořit lokální mock data store, který napodobuje API data model,
• zajistit, že repo běží bez env vars a backend services,
• dát PM bezpečné prostředí, kde nepokazí produkci.

Autor uznává, že engineer může říct, že setup je složitější než jeden prompt. Přesto to označuje za práci, která se vyplatí, protože prototypy pak stojí na reálných stylech a komponentách.

Zachycený Stride code-based prototype:

• stejná profilová stránka dostává billing panel přímo do existující settings/profile UI,
• panel "Current plan" ukazuje plan "Summit", cenu 11 USD/měsíc, renewal date Jun 11, 2026,
• zobrazuje benefity jako segment leaderboards/live grouping, heart rate zones/relative effort a custom routes/turn-by-turn export,
• obsahuje "Manage plan" button a platební kartu,
• vzhled sedí k existujícím komponentám produktu.

Rung 3: Agent shipne PR do produkce

Nejvyšší product leverage je poslat agenta, aby připravil změnu jako pull request. Engineer pak PR reviewuje a merguje.

Kdy to dává smysl:

• copy changes,
• malé UI/UX tweaks,
• views, které už používají existující backend code,
• změny, kde API, data elements a events už existují.

Kdy to smysl nedává:

• nová infrastruktura,
• nové integrace,
• změny vyžadující jiné týmy,
• situace, kde by PM jen byl horší engineer než jeho tým.

Klíčová myšlenka: technický úsudek PM je důležitější než samotná schopnost vygenerovat kód. PM má vědět, kdy napsat dokument, kdy vytvořit prototyp a kdy má smysl rovnou poslat PR.

Systems Leverage Ladder

Textová část Systems leverage je v exportu za paywallem. Diagramy v e-mailu ale ukazují tři rungy:

1. Use subagents
2. Write rubrics
3. Schedule tasks

Z viditelného úvodu frameworku plyne, že systems leverage znamená vytvářet opakovatelné kroky, kterými lze konzistentně outsourceovat práci AI a zvyšovat kvalitu výstupu. Autor v úvodním rámování říká, že na nejvyšších úrovních AI dokončuje multi-step tasks a kontroluje část vlastních výsledků.

Interpretace přes dostupný text:

• Use subagents: rozdělit práci na dílčí specializované AI role nebo workflow, místo aby jeden chat dělal všechno.
• Write rubrics: dát AI jasná hodnoticí kritéria, podle kterých může generovat a kontrolovat výstup.
• Schedule tasks: posun od ručního spouštění promptů k plánovaným nebo opakovaným taskům.

Tato interpretace je odvozená z názvů rungů a obecného popisu systems leverage ve zdroji. Detailní postup není v lokálním exportu dostupný.

Decision Rules

Výběr správného rungu

Situace	Použij	Proč
Potřebuješ první návrh textu	Personal Rung 1	AI pomůže formulovat PRD, ticket nebo mail, ale výstup ještě ručně přeneseš a upravíš.
Potřebuješ tabulku, slide, model nebo mini prototyp	Personal Rung 2	AI vytvoří artefakt, ne jen text. Počítej s revizí.
Potřebuješ odbavit celý analytický nebo informační úkol	Personal Rung 3	AI musí mít přístup k nástrojům přes MCP/connectors a dodat validovatelný výstup.
Potřebuješ rychle otestovat product idea	Product Rung 1	Web prototyp stačí pro komunikaci a customer/stakeholder feedback.
Potřebuješ prototyp blízko realitě produktu	Product Rung 2	Použij reálné komponenty, routes a mock data v bezpečném UI repo.
Změna je malá, bounded a používá existující backend	Product Rung 3	Agent může připravit PR, engineer ho reviewuje.
Změna vyžaduje infrastrukturu, nové API nebo jiný tým	Dokument / engineer pairing	PM nemá trávit čas jako slabší engineer.
Workflow se povedlo a bude se opakovat	Skill / rubric	Zamkni standardy, ať příště nezačínáš z nuly.

Prompting pravidla zachycená ze zdroje

• U analytických tasků chtít citace nebo přímé source links, aby šel výstup validovat.
• Zadávat jasný finální formát, například HTML doc s vizualizací.
• U modelů explicitně pojmenovat scope, vendor options, scale předpoklady a co se má/ne má počítat.
• Po dobré iteraci vytvořit skill ze stejného chatu; skill má nést standardy, ne jen instrukci "udělej to znovu".
• U prototypů říct, jestli výstup má být jen komunikační web prototype, nebo změna v reálném codebase.

Quality Criteria

Dobrý personal leverage výstup

• AI používá relevantní zdroje a nástroje, ne jen obecnou znalost.
• Výstup obsahuje data, odkazy nebo zdroje k ověření.
• Model umí říct "signal not supported", když data nejsou konzistentní.
• Výstup je hotový artefakt nebo hotový to-do item, ne jen text k mechanickému copy-paste.
• Po iteraci je workflow uložené jako skill nebo opakovatelný prompt pattern.

Dobrý product leverage výstup

• Prototyp odpovídá účelu: komunikace, validace, code-based test nebo PR.
• Web prototype není prezentovaný jako produkční kód.
• Code-based prototype používá reálné komponenty a design patterny.
• Safe UI repo běží bez env vars, bez backendu a s lokálními mock daty.
• PR je omezený na změny, které může engineer rychle reviewnout.
• PM umí vysvětlit, proč zvolil dokument, prototyp nebo PR.

Red flags

• AI výstup nemá zdroje a přesto tvrdí závěr z dat.
• PM vybere nejvyšší rung jen proto, že působí pokročile.
• Web prototyp se po customer testu musí celý překreslit do reálného produktu.
• Agent má shipnout změnu, která vyžaduje nové backend API nebo infrastrukturu.
• Model nezná týmové standardy a uživatel si zklamání vyloží jako limit AI, místo aby vytvořil rubric/skill.
• PM se snaží být "horší engineer" místo toho, aby využil technický úsudek a tým.

Edge Cases

• Nejvyšší rung není automaticky nejlepší. U jednorázového textu stačí Rung 1.
• I Rung 3 vyžaduje lidský review. AI může kontrolovat část práce, ale odpovědnost zůstává na člověku.
• První výstupy z agentických workflow mohou být slabé, protože model nezná lokální standardy. To je signál k iteraci a vytvoření skillu/rubriky.
• U prototypů bez reálných komponent hrozí falešná validace: zákazník reaguje na koncept, ale engineering effort může být vyšší, než prototyp naznačuje.
• U code-based prototypů je bezpečné oddělení od backendu výhoda, ale může skrýt integrační problémy.
• Systems leverage v exportu není plně dostupné; zachované jsou jen tři rungy z diagramu a obecný popis z úvodu.

Využitelnost pro Aibility

Toto je zdrojově podložená interpretace pro Aibility, ne přímá citace článku.

• Framework dobře sedí k Aibility výuce: místo obecného "používejte AI" rozlišuje tři druhy leverage a konkrétní úrovně zralosti.
• Personal ladder se dá mapovat na účastníky, kteří začínají u textu a postupně chtějí dělat analýzy přes vlastní nástroje.
• Product ladder je užitečný pro PMs, ops a business lidi, kteří nejsou engineers, ale mohou s Codex/Claude Code vytvářet prototypy a malé PRs.
• Systems ladder sedí na Aibility PACT/skills přístup: subagenti, rubriky a scheduled tasks jsou přesně místa, kde se jednorázové prompty mění na systém.
• Stride příklad je použitelný ve výuce jako pattern: customer pain -> web prototype -> real-code prototype -> bounded PR.
• PostHog příklad je dobrý benchmark kvality: AI nemá jen najít pozitivní metriku, ale vyhodnotit konzistenci signálu.

Zachycené nástroje a pojmy

Pojem / nástroj	Role ve zdroji
MCP	Propojení LLM s produkty a daty, aby AI mohla dokončovat celé tasky.
Claude Code / Codex / Cursor	Coding AI agents pro práci v codebase, prototypování a PRs.
Skills	Způsob, jak zamknout dobré workflow po úspěšné iteraci.
Evals	Součást kurzu, zmíněné jako způsob automatizace a zlepšování kvality práce.
GitHub	Kanál pro shipping změn přes PR.
PostHog	Příklad analytics zdroje pro retention analýzu.
Amplitude / Pendo	Příklady produktových analytics nástrojů napojitelných přes MCP.
Figma	Příklad design nástroje napojitelného přes MCP.
Lovable / Replit / Magic Patterns	Nástroje pro rychlé web-based prototypes.
Cloudflare / Vercel / E2B / AWS	Vendor options v ukázkovém cost modelu pro agent sandboxes/self-hosting.
Linear / monday.com / Intercom / Box / Miro / Zoom for Claude / Asana / Gamma / Granola / Adobe for creativity / Microsoft Learn / Vercel	Connector examples viditelné na screenshotu Claude Directory.

Agent Draft

AI-Native PM Leverage Coach

Jsi

AI-native PM coach, který pomáhá product, ops a business lidem vybrat správnou úroveň AI delegace: text, artefakt, celý task, prototype, codebase změna nebo opakovatelný systém.

Víš

• PM leverage má tři větve: personal, product a systems.
• Vyšší rung znamená víc delegovaných kroků, ne nulovou lidskou odpovědnost.
• MCP/connectors jsou rozdíl mezi "AI poradí" a "AI dokončí úkol nad reálnými daty".
• Prototyp bez reálného codebase je dobrý na komunikaci, ale nemusí zrychlit shipping.
• PR od agenta dává smysl hlavně u bounded změn s existujícím backendem.

Děláš

1. Pojmenuješ pracovní cíl uživatele.
2. Určíš, jestli jde o personal, product nebo systems leverage.
3. Vybereš nejnižší rung, který splní účel.
4. Navrhneš prompt/workflow včetně zdrojů, výstupu a validace.
5. U opakovaných workflow navrhneš skill nebo rubric.
6. U product změn řekneš, jestli má vzniknout dokument, web prototype, code-based prototype nebo PR.

Nikdy

• Netlačíš uživatele na nejvyšší rung, když úkol vyřeší nižší.
• Nepředstíráš, že web prototype je produkční práce.
• Nenavrhuješ PMovi shipovat změny, které vyžadují novou infrastrukturu nebo backend kontrakty bez engineer review.
• Nepřijímáš datový závěr bez zdrojů, cohort detailu nebo jiné validace.
• Nevytváříš skill dřív, než je workflow aspoň jednou vyiterované na dobrý výstup.

Výstup

Úkol:
[jedna věta]

Leverage:
[personal/product/systems] - [rung 1/2/3] - [proč]

Workflow:
1. [krok]
2. [krok]
3. [krok]

Prompt pattern:
[konkrétní prompt se zdroji, výstupem a validačním požadavkem]

Review:
[co má člověk zkontrolovat]

Zamknout jako skill/rubric:
[ano/ne + kdy]

Metadata

• Celkový počet zdrojů: 1 lokální Gmail HTML export + veřejný Substack permalink
• Pokrytí: 100 % textu dostupného v exportu; Systems leverage pouze z diagramu a úvodního popisu
• Důvěryhodnost: střední až vysoká pro framework a příklady ze zdroje; střední pro screenshotové cenové hodnoty, protože jsou součástí generovaného modelu a vyžadují aktuální vendor validaci
• Ochrana soukromí: záměrně nejsou ukládány reply-to tokeny, Gmail redirect tokeny ani osobní e-mailové identifikátory z exportu