Asaf Nakash | Principal Product Manager, AI Security, Microsoft Defender
Use → to navigate | Press Esc for overview
The right-hand column is the entire job description.
A product manager who has stopped being the producer of artifacts
and become the author of the system that produces them —
and who remains personally accountable for every one.
Prompts are disposable. Systems persist.
Enthusiasm ships unverified work. This is a discipline.
Delegating production never delegates responsibility.
Specs, research, feature state, meeting notes, drafts — plus the configuration that lets agents work on all of it. One year, by commit type:
documents
things built
corrections
The artifact of product management is prose — which is exactly what these models are best at, and exactly where a confident error survives review.
Write the context
down before you
ask for anything.
Narrow scope,
explicit bounds,
evaluable output.
Run a check you
built, not a review
you performed.
Defend it in your
own words, or
you haven't shipped.
It's a loop, not a pipeline. What you learn in Verify goes straight back into Frame.
Chat is a session. Files are an asset. Anything you repeat belongs in version control.
The convention nobody documented is the only input the model can't get anywhere else.
Not "good." Something a stranger could test without you in the room.
The test: could a competent new hire do this from what you just wrote? If not, you're not framing. You're hinting.
Skip this step and you don't get bad output. You get polished wrong output, citing your own notes back to you.
A narrow agent can be evaluated. A general one can only be liked.
Always Ask first Never. The middle tier does the work.
Let it fetch what it needs. Smaller instructions, better output.
To change behaviour, edit the file — never re-explain yourself in chat.
Delegation is a hiring problem, not a prompting one.
"Review this" returns a tidy list. "Write the check that would catch this" returns the bug.
If you can't link to it, it doesn't ship. Enforce this in the agent, not in your head.
Ask what it couldn't verify, and reward the flag. The unflagged guess is the expensive one.
Most bad output is a correct answer to a question you didn't mean to ask.
If you can't explain why in your own words, you haven't decided. You've forwarded.
Because eventually one does. Write for the reader you didn't plan for.
Not every comment is technical. Some are positions. Some mean "you didn't ask me."
I work in AI security, so I'll say the quiet part: the context window is an attack surface. Never put a credential in a conversation — you cannot un-say it.
You can safely delegate exactly as much as you can check.
Past that line you are not managing. You are hoping.
Not a metaphor — a hard limit. It caps how much leverage you can take from an agent, and it is independent of how good the agent is.
Most teams delegate past it, ship anyway, and call the gap velocity.
Build the checks. Evals, harnesses, sourcing rules, acceptance criteria you can actually run. This is PM work now, not an engineering chore.
Hand over less until you can check more. Unglamorous, unpopular, and correct.
Success is not "used AI more." It is raised the ceiling faster than you raised the delegation.
Which turns out to be writing for a new hire. Practise by handing your brief to someone with no context and watching what breaks.
Splitting a job into roles narrow enough to judge. Same muscle as writing a good job description, and it fails the same way.
The genuinely new skill, and the one PMs keep outsourcing. If you learn one thing here, learn this.
Staying suspicious of output that sounds certain. Taste stopped being a soft skill the moment ten plausible options became free.
pm-command/ ├── AGENTS.md conventions — how work is done ├── CONTEXT.md memory — read every session ├── .github/agents/ one file per agent │ ├── spec-writer.md │ ├── compete-research.md │ └── meeting-prep.md └── docs/ ├── features/<slug>/ durable feature state ├── research/ one file per vendor └── specs/ specs + review responses
No database, no platform, no subscription. Version-controlled context was the single highest-leverage thing I did.
Answers: how is work done here? Written once, read by every agent, every session.
# PM Command Center ## Identity - Owner: <name> — <role, and the 3 things you actually own> ## Where things live - Feature state → docs/features/<slug>/README.md - Vendor research → docs/research/<vendor>.md - Specs + reviews → docs/specs/ ## House style - Narrative prose. No emoji, no bullet pyramids. - Verify before speed. Never publish an unverified claim. - Surgical changes only — don't refactor what I didn't ask about.
Answers: what's going on right now? Memory as a file you can edit — not a feature you have to trust.
# Read this at the start of every session. ## Active work 1. <feature> — status, current blocker, next decision owed 2. <feature> — status, current blocker, next decision owed ## Decisions already made (so nobody re-litigates them) - Chose X over Y because <reason>. Revisit if <condition>. ## Learnings (the expensive ones) - HTTP 403 ≠ broken link — some sites block bots, not humans. - First drafts are structurally right and tonally dead. Feed it things I actually sent, and the voice problem goes away.
Note how much of it is prohibition. That's the part that makes output trustworthy.
--- name: compete-research description: Maintains the vendor landscape. Use for market questions. tools: [read, write, fetch, search] --- You maintain one file per vendor in docs/research/. ## Rules - Every claim needs a published, linkable source. - No source → the claim does not ship. Say so explicitly. - Rate maturity on evidence, never on marketing language. ## Never - Speculate about unannounced products. - Infer someone's current role from an old article. # cost me once
Cite sources. Keep changes surgical. State assumptions. Run the build before claiming done.
New dependencies. Schema changes. Anything that touches another team. Anything irreversible.
Commit secrets. Publish unverified claims. Speculate about unshipped work.
Most people write two tiers. The middle one is where all the value is — it's how an agent moves fast on the safe 90% without quietly deciding the other 10% for you.
Pasting the whole spec, the whole style guide and the whole history into every prompt. Feels thorough. Buries the actual instruction and goes stale the moment the source changes.
See docs/specs/current.md for scope
and open questions.
Shorter instructions, better output, and it's never out of date.
Your instructions should read like a map, not a briefing pack.
A table in AGENTS.md mapping how I actually talk to which agent should answer.
| What I say | Who handles it | |-----------------------------|------------------| | "status of <feature>" | feature-copilot | | "prep me for the review" | meeting-prep | | "update <vendor>" | compete-research | | "draft the follow-up" | email-drafter | | "recap this week" | weekly-recap | | "spec for <thing>" | spec-writer | | "what are customers saying" | feedback-analyzer|
Ten job descriptions, not one assistant. Narrow enough to evaluate is the only design rule that matters.
Custom scrapers, bespoke integrations, hand-built tools. Most were genuinely useful when I built them. Most were dead weight within two months — not because they were badly made, but because the models improved past the need for them.
Re-read your own config every couple of months and delete what the model now does natively. Tooling that once added capability starts quietly constraining it.
My repo was literally called vibecoding before it became a command center. That rename is the honest summary of the year.
Everything above is about how a PM works. This is about what a PM now ships. It is the bigger shift.
If your product, your docs and your positioning are only legible to humans, you are invisible to the reader who arrives first.
Not support material. They are the API an agent uses to understand you. Stable URLs, plain text, no content locked in a diagram.
A human infers your positioning from tone. An agent quotes whatever sentence you actually wrote. Write the sentence.
Every human affordance needs a machine one: a UI needs an API, a doc site needs plain markdown, a deck needs a file.
"Accessible" used to mean readable by every human. It now includes the software they sent instead.
The slides are for you. These are for the thing you delegate to. Same content, one fetch, no scraping.
Read https://nakashon.github.io/the-agentic-pm/llms-full.txt
and set up a PM command center for me in this repo.
Interview me for what you need. Don't guess my context.
Show me the files before you write them.
It will ask you what you own, what you ask for most, and what must never ship. Those answers were always the hard part.
Create two files: AGENTS.md and CONTEXT.md. Put them in git. That's the whole day-one setup.
Take the two things you ask for most often. Make each one a narrow agent with an always / ask first / never block.
Build one real check you can run. Then delete one tool you built that the model no longer needs.
None of this requires a platform, a budget, or permission. It's four markdown files and a habit.
You can hand over exactly as much as you can check. Build checks, or hand over less. There is no third option.
Frame, Delegate, Verify, Own. Every failure I've had was a step I skipped — and I could name which one afterwards, every time.
Context in version control is the difference between a clever session and a system that compounds.
That's a better job. It is not a lighter one.
Asaf Nakash | nakashon.com | LinkedIn | X | GitHub