Claude Opus 4.7, Codex Expands, and Marty Cagan on Why You're Building the Wrong Thing

Anthropic — Claude Opus 4.7#

Source: https://www.anthropic.com/news (April 16, 2026) Credibility: High (first-party announcement)

What happened: Anthropic released Claude Opus 4.7, their latest flagship model, on April 16. The announcement positions it as bringing "stronger performance across coding, agents, vision, and multi-step tasks, with greater thoroughness and consistency." Notion moved fast — they updated their AI model to Opus 4.7 the same day, visible in their April 16 release notes.

Key capabilities:

• Improved coding performance (specific benchmark numbers not available in the excerpt)
• Stronger agentic task performance — Anthropic is clearly positioning Opus 4.7 as the go-to for multi-step, autonomous workflows
• Vision improvements, which matters for any product doing document processing, UI-to-code, or image-based tasks
• "Greater thoroughness and consistency" is the key positioning phrase — addressing the reliability problem that's been a blocker for enterprise adoption

Why it matters for PMs: This is the clearest signal yet that Anthropic is betting their flagship on agentic reliability, not raw capability. "Thoroughness and consistency" isn't benchmark marketing — it's a direct response to the adoption blocker for enterprise AI: agents that fail quietly or inconsistently. If you're building on Claude for multi-step workflows, this is the version to evaluate. The same-day Notion integration is also worth noting: major productivity platforms are now running model upgrades within hours of release, which compresses your evaluation cycle if Claude powers any features in your stack.

Simon Willison's notes from the same day are relevant here too — he shipped llm-anthropic 0.25 to support the new model in his LLM CLI tool, and separately observed that a local Qwen model drew "a better pelican than Claude Opus 4.7" — a reminder that "flagship" doesn't mean "best at everything" and open-weight models are closing gaps fast on creative/generative tasks.

Critical questions:

• What does "greater thoroughness" actually mean in agent failure modes — does it fail more loudly, or does it genuinely reduce failure rates?
• How does 4.7 pricing compare to previous Opus? If the cost-per-token went up, the agentic use case math changes significantly.
• Notion integrated same-day — did they validate quality before flipping the switch, or is this an automatic passthrough? What's the user-facing quality signal?
• With open-weight models (Qwen, Llama) continuing to close the quality gap, what's the durable differentiation for Opus pricing?

Action you could take today: If you have any Claude-powered features in production, queue a regression test using Opus 4.7 — especially for multi-step or agentic workflows. The "greater consistency" claim is testable, and you want to catch regressions before your users do.

OpenAI — Codex for (Almost) Everything#

Source: https://openai.com/index/codex-for-almost-everything (April 16, 2026) Credibility: High (first-party announcement)

What happened: OpenAI updated Codex — their desktop app for macOS and Windows — with a significant capability expansion: computer use, in-app browsing, image generation, memory, and plugins. This isn't an API update; it's a reposition of Codex as an all-in-one developer workspace, not just a coding assistant.

Key capabilities:

• Computer use: Codex can now control the desktop environment, not just write code
• In-app browsing: Agents can look things up without leaving the workflow
• Image generation: Built into the same tool, not a separate product
• Memory: Codex now remembers context across sessions
• Plugins: Extensibility layer added, opening the ecosystem play

Why it matters for PMs: OpenAI is doing what Cursor has been doing — but from the application layer, not the editor. This is a direct shot at the "developer workspace" category. More interesting for PMs: the memory + computer use combination is the first real signal that OpenAI wants Codex to become a persistent developer agent, not a stateless assistant. That's a different product. For PMs evaluating coding tools, the question just shifted from "which LLM writes better code" to "which product owns the developer's workflow context." That's a much harder moat to switch from.

The name is also interesting — "Codex for almost everything" implies OpenAI knows it's not quite there yet. That honesty is either good product positioning or an actual gap worth probing.

Critical questions:

• Computer use in a developer tool raises significant security questions — what's the permission model? Can it access credentials, read private files?
• Memory across sessions is valuable but introduces privacy/IP concerns for enterprise users — how is this scoped?
• How does this compete with Cursor 3.0's parallel agents window vs. Codex's single-session computer use model? Different assumptions about workflow.
• Plugins: who's building them, and what's the vetting process? This is where the ecosystem either accelerates or becomes a liability.

Action you could take today: If you have developers on your team using Codex or evaluating coding tools, ask them to specifically test the memory feature — whether it actually reduces the "re-explain the codebase" tax is the highest-value claim to validate.

Marty Cagan — Build to Learn vs. Build to Earn#

Source: https://www.svpg.com/build-to-learn-vs-build-to-earn/ (April 16, 2026) Credibility: High (Marty Cagan, SVPG, recognized PM craft authority)

What happened: Marty Cagan published a new post drawing a distinction between two modes of building: "build to learn" (validating assumptions, running experiments, reducing risk) and "build to earn" (executing on what you've already validated, shipping to generate revenue). His framing is that most teams are confused about which mode they're in — and that confusion is expensive.

Key patterns:

• Build to Learn is the discovery phase: you're spending time and money to reduce uncertainty. Success looks like validated learning, not shipped features.
• Build to Earn is execution on validated opportunities: you know what to build, and the goal is speed and quality of delivery.
• The failure mode Cagan identifies: teams treating "build to learn" work with "build to earn" timelines and metrics (velocity, story points, sprint goals), which kills the learning.
• The inverse failure: teams stuck in perpetual discovery, using "we need to learn more" as cover for not committing.
• In an AI context, this distinction gets blurrier — AI features often require shipping to learn (you can't A/B test an agent in a sandbox the way you can test a button color).

Why it matters for PMs: This is one of those frameworks that's useful precisely because it forces a conversation your team probably isn't having explicitly. Most roadmaps mix learning items and earning items without labeling them — which means they get measured the same way and fail for different reasons. The AI product context makes this especially sharp: when you're building an AI feature, are you trying to learn whether users want this (build to learn) or shipping a known-good capability at scale (build to earn)? The answer should change your timeline, your success metrics, and your risk tolerance. If you're in a sprint right now with AI items on it, it's worth 10 minutes to label each one.

Critical questions:

• How do you handle mixed-mode items — features that are partially validated but need production data to fully validate? Most AI features live here.
• Does your organization even have the cultural space to declare something "build to learn" without it becoming a career risk if the learning is "this was the wrong thing to build"?
• Cagan's framework assumes you can clearly separate learning from earning — what do you do when your investors or leadership can't tolerate the former?

Action you could take today: Take your current sprint or roadmap and tag each item "L" (build to learn) or "E" (build to earn). If more than half your items are unclear, that's the conversation to have with your team before the next planning session.