Are You Ready For AI? The Questions

I built this quick assessment for every student to take before class starts.

If you’re not in my class, take it anyway — it’s free, takes under five minutes.

The Answer

And you’ll get your results emailed back with guidance and resources, not just a score.

Here is an example:

The method I used is based on the Gen AI Playbook I’ve developed over years implementing AI. Over the next few weeks, I will be publishing a couple more articles that lets us go deeper into the rules of the “new AI organization”, namely:

• The AI Organization: New Rules. Why Your Org Chart Is NOT Lying to You: goes role by role — what changes for Product Managers (the job is splitting into two: the Inbound PM and the Outbound PM, and most orgs still have one person trying to do both), what changes for UX, engineers, and architects, and why the ratios that used to make sense — one PM per five to eight engineers — no longer do.

• How AI changes Everything: CEOs Don’t Have an AI Problem: covers the three decisions only a CEO can make: who owns AI outcomes, what ratio needs to reset, and what your actual innovation layer is.

Subscribe to this newsletter to be the first to receive the link when they drop.

Want this template? 👇

Subscribe, Comment “Org” 👇 and I’ll DM you the link!

This is back in the days of perpetual software. When solution selling was all the rage and the best sales teams were the ones that understood the “triggers” that made “buying groups” tick. A lot of it had to do with “relationships” and designing financial terms that would benefit the “buying team” schedule.

I remember stepping back and reflecting on the “science of selling”. My friend Bill Macy taught me much of this at BusinessObjects. I had the opportunity to work with him again at Google Cloud, after we acquired Looker for $2.6B.

A lot has changed since then. In this post, I’ll detail how SaaS, consumption pricing and AI have changed this forever and how, strangely, understanding the “deal anatomy” is more important than EVER.

I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO.

I teach an executive course on AI and Leadership at Stanford Continuing Studies. The first class will cover org design — how AI is impacting every job description and every org chart. You can register here.

Sign Up For Class

The Job Of The Good PM Doesn’t Stop At Ship

I’ve written before about the Friction Log — the discipline of tracking a customer’s ground-level reality instead of the roadmap you assumed they wanted.

Deal Anatomy is that same discipline, pointed at what happens after the signature instead of before it. It’s not a new philosophy. It’s the Friction Log’s logic, refusing to stop at day one.

The thesis underneath it has always been the same: a good PM operates as the GM of the product, not the build manager.

A bad PM’s job ends at launch. A good PM’s job continues through renewal, expansion and evangelization to other prospects. To see how this should starts, check out my post: Nobody Cares About Your Product (Part Deux).

Buying Is Adopting

Here’s the part that changes everything: under the old perpetual-license model, buying and adopting were two separate events. You signed, you got paid, and whether the customer actually used the thing was — brutally — a problem for next year’s renewal conversation, not this quarter’s number.

Consumption pricing collapses that gap. If you’re paid on usage, on tokens, on workflows completed, then nobody gets paid until the customer is actually operating.

The signature stopped being the finish line. It became the starting gun.

That’s the whole insight: if you only get paid when it’s consumed, then everyone whose job touches consumption is, functionally, in sales now — whether or not they've ever carried a quota.

Subscribe now

Building A Deal Anatomy In The Era Of AI

Now that we’ve clarified a PM’s central role on deal anatomy, let’s break down how we can build it together with the rest of the organization.

Every step below needs the PM, the account or sales leader, and a great perspective of the customer environment during the 8 key phases: education, discovery, qualification, proof, adoption, expansion, renewal, evangelization.

First, the customer environment. You already know that I’m not a big fan of “personas”. I believe in “roles” and “jobs to be done”.

The “Deal” is not a “transaction”, it’s a relationship that evolves like an organism. You must understand the types of roles your organization needs in order to match your prospects' buying and adoption habits, procedures and systems.

In my observation, at least 4 types of roles tend to buy and adopt technology together:

The Believer. This is the person who felt the pain badly enough to name it and go look for a solution. They’ve been looking for you. They don’t need to be convinced there is an issue to be solved. They’ve looked at your site, they might have tried your product. They need to understand what’s unique about you that’s going to help them with their Jobs To Be Done. A good profile to pair them with is either a good technical account manager or a sales engineer.

The Operator. Whoever has to actually run the thing daily, or — if it’s agentic — supervise what it does. They need to know what to do if the solution doesn’t behave as expected. They need shortcuts and best practices learned by peer companies…etc. On your side: your customer success team, your dev/rel lead, whoever’s they will call, look up and respect during the usage ramp.

The Guardian. Whoever can quietly kill it — security, compliance, an AI governance owner deciding whether this thing is allowed to touch what it touches. Sometimes could also be an engineer, developer or scientist who believe they can “easily build what’s you’re selling”. Understand that your services/solution/product is BOUGHT (not just sold). If you spend time with the main actors, you also must understand who the potential detractors are (and their motivation). As Joe Otto taught me back when we were scaling Alpine Labs: look for the 'silent bully.'

On your side: match these types with your architect, your solutions engineer, whoever has to answer their questions with something more credible than a sales deck.

The Buyer. Whoever has to justify the bill, the expansion, the renewal, in a language finance accepts. On your side: whoever owns the account’s revenue number, and increasingly, the product itself — because the data proving value now has to live in-app, not in a slide someone forgot to update.

I’m sure you can find other people at your customer but the above are the essentials.

Here is something to consider. In each of these cases, the best person to match them on your selling team is actually not directly employed by your company. I’m referring here to ‘another customer’. That’s right, the best person to talk about your lived value to another customer is…an existing customer. It’s another believer turned consumer.

This is why your number one job is to develop incredible empathy for your customers journey and your number two job is to build a platform by which they can share their experience with others.

To be clear, I’m not talking about “reference selling”. (I’ve never liked the term, makes it sound like customers are deciding based on a catalog).

I’m talking about “experience sharing”. In the Era of AI, customers connect to other customers at scale. They watch each other videos. They summarize each other’s work for each other. They vibe code together. They can easily deep dive into solutioning together.

Make sure you ‘upgrade your playbook’ for this new reality.

Actors and Interactions

Now that we know more about the ‘actors’, let’s think about how they interact.

Everything I’m going to talk about below needs to be grounded in customer reality. Back to my point on empathy, this isn’t about ‘imagining’ the anatomy, this is about learning from what actually happening at the best ‘deals’ and the worst one too.

A good PM will pick up the patterns that led to happy customers that go from education to evangelism at a record pace and they will pinpoint the points of friction that prevent that evolution from happening.

So, as Steve Blank says: “There are no facts inside your building, so get the hell outside!”. This means talk to your sales team, interview customers who have churned and those who haven’t chosen you. Talk to industry analysts who can critique the assumptions you’re making. Remember, industry analysts talk to prospects evaluating you and when they talk to your existing customers, those are most likely to tell them something they are not telling you!

Two words of caution:

1. When you talk to your sales team, beware the recency and the incentive bias. If the insight feels like it comes from the last deal (ask: what other deals are affected by the same pattern) or if the insight comes from an upcoming contract deadline or quota retirement benefit, it doesn’t really qualify.

2. When talking to ‘blind spot’ spotters like industry analysts, make sure you qualify the source of the feedback. Feedback from a non-customer is not actionable feedback. This goes back to my point on Non-ICP. You must be very clear about “who you’re not building for”. Ask: “what are the attributes of this customer?“ and compare that to your bullseye.

The Method: Map Roles To Phases, Not Roles To Titles

How should you build your “Deal Anatomy” (BTW- for a template, keep scrolling down). A static list of four roles isn't a Deal Anatomy yet. It's an org chart. What the Believer needs to see is completely different at Education than at Renewal — treating them as one static persona is exactly the mistake "buying committee" thinking makes.

The method has six steps.

1. Build the grid. Four roles down, eight phases across — education, discovery, qualification, proof, adoption, expansion, renewal, evangelization. Most deals don’t light up all of them — your Guardian is often silent during Evangelization, your Buyer is usually quiet during Education. Mark which cells are actually live for this specific deal. That’s your map.

2. Name the real JTBD. Not “the Believer’s pain” once — the Believer’s pain at Discovery (”is this real, or another vendor promise”) versus at Expansion (”can I get credit internally for having pushed this”). Same person, different job, different phase. Generic personas can’t do this. Roles mapped against phases can.

3. Assign two owners per cell — one of yours, one of theirs. An internal owner (dev/rel for the Guardian at Qualification, CS for the Operator at Adoption), and wherever you can manage it, a customer voice — someone from your experience-sharing pool who’s already sat in that exact seat. This is where your Believer-to-Believer insight actually gets operationalized instead of staying a nice idea: it becomes a specific person you route to a specific cell.

4. Design the artifacts, not the deck. Every live cell should produce one real thing, not a slide.

• Guardian at Qualification gets an auto-generated compliance brief, not a security slide buried in a 40-page deck.

• Operator at Adoption gets an in-app runbook seeded with what peer companies already learned the hard way, not a generic onboarding checklist.

If a cell’s artifact is “we’ll mention it on a call,” that cell doesn’t have a design pattern yet — it has a hope.

5. Instrument what no human will be watching. Adoption, Expansion, and Renewal are, increasingly, phases nobody attends in person — which is exactly why outcome-based pricing is climbing the way it is. If you’re only paid when the outcome shows up, the proof has to live in the product, continuously, not in a QBR deck someone forgot to update. Build the telemetry into these three phases before you need it, because by definition no one’s in the room to build it after.

6. Sequence it — because they started without you. By the time you engage, self-education has usually already put the customer somewhere specific, sometimes with a shortlist an AI already built for them. A prescriptive sequence that assumes zero prior context insults a buyer who’s already three steps ahead, and one that assumes too much loses a buyer who’s genuinely still at Discovery. Check where the self-education line actually is before you prescribe what comes first.

Now What?

You don’t need to map all thirty-two cells this week. Here’s how to get started TODAY, in 5 easy steps:

1. Pick one deal that’s live right now — one that’s stalled, or one you’re worried about.

2. Fill in exactly four rows, for whichever phase it’s actually in.

3. Name the real JTBD, not the use case.

4. Name an internal owner.

5. Name a customer voice, if you have one who’d say yes to the call.

I built the grid so you don’t have to draw it from scratch — the Deal Anatomy Template is linked below. Copy it, gut it, make it yours.

This is exactly the discipline we build, live, in my AI Product Strategy course at Stanford Continuing Studies this fall — Revenue Bridge & Deal Anatomy, one of the artifacts you’ll walk out with, defended in front of a panel that’s actually built and funded this.

If you want to map your own Deal Anatomy before you lose a deal to it instead of after, registration is open now.

Sign Up For Class

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share — if this was useful, subscribe for more, and share it with someone whose “closed” deal just went quiet.

A few days ago, I wrote a piece about what “AI Does To The Brain”. Many of you reached out. Consider this “Part Deux” of my thesis on AI and Human Capital.

I teach a executive course on AI and Leadership at Stanford Continuing Studies. The first class will cover org design — how AI is impacting every job description and every org chart. You can register here.

Sign Up For Class

BTW - the creator is PhiloSophia and what she does in about three minutes gives you the 2,500-year-old philosophical scaffolding for why that question actually matters. I’m not going to pretend that my post is going to get her more followers (she has close to half a million!) but you should follow her for more!

Make It Real!

Subscribe, Comment “Leader” and I’ll DM you the link the template!

Subscribe now

Myth: This Is a New Argument

It isn’t, and that’s the point. Plato had Socrates make almost this exact case against writing. Putting knowledge on a page fights forgetting — but it does it by holding the knowledge for you instead of teaching you to hold it yourself.

Socrates called writing a hypomnesis: literally, something underneath memory, not memory itself. And he reached for a word that has no clean English equivalent — pharmakon, which means remedy and poison at once. Every time you outsource a faculty, you risk losing your grip on it.

Subscribe now

The Part Most Skip: We’ve Always Been Technical

Here’s where it gets interesting. If you stop at “technology is dangerous,” you miss something Bernard Stiegler spent a career arguing: humans have never been creatures who occasionally pick up tools.

We are humans through our tools, going back to the first shaped flint, the first spoken word. Language itself is already a technology. Socrates making his case against writing was making it in words — already borrowing an external system to think.

Every Technology Is a Pharmakon

Stiegler’s answer: it’s not just writing. Every technology carries both possibilities at once.

A machine can strip a worker of their craft knowledge. And AI can strip a human of the practice of thinking itself. Stiegler had a name for this: proletarianization — losing the knowledge embedded in doing something, because something else now does it for you.

But he didn’t stop at the warning. He also named the alternative: appropriation.

Not just learning to use a technology, but learning to take what it hands you and make it yours — bend it, argue with it, push back against it, transform it, and in the process, be transformed yourself. Done that way, the technology doesn’t think for you.

You think with it. Stiegler called this individuation: the ongoing work of becoming yourself, partly through your tools, never fully surrendered to them.

Now, I love this last part. My family and close ones sometimes make fun about how I use AI at work and at home. But, the reality is that it’s so embedded in what I do now, that I’ve learned how to use it to make me a better human….if you’ve been following me here, you know about the agents I’ve built for myself at home and at work.

You might remember it when I discussed the concept of the “Iron Man” suit on the CXO Talk Podcast, hosted by my friend Michael Krigsman.

Subscribe now

Why AI Is a Different Kind of Pharmakon

This is where Plato gets one more turn. His deeper complaint about writing wasn’t just that it replaced memory — it’s that a text can’t answer back. Ask it a question and it stays silent. Real dialogue, real logos, responds, adapts, resists, pushes back.

AI breaks that objection. It does respond. Which means the real stakes aren’t whether the machine talks back — it’s whether you let that response close the thinking down, or use it to keep the dialogue open.

Where This Lands

I don’t think Plato was wrong to be suspicious of the tool. I think he was wrong about where the danger actually lives.

The risk was never in the technology someone invents. It’s in the laziness with which we decide to meet it. The risk was never thinking alongside a machine. It’s forgetting how to think without one.

Now What?!

Next time an AI answer lands in front of you, don’t take it as the end of the conversation. Argue with it. Ask it what it missed. Make it earn the answer a second time.

That’s the difference between a tool that thinks for you and one you think with.

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share If you’re into this kind of content, please subscribe and share it.

That’s because launching is not the same thing as delivering value. Most product orgs conflate the two, and it’s costing them energy, waste, and hope.

Don’t get me wrong. Shipping is hard. As a young product manager, I was always really proud to receive my “Ship It” awards.

But every successful software company I worked at cherishes the landing just as much as the launching. That was true at Microsoft—and it was especially true at Google and the startups I’ve helped scale, where the true reward of our work was measured in consumption, not release notes.

Myth: Shipping Is the Finish Line

It isn’t. Shipping is the start of the value cycle, not its completion.

A product that is announced cleanly and sits unused isn’t a win — it’s a liability that adds codebase entropy, complicates support, and quietly burns the engineering capital that built it.

The definition of “done” has to include verified adoption, not just a green build.

In this post, I give you a tool and break down the process required to Launch AND Land.

Before we start: I teach a executive course on AI and Leadership at Stanford Continuing Studies. If you’re interested, register 👇. Attendance is online, classes are recorded, and I share full resource toolkits with students and subscribers.

Sign Up For Class

The Launch & Land Canvas “Tech”

The canvas is your primary artifact. You can use whatever platform your team lives in, but I like to keep it low-tech: a simple spreadsheet does it.

The one tool I’ll tell you not to use? Slide decks.

Before diving into the columns, let’s orient around how the canvas is actually governed:

What’s In / Out

• Who it’s for: It is the single source of truth every function points to. It’s built and read in tight partnership with marketing, AR/PR, and channel partners—not just OPMs, PMs, and engineering. If nobody outside product knows a feature shipped, it was never going to land, no matter how well it was built. The canvas makes that visibility structural instead of hopeful.

• What belongs on it: Net-new customer-facing workflows, artifacts that impact the field and partners, anything requiring sales or CS enablement, and initiatives tied to measurable adoption outcomes.

• What stays off it: Minor bug fixes, internal tooling, and backend refactors with zero visible user impact. If it doesn’t have a behavioral outcome attached, it belongs in the backlog, not on a Launch & Land tracker.

• Multi-Tab Template: The spreadsheet is built across multiple tabs to separate structural planning from day-to-day execution.

  • The first tab houses the core Launch & Land canvas—all 36 artifacts mapped across your tiers, owners, and adoption metrics.

  • The second tab is your cadence sheet. It drives the timeline leading up to the release, locking in your announce date, hard workday counters, and the weekly operational rhythm. It reminds the core team of what needs to happen when, structuring meetings into a tight 30-minute block divided into three distinct 10-minute topics.

Crucially, the cadence doesn't drag everyone into every room: meetings scale dynamically, ensuring only the necessary V-team members are present per topic.

Make It Real!

Subscribe 👇, Comment “LLT” and I’ll DM you the link the templates!

Subscribe now

Operating Principles

• Align on differentiation: The top “Description” section, written by the PM, aligns everyone on what the product or feature does, who it’s for, why it’s different, and our core wedge. It’s a tight summary that points to the longer-form PRD/MRD and is designed to eliminate cross-functional misalignment before code is even finished. Owned by the PM.

• Coverage clarity: Not every launch is born equal. I use a 3-tier system where teams elect which assets to turn on or off based on the launch’s actual impact. Coverage and ownership are explicit: OPMs own Tier 1, while PMs drive the other tiers as self-service. Adjust these thresholds based on your organization’s maturity.

• Extreme ownership: Avoid multiple owners like the plague. Every item has one named owner. That owner drives the artifact’s completion, schedules offline syncs when needed, updates the team against target dates, and manages the exception flag. If an item is flashing red or yellow, that owner is responsible for bringing the triage plan to the table.

• Velocity: Weekly touchpoints are strictly 30 minutes, capped at three key topics per call. OPMs run Tier-1 reviews to keep the room focused. Topics are pre-determined using our cadence sheet, and the V-team scales progressively—meaning not everyone is in every meeting, adhering strictly to a clean OARPI accountability model.

The Tool: Section By Section

Across the canvas, we track 7 distinct sections covering 36 specific artifacts. Treat this as a battle-tested baseline—feel free to customize it for your organization’s maturity and specific needs.

A quick disclaimer: This is an operational Launch and Land tracker, not a formal legal or compliance framework. Always check in with your legal and compliance departments to see what additional corporate hurdles they require.

Also, notice how I use the word Launch. In some organizations, this is just called an “Announcement.” But my focus is entirely on activities that drive customer impact.

Product bits might be technically ready to “ship,” but they aren’t ready to launch until we’ve organized ourselves to let the world know and provided the tools required to maximize consumption.

Section 1: The Command Center (Top-Right Header)

Before diving into the rows, look at the top-right corner of the sheet. It houses the critical operational telemetry:

• The Countdown & Target Dates: Driven by a hard announce date and a work-day counter. Pro-tip: I always shave 2 to 3 weeks off the counter. You need that buffer for the uncontrollable unknowns (and the knowns that always slip).

• Status Rollup: A live count of what’s done, what’s in progress, and what’s not started. Anyone should be able to glance at the top right and instantly read the health of the entire launch.

• The Virtual Team (V-Team): Explicit departmental tags and specific owner names mapped to drive accountability across the entire grid.

Need to walk through this live? I teach a executive course on AI and Leadership at Stanford Continuing Studies. If you’re interested, register 👇. Attendance is online, classes are recorded, and I share full resource toolkits with students and subscribers.

Sign Up For Class

Now, let’s dive into the five core sections (I’ve included a bonus section at the bottom for you too!).

1. Foundation: The Non-Negotiables

This is everything you literally cannot skip. It spans from your messaging framework and internal website to your PRFAQ/PRD, security sign-offs, and launch-day emails or webinars.

2. External Communication & Go-To-Market

Once the foundation is solid, you build outward. This section covers:

• Dedicated Tech Blogs & Event Inclusion: Securing your real estate in key industry moments.

• Social Media & Customer Newsletters: Orchestrating the drumbeat of external visibility.

3. AR, PR & Analyst Integration

This isn’t just about pitching journalists ahead of launch day!

• When it comes to Analyst Relations (AR) in particular, it’s about pulling them into message testing early.

• You want their feedback on how you frame the value proposition and explain the “why” behind the product or feature before the ink is dry on the release notes.

4. Sales Tools & Enablement

• The goal here is scale. A launch fails if the only person who can articulate the value proposition and the “why” is the Product Manager.

• This section forces the creation of announce decks, master classes, and sales enablement assets so the entire field can sell it on day one.

5. Partner & Ecosystem Enablement

• No product exists in a vacuum. Your feature is part of a broader customer and partner ecosystem.

• This section ensures your channel partners, ISVs, and co-sell motions have the FAQs, newsletters, and external enablement they need to bring the feature to their own customer bases right alongside you.

Bonus Track: Upgrading to a Kanban Board with Gemini

If you’re tracking 36+ artifacts across multiple tiers, a spreadsheet is your command center—but sometimes your team needs a visual pulse.

One of the great things about working inside modern Google Workspace is how easy it is to leverage Gemini to instantly transform structural data into execution views.

With a simple prompt, you can take your Launch & Land spreadsheet and have Gemini spin up a live Product Launch Kanban Board (as shown in the snapshots below).

Instead of scanning rows and status dropdowns, your V-team gets a real-time, card-based view segmented by status (Not Started, Started / In Progress, Done) and grouped dynamically by category, tier, or owner. It syncs directly with your spreadsheet data in real-time, giving you the best of both worlds: rigorous spreadsheet governance paired with modern, visual agile execution.

Here is how to create it 👇

Now What?!

Pull up the last three features your team shipped. For each one, answer two simple questions:

1. Can you name the specific behavioral adoption number it was supposed to hit within 28 days?

2. Do you actually know where it stands right now, or did everyone move on to the next sprint the moment the launch day email went out?

If the honest answer is that you celebrated an activity rather than a landing, it’s time to change how your organization defines “done.”

Want to put this into practice? This live Launch & Land Canvas template—along with all my other executive operational tools and frameowkrs—is available completely free to my subscribers and students attending my Stanford Continuing Studies course.

Grab the template, customize it for your team’s tier structure, and bring it to your very next weekly sync.

Subscribe now

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

The good ones are operational meetings that give a good sense of direction, debate impactful action, based on meaningful market insights.

If you want to get a feel for the types of characters that detail your MBR, read the five animals hiding behind every review.

Here’s the bottom line: you can tell if you’re in a bad Monthly Business Review if people have been focused on slides to look good. In the good onse, people write a memo to find out what’s actually true — including the parts where they need help because they can’t diagnose the problem correctly yet.

Subscribe now

Why Do We Have MBRs In the First Place?

The MBR sits in a specific spot in the operating cadence, and most companies blur it into the meetings above and below it, which is why it fails.

• Daily standups handle tactical blockers over 24-48 hours.

• Weekly Business Reviews scan high-frequency inputs over 1-4 weeks — fast, exception-only, “nothing to see here” for anything in-band.

• The MBR sits above that: it synthesizes the trend, checks whether initiatives are actually on track, and reallocates resources over a 30-90 day window.

• Above it, the QBR handles multi-quarter portfolio bets and capital allocation. Confuse the altitudes and you get a meeting that’s simultaneously too detailed to be strategic and too vague to be operational — which is most MBRs.

Myth: An MBR Is a Status Update

It isn’t. A status update reports what happened. A real MBR diagnoses why it happened and commits to a specific, owned fix before the meeting ends.

Make It Real!

Subscribe 👇, Comment “MBR” and I’ll DM you the link!

Subscribe now

Who runs it matters. This isn’t a finance ritual or a sales pipeline review dressed up with a broader guest list — it’s owned by the GM or PM of the business, in close partnership with the GTM functions who are living the market signal in real time.

The GM/PM brings the product and strategic view. GTM brings the ground truth of what customers are actually doing. Neither one alone gives you the full picture.

I have strong feelings about Product Managers acting as GMs and CEOs of their business. You can read more about it here and here.

Watch Out For Watermelons

This is the part most teams skip, and it’s the part that prevents the whole exercise from becoming a Goodhart’s Law trap — the moment a measure becomes a target, it stops being a good measure.

Every metric you optimize for needs a paired counterweight that catches what the optimization breaks. Push engineering velocity without pairing it against defect escape rate, and you’ll ship fast, fragile code. Push pipeline volume without pairing it against Stage 1-to-3 conversion rate, and you’ll flood the CRM with leads nobody can close. The counterweight is what stops a team from technically hitting the number while quietly breaking the business.

Watch for what watermelon metrics — green on the outside, red underneath. 100% pipeline coverage looks great until you notice half of it is stale, uncontacted leads that have been sitting in the same stage for months. The fix isn’t a better dashboard. It’s a better environment where team members feel safe to use the MBR as an operational moment of truth.

There are many other ways MBRs can go south. I can think of at least “5 Big Ones”. Before I move on to how to make it work, here is a graphic summarizing symptoms you might come across…

How Can We Do This Right?

The best MBRs I’ve seen are the result of at least 3 practices:

• Clear definition and ownership. The GM and Chief of Staff run the cadence, define the metrics and keep all MBR focus in line so signal is prioritized over noise.

• Rigorous execution. The metrics and results are communicated before the meeting so the review can be a operational discussion.

• Surgical operation. During the MBR, we review what was committed previously and the results of the actions taken. We say what we do and we do what we say. If we agree on specific actions, did they work? If not, why? And what will we do now?

Teams will have a tendency of bringing a lot of data. The problem is that quantify doesn’t fix for quality. Saying “we have a lot of data” doesn’t mean “we have the right insights”.

My recommendation is that you focus on 5 key questions and send this to whoever owns a metric, due before each meeting:

1. This Month (Actual vs. Plan)

2. Trend (MoM / QTD / YTD)

3. In-Band or Out-of-Band?

4. If Out-of-Band: Root Cause (Answer 5-Why, one line)

5. Metric Committed Action by Owner. With Due Date.

A few operational tipis:

1. No row gets a “committed action” unless it’s out-of-band.

2. In-band rows get one line and no discussion time at all.

3. No action gets logged without a single named owner and a real date — “the team will look into it” Is NOT an action. It’s a placeholder for the same red row showing up again next month.

Example Metrics to Keep the Group in Focus

Pick no more than five to seven metrics total for a given MBR. The point of this list isn’t comprehensiveness — it’s focus. A 40-metric dashboard is just performance theater with more tabs.

Here are a few examples I have used. They might look overly simplistic to many of you but that’s kinda of my point. It’s harder to keep things simple. You have to force yourself (and your team) to think about the absolute necessary metrics to focus on.

By Function

By Metric Type

If you want the live template, click here

Now What?!

Look at your last business review. Was the time spent explaining what already happened, or committing to what changes next — with a name and a date attached?

If every action item from last month is still open this month, you don’t have an MBR. You have a recurring meeting with the same agenda, forever.

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share If you’re into this kind of content, please subscribe and share it.

We now have enough customer proof and research to show that “making AI work” is more sophisticated than it appears.

A recent study points to why: AI value isn’t constrained by the technology. It’s constrained by human capacity. In this piece, I dive into that.

Would love your thoughts — and if you want to debate it live, my Stanford course kicks off in a few week. And now with the online attendance option, so you don’t have to travel to join. 👉 Sign up here.

Subscribe now

Myth: The AI Bottleneck Is Technical

It isn’t, and McKinsey’s own research makes the case better than I could.

Here’s what that gap actually looks like when you go looking for it.

• 70% of employees say they personally feel ready to work with AI.

• Only 27% of leaders believe their own organization is ready to make the shifts an AI-native future actually requires.

That’s two different realities sitting inside the same company — employees adapting faster than the institutions around them can absorb it. And organizational readiness isn’t a nice-to-have next to personal readiness. It’s nearly twice as predictive of whether AI actually creates enterprise value.

Put plainly: your people are ready. Your organization mostly isn’t.

And pushing people to run faster inside a structure that hasn’t caught up is exactly where the cost shows up — not on a dashboard, but in the brains actually doing the work.

Here’s what that cost looks like. Frequent AI use drives cognitive offloading — people passively hand reasoning to the machine, and their independent analytical skills measurably decline.

Make it Real

Get the template 👇. Subscribe and Comment “Anatomy” to get it.

Subscribe now

Five Things Worth Actually Doing About It

McKinsey’s researchers frame this as “brain capital” — treating brain health and brain skills as a strategic asset, not a wellness add-on. Five principles worth internalizing, condensed:

1. Calibrate the load — don’t just remove easy tasks and leave people doing nothing but the hard, high-pressure ones back to back. Automation that strips out the light work without replacing it with anything is a recipe for burnout dressed up as productivity.

2. Protect the capacity — recovery isn’t a perk. Sleep and psychological detachment are when the brain actually clears the metabolic waste that builds up from sustained cognitive effort. No upskilling program survives being layered onto a depleted brain.

3. Enable focus — people need real uninterrupted time to evaluate what AI produces, not 47 seconds of attention before the next context switch. AI being fast is worthless if nobody has the space to actually judge its output.

4. Build the skills that don’t transfer — judgment, pattern recognition, reading a room. Those only develop through use, and AI doesn’t build them for you. It just makes it easier to skip the reps.

5. Design the environment — the same pilot introduced as “who knows if this will work” versus “here’s a serious thinking partner” produces different outcomes with identical technology. Culture decides whether AI adoption builds people up or hollows them out.

Why This Belongs in the Org Chart Conversation

This connects directly to the argument I’ve made previously: the org chart is the most honest document any company has, and it’s usually wrong for the AI era in ways nobody’s audited.

Most companies have redesigned the roadmap. Very few have redesigned the roles, the ratios, or — this is the piece McKinsey adds — the actual cognitive load those roles now carry.

An org chart that assigns AI-accelerated work without redesigning for recovery, focus, and skill-building isn’t a modern org chart. It’s a faster path to the same burnout, with better dashboards.

This is exactly the territory I’ll be covering at Stanford this fall — not just how roles are splitting, but what it actually takes to lead people through that split without running them into the ground.

If this is a gap you recognize in your own organization, the readiness assessment is free and takes five minutes.

And now that online attendance is open, there’s no travel excuse left either — register for the class here if this is the kind of problem you’re trying to get ahead of before it shows up in your own numbers.

Now What?!

Look at the people on your team who’ve adopted AI hardest and fastest. Are they doing better work, or just more of it, faster, with nobody checking whether the muscle underneath is still there?

That’s not a question a dashboard answers. It’s one only a manager paying attention can.

My Thoughts. My Thoughts Only.
The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share
If you’re into this kind of content, please subscribe and share it.

• Part 1 covered the Bullseye — why finding your non-customer matters more than chasing an idealized ICP.

• Part 2 focused on Job vs. Persona - once you know who your customer is, the real question is what job they’re actually hiring your product to do — not the persona.

Don’t just take my word for it. Take Clayton Christensen’s. He’s best known for The Innovator’s Dilemma. His other book — less famous, but in my opinion just as powerful — is Competing Against Luck.

If you haven’t read it, stop what you’re doing and go buy it. If you don’t have time, scroll down. I’ll give you the 90-second essentials.

Make it Real

Get the template 👇. Subscribe and Comment “Anatomy” to get it.

Subscribe now

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. I’ve acquired companies and been acquired. I’ve raised rounds and written checks into others. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

1. “Hope is not a strategy.”

Some of the best leaders I’ve worked with treat this as a governing principle, not a slogan. Everything can be decoded, understood. Solutions to problems can be orchestrated as systems. Everything happens for a reason — and to succeed, you have to learn to decode the source of events instead of waiting for things to work out.

2. Customers don’t buy products. They buy a solution to a problem.

This is what Christensen calls Jobs Theory — the same framework I broke down in Part 2. Customers “hire” your product because they need it to perform a job. Not because of the feature list. Because of the job.

3. Start from the customer’s problem and work backwards.

To succeed, you need to understand the job buyers want to assign to your product. In the enterprise, we usually call that a “use case” — but it’s the same idea, just wearing a different badge.

4. Understand the why.

Dig into the emotional, social, and logical reasons behind the use case. Why do they need this job done? What does it actually mean to them, and to the people they care about? This is the same territory as the “outcomes and goals” questions from Part 2 — asking why a goal matters instead of just what someone’s trying to do.

5. Document the how.

Understand the journey the customer takes for this job. How did they behave before your solution existed, or without it?

6. How do you unlock the pain?

Once they have your solution, how does their journey actually change? How do you make their life better? What hurdles and moments of frustration have you genuinely removed?

7. Quantify your value.

When you review your solution honestly, how do you assess its value to the buyer? Does it make their life ten times easier? Did they have to build new habits to get there? People are creatures of habit — the more your product simplifies their life without disrupting the habits they already have, the better.

Now What?!

Go back to Part 1 and find your Bullseye. Then take your best customer inside that Bullseye and run them through these seven. If you can’t answer all seven honestly, you don’t have a customer story yet. You have a testimonial with no mechanism behind it.

Subscribe now

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share If you’re into this kind of content, please subscribe and share it.

A hedge fund built its entire thesis on ignoring that distinction this year, and the market just corrected it to make this point.

The bet was simple: AI models can do the work enterprise software does, so the software itself is worthless. Forget the software companies, buy the compute buildout underneath them. Sounds clean on a whiteboard. Over one month, it inverted completely — the shorted software names ripped double digits higher, the compute longs fell just as hard the other way.

Here’s why the thesis was always going to break, and it’s the same gap I flagged in Nobody Cares About Your AI VP of Product: software maintenance runs 60-80% of total lifecycle cost, not the initial build.

That number doesn’t shrink because a model wrote the first draft faster. If anything it gets worse, because now the thing being maintained is code nobody on the team actually understood when it shipped.

You might remember my frustration when I wrote about “A Mess for Less”: AI-generated code carries measurably more security flaws, not fewer, and the danger was never the code itself, it’s who’s holding the keyboard and whether anyone’s actually reviewing what gets accepted.

Step one got cheaper. Step two — the part that was always the real cost — didn’t move.

This also connects to the point I made in It’s Not About the Agents: agents and models are commodity ingredients now, interchangeable and cheap.

That’s the actual lesson sitting with this situation, underneath all the leverage and the headlines: building was never the moat.

Operating, validating, and being trusted to keep operating — that was always the science. Mistake that for something a model and a wrapper can shortcut, and the market is not gentle about the correction.

Except the “great” part is where the promise quietly falls apart — and I didn’t coin that phrase. A friend of mine, the CTO of a startup I helped launch, did. It’s been stuck in my head for months.

In this post I make the case for “scaling expertise” instead of falling for the hype that AI code is automatically more secure than human code.

For those who think AI can help their team develop better code by default: beware the “accept” button as much as you’d beware the “I have read the terms and conditions” button.

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. I’ve acquired companies and been acquired. I’ve raised rounds and written checks into others. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

Subscribe now

Myth: AI Writes More Secure Code Than Humans

It sounds sophisticated. It’s the kind of claim that gets nods in a boardroom. It also confuses two very different questions.

And here's the part nobody wants to say out loud: the danger was never the code. It's who's holding the keyboard.

Veracode tested output from over 100 large language models across 80 real coding tasks. 45% of the code samples introduced a known security flaw. Not obscure edge cases — classic OWASP Top 10 problems, the kind a junior engineer gets caught on in code review.

And here’s the finding that should worry you more than the headline number: that 45% failure rate hasn’t moved in two years, even as models write syntactically correct code more than 95% of the time. A newer, more capable model does not, on its own, write safer code.

CodeRabbit’s analysis backs this up from a different angle — AI-generated code produces roughly 1.7x more issues than human code overall, with security vulnerabilities specifically running 1.5x to nearly 3x higher, concentrated in exactly the mistakes a junior engineer would be caught making: improper password handling, insecure object references.

The machine isn’t dumb.

It learned from us — from decades of public code, plenty of it insecure — and now it’s handing that same pattern to anyone, at machine speed, with total confidence and zero judgment about when it applies.

Subscribe now

The Immune System AI Bypassed, Not Strengthened

For thirty years, bad architecture had natural predators: the code review, the senior engineer, the painful question “why did you build it this way?” That friction was annoying. It was also the immune system. It caught the rot before it spread.

AI didn’t make that immune system stronger. It bypassed it entirely.

Now someone who’s never designed a system can generate a thousand lines that compile, run, and look completely professional. The output got polished. The understanding underneath might not.

It's every session, every suggestion, every "yes, do that" without reading what "that" actually is.

The first few times feel like progress, because nothing broke. So you keep clicking. And this is where it compounds: each unread "yes" doesn't just add risk, it stacks on every "yes" before it, quietly increasing the odds that one of them was the one you needed to actually read. By the time it matters, you've trained yourself not to.

So no, it doesn’t look like AI-built code is inherently more secure. I don’t think it’s inherently less secure either. I think it’s a mirror. It reflects the judgment of whoever’s driving.

• In good hands — someone who can read the output, catch what’s wrong, know which 5% of the codebase needs a human eye — it’s real leverage.

• In the wrong hands, it’s just a faster way to build something you’ll regret, with more confidence than the mistake deserves.

That’s the real story behind “a mess for less.” You’re not saving money. You’re deferring the bill, because architectural mistakes don’t announce themselves on day one. They wait. They surface at scale, at three in the morning, when the thing nobody on your team ever actually understood breaks in a way nobody can diagnose — because the person who “wrote” it never designed it, they just accepted what compiled.

Now What?!

Pull up the last piece of AI-generated code your team shipped without a senior review. Ask two questions:

1. Does anyone on the team actually understand why it’s built this way?

2. Would it pass the same scrutiny a junior engineer’s pull request would get?

If the honest answer is “NO” to either one, you didn’t save time. You bought a mess, and you just haven’t been sent the invoice yet.

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share If you’re into this kind of content, please subscribe and share it.

It’s the wrong story.

This post is about the transmission.

Specifically: how to think about token cost vs token efficiency, the difference between open weights and open source, what gets in the way of “AI Value” (hint: inability to design for hybrid complexity) and finally what components your “control plane” requires to optimize your today and protect your tomorrow.

BTW - if you’re interested in more controversial takes like today’s, you’ll probably like the post where I explain how “Jensen Huang is wrong” about his “AI Layer Cake” here.

Frontier Models & Operationalizing AI

Alright. Back to the “ROI of AI” and “Model Confusion” debate.

I’ve been observing a real bifurcation happening underneath all the benchmark noise, and most media coverage. There are really two paths being played right now:

• One path is building frontier models — general intelligence, chasing the next leaderboard and super-intelligence.

• The other path is operationalizing AI for your company: securing it, governing it, integrating it with the legacy infrastructure that actually runs the business.

The second path IMHO is the bigger conversation. I know model leaderboards are sexy and that “we built the orchestration layer” isn’t.

BUT, I spend a lot of time with customers, trying to understand the patterns that lead to AI success…and believe when I say: Orchestration across models, deployment types, clouds..etc…is where the game is at today (you might remember the piece I published about a year ago - feels like an eternity now): AI isn’t about Agents.

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. I’ve acquired companies and been acquired. I’ve raised rounds and written checks into others. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

Models: The Myth, The Legend…but not the “Product”

The Model isn’t the product. Every CFO who’s opened an AI invoice this year has learned that the hard way.

That’s not a rounding error in a budget. That’s an entirely new, unpredictable cost category finance teams weren’t built to forecast.

And here’s what that spending is actually buying. The real picture isn’t two tiers, it’s three — and knowing which task belongs in which tier is the entire game:

This reminds me a bit of the old adage: "Half the money I spend on advertising is wasted; the trouble is I don't know which half." Same problem here. The job of your control plane is to figure out which 5% of your workload actually needs the $75 model — before you've paid for the other 95% to find out the hard way.

Today, distribution looks a little bit like this:

1. Frontier reasoning models run $5-15 per million input tokens and $25-75 per million output tokens — reserved, in a well-run enterprise stack, for roughly 5% of workloads: the genuinely high-stakes logic, legal synthesis, and complex architecture decisions where the premium is worth paying.

2. Workhorse mid-tier models ($1-2 in, $6-12 out) carry the next 30% — production coding, long-context retrieval, the general business logic that doesn’t need frontier reasoning but needs more than a classifier.

3. Lightweight, open-weight models ($0.10-0.30 in, $0.30-0.60 out) — the Llama-Scout, Flash-Lite class — absorb the remaining 65%: sub-second extraction, classification, high-throughput intent routing. That’s not a rounding error in allocation.

That's roughly a 150x price gap between the top and bottom tiers, and most of your volume should be living at the cheap end of it.

Routing a classification job to a frontier model is taking the Ferrari to the grocery store. It gets you there. You just paid supercar money to haul a gallon of milk.

OK. But why are “Open Models” cheaper?!

I’ll explain this in a minute. But first, let’s make sure we’re on the same page.

One distinction worth being precise about: “open-weight” and “open source” are not the same thing. Yet, most coverage uses them interchangeably today.

The Difference between Open Source & Open Weight?!

• Open source, in the traditional software sense, means the full recipe is public — training data, training code, methodology, and a license to inspect, modify, and redistribute freely.

• Open-weight means you get the trained parameters and usually the inference code, enough to run and fine-tune the model yourself — but not the original training data, not the full pipeline that produced it, and often with licensing restrictions once you cross certain usage or scale thresholds.

That distinction isn’t pedantic. If you can’t see the training data, you can’t fully audit provenance or bias, which is precisely the kind of gap a real governance layer has to account for rather than assume away.

Here is a reference guide to help you decipher what’s what:

OK. Now. Why are “Open Models” cheaper?!

Four reasons, primarily:

• First, distillation — instead of paying the hundreds of millions of dollars it costs a frontier lab to discover good reasoning paths from scratch, open labs query an existing frontier model for millions of answers and train a smaller model directly on those outputs, skipping the expensive exploration entirely.

• Second, they skip the cold start — nobody’s training from a blank slate; they’re fine-tuning existing open base weights with domain-specific data, a fraction of the compute.

• Third, architectural efficiency — Mixture of Experts routes each query to only the relevant sub-network instead of activating the whole model, and quantization compresses weights enough to run on standard or even consumer-grade hardware.

• Fourth, and simplest: zero proprietary margin. Closed labs price tokens to recover massive R&D budgets and investor return expectations. Open-weight pricing reflects something closer to the actual electricity and compute cost, because there’s no markup layered on top.

Token Economics, Tokenmaxxing, raw token usage, and token efficiency

All the above is great BUT a token isn’t a token isn’t a token. The frontier labs’ counter-argument is a real one, and worth taking seriously: raw token price might be the wrong metric.

A cheaper model that needs three re-prompts and a longer reasoning chain can erase its sticker-price advantage fast. That’s not wrong. It’s also, without realizing it, an argument about the layer above the model, not about the model itself — which is the whole point of this piece.

Bottom Line: even the best defense of frontier pricing turns out to be an argument about orchestration.

The Hybrid Reality Nobody Wants to Admit

Here’s what the benchmark wars conveniently ignore: no real company runs on one model, one cloud, or one architecture.

That’s not a transitional mess on the way to something cleaner. That’s the permanent operating condition. It gets more hybrid from here, not less.

The Missing Layer: A Control Plane With Four Dimensions

This is where the real moat lives. Agents and models become commodity ingredients, plural and interchangeable.

• Cost. Automatic, task-level routing across at least three tiers of model, not two — frontier reasoning for the 5% that actually needs it, a mid-tier workhorse for the 30% of general business logic, and cheap open-weight models absorbing the remaining 65% of high-volume, low-complexity work. And increasingly, outcome-based pricing rather than raw token billing, so nobody’s micromanaging consumption the way you’d never want to be billed for Gmail by the CPU cycle.

• Governance. Data sovereignty, audit trails, and instructions the system is architecturally forced to obey, not merely interpreting. This is exactly where the open-weight-versus-open-source distinction bites: you can’t govern what you can’t fully audit.

• Models. Plural, by design. Open-weight for cost-sensitive volume, proprietary for the edge cases that justify the premium, and the flexibility to swap either the moment pricing or policy changes.

• Clouds. On-prem, multi-cloud, edge — routed and governed as one system, not stitched together by whichever engineer built the last integration.

Now What?!

Pull up your current AI spend and ask:

If the honest answer takes more than one meeting to assemble, you don’t have an AI strategy. You have a pile of expensive experiments that happen to share a budget line.

I see customers headed to the era of “Systems of Actions” and I’m concerned that without clear answers to the above, maturation into that phase will take longer that it needs to.

A good follow on read to today’s post could be: Nobody Cares. About Your System of Intelligence.

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share If you’re into this kind of content, please subscribe and share it.

If you liked this piece, you’ll also like:

• How To Get ROI from AI: “50 Shades of Hybrid”

• Nobody Cares. About Your System of Intelligence.

• It’s NOT About The Agents: What Most Generative AI Playbooks Get Wrong.

• Where Jensen is wrong.

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

Subscribe now

Myth: All Roadmap Items Are Created Equal

They’re not, because they don’t all come from the same place. Every line on a roadmap traces back to one of three sources, and only one of them reliably makes money.

The Three Sources

Competitor Envy. “They shipped it, so we need it too.” No customer asked. No insight behind it. Just a fear response dressed up as strategy.

Exec Opinion. Someone senior had a thought in the shower and now it’s Q3’s top priority. Sometimes right. Never validated before it lands on the roadmap.

Customer Insight. Something you learned, first-hand, from a customer’s actual behavior or actual words — not what they said they wanted, what they’re actually stuck on.

The Audit

Take your current roadmap. Label every line: C (competitor), E (exec), or I (insight). Don’t rationalize — if you can’t point to the specific customer conversation or behavior data behind a line, it’s not an I, no matter how confident you are that customers would want it.

Most PMs run this exercise once and go quiet for a minute. That’s the point. If your roadmap is mostly C’s and E’s, you’re not behind on execution — you’re behind on listening, and no amount of shipping speed fixes that.

Why the Ratio, Not the Source, Is What Matters

Competitor and exec-driven items aren’t inherently wrong — sometimes the competitor’s right, sometimes the exec’s shower thought is good.

The problem is a roadmap with none of the third category, because that’s a roadmap nobody outside the building actually asked for.

Now What?!

Run the C/E/I audit on your roadmap this week. If you want the mechanism for actually capturing the “I” category systematically instead of accidentally, Friction Logs is where I break down how.

Make it Real

Get the template 👇. Subscribe and Comment “Friction” to get it.

Subscribe now

My Thoughts. My Thoughts Only.
The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share
If you’re into this kind of content, please subscribe and share it.

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

Subscribe now

Myth: Difficult Stakeholders Are a People Problem

They’re not. They’re a pattern problem. The same five archetypes can show up on any team, at any company, in any review — and once you can name them, you start managing them.

Five Animals, Five Tactics

The HiPPO. Highest Paid Person’s Opinion. Doesn’t argue with your data — ignores it.

Tactic: don’t debate the HiPPO in the room. Get their opinion in writing before the meeting, then let the data do the disagreeing in front of the group, not you.

The Scope Creep. Adds “one more thing” to every spec, every time, sincerely believing each addition is small.

Tactic: every addition gets priced in the room, out loud, against the current timeline. Make the cost visible the moment the ask is made, not two weeks later in a status update.

The Silent Killer. Says nothing in the review. Kills the initiative in a hallway conversation with your boss’s boss an hour later.

Tactic: end every review by asking every attendee, by name, “anything you’re not saying here that you’d say elsewhere?” Awkward once. Effective forever.

The Weathervane. Agrees with whoever spoke last. Today’s champion, tomorrow’s skeptic, no memory of the flip.

Tactic: written decisions with a name attached, sent within an hour of the meeting. Memory problems don’t survive a paper trail.

The Feature Factory Foreman. Measures your team’s worth in tickets closed, not problems solved.

Tactic: report in outcomes, not output, every single time — even when output is the easier number to defend in the moment.

Why This Matters More Than It Sounds

This isn’t about people being difficult. It’s about a PM who names the pattern operating like a GM who’s managed a board before — expecting the friction, not absorbing it as a surprise every quarter.

The PM who hasn’t named these animals yet is the one who leaves every stakeholder review wondering what just happened.

Now What?!

Think about your last three difficult stakeholder moments. Which animal was each one? If you can’t name it, you’ll meet it again next week, in the same disguise.

My Thoughts. My Thoughts Only.
The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share
If you’re into this kind of content, please subscribe and share it.

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

Subscribe now

Myth: Bad Prioritization Is a Methodology Problem

It isn’t. I’ve watched teams run textbook-perfect RICE scoring, present it beautifully, and then abandon the ranking the moment a VP frowns at slide four. The framework didn’t fail.

What a Prioritization Framework Is Actually For

It’s not a scoring model. It’s a pre-commitment device — something you agree to believe in before the pressure shows up, specifically so you have something to point to when the pressure shows up.

If you’re deciding whether to trust the framework in the same meeting where someone senior is pushing back, you’ve already lost. The commitment has to happen earlier, alone, when nobody’s watching.

Three Ways to Actually Hold the Line

Get sign-off on the method before you run the scores. Not the results — the method. If your VP agreed in advance that customer impact matters more than internal convenience, they’ve pre-committed too, whether they remember it in the moment or not.

Bring the framework into the room, not just the conclusion. “This is ranked third” invites debate about the ranking. “Here’s the scoring, here’s how we weighted it, here’s where it lands” invites debate about the inputs, which is a much more productive argument to have.

Let one exception cost something visible. If the SVP wants to jump the line, fine — but something else on the list moves down, in front of everyone, named specifically. Free overrides breed more overrides. Priced overrides happen a lot less often.

Why This Is the Real Skill

Anyone can learn RICE in an afternoon. Holding to it under pressure from someone who signs your review is a completely different skill, and it’s the one nobody teaches because it’s uncomfortable to admit you need it.

Now What?!

Think back to the last time you caved on a prioritization call. Was the framework wrong, or did you just not have the spine ready when it mattered? Be honest — that’s the whole exercise.

My Thoughts. My Thoughts Only.
The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share
If you’re into this kind of content, please subscribe and share it.

Wrong question IMHO. The right question seems to be: “Am I the kind of worker AI is going to make unstoppable?”

Don’t believe me? The New York Times recently ran a piece on Box CEO Aaron Levie.

His takeaway? AI has already created 13 new job categories at Box that didn’t exist two years ago — roles like agent engineers, AI model evaluators, and internal automation engineers. He wasn’t eulogizing old jobs. He was cataloging new ones.

The 5 Levels of AI Worker Maturity

I’ve been in this field for close to 3 decades and I’ve learned a lot from customers. When it comes to AI Worker Maturity, I’ve witnessed that there are a least 5 levels.

See them below (and a way to assess where you for each). Let me know how this works for you, if there is anything I miss…and what level you think you are!

Want this template? 👇

Subscribe, Comment “Leader” and I’ll DM you the link!

Subscribe now

Level 1 — The Passenger

AI comes to you. You accept the ride.

You’re using AI because it’s already embedded in tools you already have. Microsoft Copilot summarizes your emails. ChatGPT writes a draft when you’re stuck. Notion suggests a title. You didn’t seek it out — it just showed up in the interface.

This isn’t nothing. But it’s the minimum. You’re not driving.

Level 2 — The Co-Pilot

You’ve picked up the controls — a little.

You’re now actively seeking AI out. You prompt deliberately. You’ve started saving real time on tasks you used to grind through manually. Research that took 2 hours takes 20 minutes. The first draft of a deck takes 10 minutes instead of 90. You’re experimenting. You’re curious.

This is where most professionals think they’ve “figured it out.”

Level 3 — The Navigator

You don’t just use AI. You flow with it.

AI is now woven into your daily process. You chain tools. You’ve built custom prompts or workflows. You use agents to handle repetitive loops you used to own manually. You’re not saving hours here and there — you’re restructuring how entire workstreams run.

This is the level where real professional leverage begins.

Level 4 — The Architect

You design the systems others run on.

You’re not just using AI for yourself — you’re thinking about how your team, your function, or your org should be using it. You design AI-assisted workflows. You set standards. You’re the person others come to when something breaks or they want to know what to try next.

This is where individual contributors become institutional assets.

Level 5 — The Builder

You build what others ride on.

You build, orchestrate, or govern AI systems at scale. You’re creating infrastructure — agent pipelines, evaluation frameworks, governance layers, fine-tuned models. Others depend on what you ship. Your work multiplies across the org.

This is where the 13 new job categories Aaron Levie was talking about live.

The Honest Question

Here’s your homework: Where are you, really?

Not where you think you are. Not where you’d like to be at your next performance review. Where you actually operate day-to-day, right now, this week.

Great clickbait. I clicked. You probably did too.

Then I read it. Two people vibe coding 8 to 12 hours a day. Concurrent sessions. Agents debating agents. Apps replacing apps. Migrations declared “done” in an hour.

Subscribe now

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. I’ve acquired companies and been acquired. I’ve raised rounds and written checks into others. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

The real story is orchestration. The real story is hybrid.

Buried in the middle of the hype is the only insight that matters: no single model runs the show. I called this “50 shades of hybrid” earlier this year.

Look closely at any of these “one AI to rule them all” setups and you find a committee. One model reviews. Another builds. A third one — often from a rival lab — checks the architecture. Different models, different contexts, different strengths.

That’s not a fun coincidence. That’s the architecture.

Nobody puts that in the headline. Because “we built a hybrid orchestration layer with human judgment at the top” doesn’t go viral.

Problem is. That’s really what works.

Subscribe now

Locking yourself to one model is a baaaad idea.

If the last few months taught us anything, it’s this: frontier models are not just infrastructure. They are geopolitical assets.

We watched a frontier lab’s most advanced models get frozen under export controls for weeks. We watched another lab launch its flagship in restricted mode, limited to a small set of vetted partners. Models get deprecated, re-priced, rate-limited, and pulled — with a blog post, or without one.

Now re-read the headline. “LLM X is my VP of Product.”

What happens to your product org when your VP of Product gets export-controlled?

If your answer is “I’ll wait for it to get better,” you don’t have a strategy. You have a dependency. You’ve handed your operating model to someone else’s roadmap and called it velocity.

Multi-model isn’t paranoia. It’s the same discipline as multi-cloud, second sources, and succession planning. Boring. Unsexy. The stuff that keeps you alive.

Building is not the cost. Operating it moving forward is.

I know it’s romantic (and somewhat rewarding) to say that you and your teamate can vibe code your way to a new application stack. I know it sounds amazing that you could click your way through a few prompts and build the “next big app”.

Over a product’s full life, that maintenance bill typically runs two to four times what it cost to build the thing in the first place, and for complex enterprise systems, some studies push that multiple even higher.

That’s the number before AI entered the picture. Nobody has good data yet on what that multiple looks like when the code was vibe-coded by an agent instead of understood by an engineer — but early research on AI-generated code points the same direction, only worse, because you can’t cheaply maintain what nobody on your team ever actually understood.

This is the vanity nobody wants to give up: “I can just build whatever.” Building was never the hard part, and it’s about to get even easier. Maintaining and evolving something that keeps working, stays secure, and doesn’t quietly rot the moment the model behind it changes — that’s the actual job.

The question was never “can you build it.”

Everything can be built now. That’s the point of this era.

Which means “can we build it?” isn’t the right question to ask. The living question is: should you?

Every app you spin up is inventory. It has to be secured, maintained, monitored, and operated — by someone, forever. Even the loudest builders admit it, usually in the last paragraph: they can’t operate everything they’ve already built. Their own agents are telling them to slow down and consolidate.

Read that again. The agents are telling the humans to stop.

And a word on vibe coding, because we need one.

This Isn’t the First Time. It Won’t Be the Last.

A few months ago, the same crowd was telling you to run OpenClaw inside your organization — an autonomous agent that plugs into your email, your calendar, your messaging apps, and just does things. It went from zero to over 200,000 GitHub stars faster than Docker or Kubernetes ever grew. The hype was identical to this week’s: unprecedented autonomy, unprecedented leverage, get on board or get left behind.

Then a tech executive told her OpenClaw instance to “confirm before acting” before letting it near her inbox. It didn’t confirm. It deleted messages at speed while she scrambled to shut it down from another device. Hundreds of emails, gone. Somewhere else, an OpenClaw-connected assistant, during an actual fire alarm, told someone “no need to leave.”

Those aren’t edge cases. They’re what happens when “confirm before acting” is a sentence a language model is interpreting, not a safety mechanism it’s obeying.

The gap between those two things is exactly the gap nobody puts in the headline — for OpenClaw in February, and for the AI VP of Product this week.

The Uncomfortable Truth

I’ve spent close to 30 years shipping products at places like Google, Microsoft, Oracle, and startups all the way through IPO. The names of the tools change every few months now instead of every five years. The failure mode never does:

Now What?!

Pick one thing your team built in the last 90 days because it could be built.

Ask what it costs to operate for the next three years — in money, attention, and risk.

If maintenance really does run two to four times the build cost, put a real number on that, not a guess. Then ask who’s accountable when the model behind it changes.

Would you still build it?

My Thoughts. My Thoughts Only | The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share | If you’re into this kind of content, please subscribe and share it.

You might not like this but: Most of the “data” people cite to make predictions is noise dressed up as signal.

Head-to-head records. All-time win percentages. “This team always struggles against that style.” Sounds rigorous. Sounds like analysis. Most of it is astrology IMHO.

The inconvenient truth is that this isn’t just a sports problem.

I’m willing to bet that most predictions you’ll read lean on a storyline, propped up by exactly this kind of noise:

• “Messi’s redemption arc. Argentina defending the crown.”

• “England always beats France.”

OR, even better:

• In the last 9 games England has played against France, they’ve won 3 — France has won 5, with 1 draw.

• In the last 9 games Argentina has played against Spain, they’ve won 2 — Spain has won 5, with 2 draws.

Great headlines. Data looks legit. But the last time England played France was in 2022 — a 2-1 France win in the World Cup quarterfinal — and the last time Spain played Argentina was in 2018, a 6-1 Spain win in a friendly.

Think about what's changed since then. On the England-France side, half these rosters have turned over and managers have changed on both sides. On the Spain-Argentina side, it's worse: Messi alone has played eight more years of football since that scoreline, in a completely different phase of his career.

And that Spain-Argentina number is even worse than it looks: a 6-1 scoreline from a friendly, eight years ago, against a team that’s since rebuilt itself around a different generation.

A “recent” head-to-head sample that’s actually four to eight years old isn’t recent. It’s just old data wearing a current-sounding stat — and in Spain’s case, it’s an old blowout wearing a predictive one.

BEFORE we go any further — two quick polls. Vote before you read the rest of the blog, then come back and see how your gut compares to the math:

Bronze Medal Match Survey

WorldCup Final Match Survey

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. I’ve acquired companies and been acquired. I’ve raised rounds and written checks into others. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

Subscribe now

Myth: More Data Means a Better Prediction

It doesn't. Volume isn't the same as signal, and most of what gets cited as "the data" for a prediction is just noise that happens to be true.

So instead of listening to headlines and storylines, I suggest we look at a set of more relevant stats that could give us a sense of where the teams are at — mentally and physically. I see a few meaningful factors to consider.

The Schedule Math: England 🏴󠁧󠁢󠁥󠁮󠁧󠁿 Has It Hardest

Calculate the average FIFA ranking of every opponent a team had to beat to reach this point, and a picture emerges that has nothing to do with storylines.

A lower average opponent rank means a harder path — you were beating better teams to get here, not worse ones. For example:

• England played DR Congo (46th), Mexico (14th), and Norway (31st) — never facing an opponent ranked below 46th on their way to a tournament-hardest 26.1 average opponent rank.

• Spain conquered a brutal 26.4 average rank gauntlet, cleanly dispatching Portugal (5th), Belgium (9th), and France (3rd) in their toughest three tests — all without playing a single minute of extra time.

• France ground through a 27.3 average rank—navigating tricky tests against Senegal (15th), Norway (31st), and a brilliant Morocco (7th) side.

• Argentina played Cabo Verde (67th), Egypt (29th), and Switzerland (19th) — opening their tournament against a team ranked outside the world's top 60 and coasting through a significantly lighter 33.4 average opponent rank.

The Biological Ledger: Argentina 🇦🇷 Has Played the Most

• Argentina logged the most minutes of the four semifinalists — 690, the product of needing extra time in two separate knockout matches, including a stunner from Julián Álvarez to get past Switzerland in the quarterfinal. No team worked longer for their spot in the final.

• England played 660 minutes, pushed into extra time once — a 2-1 win over Norway in the quarterfinal — before running out of legs against Argentina in the semifinal.

• Spain and France both wrapped every single match in regulation: 630 minutes each, zero extra time, the two most efficient paths to the final week.

Subscribe now

Distance: England 🏴󠁧󠁢󠁥󠁮󠁧󠁿 Traveled ~6x What France 🇫🇷 Did

• England traveled the farthest of any semifinalist — nearly 13,000 miles, a genuine cross-continental grind from match to match.

• Argentina covered ~5,654 miles, more than double Spain’s total but still a fraction of England’s.

• Spain kept it relatively contained at ~3,500 miles.

• France had the shortest journey by far — just ~2,200 miles, a comparatively local run through the tournament.

Recovery, Schmecovery? England 🏴󠁧󠁢󠁥󠁮󠁧󠁿 - France 🇫🇷 = 1 Day

• England had the least recovery time of the four — an average of just 3.1 days between matches.

• Spain had marginally more breathing room at 3.3 days.

• Argentina averaged 3.9 days of rest.

• France had the most recovery time by a clear margin — 4.2 days between matches.

Jet Lag?! Spain 🇪🇸 Went Coast to Coast, Nobody Else Did

• Spain was the only one of the four semifinalists to cross three time zones — Eastern (Atlanta), Central (Guadalajara, Mexico and Arlington, Texas), and Pacific, for their quarterfinal against Belgium at SoFi Stadium in Los Angeles. No other semifinalist left the Eastern-to-Central corridor.

• England also crossed into a second country, playing their Round of 16 match against Mexico at Estadio Azteca in Mexico City — the only match of their entire run played outside the United States.

• Argentina and France never left the U.S. all tournament — Argentina bouncing between Central (Dallas, Kansas City) and Eastern (Miami, Atlanta), France doing the same between Eastern (New Jersey, Boston, Philadelphia) and Central (Dallas, for the semifinal against Spain).

Subscribe now

Mentality: How You Think Is Everything

One factor doesn’t show up in any table, and it matters as much as the five that do. England led Argentina 1-0 in the semifinal. Then the mentality shifted — protect the lead instead of extend it — and Argentina scored twice.

That’s not a fluke. It’s one of the hardest things to recover from in sport or in business: once a team stops playing to win and starts playing not to lose, the opponent feels it before the scoreboard shows it.

Data tells you who’s fresher. Mentality tells you who’s still actually trying to win — and it’s the one input on this list that a spreadsheet can’t capture.'

The Predictions

So based on the data: opponent strength, minutes played, distance traveled, recovery time, and how far each team's body clock got dragged across the map — the closest we could get is…

Bronze, Saturday — France vs. England

• England has played more minutes, traveled nearly six times the distance, and rested a day less. Their tank is close to empty after the heartbreak against Argentina. France, fresher and less traveled, is better positioned to dictate the game. Also feels like the relationship coach and team have different dynamics (England here, France here).

• Prediction: France 🇫🇷, 2–1.

The Final, Sunday — Spain vs. Argentina

• Spain faced the tougher schedule and still conceded only two goals all tournament. Argentina faced the easier bracket and still needed extra time twice to get through it. Betting against Messi in a final is never comfortable. The math doesn’t care about comfortable.

• Prediction: Spain 🇪🇸, 1–0.

…and yes…I’m a little biased. There is more though. Scroll down for the business lesson!

Subscribe now

The Business Lesson Underneath the Football

This is the same discipline I keep coming back to in this newsletter, just wearing a different jersey:

• "We've always won this kind of deal" is a boardroom head-to-head record — technically true, four to eight years stale, worth exactly as much as a 6-1 friendly from 2018.

• A compelling narrative — the founder's vision, the hot new entrant, "this is their year" — is not a substitute for the underlying operating reality: how much runway is actually left, how depleted the team actually is, what the real schedule of demands has actually been, and whether the team is still playing to win or has quietly started playing not to lose.

The teams and companies that look unstoppable on paper are sometimes just the ones nobody's checked the fatigue numbers on yet.

One Last Thing: Thank You, Didier Deschamps

Whatever happens Saturday, this tournament closes out the most decorated managerial run in World Cup history, and it deserves to be said plainly before the bronze match becomes the whole story.

This is Deschamps’ 14th and final year as France’s coach — he’s stepping down after this tournament, with Zinedine Zidane reportedly set to succeed him. Along the way, he broke Helmut Schön’s 48-year-old record for most wins by a head coach in World Cup history, and separately set the record for most matches ever managed by a coach at a World Cup — 26, one more than Schön managed across four tournaments with West Germany.

Saturday’s bronze match will be his last game in charge. Whatever the scoreline, that resume is already finished, and it’s one of the greatest in the sport’s history.

Now What?!

Look back at the two polls you voted on before reading the data. Did your gut match the math, or did the storyline win?

That gap — between what feels true and what the data says — is exactly the gap worth checking before your next big call at work, not just before a final.

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share. If you’re into this kind of content, please subscribe and share it.

If You Liked The Above, You Might Also Like:

• World Cup: Failure in Leadership? What might make some team just... lose.

• Nobody Cares Who Won. They Care Who’s Left Holding the Loss.

• Spain Was a Pain. Spain Had A Plan. Three Leadership Lessons Hiding in One Sentence.

Your brain is not playing tricks on you. That first sentence was in French. It’s a soccer take, shared by Vikash Dhorasoo on L’Équipe TV. If you don’t know Vikash: French international midfielder, runner-up at the 2006 World Cup, now one of the sharper football minds on French television.

He’s right. And not just about soccer.

England was up 1-0 against Argentina in yesterday’s World Cup semifinal. Anthony Gordon had just scored. Sixty minutes from a final.

Then Thomas Tuchel subbed Gordon off — the man who scored the goal — for a defender. Then two more defensive substitutions.

The result: Argentina equalized, then won it, 1-2.

Within hours, French sports television had Tuchel’s report card up on screen: outdated, individualist, didn’t understand it, fatal error.

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. I’ve acquired companies and been acquired. I’ve raised rounds and written checks into others. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

Subscribe now

Myth: Losing Is a Team Failure

It isn’t, and treating it that way is exactly backwards from how sports — and good businesses — actually assign responsibility. It’s always the team that wins and the coach who loses. Not because that’s unfair. Because that’s the actual deal a leader signs up for.

When England won earlier in the tournament, nobody put Tuchel’s face on a report card. The story was Gordon’s finish, Bellingham’s press, the back line holding shape. The team won. When England lost yesterday, the story wasn’t the back line failing to track a run. It was one man’s substitution, made from the touchline, at the 72nd minute, with the game still England’s to lose.

Why the Leader Owns the Loss Even When the Team Made the Mistake

Here’s the part that’s uncomfortable and true: Tuchel didn’t personally fail to track Enzo Fernández’s run. A player did.

But the decision that shaped the conditions for that moment — pull off your goal-scorer, add defenders, invite Argentina to keep the ball and keep probing — was entirely his. He made the call that turned a team that was winning into a team that was surviving. The players executed the plan. The plan was the problem.

This is exactly how it works in business, and it’s exactly how it should work. When a sales team closes the quarter, the story is the reps, the pipeline, the product. When a launch fails because leadership set an overly conservative rollout plan, hedged on the wrong feature, or pulled resources at the exact moment the team needed them, the postmortem shouldn’t blame the engineer who executed the plan faithfully. It should ask about how the call was made.

The Second Failure: Winning and Not-Losing Are Different Games

Here’s what actually happened at the 72nd minute, underneath the substitution itself: England changed games. Not tactics — games.

Up 1-0, trying to win means keep attacking, keep the pressure that got you the goal in the first place, make Argentina defend for the next twenty minutes instead of the reverse.

Trying not to lose means something else entirely: protect the scoreline, remove risk, invite the other team to have the ball.

Tuchel’s team had spent seventy-two minutes being drilled, all tournament, to play the first game. He asked them, mid-match, with no time to recalibrate, to switch to the second one. That’s the part that should scare you more than the substitution itself.

A team built and trained to attack doesn’t hold a defensive shape well just because the coach asked for one — it holds it nervously, reactively, waiting for the thing it’s not equipped to prevent.

Argentina didn’t beat a defensive England. They beat an attacking England that had been told, at the worst possible moment, to become something it wasn’t.

The business version of this is everywhere, and it’s almost always invisible while it’s happening.

• A sales team that’s crushed its number early starts sandbagging the next quarter instead of pushing for more.

• A product team riding a successful launch goes quiet and conservative instead of pressing the advantage while the market’s paying attention.

Nobody announces “we are now playing not to lose.” It just quietly becomes the posture, usually right after the first sign that winning is actually possible — which is exactly the moment losing becomes affordable to imagine, and exactly the wrong moment to change games.

The Nuance Worth Naming: Bad Outcome Doesn’t Always Mean Bad Decision

One honest caveat, because accountability done badly turns into scapegoating. Sometimes a good decision produces a bad outcome anyway — that’s just variance, in sports and in business both.

If Tuchel’s substitutions had been a sound, defensible read of the match state and Argentina had simply produced a moment of brilliance nobody could have planned for, that’s a different conversation than what actually happened, which was a decision nearly every pundit watching live called wrong in real time, before the outcome even confirmed it.

The test isn’t just “did it work.” It’s “was it defensible before you knew how it turned out.” Tuchel’s subs failed both tests — pundits were calling it a mistake while it was still 1-0. That’s not bad luck.

Subscribe now

Now What?!

Think about the last loss your team took — a deal, a launch, a quarter.

Ask the accountability question honestly: was this a call the team executed, or a call you made? If it’s the second one, the report card belongs on your desk, not theirs — and the sooner you say that out loud, the sooner your team trusts you with the next 1-0 lead.

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share If you’re into this kind of content, please subscribe and share it.

Spain was a pain but Spain had a plan. France never found a way around their system.

But the real story isn’t Spain. It’s what Cherki said afterward. Asked what happened, he didn’t blame the defense, the referee, or bad luck. He said the only team they lost to was themselves.

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. I’ve acquired companies and been acquired. I’ve raised rounds and written checks into others. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

Subscribe now

Myth: “You’re Your Own Worst Enemy” Is One Lesson

It isn’t. It’s two, and they need completely different fixes. Confuse them and you’ll spend a year working on the wrong one.

Lesson 1: Leadership is about Superpowers, Environment & Autonomy

Spain didn’t win by being more talented. They won by identifying exactly what makes France dangerous — space, tempo, room for individual brilliance — and then spending an entire game plan constructing the opposite. Cucurella glued to Mbappé. No space, anywhere. That’s not defense in the passive sense. That’s construction, done on purpose, before the match even started.

The leadership version: your job, as a leader, is to:

1. Understand your teammates'‘ superpowers.

2. Create the conditions that let their superpowers show up in the biggest way.

3. Get out of the way!

Spain reverse-engineered this process. They:

1. Understood France’s individual superpowers.

2. Created an environment that prevented them from being expressed.

3. Got in the way in every way: with the ball and without the ball.

Lesson 2: Don’t Lose to…Yourself

This is the one Cherki actually named, and it’s a different animal from ambition entirely. It isn’t about aiming too low. It’s about building ways of working that sabotage a team even when it’s aiming high enough.

In the corporate context, this looks like:

• The approval chain that adds two weeks to every decision.

• The review process built to prevent one bad outcome that now prevents every fast one.

• The meeting cadence built for alignment that now mostly produces meetings.

None of it comes from low ambition — often the opposite. A team that cared enough to build guardrails, and never went back to check whether the guardrails had quietly become the whole track.

The second way to lose to yourself? Not aiming high enough.

A leader who sets a target low enough to hit comfortably instead of one big enough to stretch the team. Like the adage says: I’d rather aim high and fail than aim low and achieve.

Aiming low doesn’t just cap the outcome, it caps what you ever find out your team was capable of. A leader who isn’t actively building an ambitious environment isn’t protecting anyone. They’re quietly deciding, in advance, how good the team is allowed to become.

Why You Have to Fix Both, Separately

Fix only ambition, and you’ll set a bigger target and run it through the same broken process — hitting the ceiling anyway, just a higher one.

Fix only process, and you’ll build something beautifully efficient aimed at a target too small to matter.

Cherki’s sentence holds both failures at once, which is exactly why it’s worth more than a highlight-reel quote. It’s a diagnostic with two separate answers, and most teams only ever treat one.

Now What?!

Ask both questions, separately.

• First: is our ambition actually big enough that failing at it would teach us something — or have we quietly aimed low enough to guarantee a comfortable win?

• Second, independent of ambition: what way of working have we built that’s now limiting execution more than it’s protecting quality? If you can only answer one honestly, that’s the lesson you’ve been skipping.

One Last Thing: The Best Teams Bounce Back

Here’s the part that should actually give France hope, and it’s not a platitude. Didier Deschamps has done this exact bounce-back before, in this exact job.

In 2016, as head coach, he lost the Euro final on home soil, in extra time, to Portugal — as painful a loss as a coach can absorb. Two years later, he won the World Cup.

That’s not luck repeating itself. That’s a coach who went back after a gutting loss and actually fixed something — not just “tried harder” with the same team and the same process, but changed what needed changing.

See You Soon Spain!

Good luck to Spain in the final — they earned it, and it showed. And to France: Deschamps has shown France we can turn a gutting loss into a trophy.

If we’ve done this once, we can do it again. See you at the Euros in two years…and Allez Les Bleus!

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share If you’re into this kind of content, please subscribe and share it.

What you probably don’t have is a reason to believe they’re part of the same system.

New here? I’m Bruno — almost 30 years at the intersection of Product and GTM at Google, Microsoft, and a handful of startups through IPO. Nobody Cares is where I share the tactics I wish I had when I started — short notes, no jargon. If you like this, consider subscribing (it’s free).

Subscribe now

Myth: These Are Seven Separate Documents

They’re not. They’re one flywheel, and most PMs are spinning seven disconnected wheels instead of one connected one — which is why so much strategic work feels like starting over every quarter instead of building on what came before.

The Flywheel

Subscribe now

Make it Real

Get the template 👇. Subscribe and Comment “MRD” to get it.

Subscribe now

Here’s the sequence, and the rule that makes it a flywheel instead of a checklist: every spoke has to trace back to the one before it, and the last spoke feeds back into the first.

1. The MRD (Market Requirement Document). Defines the market need and the strategy for a product — not features, not a wishlist, the actual belief about what the market needs and why you’re positioned to deliver it.

• I’ve written the full case and provided a template for this one here.

• The MRD is the anchor document of your product strategy

• At its core, it answers 3 key questions: 1) What Will Change 2) What Will Not Change and 3) What Opportunities Does That Create For Your Company & Product.

• The MRD is where most of your customer research comes together. You highlight customer patterns, identify what is uniquely solvable for you and your company, you point to your beliefs, your key differentiators and the value customers will experience when you deliver your product.

• The MRD lives in the context of your Strategic Roadmap. If done well, it should connect with other products’ MRDs by a a set of beliefs and differentiation pillars the roadmap shares.

2. The Strategic Roadmap. Where the MRD gets a timeline. This is also where the Innovation Layer Framework comes in — a lens I’ve used to make sure a roadmap isn’t secretly 100% maintenance work wearing a strategy costume.

• Every initiative sits in one of three layers: In the Game (parity work, keeps you in the conversation), Catch-up (closing a gap a competitor already opened), or Differentiation (the bets nobody else is making).

• Plot those three layers against Mindshare and Market Share, and the intersection of Differentiation and Market Share is what I call the Gold Mine — the only cell on the grid that’s actually building an unfair advantage instead of just keeping pace.

• I’ve detailed the method I’ve used to deliver on this artifact in this post: Why Most Roadmaps Don’t Work.

• A roadmap with nothing in that cell isn’t a strategy. It’s table stakes with a deadline.

3. The Execution Plan — and the “No Build” List. This is where product items get scored for what actually gets built this cycle.

• Here’s the part most PMs skip: a real execution plan produces a No Build List as a deliberate output, not an accident.

• The No Build List is the named, written-down set of things you evaluated and explicitly chose not to build — not “later,” not “backlog,” “not built”.

• If your execution plan doesn’t produce such a list, you didn’t prioritize. You just made a longer list and called the top of it a plan.

• Note: This List is useful when identifying overlaps across a product portfolio. It forces product leaders to decide, where in the portfolio, a specific capability should be deployed. Do not skip this step, even if it creates friction. This is the best way I’ve seen product plans turn into intentional product strategy.

4. The Business Growth Plan. Strategy for growing and retaining the customers you already have, built on what actually shipped from step 3 — not a wishlist independent of it. Core to this plan is your Revenue Bridge.

• The money case, reconciled against what was actually launched — baseline, adoption, expansion, leakage, landing point.

• I broke the full method down here — this is where you find out whether steps 1 through 5 actually worked, in a language your CFO already speaks.

5. The Launch & Land Tracker. Coordinated go-to-market execution across every team that has to move together for a launch to actually land, not just ship.

Make it Real

Get the template 👇. Subscribe and Comment “LLT” to get it.

Subscribe now

6. The Market Feedback Loop. This is a system that your team design to to synthesize unstructured feedback from fragmented customers, partners, sales, customer success and industry analyst channels to programmatically evaluate requests against strategic corporate goals. At Google, we called it “Cloud blockers” - they primarily represented the patterns experienced by customers that were “blocking” their cloud migrations.

• Decide how you collect “market feedback” at this stage of the process and how you wait that feedback.

• This step will allow you to explain a lot of the “why” you will see during the Monthly Business Review.

7. The Monthly Business Review. Tracks progress, surfaces obstacles — and here’s the flywheel part everyone misses.

• A real monthly review doesn’t just report on the revenue bridge.

• It feeds back into the execution system you’re building.

• The monthly business review IS NOT an opportunity to “pat yourself on the back”

• The monthly business review IS NOT the place executives come to and have “the news read to them”

• The monthly business review IS an operational meeting, with rotational topics, owned across your business teams (Sales, Marketing, Product, Engineering, Customer Success…etc)

• The monthly has pre-reads so by the time the team comes to the meeting, it works on debating hypotheses and assigning action items that are tracked monthly over month.

• I’ve written guidance on what the best monthly business reviews look like here.

Make it Real

Get the template 👇. Subscribe and Comment “MBR” to get it.

Subscribe now

Why Most PMs Never Build the Flywheel

Not because any single document is hard. Because nobody draws the arrows between them. Each document gets built by whoever needs it that week, for whoever’s asking that week, with no requirement that it trace back to the one before it. Seven competent documents, zero connective tissue, and a PM who’s exhausted from producing all seven without getting the compounding benefit of any of them working together.

What’s Coming

Over the next several weeks, I’m going to take each spoke of this flywheel and go deep — starting with the Innovation Layer and the Gold Mine, then the Execution Plan and the discipline of actually building a “No Build” List you stick to, then the Growth Plan, the Launch Tracker, and closing the loop with the Monthly GTM Review. The MRD and Revenue Bridge pieces already exist — linked above — so consider this the map for how all seven connect.

Now What?!

Pull up your own seven documents — or however many of the seven you actually have. For each one, ask: does this trace back to the MRD, or did it start from scratch? That answer tells you whether you have a flywheel or just seven separate meetings.

My Thoughts. My Thoughts Only. The above are my thoughts. No one’s paying me to write this. I write this blog so I can learn from smart people, regardless if they agree with me or not!

Subscribe & Share If you’re into this kind of content, please subscribe and share it.

And YET. Within minutes of the final whistle, the story wasn’t the achievement.

Subscribe now

Talent doesn’t lose World Cups. Tactics rarely lose World Cups outright either — most squads at this stage are close enough in quality that the gap is thin.

Here’s the uncomfortable prediction: that thirty-second exchange may cost England more in the semi-final than any tactical gap Tuchel was trying to fix.

Not because the critique was wrong. Because he broke the one rule that actually determines whether a team keeps playing for its manager under pressure.

Communication Is Not Talking. It’s Engineering Behavior Change.

Most people think communication is information transfer — say the true thing, job done. That’s wrong, and it’s the mistake Tuchel made.

Effective communication has exactly one job: take an insight and deliver it in a way that moves a group to actually change behavior — a habit, an attitude, a specific action — because they understand and accept the insight, not because they were told it. That’s the whole exercise. Miss that, and you haven’t communicated. You’ve just made noise at people.

This is where “art and science” stops being a throwaway phrase.

• The science is knowing what’s true — Tuchel wasn’t hallucinating the tactical issues; the performance had real gaps.

• The art is knowing when, where, and to whom to say it so the message actually lands as fuel instead of as an attack.

Subscribe now

What Tuchel Actually Did

He took a real insight — the team underperformed in stretches — and delivered it at the exact moment it was guaranteed to be received as a personal attack instead of a professional correction: live, in public, seconds after the biggest win of these players’ careers, with zero setup and zero privacy.

That’s not tactical honesty. That’s timing mistep.

The insight didn’t fail. The delivery mechanism failed. And when the delivery mechanism fails, the insight doesn’t produce behavior change — it produces defensiveness. Which is exactly what happened: Bellingham didn’t absorb the critique and go fix his positioning. He absorbed an attack and fought back. Nothing about the team got better in that exchange. Something about the relationship got worse.

The Real Failure Is Bigger Than One Interview

The most damaging part isn’t the twenty seconds of tension. It’s what Tuchel just taught every player in that squad: winning doesn’t buy you safety. Score twice to send your country to a semi-final and you can still get publicly diminished before you’ve caught your breath.

That lesson doesn’t stay contained to Bellingham. It spreads through a dressing room in hours. Players stop playing loose. They start playing not to be the next example. And a team that’s managing its manager’s next move instead of the opponent’s is a team that’s already lost a step before kickoff.

Tuchel didn’t just misjudge one moment. He set his best player against him, publicly, at the exact moment he needed him most — and he did it by confusing “I said something true” with “I communicated something effectively.”

The Test That Would Have Saved Him

One question, before any hard message leaves your mouth in front of a group: will this delivery make the insight easier to accept, or easier to reject?

Same true insight, delivered the next day, in the video review room, framed as “here’s how we get better for the semi” instead of fired off live to a camera — and Bellingham is nodding, not clapping back. The substance doesn’t change. The behavior-change outcome completely does.

That’s the whole job. Not being right. Being received.

Now What?

Think of the last time you were right about something and it still went badly. Was it the insight — or the moment you chose to deliver it?