Learning Brief — 2026-06-03

What we covered

• AI news: Google's Capital Surge and Agent Rollout Signal Shift to Agentic AI as the Near-Term Battleground
• PM news: Google's Gemini Omni Avatar: The AI Cloning Feature That Changes How We Think About User Onboarding
• PM learning: What I Learned from the Recent Wave of Package Hacks (And Is Cowork Immune?)

Mental model

Competitive threats only matter if they change user behavior; optimize for features that make your core offering questionable, not features that optimize existing workflows.

Summary

Alphabet just raised $85 billion in a record stock sale explicitly earmarked for Google's AI business, signaling massive investor confidence and capital allocation toward scaling AI infrastructure and product launches. Google launched Spark, a new Gemini-powered AI agent that can access personal data from your Google account—your dog's name, your wife's first name—and take autonomous actions on your behalf, demonstrating real-world agentic capabilities moving beyond chat interfaces. Google released Dreambeans, an AI tool that transforms your personal data from Google services into AI-illustrated stories and narratives, showing consumer-facing applications of personalized generative AI that rely on deep account integration.

Google just shipped something genuinely wild with Gemini Omni—a feature that lets you clone your face and create an AI avatar in under fifteen minutes. You scan a QR code, the system captures your likeness, and suddenly you have a digital version of yourself ready to deploy. This isn't sci-fi anymore; it's a shipping product.

Here's what matters for you as a PM: this is a masterclass in removing friction from a high-friction user action. Creating a personalized avatar used to require motion capture studios, professional actors, or weeks of 3D modeling. Google just compressed that into a fifteen-minute QR scan. That's a ten-thousand-to-one improvement in time investment.

But there's a deeper PM lesson hiding here. Google is betting that the barrier to adoption for avatar-based products wasn't actually the technology—it was the effort required to get started. They identified the real bottleneck, solved it ruthlessly, and suddenly opened a whole product category to mainstream users. This is the kind of constraint-removal thinking that separates incremental features from category-shifting launches.

It also signals something about Google's AI strategy. They're not just building better models; they're packaging those models into workflows that feel effortless. That's a product decision, not an engineering one. It means they're thinking about friction points in user journeys and systematically eliminating them.

For your own product, ask yourself: what's the smallest, highest-friction step keeping users from experiencing your core value? Can you compress it the way Google did with avatar creation? Because if you can, you might unlock an entire user segment that was technically able to use you but practically unable to get started.

Here's the thing that separates senior PMs from everyone else: you need to understand the difference between a feature that solves a problem and a feature that changes how people work. Teresa Torres just published something that cuts right to this, and it's worth your attention because it's about how you think about competitive threats and product moats.

So there's been this wave of what she calls "package hacks"—basically, people taking existing tools and wrapping them with AI to create something that feels new. The instinct for most PMs is to panic. You see a competitor do something clever with your API or your data, and you think, "We need to ship that feature faster." But Torres is asking a different question: Is the hack actually solving a real problem, or is it just solving a problem for people who already use your product?

What that means in practice is this. A package hack only becomes a real threat if it changes user behavior at scale. If it's just a clever wrapper that saves power users ten minutes a week, it's not a moat-breaker. But if it fundamentally changes how someone approaches their workflow—if it makes them think, "Actually, I don't need the original tool anymore"—that's when you should care.

The mental model here is: Don't compete on features that optimize existing workflows. Compete on features that make people question whether they need your core offering. That's the difference between a feature release and a strategic vulnerability.

Let's ground this in something concrete. Imagine you're running a design tool and someone ships a "design-to-code" wrapper using Claude that takes your exports and turns them into production-ready components. On the surface, that's a feature you could ship in a sprint. But the real question is: Does this change whether designers need your tool, or does it just make your tool more useful? If it's the latter, you're competing on velocity. If it's the former, you're losing a customer.

The move here is to spend less time on feature parity with hacks and more time on understanding what workflow changes would actually make your product irrelevant. Then you either own that workflow shift yourself, or you deliberately decide it's not your market to own.

This week, pick one competitive threat your team's been tracking and ask: Does this change how people work, or does it just optimize what they already do? The answer changes everything about how you should respond.