Depth always creates a gap somewhere else. Planning where that disappointment lands changes how the work feels. It shifts energy toward just-in-time outcomes.

When product managers choose to disappoint, they find the smallest impact possible: - contributing analysis when the team is ready - enabling engineering with a focused customer summary - deferring exploration of a new technology until you understand the customer benefit clearly.

Pressure arrives before clarity. Expectations rise. Feedback gets sharper. Many product managers are experiencing this at the same time organizations are figuring out their next operating model. A few thoughts on navigating that middle ground:

Product managers think about pre-disappointment conversations. Stakeholders rarely react well to abstract worry. They engage with specific, framed tradeoffs. Most stakeholders want a chance to control outcomes within the constraints of the organization.

Most product managers carry inside knowledge that is rarely written down: - Margin estimates and margin targets - How sales navigates tradeoffs, - How engineering expects product managers to contribute, - How leadership language translates into product decisions.

There is hidden value in validation before coding. Itamar Gilad reminds us how easy it is to act before thinking. "The temptation to start with code has very serious consequences on our ability to learn and iterate fast." buff.ly/1a25Z4M

Product managers who use an environment strategy don’t try to be equally strategic everywhere. They choose where to think deeply. They accept “good enough” elsewhere. They time their contributions to land when teams are ready to act.

The point of an environment strategy is to step back from the day‑to‑day and decide how much of yourself each environment gets. A useful question is “What does done mean here?” In fast‑paced environments, being done may mean small, frequent decisions and clear signals so others can move.

Organizations are moving, but change comes at the pace of learning.” That became my biggest takeaway after revisiting product management trends from 6 months ago. The transition feels much messier than expected.

Instead of seeing your role as one continuous backlog, you can view it as a set of environments that need different product management behaviors. Each environment rewards different actions. Going deep is essential in some. Speed and timing matter more in others.

An environment strategy is how a product manager decides where to apply their thinking, energy, and learning across fast‑changing contexts. Its job is to help you decide where your judgment matters most right now.

While AI accelerates IC product managers, how do our managers keep pace? Liz Fosslien and Mollie West Duffy have suggestions from their research: 💠 Operate like a manager of managers 💠 Make managing up a core skill 💠 Use AI to filter, not flatten buff.ly/JCmbPwi

Being good at alignment means helping the organization see the tradeoffs it’s already making. And choose tradeoffs deliberately instead of by default. When alignment stalls due to structural issues outside your control, your role isn’t to force consensus. It’s to make the cost of indecision visible.

If alignment keeps stalling before requirements, the problem might not be your alignment skills. Before refining requirements again, it’s worth asking whether the organization has agreed on the risk it’s willing to take.

Some products change the product manager role in subtle ways. The job stops being: “produce certainty upfront.” And becomes: “help the organization learn safely while execution is already happening.” That shift explains a surprising amount of friction in product management.

When risk isn’t chosen deliberately, it gets absorbed accidentally. Usually by: - Process - Rework - Or the product manager

Most stalled decisions aren’t disagreements. They’re risk tradeoffs no one has chosen.

The Ideal Customer Profile (ICP) is an underused tool for product managers: - A good ICP steers you away from revenue that drags you in the wrong direction - ICP is a blueprint for the perfect hypothetical company - Use ICP to decide which workflows deserve AI support buff.ly/TBsRzcM

Builder PMs emerge because product speed changes where value lives. As the pace increases, the product managers who hold offer and customer context become the ones teams need. Because they help the product keep moving without breaking.

Builder PMs scale their products by borrowing expertise instead of waiting for artifacts. In fast teams, documents explain the past. Conversations shape what you deliver.

Lately, product work has felt quieter, while its impact has grown larger. More learning and clearing uncertainty. I wrote about my product operating model changes:

Builder PMs scale their products by mapping dependencies that are customer visible: - pricing and SKUs - demos and mockups - performance impact Customers feel these dependencies before teams notice them.

Who do people DM when something "feels off"? If it's rarely you, then your product team is bypassing you. Builder PMs are moving the work earlier, before speed removes your options.

What IC product managers do differently for high impact: 💠 Run an initiative end-to-end: 💠 Get access to the right context 💠 Figure out how to connect what you're doing to the core metrics "It’s now becoming cheaper to just try something than to debate it." buff.ly/f4QCOt6

The best way to avoid AI-theater in your product? Let product ownership be your guide.

AI-first thinking often starts as: Can AI do this? Product-owned AI-first thinking is: What changes if AI does this?

AI initiatives stop behaving like normal product work much earlier than most product managers expect. The more organizational inconsistency AI touches, the more product work starts looking like transformation work instead of feature delivery.

AI-first work moves fast. Fast work makes decisions feel temporary. Each decision seems small. Together, they decide whether something is becoming a product. Product principles rarely break in one moment. They fade through convenience.

The step from “AI helps me think” to “AI touches the product” feels small. Once AI touches the product, even a simple experiment carries consequences. Security and product ownership are the top ones.

3 ways to rewrite product growth: 1️⃣ Show up for customers - win by being visible and connected to your customers 2️⃣ Separate standard product from experimentation - give experiments a chance to work 3️⃣ AI is making it possible to lead and do IC product work buff.ly/qTyU6Rq

AI perception feels hard to measure because answers change. But patterns don’t. Run the same set of prompts. Compare outputs across tools. Score what you see. Fix one thing. Repeat. Over time, you stop guessing how your product is understood. You start observing it.

Most teams respond to poor AI answers with content ideas: “We need an FAQ.” “We should update the website.” “Let’s write a comparison page.” All valid. None prioritized. The shift is treating AI perception like a product problem: Define the outcome. Create a repeatable test. Measure improvement.

You don’t need more detail. You need a smaller decision. This shows up a lot in cross-functional work things look busy, but nothing actually moves. I’m calling it the Completeness Trap.

A useful exercise: Ask an AI to explain your product. Not your pitch. Not your roadmap. Just: “What is this product and when should I use it?” The gap between what you expect and what it says is a signal.

Product managers used to own features. Now they also own how the product is understood. Not in a messaging sense. In a systems sense. AI is already forming opinions about your product before a buyer ever talks to you.

CEO of Anthropic suggests learning: - Knowing what the demand is - Design - Knowing what's useful to users - Managing teams of AI models

Start product explainability with what already exists. Then look for friction: Where do people ask the same question twice? Turn that into a product FAQ. With that AI stops guessing Nothing about the product changes. But everything about how it’s understood does.

Explainability behaves like a system: A source of truth A structure for how knowledge is organized Triggers that keep it current Without all three, it decays. The shift for product managers isn’t writing more. It’s designing how product knowledge holds together over time.

A common failure mode with multiple product managers on the same problem: the work starts to drift. Same topic. Different conversations. Slightly different understandings. It shows up later as slow decisions. A small coordination habit helps

There was a time when unclear product gaps didn’t matter as much. Product managers filled the gaps live. So if your constraints, tradeoffs, and positioning aren’t explicit… AI will infer them. Product gaps that used to be hidden in conversations are now visible in first impressions.

Your competitor won because they’re easier to understand. If a buyer (or AI) can quickly answer: What this product is for Where it works Where it doesn’t They move forward with confidence. If your product requires a conversation to understand… you’ve already introduced friction.

Leaders need to be the source of disruption Standing still is usually a losing bet www.proofofconcept.pub/p/the-shape-...

The highest-leverage shift I’ve seen in product managers isn’t “doing more GTM.” If one seller asks it → many will If many will → it belongs in the product system Captured. Reusable. Scalable. That’s how you stop being pulled into every deal …and start building a product that sells without you.

After a launch, the same questions always show up: “What’s actually included?” “Can this work for this weird customer case?” “How do we beat a cheaper competitor?” It feels like sales support. Those questions show you where your product isn’t operationally sellable yet.

Building product context is step one. Making it reusable is what actually drives growth. Otherwise every answer still starts from scratch.

Product managers asking: “Should I stop focusing on launches and help GTM instead?” It’s the wrong tradeoff. If you step away from delivery: progress slows you lose leverage with your team you still don’t fix how the product sells at scale It's a launch “done” too early.

You didn’t miss your goals this year. You shipped. You launched. You did the work. But if you’ve sat in on a sales call lately, you’ve probably felt it: Something didn’t transfer. The product makes sense to you …but not to the people trying to sell it. That gap? It’s unfinished product work.

Is product return on investment a calculation or a system? The system of behaviors that product teams practice: 💠 Asking hard questions every day 💠 Growing confidence in the hypotheses 💠 Having honest conversations with finance buff.ly/Z3pXS1M

Early experiments aren’t about proving you’re right. They’re about finding where you’re wrong—fast. Each hypothesis carries hidden assumptions: – who the buyer is – what would need to change – what “good enough” looks like A good experiment surfaces the weakest assumption first.

Pricing estimation for product managers: How much effort people spend working around a problem. That effort quietly sets an upper bound on your pricing. If someone spends ~1 hour/week dealing with it, your product likely won’t capture more value than that.