AI produkt má stavět na kontextu, ověřené hodnotě a viditelné agentní práci

Analyzováno: 1 dokument / 1070 slov

Executive Summary

  • Obrana proti kopírování nemá stát na izolované funkci, ale na širším budoucím job to be done a na několika úlohách, ve kterých produkt dosáhne výrazně lepší kvality.
  • Nové AI funkce mají nejprve potvrdit uživatelskou hodnotu v malém měřítku; až potom přichází práce na architektuře, spolehlivosti a škálování.
  • Samotný model nestačí: použitelný výstup vyžaduje relevantní kontext, strukturu, odpovídající pracovní prostředí a viditelné důsledky agentních akcí v UI.

Core Knowledge

  • Job to be done označuje širší pracovní potřebu, kterou má produkt řešit i po proměně spolupráce lidí a AI, nikoli jen aktuální produktovou kategorii.
  • Produkt může zpřístupnit svůj kontext jiným agentům přes API nebo MCP a přitom si zachovat vlastní fokus na specifických use casech.
  • Přístup „pirát a architekt“ rozděluje vývoj do dvou etap: pirát rychle hledá hodnotu bez předčasného zdokonalování architektury, architekt po jejím potvrzení stanoví strukturální pilíře, invarianty a cestu k udržitelnému provozu.
  • Workflow pro novou funkci začíná pojmenováním uživatelské potřeby, pokračuje průzkumem více variant a malou validací s uživateli; potvrzené řešení se následně převádí do spolehlivé a škálovatelné podoby.
  • Agentní práce má dva režimy: sdílený kanál pro veřejné asynchronní delegování a týmovou diskusi, a společnou pracovní plochu pro hlubší spolupráci člověka s agentem nad stejným stavem.
  • Slack je ve zdroji příkladem sdíleného kanálu pro stavové přehledy, delegování a průběžnou týmovou komunikaci.
  • Codex a Claude desktop app jsou ve zdroji uvedeny jako prostředí pro soustředěnou spolupráci člověka a agenta nad společnou věcí.
  • Agent nemá zůstávat odděleným vykonavatelem API volání: akce přes CLI nebo MCP mají měnit stav rozhraní sledovaného uživatelem.
  • Proof ilustruje tento vzorec tím, že agent může v editoru ukázat svou přítomnost a pozici v dokumentu.
  • Kontext dává flexibilnímu modelu konkrétní pracovní tvar; u meetingového obsahu to znamená pracovat vedle transkriptu také s identitou osob, rozhodnutími, akcemi, nuancemi a průběhem interakce.
  • Pokud uživatel nebude v rozhodujícím okamžiku čekat, má být výstup předgenerovaný s relevantním kontextem.
  • Pre-meeting brief je příkladem výstupu připraveného před schůzkou z kontextu účastníka a předchozích rozhovorů.
  • Nízká frekvence použití sama o sobě neurčuje malou hodnotu podpůrné funkce, protože její přínos může nastat právě v kritickém okamžiku.
  • Pokročilá workflow uživatelů nad API nebo MCP jsou vstupem pro produktové objevování: opakovaný postup s širším přínosem lze převést do jednodušší nativní zkušenosti.
  • Zdroj uvádí, že pre-meeting brief nejprve vznikl jako komplexní workflow v Claude Code a později byl nahrazen jednodušší funkcí produktu.
  • Anti-patterny zahrnují obranu jedné současné funkce, škálování před validací, oddělenou práci agenta mimo UI, práci jen nad transkriptem a produktizaci každého individuálního experimentu.

Decision Rules

  • IF konkurence kopíruje současnou funkci, THEN formuluj širší budoucí job to be done a vymez několik úloh, v nichž může být produkt výrazně lepší.
  • IF hodnota řešení nebyla potvrzena uživateli, THEN neupřednostňuj investici do dokonalé architektury, spolehlivosti ani škálování.
  • IF navrhuješ novou funkci, THEN postupuj od job to be done přes více variant a malou validaci k produkčnímu provedení.
  • IF je úkol veřejný, asynchronní a týmově diskutovatelný, THEN použij sdílený kanál se stavovými přehledy.
  • IF úkol vyžaduje hlubokou spolupráci člověka a agenta, THEN použij společnou pracovní plochu nad jedním stavem.
  • IF agent pracuje přes CLI nebo MCP, THEN promítni jeho akce do stavu UI, který uživatel sleduje.
  • IF je výstup potřebný v krátkém časovém okně, THEN zvaž jeho přípravu předem.
  • IF AI zpracovává významově bohatý obsah, například meeting, THEN doplň disambiguaci, relevantní kontext, rozhodnutí, akce a stav pracovního prostředí.
  • IF pokročilí uživatelé opakují podobné workflow nad API nebo MCP, THEN posuzuj nativní produktizaci jen u postupů s širším přínosem a návazností na silnou oblast produktu.

Quality Criteria

  • Checklist: Je pojmenován širší job to be done, nikoli jen současná funkce?
  • Checklist: Proběhla malá uživatelská validace před investicí do škálování?
  • Checklist: Odpovídá zvolený pracovní prostor režimu práce, tedy asynchronnímu delegování nebo hluboké spolupráci?
  • Checklist: Jsou důsledky agentních akcí přímo viditelné ve stavu UI?
  • Checklist: Pracuje řešení s relevantním kontextem, disambiguací, rozhodnutími a akcemi, nejen se surovým transkriptem?
  • Checklist: Je časově kritický výstup dostupný v okamžiku potřeby?
  • Checklist: Má produktizované workflow širší přínos a vazbu na oblast, kde může produkt vyniknout?
  • Red flag: Strategie reaguje jen na kopírování jedné dnešní funkce.
  • Red flag: Tým řeší architekturu a škálování dříve, než ověří, zda si uživatelé řešení zvolí.
  • Red flag: Uživatel nevidí, kde agent pracuje ani jak se jeho práce promítla do rozhraní.
  • Red flag: Výstup vzniká až po vzniku potřeby, přestože uživatel nebude ochoten čekat.
  • Benchmark: Dobrá funkce má konkrétní job to be done, prověřené varianty a po potvrzení hodnoty spolehlivou nativní realizaci; slabá funkce se škáluje nebo architektonicky zdokonaluje bez ověřené volby uživatelů.
  • Benchmark: Dobré agentní rozhraní ukazuje přítomnost či pozici agenta ve společném UI; slabé rozhraní nechává agenta pouze odděleně volat API.

Edge Cases

  • Zřídka používaná podpůrná funkce může být hodnotná, pokud pomáhá v kritickém okamžiku; její hodnocení proto nemá stát jen na četnosti použití.
  • Otevření produktového kontextu jiným agentům nevyžaduje soutěžit ve všech možných úlohách; workaroundem je udržet fokus na několika specifických use casech.
  • Komplexní workflow jednoho pokročilého uživatele nemusí být vhodné pro nativní funkci; produktizovat se mají opakované postupy se širší hodnotou.
  • Jeden typ rozhraní nemusí dobře pokrýt asynchronní delegování i hlubokou spolupráci; řešením je rozdělit tyto režimy mezi sdílený kanál a společnou plochu.
  • Rychlý růst týmu přináší nové organizační problémy a tlak na konzistenci produktu; zdroj nevymezuje konkrétní organizační workaround.

Metadata

  • Celkový počet zdrojů: 1
  • Pokrytí: 95 %
  • Důvěryhodnost: vysoká - zdroj je obsahově soustředěný a uvádí explicitní principy, postupy i příklady; závěry jsou omezené na vlastní tvrzení zdroje, protože neobsahuje externě ověřitelné podklady ani podrobné metriky.
  • Zdroj 1: Granola's Chris Pedregal on Building a $1.5B AI Company