Home
May 12, 2026
View All

The 'Product Builder Myth' and What Non-PMs Shipping to Prod Really Means

·1 underrepresented voice

The Short Version#

Teresa Torres is pushing back on the "product builder" framing at exactly the moment when non-PMs shipping directly to production is becoming a real organizational pressure — and the two signals together tell you something worth sitting with.

Teresa Torres — The "Product Builder Myth"#

Source: https://www.producttalk.org/product-builder-myth-all-things-product-podcast-with-teresa-torres-petra-wille/ Credibility: High (first-party post from Teresa Torres's own blog, part of an ongoing podcast series with Petra Wille)

What happened: Teresa Torres and Petra Wille released a new episode of the All Things Product Podcast on May 12 arguing against the "product builder" identity — the idea that PMs should define themselves primarily by their ability to build and ship. The episode is framed as a direct challenge to a prevailing narrative in the current AI-accelerated product development environment, where the lines between PMs, engineers, and founders building with AI tools are increasingly blurred.

Key PM craft patterns:

  • The "product builder" framing conflates execution capability with product thinking — Torres and Wille's longstanding argument is that PMs who over-index on building lose the discovery and judgment muscles that make product work distinct
  • In an AI context, this tension sharpens: if anyone can ship with vibe coding tools, "shipping" is no longer a differentiator for PMs — so what is?
  • The episode appears to make the case that the PM's irreplaceable value is in the thinking before the build: continuous discovery, outcome orientation, connecting user needs to business goals
  • This is a direct counter-narrative to the "everyone is a builder now" framing that's been dominant in AI-assisted dev discourse

Why it matters for PMs: Teresa Torres has been one of the most consistent voices on PM craft for years. The timing of this episode is pointed — it lands during a week when Lenny's community is actively discussing what happens when non-PMs start shipping directly to production (see Community Wisdom 185 below). The implication: if your PM identity is "I ship things," you're in trouble as AI democratizes shipping. If your identity is "I make sure we're building the right things," you're more durable. That's not a new argument, but it's never been more practically relevant than right now.

Critical questions:

  • Does the "product builder myth" argument risk becoming a defensive rationalization — PMs protecting turf by devaluing the building skills they don't have?
  • In very small teams or solo AI-assisted product work, is the discovery/build separation even realistic anymore?
  • What concrete practices does Torres recommend that remain distinctly PM territory even when engineers can self-direct with AI?
  • How do you evaluate whether a PM is providing genuine discovery value versus using "product thinking" language to avoid accountability for outcomes?

Action you could take today: Pull up your last three PRDs or discovery documents and ask: would the team have built something significantly different without them? If the answer is "probably not," that's your signal that the "product thinking" value you're claiming may not be as real as you think.

Lenny's Community Wisdom — When Non-PMs Start Shipping to Production#

Source: https://www.lennysnewsletter.com/p/community-wisdom-what-to-do-when Credibility: High (Lenny's Newsletter Community Wisdom series, sourced from practitioners)

What happened: Community Wisdom 185 tackled a question that's becoming a real organizational flashpoint: what do you do when non-PMs — engineers, designers, founders — start shipping features directly to production? The post also covered thoughts on Claude Code's pricing A/B test and gen AI in games, but the non-PM shipping question is the signal worth unpacking.

Key patterns from the community:

  • The core tension: AI coding tools have reduced the friction between "I have an idea" and "it's in prod" to near zero for technical team members, which bypasses the PM review, prioritization, and discovery loops that exist for good reasons
  • Community responses appear to cluster around two camps: (1) celebrate it — faster shipping is good, PMs should focus on higher-leverage work; (2) push back — uncoordinated shipping creates tech debt, UX inconsistency, and undermines product coherence
  • Claude Code's pricing A/B test came up separately — the community apparently has thoughts on the ethics and strategy of A/B testing pricing itself, not just features
  • Gen AI in games is an emerging topic: players interacting with AI-generated NPCs or content creates new retention and monetization patterns

Why it matters for PMs: This isn't hypothetical anymore. If you're in an org where engineers have GitHub Copilot, Cursor, or Claude Code, the question of "who decides what gets built and shipped" is genuinely live. The PM value proposition is being renegotiated in real time. The community wisdom framing is useful here because it's practitioners describing what's actually happening, not what should happen in theory.

Critical questions:

  • Is the right PM response to non-PMs shipping "set clearer gates" or "redefine what the PM contribution is"?
  • If an engineer ships a feature that users love, does it matter that it bypassed product process?
  • Claude Code's pricing A/B test raises a real question: is it appropriate to A/B test what users pay? What's the ethical and strategic framework for that decision?
  • At what org size or stage does uncoordinated shipping become genuinely harmful vs. a sign of healthy autonomy?

Action you could take today: Ask your engineering lead: in the last 30 days, did anyone ship something to production that didn't go through a product review? If yes, that's a conversation worth having — not to re-establish control, but to understand what the new implicit norms are and whether they're working.

OpenAI Signals — ChatGPT Adoption Broadened Significantly in Q1 2026#

Source: https://openai.com/signals/research/2026q1-update Credibility: High (first-party OpenAI research/signals post with named data)

What happened: OpenAI published a Q1 2026 adoption update showing ChatGPT's fastest growth is now among users over 35, and that gender usage has become more balanced. The framing is that ChatGPT has crossed from early-adopter/tech-native territory into mainstream consumer adoption.

Key details:

  • Fastest-growing user segment: 35+ age group — this is a material shift from the 18-34 skew that characterized early ChatGPT adoption
  • Gender balance improving — historically AI tools have skewed heavily male; more balanced usage suggests the product is working for a broader population
  • The post is framed as a "signals" report, suggesting OpenAI is now publishing periodic adoption data rather than one-off announcements

Why it matters for PMs: If your product relies on "AI-savvy users will figure it out," the user base is shifting under you. Users over 35 have different tolerance for ambiguity, different mental models of what AI can do, and different trust thresholds. The implication for product: the UX and onboarding patterns that worked for early adopters are probably not sufficient for the mainstream audience now arriving. This also matters for anyone building on top of ChatGPT or competing with it — the addressable market just got significantly larger, but so did the UX bar.

Critical questions:

  • What's driving the 35+ growth — is it organic word-of-mouth, enterprise spillover, or specific use cases (health, finance, career)?
  • Does more balanced gender usage reflect product changes OpenAI made, or organic adoption shifts? The distinction matters for product teams trying to replicate it.
  • As the user base broadens, will OpenAI's product decisions start optimizing for the mainstream rather than power users — and what does that mean for API developers building on their models?
  • Is publishing "signals" data a strategic move to compete with enterprise narratives, or a genuine transparency effort?

Action you could take today: Look at your own product's user demographic data. If you're still designing for early-adopter AI users, pull your age and usage pattern distribution and ask whether your onboarding and UI complexity still match the actual audience using you.

Cursor — Now Available in Microsoft Teams#

Source: https://cursor.com/changelog/microsoft-teams Credibility: High (official Cursor changelog entry)

What happened: Cursor shipped a Microsoft Teams integration on May 11. You can now @mention Cursor in any Teams channel to delegate a coding task to a cloud agent or pull information from Cursor into Teams. Cursor automatically picks the right repository and model based on your prompt and recent context.

Key capabilities:

  • Mention @Cursor in any Teams channel — no context-switching to the IDE required
  • Delegates tasks to a cloud agent that runs in the background
  • Auto-selects the right repo and model based on prompt + recent activity
  • Returns results directly in the Teams channel thread

Why it matters for PMs: Cursor is doing what every B2B developer tool eventually does: meet users where they already are. Microsoft Teams is where engineering teams live for standup, incident response, and async coordination. Putting a coding agent there means engineers can kick off tasks without leaving the communication layer — which lowers the activation energy for AI-assisted work significantly. For PMs who work in Teams-heavy orgs, this also creates a new surface where you might see what engineers are delegating to AI — which has implications for process visibility and coordination. The auto-repo-selection is also notable: it's building context-awareness into the agent, not just raw capability.

Critical questions:

  • Does the auto-repo-selection actually work reliably, or is it impressive in demos and fragile in production with large monorepos?
  • What's the security model for a Teams bot that has write access to codebases? Enterprise procurement teams will have questions.
  • Does this create a new vector for scope creep — engineers shipping things initiated from casual Teams conversations that never get proper review?
  • How does this change the PM/engineer coordination workflow? If engineers can kick off builds from Teams, should PMs be in those channels more actively?

Action you could take today: If your org uses Teams, find out whether your engineering team is adopting this integration. If they are, ask to be in the channels where Cursor tasks get delegated — not to gatekeep, but to maintain visibility into what's being built.

Quick Hits#

The Thread#

The question underneath this week: what is PM work when anyone can ship? Cursor in Teams, non-PMs shipping to production, Teresa Torres challenging the "product builder" identity, spec-driven development automating standups — every signal this week is a different angle on the same disruption. The PMs who are treating this as a tooling shift are missing the larger renegotiation happening around who owns product decisions and what "PM value" actually means.

Sit With This#

Lenny's Community Wisdom 185 surfaced a real tension: non-PMs are shipping directly to production, enabled by AI coding tools. Teresa Torres dropped an episode the same week arguing that PMs who define themselves as "builders" are building on sand.

For your team: If an engineer on your team shipped a feature last month without a product review and users loved it — what does that tell you about where your actual leverage is? And if the answer makes you uncomfortable, is the discomfort about product quality risk, or about role identity?