Leadership

• Talent identification method: continuously expand an employee's scope of responsibility until they hit their ceiling -- the level just before it breaks is their optimal role (from talent identification rabois)
• Use "desk traffic" as a signal for hidden leaders -- if many people go to someone's desk for help, that person should be promoted and given more responsibility quickly (from talent identification rabois)
• Test people with small, unsolved operational problems before giving them high-stakes work -- success on unglamorous tasks predicts success on consequential ones (from talent identification rabois)
• People with non-traditional backgrounds can handle enormously complex tasks -- filter talent by demonstrated capability under expanding scope, not by pedigree (from talent identification rabois)

AI-Augmented Executive Leadership

• A CEO (Ada) reports Claude Code as AI Chief of Staff roughly doubles productivity by unifying 6+ inboxes, managing overnight todo lists, and enriching contact records from meeting transcripts (from ceo ai chief of staff claude code)

• The "AI Chief of Staff" framing positions Claude Code not as a developer tool but as an executive productivity layer, with the agent pushing back on decisions and aligning time to goals (from ceo ai chief of staff claude code)

• The "multiplayer todo list that works overnight" pattern represents a new category of async agent work -- the AI processes the queue while the human sleeps (from ceo ai chief of staff claude code)

• AI compresses a comprehensive Friday review from hours to ~12 minutes, removing the time barrier that causes leaders to skip the practice -- the obstacle was never understanding its value, it was the "I'll find a couple hours over the weekend" procrastination cycle (from ai automated friday review workflow)

• A 5-minute AI prep routine before 1:1s replaces agenda-glancing and hoping for useful conversations, making management meetings structured and intentional rather than improvised (from ai prep one on one meetings)

• Lux sharing a full quarterly LP letter reinforces investor letters as a leadership artifact: they communicate portfolio performance, market worldview, and trust-building narrative to limited partners, not just numbers (from lux capital q1 2026 lp letter)

Institutional Knowledge as a Leadership Asset

• New hires take 6-7 months to feel settled and 47% of companies cite institutional knowledge loss as their top offboarding challenge, costing 8+ hours of productive time weekly from context questions -- quantifying the leadership cost of un-captured team knowledge (from team os knowledge sharing architecture)
• Hannah Stulberg (DoorDash) built a shared repo where teams check in customer call summaries, decision logs, and analytics queries, enabling natural-language queries that return full reasoning in 15 seconds without pulling a human off their work (from team os knowledge sharing architecture)
• Four independent implementations (DoorDash, Pendo, Google, solo builders) converged on the same three-layer architecture for team knowledge systems -- a sign the pattern is structurally robust, not idiosyncratic (from team os knowledge sharing architecture)
• A one-command skill converts a personal PM operating system into a team OS without leaking personal context -- turning individual productivity gains into team-wide compounding benefits (from team os knowledge sharing architecture)

Ownership Culture

• Product managers at Rippling fix their own copy errors rather than relying on separate teams -- ownership model reduces coordination overhead (from real time customer issue tracking at rippling)

Evolving Org Structures

• AI-native companies are replacing the traditional PM role with a "product builder" archetype that combines product, design, and engineering skills into a single IC role (from cpo role vanishing)
• The standalone CPO role creates coordination tax and cognitive dissonance when the IC roles underneath it are already blending -- a separate product leader becomes overhead rather than leverage (from cpo role vanishing)
• Career implication for PMs: stop specializing in product management alone; instead develop fluency across product, design, engineering, and analytics to become a full-stack product builder (from cpo role vanishing)
• AI-native companies will set the cultural tone for the next generation of tech, meaning their org structures will propagate even to non-AI companies within 5 years (from cpo role vanishing)

AI Governance

• Agent governance should follow constitutional design: AI systems with distinct invested values (transparency, equity, due process) checking and balancing other AI systems, because no single concentration of intelligence should regulate itself (from agentic ai intelligence explosion)
• The SEC example illustrates the governance gap: hiring business school graduates with Excel to combat AI-augmented trading platforms is structurally inadequate — governments need AI-powered oversight to match AI-powered actors (from agentic ai intelligence explosion)

AI-Native Organization Design

• Dorsey's four-layer AI-native org: Capabilities (hardware/models), World Model (company's living memory as unified vector DB), Intelligence Layer (agent fleet making decisions), Surfaces (where humans interact) — any company can map this to their own structure (from shared link without context)

• The DRI (Directly Responsible Individual) system from Dorsey applied to agent teams: spin up temporary teams around specific goals with 90-day deadlines, agents return to pool when done, learnings (including from failures) absorbed into the organizational brain (from shared link without context)

• Agency/consulting new model: internal AI implementation becomes the product — months of compounded data and operational learnings become the differentiation; clients buy the fact that you already made the mistakes and know what works (from shared link without context)

Defensibility and Moats

• Five moats that survive AI: compounding proprietary data (living, not static), network effects, regulatory permission, capital at scale ($20B chip fabs, $10B nuclear plants), and physical infrastructure — all bottlenecked by time that can't be parallelized (from tweet link only michael bloch)

• Capital at scale is the moat almost everyone underweights — when the bottleneck shifts from software to atoms, the ability to finance and deploy at massive scale (plus the institutional trust and track record it requires) becomes defining (from tweet link only michael bloch)

• Open question: does trust become its own moat when AI does more work? Someone must be accountable when things go wrong, and the institution bearing that liability might become MORE valuable, not less (from tweet link only michael bloch)

Executive Onboarding

• Marek Siliski's clipboard trick (now widely shared as @msiliski's pattern at Stripe): printed photos of every team member with note space per person — explicit face-to-name memory tooling let him ramp faster than any new exec the team had seen, in a complex space (from executive onboarding name memory system)

• The general principle: structured, physical name/face memory systems beat generic onboarding because they convert relationship-building into a deliberate practice with checkpoints, not a passive byproduct of meetings (from executive onboarding name memory system)

Decision-Making Techniques

• The premortem prompt (Kahneman's most-valued decision technique, used by Google, Goldman Sachs, P&G) turned into a Claude pattern: "it's 6 months from now and this is already dead — tell me how it died"; flips Claude's training-induced optimism off because the premise already says it failed (from claude premortem technique decision making)

• A proper premortem returns four things: which failure is most likely, which is most dangerous, the single biggest hidden assumption (often the most valuable output), and a revised plan with the gaps closed — counters confirmation bias on high-stakes decisions (from claude premortem technique decision making)

decision-frameworks

• To finalize a decision memo, run two independent analyses: top-down (general principles to specifics) and bottom-up (specific evidence to broader conclusions), then compare both on a single page rather than merging them prematurely. (from structure problem pm decision skill)
• Where top-down and bottom-up analyses align, that forms the basis of the directive; where they diverge, document the discrepancy rather than resolving it prematurely — the disagreement itself is useful information. (from structure problem pm decision skill)
• A decision statement must specify the actual choice, who approves it, and the deadline — e.g. 'Should we switch to per-seat pricing before renewal season, and who approves?' — not just a subject like 'Pricing.' (from structure problem pm decision skill)
• This method extends the Pyramid Principle (answer-first) by requiring the two independent analyses (top-down/bottom-up) and their comparison as prerequisite steps — without that work, stating the conclusion first risks presenting a predetermined outcome without real investigation. (from structure problem pm decision skill)
• The hardest part of this process isn't the structure — it's the subjective judgment call of deciding which findings count as consistent vs. contradictory; that judgment belongs to the person, not the process, and most PMs already have this skill but lack a format to articulate it. (from structure problem pm decision skill)

problem framing

• Product/business problems often fail because teams never agree which question they're answering—cause, plan, or solution get conflated into one discussion, causing missed facts or weak decisions. (from mckinsey issue tree pm skill)

• Product/business problems often fail early because teams never agree on what problem they're solving — a single ambiguous question can make people simultaneously think about cause, plan, and solution, leading to mismatched answers and weak decisions. (from mckinsey issue tree pm skill)

• Three distinct problem-tree types serve different jobs: Why-tree (root: why is X happening; leaves: candidate causes; output: testable hypotheses), What-tree (root: what work does a deliverable require; leaves: analyses/decisions/commitments/artifacts; output: sequenced workplan), How-tree (root: how might we reach a goal; leaves: concrete actions; output: ranked options). (from mckinsey issue tree pm skill)

• Choose tree type by what answer is needed: Why-tree when cause is unknown, What-tree when you need to produce a plan, How-tree when the cause is already known and you need options — mixing these up is a common failure mode. (from mckinsey issue tree pm skill)

• All three tree types share one structural rule: MECE (branches shouldn't overlap, and together should cover all important areas). This check reveals gaps and redundancies but cannot prove the tree's content is actually true. (from mckinsey issue tree pm skill)

issue-tree types

• Why-tree: root asks why something is happening, leaves list candidate causes, output is a set of testable hypotheses. Use when the team knows the symptom but not the cause. (from mckinsey issue tree pm skill)
• What-tree: root asks what work a deliverable requires, leaves list analyses/decisions/commitments/artifacts, output is a sequenced workplan in correct order. (from mckinsey issue tree pm skill)
• How-tree: root asks how to reach a chosen goal, leaves list concrete actions, output is a set of ranked options. Use only once the cause is already confirmed. (from mckinsey issue tree pm skill)
• All three tree types share one structural check: MECE (branches must not overlap, must cover all important areas at each level). This check validates structure, not truth—it can't prove the tree's content is correct. (from mckinsey issue tree pm skill)

ai-assisted problem solving

• Recommended workflow: talk through problem context with AI, have it draft branches and build the tree, run MECE checks, then review by hand for one missing branch and one duplicate branch before trusting the tree. (from mckinsey issue tree pm skill)

pm tooling

• Design principle for scaling repeatable analysis methods: each PM keeps their own product context while the team shares workflows/review standards, so AI outputs stay grounded in real product constraints rather than generic advice. (from mckinsey issue tree pm skill)

question-selection

• Teams often solve the wrong problem not from bad tools but from skipping question-selection: issue trees and causal maps can look rigorous while addressing a need that doesn't exist, because choosing the right question happens before those tools are applied. (from good question brainstormer pm questioning)
• Go-wider technique: before diverging, state the decision motivating the work, the audience for the question, and what answer would actually change the team's next action — then generate questions via Why (causes/assumptions/beneficiaries), What-if (alternative scenarios like 1/10 budget or product disappearing), and How (reframe as experiment/discussion) lanes. (from good question brainstormer pm questioning)
• Three supplementary inquiry modes prevent narrow framing: contextual inquiry (observe to verify framing is accurate), appreciative inquiry (focus on what's already worked), and the eigenquestion approach (find the fundamental principle governing the whole category of decisions, not just this instance). (from good question brainstormer pm questioning)
• Warren Berger's research finding: people typically stop generating questions around 25; the most valuable questions tend to emerge after that threshold, so pushing past the obvious ones creates space for unusual, insightful inquiries. (from good question brainstormer pm questioning)
• Berger's open-and-close rewrite technique: convert closed questions to open ones ('Should we launch?' → 'What conditions would make launching now correct?'), narrow broad questions with specificity ('How do we grow?' → 'Which customer segment would be most impacted if we ceased to exist tomorrow?'), and add ownership/time horizon to vague ones. (from good question brainstormer pm questioning)
• Berger's formula: questioning + action = innovation; questioning − action = philosophy. A good-question exercise is incomplete without a required concrete output: a primary question, its justification, and a next step (observe, talk, prototype, or experiment). (from good question brainstormer pm questioning)
• Recurring roadmap debates (build vs. buy, quality vs. speed, segment focus) often signal an unstated, recurring principle rather than a one-off decision — applying the eigenquestion approach to name that principle can resolve repeated arguments permanently. (from good question brainstormer pm questioning)

human-factors-in-ai-adoption

• Most employees stall on AI adoption not from lack of access but lack of imagination and product-management skill: adopting AI requires rebuilding workflows from first principles and breaking muscle memory, not just asking 'can AI do X'. (from ai adoption stalls human systems)
• The 'trough of disillusionment' for AI adoption often manifests as teams getting stuck writing docs/code/daily-briefing use cases rather than reimagining the underlying workflow. (from ai adoption stalls human systems)

organizational-change-management

• Leaders rarely block AI adoption for technical reasons; the real blocker is unwillingness to manage change ('I know we need to change but...' followed by fears of attrition, data leaks, token costs, bad code, quality drops). (from ai adoption stalls human systems)
• Whether an org successfully adopts AI often reduces to whether a small group (~5 people) at the top is willing to jointly commit to and absorb the change-management cost — a coordination/willpower bottleneck rather than a tooling one. (from ai adoption stalls human systems)

prompt design

• Effective prompt pattern for high-context analytical requests: explicitly instruct the model to avoid filler ('never fill space for the sake of it... every graphic and word should matter') and let it choose freely between text and charts/visuals based on need. (from gpt astra full context planning)