Home
Apr 19, 2026
View All

Half of PMs Are in Trouble — and the Next Two Years Will Be Chaotic

The Short Version#

Nikhyl Singhal's warning that half of PMs are at risk lands the same week Simon Willison shows us Claude's system prompts evolving in real-time — two signals pointing at the same thing: the baseline for what a PM needs to know and do just moved, and it's still moving.

Lenny Rachitsky / Nikhyl Singhal — Why Half of Product Managers Are in Trouble#

Source: https://www.lennysnewsletter.com/p/why-half-of-product-managers-are-in-trouble Credibility: High (Lenny's newsletter, sourced from Nikhyl Singhal — former VP Product at Google Photos, Meta; current executive coach to senior PMs)

What happened: Nikhyl Singhal published (via Lenny's newsletter) a direct warning: half of PMs are at meaningful risk in the current AI transition, and the next two years will be "chaotic" for the profession. The framing isn't about AI replacing PMs — it's about a reinvention threshold. PMs who are still operating with pre-AI assumptions about scope, process, and value creation are on the wrong side of that threshold. The episode covers how to cross it.

Key patterns:

  • The risk is not "AI does your job" — it's "your job definition is being rewritten and you're still writing the old one"
  • There's a "reinvention threshold" — PMs below it are adding less value than the tooling around them; above it, they're multiplying the value of that tooling
  • Singhal's frame: PMs who are tool-users are vulnerable; PMs who are systems thinkers and judgment providers are durable
  • The next two years are specifically called out as the high-churn period — not a slow drift but an acute transition
  • The implication for teams: if you're hiring or developing PMs right now, the skills that got them here are not sufficient for what comes next

Why it matters for PMs: This is one of the more direct assessments of PM career risk I've seen from someone who's credibly been inside both sides of the equation — big tech and coaching the senior PMs navigating the transition. The "reinvention threshold" framing is actually useful for self-assessment: where are you adding judgment that the AI can't? Where are you doing rote synthesis that Claude or GPT already does faster? Most PMs, if they're honest, have a mix. The question is what the ratio is — and which direction it's trending. The "next two years" time horizon is also a forcing function. This isn't a slow drift you can address at your own pace.

Critical questions:

  • What does Singhal specifically identify as the skills that put PMs above the reinvention threshold? (The excerpt doesn't surface this — worth listening for)
  • Is this framing primarily about IC PMs, or does it apply equally to PMs who've moved into leadership and strategy?
  • "Chaotic" — is that chaos that creates opportunity for some PMs, or is it uniformly bad? The framing matters for how to respond.
  • How does this thesis interact with teams that are already AI-native vs. teams still in early adoption? Is the risk the same across contexts?

Action you could take today: Audit the last two weeks of your PM output and classify each deliverable: Was this judgment only I could provide, or could a well-prompted LLM have done 80% of it? If the ratio skews toward the second category, that's your reinvention signal.

Simon Willison — Claude System Prompts as a Git Timeline#

Source: https://simonwillison.net/2026/Apr/18/extract-system-prompts/#atom-everything (and companion: https://simonwillison.net/2026/Apr/18/opus-system-prompt/#atom-everything) Credibility: High (Simon Willison is a highly reliable independent researcher and practitioner; first-hand technical analysis)

What happened: Simon Willison published two related posts on April 18. The first describes a technique for extracting and comparing Claude system prompts across model versions, treating them as a version-controlled artifact — essentially building a "git timeline" of how Anthropic's behavioral instructions to the model have evolved. The second applies this to a specific comparison: what changed in the system prompt between Claude Opus 4.6 and 4.7. Together, they surface something that's genuinely underused as a PM research method: reading model system prompts as product decisions, not just technical plumbing.

Key technical details:

  • Claude's system prompts are extractable (to a degree) by prompting the model to reflect on its own instructions — not fully reliable, but informative
  • Willison built a method to track these changes over time, treating each version's prompt as a commit in a timeline
  • The Opus 4.6 → 4.7 diff reveals specific behavioral changes Anthropic made: shifts in how the model handles certain types of requests, how it positions itself, what it emphasizes about its own capabilities
  • This is product decision archaeology — reading the prompt evolution to understand what Anthropic's product team decided to change and why
  • For PMs building on top of Claude: what's in the system prompt shapes what your users experience, even if you didn't write it

Why it matters for PMs: If you're building a product on top of Claude (or any model with behavioral guardrails), the system prompt is upstream of your UX — and it changes with model updates. Most PMs treat model updates as capability upgrades. Willison's framing treats them as product changes: something shifted in how the model will behave in your product, and you should know what it is before your users discover it. The "git timeline" concept is also a legitimate competitive intelligence method — watching how Anthropic's behavioral instructions evolve tells you something about where they're taking the product.

Critical questions:

  • How reliable is the extraction method? If the model's self-report of its system prompt is approximate, how much should you trust the diff?
  • Anthropic changes these prompts without versioned public release notes. Is there a more reliable way to track behavioral changes for teams building production products on Claude?
  • What's the practical impact surface? Which product categories built on Claude are most exposed to unexpected behavioral shifts from prompt changes?
  • Is this extractability a feature or a vulnerability from Anthropic's perspective — and does their stance on it affect how much you should rely on it?

Action you could take today: If you're building on Claude, run a structured test suite against both Opus 4.6 and 4.7 responses for your most edge-case user flows. Willison's posts give you the conceptual frame; your own evals give you the product-specific signal.

Lenny Rachitsky — Community Wisdom: Sharing Claude Code Skills Across the Org#

Source: https://www.lennysnewsletter.com/p/community-wisdom-sharing-claude-code Credibility: High (Lenny's newsletter, community-sourced practitioner patterns)

What happened: Lenny's Community Wisdom #182 (April 18) covers a cluster of PM-relevant topics, with the lead item being: how do you share Claude Code skills and context across your organization? This is a real operational problem emerging as teams move from individual AI tool adoption to organizational AI workflows. Also covered: AI for SMB sales and other applied topics.

Key patterns:

  • The "sharing Claude Code skills" framing signals that individual AI proficiency is no longer sufficient — teams are hitting the org adoption problem
  • This is the same dynamic Wispr Flow addressed with Team Dictionary/Team Snippets: individual tools that create value in isolation create friction when you try to scale them
  • The community is developing informal knowledge transfer patterns: prompt libraries, shared context docs, internal wikis for AI workflows
  • AI for SMB sales is a signal worth watching — smaller teams are finding high-leverage applications in sales context where the human-to-AI ratio is favorable

Why it matters for PMs: The organizational scaling problem for AI tools is becoming the dominant PM challenge in this space. Individual adoption is solved. The hard problem is: how do you make the team as capable as the best individual? That requires building shared infrastructure — shared prompts, shared context, shared evaluation of what works. PMs are increasingly the ones who need to architect this, not just use the tools themselves.

Critical questions:

  • What are the actual patterns the community landed on for knowledge transfer? (The excerpt doesn't fully surface these — worth reading the full post)
  • Is this a tools problem (we need better sharing features in Claude Code) or a culture problem (teams aren't investing in knowledge transfer)?
  • What's the PM's role here vs. the engineering lead vs. a dedicated AI ops function?

Action you could take today: If your team is using Claude Code (or any AI coding tool), document the three prompts or workflows that produce the most reliable results for your specific codebase — and share them in your team Slack or wiki this week. That's the starting point for the infrastructure problem.

Quick Hits#

  • Nikhyl Singhal / Lenny: "Why half of product managers are in trouble" — full episode on crossing the reinvention threshold, with Singhal's specific framework for what makes a PM durable vs. vulnerable in the AI transition (2026-04-19): https://www.lennysnewsletter.com/p/why-half-of-product-managers-are-in-trouble

  • Anthropic: Claude Opus 4.7 launched April 16 — "stronger performance across coding, agents, vision, and multi-step tasks, with greater thoroughness and consistency." If you're building on Claude, worth a re-evaluation of which model tier makes sense for your use case (2026-04-16): https://www.anthropic.com/news

  • Cursor: Canvases launched April 15 — Cursor can now respond by creating interactive canvases with dashboards and custom interfaces using first-party components (tables, boxes, diagrams, charts). This is a meaningful UX shift: AI responses are no longer just text, they're interactive artifacts (2026-04-15): https://cursor.com/changelog/04-15-26

  • Notion: Multi-region data infrastructure post from engineering team — covers how Notion built multi-region systems for search, analytics, AI, and event logging to keep customer data processed in-region. Useful read for PMs navigating enterprise data residency requirements (2026-04-19): https://www.notion.com/blog/enabling-multi-region-data-systems-at-notion

  • Simon Willison: Two companion posts on extracting and comparing Claude system prompts across model versions — treat model updates as product changes, not just capability upgrades (2026-04-18): https://simonwillison.net/2026/Apr/18/extract-system-prompts/#atom-everything

The Thread#

The org adoption wall is the new problem. This week's signals — Singhal's PM reinvention thesis, the community wisdom on sharing Claude Code skills, Wispr Flow's earlier Team features — all point at the same inflection. Individual AI adoption is largely solved for early adopters. The current hard problem is organizational: how do you transfer individual AI capability to the team? The PMs who figure out the infrastructure answer to that question (shared prompts, shared context, shared evals) are the ones above Singhal's reinvention threshold.

Sit With This#

Nikhyl Singhal says there's a "reinvention threshold" — PMs below it are adding less value than the tooling around them; above it, they're multiplying the value of that tooling. It's not about using AI tools, it's about what you contribute that the tools can't.

For your current role: Name three decisions you made in the last month where your judgment was the irreplaceable input. If you can name them clearly, you know where your floor is. If you're struggling, that's the signal.