Executive Onboarding PlaybookSAFE
Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.
Overview
Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.
0b657a54b6d7OBSERVED · 2026-10-07What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
--- name: executive-onboarding-playbook argument-hint: "[role and company context]" description: Plan a VP or CPO 30-60-90 day diagnostic onboarding path. Use when entering a new executive product role and avoiding premature change. intent: >- Structure the first 90 days of a VP or CPO transition as a diagnostic process, not an execution sprint. The single most common failure in senior product leadership transitions is acting before understanding — changing structures, replacing people, or announcing strategy before building the evidence base that makes those decisions defensible. type: workflow theme: career-leadership best_for: - "Starting a new VP or CPO role in the first 90 days" - "Evaluating a CPO offer — what to ask before you accept" - "Diagnosing an organization you've just inherited" scenarios: - "I just accepted a VP of Product role starting next month — help me plan my first 90 days" - "I'm evaluating a CPO offer and want to know what questions to ask the hiring CEO" - "I'm two months into a new role and want to validate what I've learned before I start acting" estimated_time: "20-30 min" --- ## Purpose Structure the first 90 days of a VP or CPO transition as a diagnostic process, not an execution sprint. The single most common failure in senior product leadership transitions is acting before understanding — changing structures, replacing people, or announcing strategy before building the evidence base that makes those decisions defensible. This playbook runs in three phases: **Diagnose** (Month 1), **Validate** (Month 2), **Act with Evidence** (Month 3). Each phase builds on the last. Skipping phases doesn't accelerate results — it guarantees expensive reversals. This is not a 100-day plan for impressing your new boss. It's a diagnostic protocol for making durable decisions. ## Input **Works best with:** The role you're stepping into (VP or CPO) and basic company context — size, stage, how the product org is set up. **Also useful:** How far you are from Day 1 (offer stage, pre-start, week 3), known landmines, and what the CEO says success looks like. Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it covers; don't re-ask. **Arriving empty-handed? That works too.** The playbook opens by asking your start date and company context, then anchors you in the right phase. **Example invocation:** `I start as VP Product at a 300-person Series C in 3 weeks — first product exec hire, founder currently runs product. Build my 30-60-90.` ## Key Concepts ### The Consultant Mindset Enter every new VP/CPO role as if you're an external consultant hired to assess the organization — before you're the person responsible for changing it. What this means in practice: - **Observe before diagnosing.** Don't form opinions in the first week based on first impressions. - **Ask questions before making declarations.** "Help me understand how this works" is more powerful than "here's what we're going to do differently." - **Understand how the steering connects to the rudder.** In any organization, there are systems and relationships that look one way on paper and work completely differently in practice. Map that reality before you touch anything. - **Don't throw the big red switch.** If you walked into a power plant you'd never operated before and saw a large red switch, you probably wouldn't throw it. The same logic applies to org structures, processes, reporting lines, and team compositions you've inherited. Understand what they control first. Negotiate this upfront: tell your boss and peers that Month 1 is explicitly a learning phase. Set the expectation that your first major recommendations will come in Month 2. Executives who've been through transitions will respect this; executives who want action in Week 1 are a signal worth noting. --- ### Unwritten Strategy At VP and CPO level, significant strategy is never fully written down. It lives in: - The CEO's head, shaped by conversations you weren't in - Board meeting dynamics and investor preferences - Last night's executive dinner - Off-the-record conversations between founders - Tribal knowledge that long-tenured leaders treat as obvious This isn't dysfunction — it's how every organization works at the executive level. Treating written strategy as complete strategy will get you into trouble fast. Your job in the first 90 days is to surface the unwritten layer. How: - Ask indirect questions: "What's the history here?" / "How did we end up with this approach?" / "What did we try before that didn't work?" - Let information find you. People who want to shape the new leader's perspective will seek you out. Take those meetings. Take notes. - Reality-check with your boss: "Here's what I'm hearing from the organization. This is different from what you told me. Help me understand." This is not confrontational — it's how you triangulate toward the truth. --- ### The Body of Evidence Every significant decision you make in Month 3 and beyond should rest on a body of evidence collected in Months 1 and 2. This means: - Detailed notes from every diagnostic conversation - Patterns noted across multiple independent sources (not just one vocal person) - Reality-checks completed with your manager and key peers - A clear picture of what's working, what's broken, and why The body of evidence is what separates confident decisions from guesses. It's also what makes hard decisions defensible — to your team, to your peers, and to the board. --- ### People Assessment: Two Categories Two distinct people situations require different responses: **Diamonds in the rough** — Capable, undervalued people who haven't had a champion. They exist in almost every organization. You'll find them in Months 1-2 by listening for: "She's really talented but nobody gives her the hard problems" or noticing who gives
Trust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
0b657a54b6d7full audit observations/trust-audit/skill/deanpeters__executive-onboarding-playbook.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-07 | 0b657a54b6d7 | SAFE | B | 89 | first audit |
Questions
What does the Executive Onboarding Playbook skill do?
Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.
Is Executive Onboarding Playbook safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Executive Onboarding Playbook access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
How current is this page?
The grade is for one exact copy of the source (0b657a54b6d7), read on 2026-10-07. The repository is watched, and a new audit runs when it changes — this is the first audit.