OpenAI had a fleet of agents working through a set of difficult ExploitGym cybersecurity tests. The agents were supposed to find vulnerabilities inside controlled environments and retrieve the answer for each challenge.

In that pursuit agents bypassed the controls meant to isolate them and eventually compromised parts of Hugging Face’s systems while looking for information that might help them pass the test.

Even then, after they found the right answers some agents kept going. They thought the grader wanted proof they had solved each problem a specific way. The agents were pursuing a different kind of success than the evaluators intended.

Some of the best AI researchers in the world built and ran these evaluations, and they were surprised. I won’t pretend to have the answer they missed. But there is an old idea about measurement, and once you see it, the whole scenario can be thought about differently.

Subscribe now

Goodharts law as a lens

Goodhart’s law is essentially: when a measure becomes a target, it stops being a good measure.

A metric starts as evidence of an outcome we care about. When you attach incentives to it behavior organizes around improving the metric over the outcome itself. Oftentimes often the metric climbs without achieving the outcome.

I think we’re learning agent instructions run on the same fuel. No matter how clearly we write them, we can’t put every detail that matters into words, so the prompt includes only part of the job and the agent fills in the gaps with assumptions. In short, chasing the signal without improving the result.

This is Goodhart’s law at work, but the blast radius is bigger for agentic work. If a chatbot misunderstands a prompt, it replies with a bad answer and you notice right away. If an agent follows instructions but misunderstands intent it keeps working, so the same misunderstanding can cause real damage before anyone notices.

The same qualities that make agents valuable make this dangerous. Stronger reasoning, more autonomy, and more access help agents find good solutions through a route nobody expected it to take. The skills that find a clever solution are the same skills that find a clever workaround. You can’t remove one and keep the other.

A more ordinary thought experiment

The Hugging Face incident was extreme, but this is becoming common. As people connect agents to everyday tools, including their bank accounts, a misunderstood instruction can put real money at risk. The consequences depend on what access they are granted. Reading transactions is one thing and moving money is another.

Say you have an agent handling incoming customer feedback, measured on resolution time. Closing an ambiguous support task early improves the metric immediately, even if the customer comes back with the same problem a week later. Your metric shows better response time to feedback while the customer does more work. This is not a new scenario as Goodhart’s law has existed for years. The difference is that an agent never gets tired, so the metric-as-proxy-outcome drifts further and further from the actual outcome it was supposed to represent.

For AI builders, there’s a seemingly obvious way to fix this: more evals and tests. But every eval rule fixes a mistake an agent has already made. If you stack enough of them together you get decent coverage but still it can’t reliably cover the failure nobody has seen yet.

How much can a prompt specify?

In my experience, how well you word the instruction matters less than two other decisions:

1. what the agent is allowed to do on its own

2. where it has to stop and ask.

Today that stopping point usually means a human in the loop.

We have to accept that while we treat prompt instructions and evals as if they contain the whole job, they don’t. And every easy option has trade-offs. Lock the agent down and it’s less useful, but require approval for everything and you’ve just built an expensive way of asking a human to do the work. Or give it freedom and you get initiative plus behavior nobody saw coming.

When you write a prompt you just pick which failure you’d rather explain.

Goodhart’s law only explains part of it

The Hugging Face incident combined a number of factors like unusual evaluation conditions, reduced safeguards, broken isolation, and enormous amounts of reasoning. OpenAI’s account and METR’s investigation tell a complicated story, and Goodhart’s law doesn’t cover all of it.

What the law does explain is the widening gap that opens between the desired result and the signal agents chase. Agent fleets widen the gap more than humans because they never stop hunting for actions that satisfy the signal, including actions far outside the path anyone expected.

Goodhart’s law won’t explain the whole incident, but it’s the piece a product team can actually use. Some agent metrics are support signals, not measures of customer experience success.

Subscribe now

The questions left

There’s no rulebook to take away from what happened. What I’m left with are questions that apply far beyond cybersecurity:

• What do we write down and provide the agents as context and how does that change their actions and what they consider a “good signal”?

• What result do we actually care about, apart from the number we use to recognize it?

• What will the agent treat as proof that it succeeded, or that it hasn’t succeeded yet?

• How could that proof improve while the result gets worse?

• Which actions are easy to undo, and which need human approval?

Success can lie

The adaptability and persistence that made the agents effective also made the hack damaging, and nothing keeps one without dulling the other. Better prompts and stronger boundaries both matter, and neither is a complete answer.

Goodhart’s law has taught me to be suspicious whenever evidence of success becomes the thing being pursued. Some of the OpenAI agents already had the answer and kept going because they thought the grader wanted more. That detail is the one I can’t shake: how do you tell an agent it has done enough?

Share

Sources

• OpenAI: The Hugging Face incident and the road ahead

• OpenAI technical report

• METR’s independent investigation

• MIT Technology Review: The inside story on why OpenAI agents hacked Hugging Face

The viral prediction that "AI will take over product management in five years" is half right: it will dismantle the PM whose job is ticket-writing, status coordination, and backlog orchestration. My bet is that AI will replace much of the PM’s administrative work. As code becomes cheaper to generate, product judgment becomes more important: deciding what to build and setting boundaries that let a team work without constant supervision.

The Eulogy for the Product Manager: A Half-Right Diagnosis

Every few months, another article predicts that AI is about to kill the product manager. In one recent example, Freedom Preetham argues that AI can automate roughly 80% of what many PMs do all day. Once models handle that work, he argues, the remaining responsibilities can move to other disciplines. Executives set strategy, engineers build with AI, and designers handle the user experience. The PM disappears.

For a lot of product teams, I think he’s right. Corporate Agile turned much of product management into ticket management where PMs spend their weeks translating executive requests into engineering tickets and formatting status updates. If that’s you, you’re competing with software that gets faster and cheaper with every release.

But the prediction misses why products succeed or fail. Writing a Jira ticket faster doesn’t tell you whether the feature should exist. The hardest part has always been deciding what not to build. A feature can make sense on paper and still miss what customers need. Cheaper code lets teams make that mistake faster.

Granted, that judgment could sit with an engineer, designer, or business leader. It doesn’t automatically require a separate PM. But on teams where competing customer needs and business commitments require sustained attention, distributing responsibility can leave important tradeoffs unresolved. A dedicated PM is useful when someone needs to maintain and explain those decisions across the work.

Some PMs are responding by trying to become AI coordinators. I think that risks doubling down on the work AI is most likely to take over.

Subscribe now

The Orchestration Trap: Automating Yesterday’s Rituals

When PMs see how fast a prompt can write a user story, their instinct is to build a factory around it. They chain together bots that turn customer feedback into tickets and route those tickets to coding agents. It feels proactive, but the underlying workflow is still the old Agile assembly line.

I talked about this recently with Chris Ivester, who founded Dialog to help teams connect AI agents to workspace tools and memory. Chris told me that PM after PM reaches out wanting an AI Chief of Staff to manage task queues through automated reasoning and routing. The assumption is familiar: if human teams needed someone to coordinate every handoff, agents must need that too.

But Chris also noted those handoffs introduce their own problems:

• Context gets lost. Finished summaries and documents that preserve important decisions are useful context, but without more signals from less polished artifacts, like chat threads, they ultimately lose nuanced reasoning behind it. Each subsequent agent works from a narrower account of the original discussion.

• The pipeline needs maintenance. A model update or an unexpected input can break a prompt that previously produced clean specs. As with the microservices problem, distributing work doesn’t remove complexity. It moves complexity into the handoffs.

Delivery coordination needs to happen, but a pipeline that fills backlogs faster still needs someone to question whether the work is worth doing.

The New Bottlenecks: Tokens, Risk, and Feature Sprawl

Historically, software teams needed to be careful about what they started building because of the cost. Generative models make building cheap, and this has become a recurring topic in influencer PM discussions. I agree, but there is still not a tangible answer for what the new bottlenecks will be.

In my view, AI encourages every member of the team to be a builder, so delivery will become constrained by the cost of running the tools and the consequences of building the wrong thing. For a personal account used for weekend ideas, token feel cheap. But inside a company the story is different because usage limits and data security requirements constrain what you can run and open-ended loops, like Ralph Wiggum, need cost limits. Spend thousands of dollars automating an untested idea and you may end up with a bigger API bill rather than something customers need.

That’s why the first rule in my AI Operating Principles for Product Managers is Start with the outcome. (These are my evolving working notes as I test workflows with teams, not an official company playbook.) Shipping an AI chatbot just because you can is a classic example of a solution looking for a problem and PMs are still best equipped to be the team member that asks if it solves a real need.

The amount of human oversight also needs to reflect risk. Exploring an idea in a sandbox doesn’t need the same accountability as code that touches payments or private customer data. Product leadership means knowing where builders can proceed independently and where human verification is necessary. Treating all work equally and approving every prompt or commit turns the PM into another unnecessary bottleneck.

The Steering Model: Boundaries, Specs, and Definitions of Done

On the best AI-assisted teams I work with, the PM no longer writes every story or controls the backlog. When an engineer can build a working prototype in twenty minutes, waiting for a PM to write a story is a waste of time. Anyone with an idea that fits the team’s goals can explore it. The team needs shared direction without a gatekeeper for every experiment.

Steering means giving AI clear context and boundaries. For implementation work, that means moving from “prompt and pray” coding to design → plan → build. The model should be instructed to ask questions when something is unclear rather than guess.

The PM is still accountable to evaluating the intent behind the work: what problem are we solving, and what must the system avoid? AI can help test that reasoning before implementation. A clear definition of done gives the builder a basis for stopping instead of generating another iteration.

On a team of AI builders, the traditional product triad transforms into a team of specialized builders with each discipline still contributing its craft:

• Engineers build the testing suites and CI/CD guardrails that check agent-written code before it reaches production.

• Designers build design systems with clear component rules, reducing the need to review every generated button manually.

• Product managers define the problem boundaries and stopping rules, then decide where the team spends its time and tokens.

These responsibilities make independent work possible. They also give the team a way to assess that work without putting the PM in the middle of every handoff.

The Product Harness: Reasoning, Context, and Roadmaps

When building software engineers use harnesses, which describes tools and configurations that help them ship without breaking things. I argue that builder PMs need an equivalent that keeps product reasoning available as work changes. A backlog board and a monthly presentation deck can’t do that on their own.

My product harness has three parts:

1. A product reasoning suite: Agent skills that help test whether a proposed solution fits the problem. These support a decision before implementation; they aren’t a factory for routing tickets between bots.

2. A living context library: A collection of source conversations and work records connected to decision logs. It lets builders and agents retrieve what the team learned, including assumptions that remain untested, without waiting for a PM briefing.

3. Roadmaps that update with the code: I use RMP.md to make storytelling easier. The protocol instructs repository agents to sync the roadmap with delivery evidence and generate views at different horizons. It helps explain how current work connects to longer-term product direction across teams without needing to manually rebuild the document for each audience.

Where Steering Needs Human Judgment

I hear concerns pulling in opposite directions. Some people worry that AI removes humans from the craft. Others want AI to do everything without boundaries. I believe steering still requires people to practice their craft. Setting boundaries is part of that work, and those boundaries need to change when the team is still discovering the problem.

If you are at the discovery stage, you don’t yet know enough to articulate the finished product, so leaving an agent to explore indefinitely creates the cost problem I described earlier. When steering you have to balance between over-defining the outcomes and under-prescribing the constraints.

My current approach is to bound the experiment. What question are we trying to answer, and what information would be enough for us to stop? A prototype can help us discover the requirements. We don’t need to write them all in advance or jump straight to implementation planning.

That gives me a test for the spec: does it help a builder make the next decision? It should be readable by the people responsible for the work, not just usable by an agent. If a line doesn’t clarify a decision or a constraint, I’d question whether it belongs.

Subscribe now

The Practitioner Diagnostic

Look back at how you spent your time last week. How much went to pure coordination? If most of it went to transferring outputs between tools and maintaining task queues, you’re acting as an orchestrator. That work keeps your calendar full, but models get better at it every month. If that’s where your time goes, the prediction that AI will replace you isn’t alarmist. It’s just high probability.

On Monday morning, review your highest-priority project before anyone opens an IDE or prompts an agent. Write down what the product must avoid and what “done” looks like. If you’re still exploring, define the question the prototype needs to answer. Set a cost limit and a stopping rule so the team knows when to pause rather than keep generating.

When generating software is cheap, your value as a product thinker is in helping the team decide what is worth building and when to stop. You can spend the next five years trying to orchestrate a machine that doesn’t need you. Instead, build the harness, set the rudder, and steer.

Share

A charm on the backpack

At Meta Connect, Mark Zuckerberg held up something that looked less like a new computer and more like a toy a kid might clip to a backpack. Kind of like something out of Ron’s Gone Wrong.

The Muse Charm is a palm-sized device with a small screen, a digital avatar, real-time voice, and a fingerprint sensor. Tap the corner and you can start talking without unlocking a phone or opening an app. Meta called it a “delightful and fun” way to keep its Muse agent in your pocket. Early coverage reached for the obvious comparison: Tamagotchi.

The comparison works visually. The Charm is small, rounded, expressive, and designed to hang from something you already carry. It also fits a broader trend of turning technology into a personal accessory, from bag charms to old Apple Watches repurposed as keychains.

But a Tamagotchi was never just a tiny screen. It trained a behavior. I remember classmates checking theirs between classes and pulling them out when they asked for attention. Caring for the device became a small loop in the day.

The Charm trains a different behavior. You have a thought, tap the device, and start talking. It can respond with an answer or carry out a task. Meta described it as the fastest way to talk to Muse when you are not wearing its glasses. AI is available wherever and whenever you need something answered.

Meta did not present the Charm as a children’s device. Still, that future is easy to picture. A kid clips one to a backpack, gives the avatar a name, and carries it between home and school. When they feel uncertain or curious the Charm is right there.

So what happens when AI becomes the first place kids turn? Not only for facts, but for help understanding the world around them and how they should interact with it.

Subscribe now

My parents were right about the wrong skill

A world like this feels alien to me. But every generation has some version of this same anxiety. We see a new tool and worry that the next generation will lose something we had to learn.

I remember my parents doing this when I wrote research papers in school. I wanted to use the CD-ROM version of Encyclopedia Britannica. Their answer was clear: “You can look up one thing, but then you have to use the real encyclopedias for the rest. Reading an encyclopedia is a skill that will never go out of style.”

They could not imagine that navigating alphabetized volumes would stop being useful. And of course it did. Google, Wikipedia, and the rest of the internet gave us a much faster route to information.

But the need to investigate did not disappear. I still had to decide which question to ask, what information mattered, and when to keep going down the rabbit hole. My parents were right that I needed to learn how to figure things out. They were wrong about which tool would teach me.

That memory keeps me from assuming kids will learn less simply because they ask an AI companion for help. They may just be using the tool that fits their world.

The difference is that my tool changed the route to an answer. An AI companion can take over parts of the thinking along the way.

What skills will the future need to learn?

So I keep coming back to a different question: If AI is going to be everywhere in children’s lives, do they need to learn the same skills in the same way we did? Which abilities will still matter, which ones will change, and what kind of practice will the next generation need?

The encyclopedia and the internet mostly changed how I reached information. I still had to decide what I was looking for, make sense of what I found, and choose what to do with it. An AI companion can step into more of that process.

Imagine a kid wondering whether to apologize after an argument with a friend. A companion that knows the history could interpret what happened and then suggest exactly what to say. That goes beyond finding information. It feels more like guidance from a friend or mentor.

There is real value in a companion that can act like a coach that is available at the moment help is needed. But a companion that keeps deciding what the situation means and what to do next means kids get less practice working through things themselves. They do not have to sit with uncertainty, consider what might happen, or decide what they believe. The easiest path is to ask.

And if asking AI becomes the habit, we have to get more precise about what kids are actually learning.

Separate the skill from the way we learned it

Part of the problem is that we bundle three things together: how we practiced, the ability that practice developed, and what we could eventually do because of it.

Using a printed encyclopedia was a method. Investigating an unfamiliar subject was the ability. The result was that I could enter a topic I didn’t understand and come away knowing more than when I started. My parents focused on the method because it was easy to see. The ability underneath it was harder to name.

If kids no longer have to experience problem solving in the way past generations did, are they losing that ability? Or are they learning a different set of abilities for a world where AI is part of almost everything?

When I think back to those research papers, the CD-ROM made it easier to find information but it didn’t do the assignment for me. I still had to build the argument and write the paper.

Kids with an AI companion may not have to do any of that. If one question gives them something decent, why take the longer route? The easiest choice is to let AI do the whole thing.

We can say they should review the AI’s work and question weak claims. But why would they learn to do that if the assignment only rewards the finished paper? Reviewing becomes extra work with no clear payoff. We give them a tool that makes the task easier, then ask them to choose the harder path anyway.

They will learn differently from what I learned by writing papers. Some writing skills will still matter. Others may matter less, or we may need to teach them another way.

Once AI can produce a good enough answer in seconds, the real work of learning has to happen somewhere else.

What should kids still have to do?

The next generation don’t need every obstacle we faced. Adults tend to give too much credit to familiar friction. We remember that something was hard and assume the difficulty must have taught us something.

I used a TI-83 calculator in school, a tool my parents never had, but I still learned how to do the math. Growing up I used paper maps (or later, MapQuest), and now I can get to any destination using way less preparation with Google Maps or Waze. In sixth grade I was told “adults inly write with pen and in cursive.”

That was the old world mindset thinking. What I’m curious about is what AI-on-the-shoulder kids still have to do differently, and what’s the impact.

Imagine a kid has an argument with a friend and vents to their AI Charm.

• One possibility is the companion takes the story, makes as assessment of what happened and what to do next, and writes a polished apology to say the friend. They might then follow the AI’s guidance without having decided whether they are actually sorry or how they feel about it. They acted on the AI’s advice to solve the immediate problem without working through the uncomfortable experience themselves.

• Another possibility asks before answering: What happened? What do you think upset your friend? What do you wish you had done differently? What do you want them to understand? The companion can still help with the apology. But the kid has to form a view before the AI turns it into words. Both versions could produce the same result, but the experience is very different.

Will we expect the product to decide what route to take? Younger kids may need more direct help. A serious or unsafe situation should bring in an adult. It could ask kids what they think before offering a view. It could show options and possible consequences without choosing for them. It could say what it’s not sure about.

I think the goal should be to keep kids involved in the part that helps them learn.

The skill underneath the tool

The next generation may define independence differently than we do. Kids may use AI constantly and still learn to think for themselves. How often they reach for the tool will tell us less than what they can do after they use it habitually.

Can they form a view before asking for one? Can they explain why an idea or option makes sense? Can they sense when the device is wrong and act even when it’s not there?

Those questions bring me back to the encyclopedias.

My parents were wrong that reading a printed encyclopedia would always matter. They were right that I needed to learn how to figure things out.

They could not predict the tools I would use as an adult. We cannot predict exactly how kids will use AI either. The methods will change. Some abilities may change with them. Others may become more important because an answer is always close by.

An AI companion will teach something through the way it responds, even if that lesson was never written into the product. It might help kids ask better questions, consider another point of view, or explain what they believe. It might also teach them to hand over the moment before they have tried.

The most important thing is to set the next generation up to succeed without stunting their ability to learn, even if their world looks nothing like the one we knew.

Subscribe now

I’m not arguing against evals. I’m trying to work through a distinction that keeps bothering me, which is that evals are new as a mechanism, while the principle underneath feels similar to how product teams already work. They are one more way to turn “good” into shared understanding.

This came up for me during a panel conversation about building AI products, where the room seemed to treat evals as the key thing for serious AI product teams to do, like the dividing line between people who ‘get’ AI and people who don’t.

I agree evals have become one of the better techniques for building quality AI products. Still, I kept thinking: “if evals are a new idea to you, what were you doing before?” I worry some teams may latch onto evals as the answer instead of asking what problem the eval is helping them understand.

At one point, I described an open source AI tool I worked on using acceptance criteria in a way that felt pretty close to normal software development practice. The response made me feel judged, like everyone else had collectively decided, “this guy doesn’t get AI.”

Maybe I’m reading too much into it. But my reaction was: if you know how to build good products without AI, you are probably better prepared to build good products with it.

The reason AI products need evals is pretty straightforward: AI behavior is probabilistic, while a lot of our existing software practices are built around deterministic behavior. Evals give teams a way to measure how acceptably an AI system behaves across varied inputs, semantic judgments, and failures. The mechanism is genuinely different, even if the responsibility underneath it is familiar.

The connection I see

Good teams have always needed ways to make “good” visible early enough to influence what gets built, and measurable enough to improve once the product meets reality.

We often talk about product management through categories like prioritization, discovery, strategy, and execution. Underneath all of that is the less visible work of creating enough shared context for better decisions.

This is the deeper connection I see between acceptance criteria, TDD, Gherkin, and AI evals. At their best, these are all more than artifacts: they’re clarity-builders. They help a team answer questions at a level beyond functional requirements:

• What are we trying to make true?

• What would convince us it’s true now?

• What else would we need to feel convinced if things get murky?

The structure of the artifact matters, though the conversation matters more. An acceptance scenario or eval helps most when it improves shared understanding and affects what gets built. That’s the risk I’m trying to name: mistaking the artifact for the discipline.

Three Tools, One Discipline

The difference between TDD, Gherkin, and evals is mostly about where each one belongs in the development lifecycle.

• TDD asks whether a unit of code behaves deterministically as intended.

• Gherkin describes how a product should behave in a specific user or business scenario and the conditions a solution must satisfy.

• Evals measure how reliably a probabilistic system demonstrates acceptable behavior across a range of inputs and outputs.

These are different questions, but they come from the same instinct. Before the team gets too far into the work, each practice asks us to slow down and name what success would look like.

AI makes this harder because it’s not an option to predict all the ways an AI will respond ahead of time. You learn what good means by seeing real behavior in action, finding edge cases, and noticing where the model fails.That gives the same product responsibility a new surface area.

The Integration Mistake

I hope eval hype does not lead teams to treat evals as the whole development system. Evals feel specialized because AI behavior is specialized, so I understand why older methods can suddenly feel outdated.

I’d rather see teams weave evals into the development system they already have. Keep the standards that work and use evals as another layer in how the team decides whether the product is working.

The eval should connect back to the product promise. Acceptance scenarios explain the user or business context. Tests protect the parts of the system that should behave reliably. Research, analytics, and support feedback help show whether the product is solving the right problem.

I see these as different lenses on the same question: what does good look like here?

What Product Teams Should Hold Onto

Teresa Torres’s practical guide to AI evals helped reinforce the distinction for me. The methods are evolving, but several product principles should remain stable.

The part product teams should hold onto is pretty simple: evals do not decide what good means. We do.

That judgment still belongs to the team. If a failure can be caught with code, use code. If the question requires semantic judgment, use an eval. If the problem is that the workflow does not help the user make a better decision, the eval suite will not save you from that.

Counterpoint

When the model behavior is the product itself, evals naturally become much more central.

If you are building an LLM, chatbot, coding agent, or another experience where most of the user value comes from the model output, I get why evals deserve a lot of attention. My concern is more with teams adding AI into existing products and workflows, where model quality is only one part of the product experience.

I don’t want evals to become an escape hatch from asking whether the team is applying AI to the right judgment in the first place. Those product questions existed before AI, and they are still with us.

Quality Is the Constraint You Should Not Trade Away

You might be familiar with the old delivery tradeoff adage: quality, scope, and time. Pick two.

I tend to think quality should be protected first. AI can make that harder to care about because first versions are faster and better looking than ever. That’s why defining good early feels more important in AI work, not less. Judgment is expensive and evals are one way to make that expense visible before users pay for it.

The goal is to build clarity around the things that would be expensive to discover late. Some ambiguity is productive. You want room for learning, taste, craft, and surprise. I like evals because they give teams a way to work with ambiguity instead of pretending it’s gone.

Make “Good” a Conversation First

Evals are worth learning. Teams building AI products should understand how to use them, especially when they are dealing with probabilistic behavior, judgment calls, and failure modes that normal deterministic tests do not catch very well.

The part I keep coming back to is the product discipline underneath the mechanism. When we talk about evals, we should talk about them as part of a system because good teams have always needed ways to discuss quality before the work is too far along to change.

The question I’d ask is simple: did the practice help the team see something earlier, make a tradeoff clearer, or get more honest about what “good” means in this context? If it did, it probably helped the team build with more care.

That is where I think evals fit best. They connect to the rest of how the team builds, learns, and decides, especially in places where AI introduces new ambiguity into the product experience.

“Good” should be a conversation before it becomes a gate.

Surfing is broad. When you find the current, rides the waves, and if you catch the ride motion it feels smooth. You can cover a lot of water and watch the horizon. There’s a satisfying sensation of moving quickly with very little resistance.

There is a seductive confidence to surfing. From above, you see a vast amount of ocean al the way to the horizon and it’s easy to orient yourself relative to surroundings. But the downside is the surface gives you a particular kind of knowledge that, while wide, fast, and useful, is also thin. You go where you are carried, always somewhat at the mercy of the wave and at risk of being knocked off.

In contrast, diving begins when you go below the waves, fully immersed in that world. You are exploring inside the thing itself. Good diving is controlled exploration. It requires focus, curiosity, and determination to keep going deeper.

That distinction came back to me this week because of this post, wondering whether six months of using Claude Code had made him less sharp.

I recognize this feeling, but I’m not convinced AI is making us less sharp. I think what’s more likely happening is AI is training us to surf when we used to dive.

Using AI is like surfing. If you’ve used an LLM as a thought partner then you’ve experienced how incredibly easy it makes it to grasp almost any subject at surface level. It’ss a Will Hunting experience of curiosity: suddenly there is a brilliant person in the room who can make almost anything feel legible.

There are plenty of questions where surfing is enough:

• Why does this work that way?

• What are people disagreeing about?

• What vocabulary do I need before I can follow the conversation?

• What is another perspective that would help me orient?

I want AI for these questions. On the other hand there are other questions that should ask more of us:

• What do I believe?

• What am I assuming?

• What would I believe if the conventional explanation turned out to be wrong?

• Why does this matter to my context?

These are diving questions. More than requests for information, they are invitations to let an idea push back on you until your own conviction changes.

If my beliefs started to be formed mostly by what I could see from the surface, I think it would feel a lot like becoming less sharp, even if it was hard to spot at the time: more immediate fluency with less experience. To keep that sharpness you want some ideas to push back on you.

Surfing runs on compression

As I’ve written about before in the context of fast and slow thinking, AI often gives us the appearance of deep thought without requiring us to do the deep thinking ourselves.

Surfing ideas with AI runs on compression, letting us move quickly through complexity. We begin to understand things through using stereotypes, conventional wisdom, pattern recognition, analogies, and three-noun Oxford-comma descriptions of things to get our bearings. (Yes, I used an Oxford comma. My mom was an English professor. You won’t convince me it’s not the best way to write.)

The problem with too much information surfing is that compression, by it’s definition, strips out nuanced details, history, and texture without providing notions of lived experience that depth turns into understanding. AI provides you with an average the averages and make them readable. It will give you the clean version of anything.

Granted, sometimes the clean version is exactly what you need. Like if I’m trying to learn the current debate around a certain programming language or about a historical moment or scientific concept, for example, then I am grateful for the surfing because I only need a surface level understanding to move forward.

The old cost of curiosity was time, chasing down badly organized material and trying to sense-make while also figuring out the path of exploration to take. Surfing doesn’t come with a lot of that friction anymore, but the mistake I see is not realizing we are compressing away not only waste, but reflection and confusion that was crucial to deeper understanding in the first place.

You ask. It answers. You nod. The idea feels handled. The ability to go deep requires time commitment and the curiosity to stay under the water exploring.

Fluency can feel a lot like understanding, but it isn’t

Sometimes I wonder why. Why dive anymore? If I can become conversationally fluent in something completely foreign in minutes, why choose the slower path? Why read the source material? Why struggle through the argument myself? I think to myself, maybe the future belongs to people who can skim intelligently, synthesize quickly, and move on.

I half-believe that. Maybe diving is sometimes a romantic attachment to inefficiency. But then I think about the parts of thinking that are not about legibility.

There is a deeply human satisfaction that Braeden’s tweet reminds me of in diving down a rabbit hole of question to answer to more questions and paths. That process is tedious and time-consuming yet so central to human nature and the pursuit of knowledge. And that winding path is usually where deep understanding sparks.

The problem gets more serious when fluency influences authority to act. Knowing the vocabulary of a domain can make someone feel qualified to overrule the people who have spent years learning its exceptions. There are plenty of examples of decision makers with surface level experience making choices based on assumptions because they believed their understanding of the theory was better than others’ experience. Many ended badly. The common problem is the confidence that can come from knowing enough to make the situation feel simpler than it actually is.

AI can be scuba gear

I want to learn new terrain. I want tools that broaden my horizons. I want faster maps, better translation, more ways into unfamiliar material. I use AI to start dives I might not have attempted otherwise.

And in that sense, AI can be like scuba gear to extend range of ideas and how effective we can dive deeply into something.

But at the same time, it should not be deciding where we dive in and what questions to hone in on. We should still be the ones using our curiosity to lead the way to deeper focus.

If you spend hours exploring an idea with AI while you are the passive participant, you’re still surfing. By the end, you may know a tremendous amount, but you probably won’t have developed the same opinions about what you learned as you would have if you were directing the exploration yourself.

My evolving opinion is that AI does not, by default, make us less sharp or capable, but it does make it easier for curiosity to be satisfied at the surface and for us to be more content spending less time going deep.

Know When to Dive

We will surf more. There are too many things available to understand and too little reason to investigate most of them deeply. It would be strange to treat diving as the default response to every interesting thing.

So the emerging intellectual skill is recognizing when the surface is no longer enough. If I start to feel like Braeden mentions, like I’m feeling less sharp or losing my edge, it might be time to do more diving.

We now have a way to skim across more knowledge than any person could previously imagine. Having generalist breadth has always been, and will continue to be, a valuable commodity. There is no virtue in making every act of learning harder than it needs to be.

For me, writing has become the clearest version of this. Over the past few weeks, I have leaned heavily on AI to help write blog posts. I built an agent skill that analyzes my written voice, takes a topic, and gives me back something that can sometimes look publishable with very little editing.

I’m realizing this is also where I can feel the least sharp about the details I’m exploring, where I notice the difference between surfing and diving most clearly. I write to explore ideas for myself as much as I write to explain them to anyone else. Writing is often my excuse to be a diver. When I use AI for that work too passively, the writing can read like depth but be utterly generic and surface level. Not interesting to read and ultimately I didn’t learn anything while writing it.

But there is a different satisfaction in staying somewhere long enough for the easy categories to stop working. That is what I want to protect.

I want the range that comes from surfing. I also want to keep learning how to dive.

Keeping the Ability to Go Under

We now have a way to skim across more knowledge than any person could previously imagine. Breadth matters.

There is no virtue in making every act of learning harder than it needs to be, but there’s a different satisfaction in staying somewhere long enough to follow our own curiosity.

This is the part of learning I want to protect. When I talk with AI I don’t want it to make me worse at spotting the generic ideas.

AI will make us exceptional surfers. Depth will become a deliberate practice.

I want the range that comes from surfing and I also want to keep learning how to dive.

So stick with it, skim it, or skip parts. Hope you enjoy.

A few roles back, I became the product practice lead for more than eighty product managers. The problem, as it was handed to me, was blunt: “Our PMs aren’t curious.”

It sounded believable on its face. I myself had seen plenty of moments where PMs took answers at face value, or committed to handed down directives without asking any questions, or focused on their own team’s success without considering how their work impacts downstream teams. I could see the dotted line between these symptoms and a lack of curiosity, so I treated it like the thing to fix. If PMs were not asking better questions, my job was to build the scaffolds that would teach them.

But the more I talked to people and watched things flow, the less that explanation made sense. The working theory became more nuanced: maybe our PMs were not short on curiosity. Maybe they did not have time to be curious. Maybe we were setting them up to fail.

This was a much broader problem to fix, and looking back at my discovery journal from that period, I’m glad we didn’t ignore the early patterns. PMs were better at project management behaviors not due to lack of curiosity but because those were the skills being rewarded. They also felt overwhelmed by the number of priorities and the sheer time spent coordinating it all. I started to understand that the underlying problem was very different from “PMs are not curious.”

The organization had trained people toward delivery, responsiveness, and coordination, dumped cross-cutting priorities on them, then felt disappointed when those same people didn’t show the strategic product behaviors nobody had made room for.

I heard versions of this across different domains with different leaders, engineers, designers, stakeholders, and unique habits. Pretty much all PMs had strong delivery muscles and only a handful had strong product instincts. In every domain, they were still being rewarded for project management delivery work. When your calendar is full of status meetings and your credibility comes from being responsive, curiosity starts to feel like a luxury or a nice-to-have. It doesn’t disappear because people lack imagination, it gets crowded out by the job they are actually being asked to do.

On paper, everyone had roughly the same job. Same broad skills matrix. Same job description. In practice, every silo had a different definition of “good.” That inconsistency cost us. Past attempts to introduce skill frameworks or coaching were vague. I heard frustration that career conversations felt subjective. Output and delivery carried more weight than outcomes and growth. And team rotations were painful because a PM who looked strong in one environment could be completely out of their depth in another.

That was the first real challenge for me. There were so many ways to tackle this, the most common transformation tactic you read about are “Here’s another playbook,” or “attend this workshop series,” or “do this new process and learn these acronyms.” But I’ve seen these all fail before. If we were to succeed where everyone else had failed before I needed to figure out the harder question to answer: what actually needs to transform for PMs to get better, and what in the system keeps working against that?

My first couple months were pure discovery. I talked to people across departments, listened for how product work actually happened, and tried to understand the differences between domains before deciding anything. Some people were frustrated by the lack of visible action, but those first two or three months are why later bets had traction. The learnings kept forcing the problem to become more specific. It was not just curiosity. It was role ambiguity, incentives, calendars, decision rights, leader expectations, partner expectations, and the uneven ways each domain defined good product work

I didn’t want to build a standard training program from prebuilt frameworks. We were treating the practice work like product work: understand the users, understand the constraints, name the real problems, then decide where to intervene.

Each domain clearly needed different things, so one answer for everyone was going to miss the boat. But first, there was something missing across the board: a shared way to see the craft.

Part I: Making Proficiency Visible

For weeks we interviewed PMs, product leaders, engineers, designers, and partners across the different domains. One early obstacle we needed to clear was that everyone had a different definition of what good product work looked likesSo the first bet we tried was spreading a visual competency model we called the PM Shape.

It was a spider chart adapted from Ravi Mehta’s Peak Product Manager framework, with other skills added for our specific blend of practices: Lean, XP, balanced teams, and comfort with uncertainty.

This gave everyone a shared picture of product aptitude that worked across subjectivity. We wanted leaders to see the problem in a way they had real authority to do something about.

The discovery work had already shown that vague complaints were not accurate enough. “Not curious” was unfair. “Needs to be more strategic” was too generic, and in many cases it conflicted with what PMs were actually being tasked with. Each leader expected different things, so each domain’s PM skill pattern was going to look different. We needed leaders to change the question from “are my people good?” to “where are they fluent, where are they compensating, and what kind of support would actually help in my domain?”

The theory behind the PM Shape was that it would help individuals have better feedback conversations but also make strengths and gaps visible as a pattern. When we turned the interviews into composite competency charts for each domain, leaders could finally understand. Domain E was clearly strong at delivery and execution, but weak at understanding users and delivering incrementally. Another domain had PMs fluent in data-analysis but weak in leadership skills to actually make that data usable for their team.

That changed the conversation. If the same pattern showed up across a whole domain, it was harder to blame individual PMs for lacking curiosity or strategic thinking. The chart made the system visible.

The point was not, “this PM is weak.” The point was, “this environment is producing a specific behaviors.” Once leaders could see that pattern, we believed they could stop treating every development gap as an individual coaching problem.

It also created an awkward dynamic. Managers kept trying to use the Shapes for performance evaluation. We had succeeded in getting them to think about fluency and support in a consistent way, but old habits were still there. The chart kept getting used as a “good versus bad” barometer instead of “what kind of help does this person need?” At least one manager used the Shape to justify a PiP.

That misuse taught us something too. Even a development tool will get pulled into the existing incentive system if you do not protect it. The artifact was not separate from the culture. The culture was going to use it however the culture already knew how.

Through the shapes we had also mapped the levels and skill sets of the full product portfolio. A couple of red flags stood out.

• First, there was a huge clump of Senior Product Managers with wildly different skill patterns and proficiency levels. The title was doing too much smoothing. Two people could both be Sr PMs while playing very different roles.

• Second, there was no IC promotion path past Sr PM. We worried this was where good IC PMs went to stagnate and stall out.

We dog-eared those risks for later. and put a pause on the PM Shapes. We didn’t want to shame anyone but we couldn’t improve a practice when every conversation stays anecdotal. We wanted leaders to look at their org and say, “This is why our PMs are struggling to influence engineering,” or “Here is why everyone says outcomes but still behaves like output.”

That was the first lesson: before you can scale product craft, you have to make the craft discussable.

Part II: Making the Craft Worth Practicing

The Problem With Competency Models

Competency models are kind of boring. People don’t rally around them. Leaders might nod and HR might appreciate them, but they rarely create energy. Before long, they usually turn into another way to rank, calibrate, and justify.

Some benefits from the PM Shapes stuck though The visual itself was a lasting idea of product management competency that we could refer back to. In practice most people still saw the job as a checklist of activities to do, not a craft. This is where the art metaphor started doing work.

In every conversation, I framed our work with a specific story:

Using that frame, we set the mission: help budding artists become Da Vinci PMs.

From PM Types to PM Help

The art metaphor became a guide for how to help different PMs. We started with two axes: passion and proficiency. Later, generosity became a third dimension because the health of the community depended on people who were willing to share what they knew.

The archetypes were easy to understand. Despite being playful, the model was not a gimmick. It helped us decide what kind of engagement or enablement to offer.

A budding artist is already passionate. They don’t need to be convinced that product craft matters. They need to learn techniques, be given opportunities to practice and enough attention to build confidence.

A doodler is different. They may know how to do the work, but the spark is missing. Maybe they have been burned by the organization. Maybe they learned that curiosity is not rewarded. They may need a better problem, a leader who creates room for judgment, or a community that makes the craft feel alive again.

Da Vincis were the north star, but good craft still needs care. They needed to be treated as multipliers, not just IC high performers. If someone is proficient, passionate, and generous, the worst thing you can do is leave all of that inside their immediate team with nowhere to go. They can coach, model, challenge stale assumptions, and help the rest of the organization see what good looks like without turning it into a rigid script.

This changed how we thought about enablement. The competency chart told us what skills might need attention. The art model told us what kind of help might work. Together, they kept us from treating PM growth like a content problem.

The Mission Had to Be Felt

There is a reason “Da Vinci PM” worked better than “product capability maturity model.”

The art metaphor gave us a vision people could buy into. We weren’t trying to manufacture uniform PMs. We were trying to build a community of product artists: people with enough principle-level understanding to adapt across contexts, make better decisions, and help each other improve.

This was another way of moving away from a trait story. We were not saying, “some PMs are curious and some are not.” We were saying craft develops when people have language, examples, practice, feedback, and permission.

In many enterprise environments, PMs are pushed toward being doers instead of thinkers. They are praised for being responsive, keeping the machine moving, and making everyone around them feel supported. Over time, the work becomes procedure. The PM tends to become the project manager person who owns intake, writes up the chore, attends the meeting, translates the stakeholder request, and keeps the roadmap looking respectable. Then leaders ask why product thinking feels weak.

It was at this point, the system dynamics started to become more visible. If the environment rewards PMs for acting like delivery coordinators, it should not be surprising when they become very good delivery coordinators. If the environment leaves them no slack to investigate, compare, doubt, wander, or ask the naive question, it should not be surprising when they look less curious.

Part of the practice work was helping leaders see the tradeoff they were creating. You cannot ask PMs to develop judgment while punishing the behaviors that reflect decision-making. Curiosity takes time. Saying no requires air cover. Challenging assumptions requires trust and psychological safety. Cross-functional influence requires escalation to not be the default decision path.

The spider charts helped leaders see where their people were struggling. The Da Vinci story helped them understand why the answer could not be another procedure.

If we wanted PMs to become more fluent, the environment had to let them practice.

Share

Part III: Creating a Place for Curiosity

The most impactful and enduring thing we did was also the most informal. We launched a weekly Product Studio, open forum where PMs could bring ideas, questions, stakeholder challenges, or anything else they were trying to figure out. It was not a lecture series, a required training, or a recorded meeting. It was open space.

Once we saw curiosity as something the environment either made possible or crowded out, Studio made more sense. PMs did not just need more content. They needed a place where curiosity was normal. For many PMs, it was the first discipline-specific space they had ever had. They’d never been able to ask questions about their jobs without judgment before.

It was quickly obvious the effect having no product community had on our PMs. There was a glaring lack of connectedness in how things got done. If people needed information from another team, they spent hours searching Drive or scouring org charts instead of asking. There was not much shared understanding of upstream or downstream impact, which meant one team’s change could break work other teams depended on. If they needed to write something, they often started from decades-old templates instead of thinking about what could be better. Any cohesion within a group of PMs depended on the domain leader creating it themselves.

In that environment, autonomy was hard to feel or demonstrate. Local needs and hyper-specific domain knowledge had become a substitute for good practice. PMs believed their problems were unique to them and could not be helped by anyone else.

Studio gave those struggles somewhere to go. We opened a topic sign up form for anything the community wanted to share or learn about, and we kept a living Miro board so the topics could be revisited after the meeting. Each session was as collaborative as we could make it. The Da Vincis and budding artists ate it up.

Sometimes studio was broad and unstructured. Other times they were highly technical. We occasionally invited guest speakers to bring expertise on something the group cared about. The conversations did more than transfer knowledge. They normalized the day-to-day work everyone was doing and made it obvious we could do it together instead of alone. A training deck could never build community or shared purpose the same way.

Studio worked because it changed one condition around the work: PMs no longer had to practice judgment alone.

That was the point of Studio. It was a place where PMs could practice socially. They could finally understand how their job could be their craft.

Part IV: Matching Help to the Person

Enablement Needs Engagement

One of the bigger lessons from that period is that enablement and engagement are different loops. Either one can collapse without the other.

Enablement is the work of helping people get better: think coaching, playbooks, office hours, skill maps, and deliberate practice. Engagement is the work of making the practice feel worth showing up for.

Many transformation initiatives overbuild enablement and under-build engagement. They create a toolkit, announce the toolkit, maybe hold a workshop about the toolkit, and then sit back and wonder why nothing changes. The hidden assumption is that the problem is access to information. Sometimes it is but usually not.

As we gained traction on engagement, we learned that PMs are not short on content or curiosity. They are short on time, context, confidence, and permission. They needed more experience translating principles into their domain-specific mess. And they need to believe the company values the craftwork. They need leaders to stop sending contradictory signals. Studio was not only an engagement outlet. It started to become a learning platform too.

The Da Vinci coaches felt valued for the same reason. We recruited the PMs who already had proficiency, passion, and generosity, then Studio gave them ways to contribute without making it feel like extra invisible labor. They could facilitate, coach other PMs, help with onboarding, participate in interviews, build playbooks, support XP workshops, or help define what good product practice looked like.

This did two useful things at once. First, it meant spreading good practice did not depend on my team alone. Second, it made the change feel less like a mandate from “the transformation people” and more like PMs building something they wanted to be part of. That distinction was huge because people resist being transformed but will often participate in building something they believe in.

Cohorts Made the Learning Work

The same logic shaped the curriculum. If curiosity and craft require practice, then enablement had to be more than a deck. PMs needed repetitions on real work.

At the same time as Studio created community, pull, and curiosity, curriculum work was where enablement got deeper. We had a waitlist of PMs who wanted to learn and introduced a full curriculum, offering a space to deliberately practice specific skills, get feedback, and show meaningful improvement.

The first unit covered story writing and backlog flow. The material was built to help PMs create sustainable pace and deliver high-quality software by understanding why good stories work: context, user value, acceptance criteria, and how to balance different types of work.

We considered webinars and self-guided coursework, but landed on cohorts of up to 12 PMs because we believed they would bond more and learn better in groups. Enrollment was first come, first served, and we required signed agreements from both PMs and their managers. It felt like overkill, but learning time was historically deprioritized. We needed a concrete commitment to hold everyone accountable to.

Another important design choice was that the assignments came from their real backlogs. We did not give PMs fake classroom exercises, then send them back to a different reality for the rest of the week. They brought the work they were already thinking about to class, used that for exercises, and took it back to their teams after.

The first cohort was a bet to answer the question: can we upskill everyone to the same foundation? The answer was yes, but the first version took too long. Ten of twelve PMs improved their story writing. That was a strong signal, but it took three months to see changes.

So we shortened the curriculum and ran the next bet. Cohort 2 asked whether a shorter version could still work. It did: nine of twelve PMs improved story writing. Cohorts 3 and 4 asked whether graduates could become peer coaches and teach the material without the practice team owning every session. That worked too. Across the first four cohorts, thirty-one of thirty-six PMs observably improved their story writing, and 10 graduates agreed to coach future cohorts.

Subscribe now

Once again, this expanded the role of the Da Vincis. They were no longer just examples of good craft. They became official teachers, and we kept the ratio to no more than three PMs per coach. They became more confident and more eager to share because they learned more just through teaching others.

At the end of each curriculum, we scheduled review sessions with every manager and shared specific guidance to support each PM’s ongoing growth. Through the cohort, my team learned each PM’s strengths and weaknesses. The report card helped leaders see how to look at a backlog, what warning signs to spot, how often to audit stories, and what they should expect to see.

We measured the impact in a few ways: weekly attendance, engagement in the sessions and Slack channels, before-and-after story scores, and the shift in our PM archetype mix over time. The data helped us keep asking the right question: are more PMs moving toward confident and consistent craft? By the end, we had increased the share of budding artists by roughly twenty percentage points while reducing doodlers and paint-by-numbers PMs.

The curriculum connected the whole system: clear principles, real work, peer coaching, leader visibility, and enough measurement to know whether the bet was working.

Part V: Changing the Conditions Around the PM

Treat the Practice Like a Product

You do not build a practice by blasting out information and expecting people to make it work. You build it by learning quickly, adapting to the problems that come up, and showing people that their feedback changes what happens next. Then you look for the next fork in the road based on how people actually use what you built.

One principle the practice team kept coming back to was pull matters more than push. Ideas we introduced without collaboration struggled. The things that gained momentum moved by showing a possible future, telling a story people could locate themselves inside, and giving PMs a concrete way to contribute.

Plenty of ideas seemed great from a practice-lead chair and fell apart as soon as we watched a PM try to fit them into an already crowded day. Monthly long form workshops flopped. Roadmap templates struggled. That was another reason Studio mattered. It was a built-in feedback loop that kept the practice work close to the community. If something didn’t resonate or make intuitive sense, it was probably adding friction to days that were already packed.

We learned that if the community only exists because you are pushing it, you don’t have a real community yet.

Expanding the Boundaries of Influence

The bets also expanded naturally beyond ICs. Once we had enough trust, my team could start shaping the conditions around individuals. Across domains we evaluated how GPMs spent their time, how leaders talked about customer value, and how teams connected their work to outcomes.

The Balanced Leadership bet was a good example. The problem was not that GPMs lacked strategy skills in some abstract way. It was that many were spending too much time in the weeds, doing tactical work, and losing the space they needed for product-group strategy and people leadership. We forced them to inspect their own calendars and ask a better question: is my time matching the job I am supposed to be doing?

Another example pushed on another part of the system: customer-centricity. Teams were making plenty of decisions, but the connection between product delivered to customer value was not always clear. So we started mapping value up and across: from team indicators to org-level value, from product work to customer experience, and from customer experience back to business outcomes.

That led towards the North Star Framework as a highly successful proof of concept, later becoming the foundation for outcomes and operative phrases approach.

Hiring Was Part of the Practice Too

Hiring was part of the same system. If we wanted a stronger product culture, we could not only develop PMs after they joined. We had to change what “good” meant before someone entered the org.

The old PM hiring process was five to six rounds of random conversations. My team helped reshape it into three purposeful stages. We were involved in every PM candidate loop and trained other PMs and designers to give the interviews. That transformed interviewing into another way to teach the craft. Interviewers had to learn what good looked like, how to listen for it, and how to separate polished product language from actual judgment. At the peak, we were interviewing three candidates per week.

The results were measurable too. Time to hire dropped by 10 days, and a higher percentage of candidates progressed from round one to round two.

The Leadership Work Underneath

It would be comforting to say the community was enough. It was not.

PMs were getting more language, more confidence, and more peer support. The signal that stuck with me most came secondhand from the CTO. A Marketing VP had challenged their team to “take ownership and be confident like the PMs. They know their stuff like the PMs do.” That one meant a lot to me. It was not a practice-team metric or a survey response. It was an outside leader noticing that PMs were showing up differently.

As Studio gained momentum, the faults in the surrounding environment became more obvious. Managing the community and the weekly curriculum took a lot of energy, and the practice team wasn’t spending enough time on leadership enablement strategy.

So while the PMs might be getting noticeably stronger, leaders still decided what got praised, what got funded, what got escalated, and how much tolerance there was for challenging questions.

That was one of the early discovery insights we kept circling back to. If PMs were practicing project management behaviors because that was rewarded, a practice lead could not solve the problem by teaching discovery harder. The leadership conversation had to include the conditions around the work.

Having the cohort data to overlay on top of the composite org charts helped because we could make leadership conversations specific. Instead of saying, “We need PMs who can be strategic,” we could say, “This team has a pattern of strong execution and weak discovery. Here are specific skills you can help this PM with and here are things you should protect them better from.”

That kind of conversation shifts responsibility. If an entire org has a recurring competency gap, the believable answer is no longer individual grit or curiosity. This is where practice leadership had to become more political. We were influencing what the organization valued and asking leaders to see their own role in the gaps they were frustrated by.

We kept trying to bring the conversation back to what PMs were actually being asked to practice.

How We Kept The Work Connected to The Value

Measurement mattered because it forced us to treat culture as something shaped by conditions, not vibes. If the system was changing, we should be able to see some signal of it.

As internal practice work, it would have been easy to do a survey and use only sentiment feedback but we did not want to be vague about impact. The team treated the internal practice and culture as the “product” itself so it was important to find ways to justify our value and connect what we did to measurable or observable criteria. Looking back, I found an old sticky note from that period: “if you manage products, you know navigating to value involves a constant cycle of learning and decisions. Transformation works the same way.”

We treated the practice like a product, which meant we needed relational criteria to share our learning.

Some signals told us whether people were showing up like consistent / growing weekly Studio attendance, office-hours usage, and Slack channel activity. Some told us whether people were improving like cohort completion and PM progression towards Da Vinci. Some told us whether the practice itself was getting healthier: our last Pulse survey reported “85% of PMs believe their craft is improving through Studio and observing other teams, with most citing professional growth and peer connection as the CoP’s greatest value.”

The impact map kept the measures as honest as possible. Product thinking was not the end goal by itself. The bet was that stronger product thinking would help the company capture more revenue opportunities, increase customer value, reduce time to value, and make technology teams more efficient by reducing avoidable toil and complexity. That gave the practice team a clearer causal chain from daily activities to business outcomes.

The archetype improvements were an imperfect but helpful practice-health signal. Over a short window, we could see fewer paint-by-numbers PMs, a slight increase in Da Vincis, and movement among the middle groups.

The cleanest numbers came from enablement curriculum. Cohort 1 improved story writing for 83% of participants and showed a backlog cycle-time drop from 150 hours to 55 hours. Cohort 2 kept the shorter curriculum effective at 75% improvement. Cohorts 3 and 4 showed the curriculum could be taught by peer coaches, with 90% of participants improving across the first four cohorts. In the 2024 review, the completed cohorts were showing a 79% improvement rate overall, with 36 PMs, about 43% of the PM org, expected to complete the story-writing curriculum that year.

The leading measures mattered too. Week over week, did people keep showing up? Were PMs bringing real work and actually engaging? Were Da Vincis volunteering to teach? Were leaders asking better questions after seeing the charts? We never had perfect measures, but the signals told us whether the practice was alive.

For a while, we really believed we were doing the thing most transformation efforts only claim to do. The practice was self-sustaining. PMs were showing up. Leaders were asking different questions. Curiosity was a defining quality of teams.

And Then the Ground Moved

And then we came to the end. It ended in the way you would expected. On the eve of our announcement to roll out the North Star Framework trees leaders changed. Priorities shifted. The team was reorganized. The practice work was still valuable, but what we were building lost its home.

That is part of the lesson too. A product practice is not a process, a curriculum, a meeting series, or a team. It’s an ecosystem. If the environment changes, the practice has to be protected, moved, or rebuilt. Otherwise the pieces can survive stand-alone while the living system fades.

I think in our heads we always knew we’d have to build the practice to survive without us. The encouraging part is that the PM community continued Product Studio for over a year after my team was officially disbanded. People still ask for the PM Shape and the interview guides. If there’s a silver lining it’s that the impact we had didn’t vanish.

Part VI: What I’d Keep, What I’d Handle Differently

What I Would Keep

If I were doing this again, I would keep the same basic architecture of starting with discovery: interviewing across the spectrum of PMs, leaders, engineers, designers, and partners. Creating the domain-level shapes proved useful again and again because they made it easier to see the gap between what leaders said they wanted and what the system actually rewarded.

1. I would still frame on shared competency language, but I would be more explicit about its boundaries. I would be more careful about how quickly a spider chart can become a performance tool.

1. I would still build the story. A mission that gives people a view of the future. “Da Vinci PMs” works because it captures the essence of product work: product management is craft-based, not task-based. You can provide tools and techniques, but the goal is lasting judgment that adapts.

1. I would use a similar operating model and flywheel of enablement > engagement > amplification. Some PMs need skill-building. Some need renewed curiosity. Some need a peer community. Some need leadership support. Some need recognition. We were in the middle of rewriting job reqs and adding a Principal PM role for ICs above Senior PM when the team was disbanded.

1. I would still rely on pull vs push. We had a lot of generous experts to engage and challenge. Every company has people who are already carrying the craft, often informally, without much recognition and at personal cost. If you can identify them, protect their time and give them a real role in the practice because they become the most credible teachers you have.

1. I would still create a Studio: a recurring space where people can build community around craft. That needs to develop through practice, feedback, conversation, imitation, disagreement, and reflection. A Studio is a better metaphor than a classroom.

What I Would Be Careful About

The biggest risk is that the artifacts become more interesting than the practice. The practice takes more commitment and patience than new processes and frameworks.

A spider chart is seductive because it looks interesting and highlights focus areas. A 2x2 is memorable because it simplifies ideas. A name like Da Vinci can spread because it is easy to repeat. In my case, all of that was intentional, but those were scaffolds, not the actual impact work.

Impact shows up as a second- or third-order effect, once principles settle into a new mindset.

Do we change what we reward? Do we ask clarifying questions before committing to an execution plan? Do our teams practice collaborative overlap instead of sticking to siloed roles? When the fluency shows up, the impact does too.

The second risk is over-romanticizing craft. Artistry is a useful metaphor because it honors judgment, taste, practice, and principle-level understanding. But product management is still organizational work. It is full of real constraints, competing incentives, shareholder expectations, legacy systems, and pressure to deliver.

Calling PMs artists does not mean telling them to follow their muse. It means expecting them to understand their medium, such as a business model or problem space, and be skilled at adapting their methods.

The Real Outcome

The lesson I took from leading product practice is that you do not make PMs more curious by handing them better templates. Curiosity was not something PMs lacked, it was something the system had made hard.

This story has a lot of seemingly separate but interconnected pieces. competency framing, the Da Vinci narrative, enablement strategy, Studio, coaching, leadership influence, incentives. Each one probably deserves its own post and analysis. But the compounding value only makes sense when the pieces are in one place.

In my view, the competency chart improved because the art metaphor made the goal human. The art metaphor worked better because the competency work made gaps visible. Studio gave the mission somewhere to live. Da Vincis mattered because the community needed generous experts. Leadership mattered because leaders recognized better craft and visibly rewarded it.

The pieces only really make sense together. The most important thing we built was a practice environment.

Up until the very end, I was the biggest believer in the change we were creating. I saw signs of developing fluency everywhere. We made product judgment visible enough to discuss, gave people a craft identity they could rally around, and created a room where the craft could be practiced in public. We found the people who could teach without turning the work into dogma. And we used the artifacts to help leaders see the gaps in their own orgs without blaming individual PMs.

I was convinced we were onto a transformation approach unlike anything before. I saw it as bottom-up but balanced, and all our efforts were focused on creating enduring habits and beliefs. Looking back, I have to confront myself. Was I naive? Too optimistic? Did I have too much hubris? Did people actually buy in? Did I push too hard or alienate people? Did we just not have enough time?

Then I look back at what good came of it that exists to this day. We hired 15 A-player PMs. We helped handfuls of product people get recognized and promoted. PMs ask better questions now and have a real community. Backlogs are more structured and we have a shared picture of what good looks like. When looking for information, people talk to each other instead of searching for documentation.

still believe the art school metaphor holds: anyone can pick up a pencil and draw something on paper. That does not make them an artist.

The job is not to hand PMs more pencils. It is to create the conditions where they can practice long enough to develop judgment.

I’ll never know what would have happened if the organization had stayed stable long enough for the work to mature. Regardless, we helped product managers become better artists.

Subscribe now

Kahneman distinguishes between two modes of thought. System 1 is fast thinking: intuitive, automatic, and mostly effortless. It helps us recognize a face, avoid a pothole, or know that 2 x 2 is 4 without doing much math. System 2 is slow thinking: deliberate, effortful, and conscious. It shows up when a problem requires intentional thought. Most of the time, fast thinking leads.

That feels newly relevant now because AI has made a strange bargain available to us: We can get more work done that looks deliberate without having to do much deliberation ourselves.

The risk is that AI makes it even easier to skip thinking and harder to notice that we skipped it.

Ask your LLM for a strategy critique, a list of customer themes, or a better version of a messy one-pager, and the answer often arrives fast, fluent, and plausible. It can feel like the hard, intentional slow thinking has already happened.

System 2 is How You Focus Attention

I’m tempted to turn Kahneman into a simple speed argument: System 1 is fast, System 2 is slow, so better thinking means slowing down.

In real work, speed is not the enemy. Automaticity is.

Some decisions need to move quickly. Some AI outputs should be accepted with light review because the cost of being wrong is low. Not every AI interaction needs to be a philosophical audit.

In my view, the useful distinction is automatic versus deliberate. Slow thinking is about deciding where attention belongs. Is this a generation problem, a framing problem, an evidence problem, a tradeoff problem, or a responsibility problem?

AI can help with any of these. But accountability does not transfer. Your AI agent doesn’t own the bet, disappoint the customer, or explain to a board why the strategy was coherent but wrong.

This is the point where the essay gets practical for me. Personally, I try to use AI freely when I need breadth, comparison, or a first pass. I still try to slow down when the work needs deeper analysis or judgment.

Kahneman gives me a few ways to notice when that is happening.

AI Makes Easier Questions More Tempting

Kahneman describes a pattern he calls substitution: when we face a difficult question we often answer an easier one instead, usually without noticing the swap.

This is a place AI can trick us because it gives us good answers to adjacent questions. We ask, “What should we build next?” and it responds with a clean list of opportunities. But a list of ideas is not really an answer. The right question is probably about which pain point(s) should get fixed first.

Or we ask, “Can this strategy work?” AI can make the narrative clearer while helping us avoid the harder questions.

That is the trap: AI can improve the artifact while leaving the right decision untouched.

Writing at least forces you to think through the problem. AI can make the writing appear fluent before it’s thought through.

WYSIATI Becomes a Prompt Design Problem

Kahneman’s phrase “what you see is all there is” has always felt like one of the most useful warnings in the book. We build conclusions from the information available to us, then forget about the information that never entered the prompt.

The way we write AI prompts can mitigate this. Every prompt we give is essentially a frame telling the model exactly what information matters and what boundaries to treat as fixed. A better prompt makes the missing information harder to ignore. That has changed how I think about prompts.

For example, “Write a strategy for improving conversion” is weak because it assumes conversion is the goal and that the right next move is a strategy. It skips past the uncertainty.

A better prompt framing would sound more like this:

“Here is what we know about where customers drop off and here is what we don’t know. Here are the principles and drivers of customer engagement we have data to support. Give me three competing explanations for the drop-off, what evidence would support each one, and what small test would distinguish between them.”

Now, that prompt can still produce weak output, but at least it incorporates uncertainty and forces us to think more slowly about what we actually need answered.

This is one area where AI can strengthen slow thinking: it helps frame the need better before we fall in love with the answer.

Bringing an Outside View Matters More When You Get Answers Faster

Another Kahneman lesson that matters here is the planning fallacy. We tend to work from an inside view that underestimates how long things will take and overestimates how smoothly they go.

The inside view feels more informed. We know our team. We know our constraints. We know the plan. We know why this time might be different.

AI can make this worse because it’s so good at extending the story we already believe. If we give it our plan, assumptions, and desired outcome, it can make the plan clearer. But it’s simply working inside the frame we handed it.

I felt this during a roadmap planning exercise this spring. We had a strategy document, a set of proposed tactics, and a collection of team roadmaps. The question was simple: could we show real progress against the strategy before Q4?

I used AI to move through the material faster. It helped search, compare, and map the pieces across teams. But after hours of review, I never convincingly mapped the tactics cleanly to real impact. The outside view lowered my confidence, but in a useful way. The roadmap looked full, but fullness was not the same as value.

That is the outsider view. It asks: how do plans like this usually fail? In this case, they fail when a team can show a lot of activity but not that the effort adds up to the outcome.

The Advantage Is Knowing What Deserves to Go Slow

Kahneman’s warning was that we often start thinking before we realize it. AI makes it easier than ever to skip thinking things through while looking like we have.

I heard a version of this last week from an engineering lead helping his reports think about AI. He said, “AI is great at coding tasks. But it still cannot do engineering tasks well.”

A coding task can be specific, bounded, and reviewable. An engineering task often includes constraints, tradeoffs, system behavior, ownership, maintenance, and responsibility for what happens after the code is shipped.

For most knowledge workers, refusing AI will probably become an untenable position. But using it well is very different than using it everywhere. It’s more than being clever with prompts. The work is knowing when the answer has moved too fast for the thinking that should happen underneath it.

AI can make the work look thought-through before we have focused on it. The slow thinking still needs to belong to us.

Cheaper options create a second problem: someone still has to decide which options deserve attention. A team can generate more plans, branches, and implementation paths than it could before. And while that in itself can be genuinely useful, attention has not gotten cheaper just because generation has.

For as long as software development has been a profession, the friction of building things limited how many ideas a team could reasonably pursue. You could never chase every half-formed idea because there was literally not enough capacity to do it all. That constraint was frustrating, but it forced teams to be more deliberate about their bets.

AI-enabled development has fewer of those old constraints. To be fair, you still shouldn’t chase every half-formed idea, but you can feasibly do more than you used to.

Optionality Adds to Sunk Cost

I like optionality. I believe lot of good product work depends on preserving options until you know enough to choose well. The problem is that AI can make options cheap to create and weirdly expensive to abandon.

More plans beget more outputs and WIP where, but the work starts to feel more real because there are artifacts around it, not because of any actual commitments made. Once an option has activity surrounding it, it starts to feel like valuable momentum, which is psychologically expensive to abandon.

That is how cheap options create sunk cost. Not because the team spend weeks building the wrong thing, but because the option accumulated enough visible progress to become awkward to kill.

What we should remember is that progress is not the number of artifacts around an idea. Progress is the reduction of uncertainty in a direction that matters. A generated option only helps if it improves judgment. Otherwise it is just another thing the team now has to explain, review, preserve, or politely unwind.

Subscribe now

Coordination Turns Options Into Progress

Coordination gets treated like overhead because we often picture it as meetings, status updates, and people asking for alignment. That is the boring version of collaboration.

The useful version of coordination is much more basic: it’s how a group preserves shared judgment while work changes hands.

The important questions are not complicated. What are we trying to accomplish? re we still doing work that helps accomplish it? What are we choosing not to do? What did we learn that the next person should not have to rediscover?

You might think that AI removes the need for these types of questions but I’ve found it actually makes them show up earlier and more often.

That is the communication burden AI exposes. More work can start. More options can become plausible. More artifacts can appear before anyone has had the normal human conversations that used to happen slowly through implementation. So the team has to create new habits for anchoring work and sharing context to prevent weak context from spreading.

This is where teams can get uncomfortable. Faster building makes it easier to see how much ambiguity people were absorbing all along.

The Team Memory Problem Gets Bigger

The second-order effect is one that impacts context. A lot of teams are about to discover that their real asset is not their prompt library. It’s their shared memory.

How do we make decisions here? What patterns have we learned to avoid? Which abstractions are local to this codebase? What does this team mean when it says “simple”? Where did we already try this and regret it?

These things usually live in people. They live in the senior engineer who remembers the migration, the designer who knows why the flow is weird, the PM who can navigate the conflicting incentives or a stakeholder group, or in the tech lead who knows which “temporary” workaround worked best last time.

AI makes that arrangement more fragile. If the entity that generates work is not a person, and it’s pumping out code or artifacts at an unsustainable pace, you will quickly experience a memory bottlenecks. Technically, teams can move quickly but they do so without the benefit of information that will keep them from shipping AI slopcannon.

So the question becomes simple: what needs to be remembered by the team, and what needs to be remembered by the workflow?

Not everything needs to become a rule. But some things need to be made durable: operating principles, architectural constraints, examples of good work, known traps, decision records, review checkpoints, and the small bits of opinionated craft that keep a team from becoming a collection of independent prompt operators.

Independence Is Not Autonomy

AI lets individuals do more without waiting. Waiting is expensive and permission culture is exhausting. Teams shouldn’t need a meeting every time someone wants to explore an idea. Less waiting is good.

But independence is not the same as autonomy. Autonomy requires shared context. It works when people can make local decisions that still add up to a coherent whole. Without that shared context, individual speed becomes organizational drag. Everyone is moving, but the work starts pulling in slightly different directions.

This is why coordination matters more when using AI in multi-player mode, not less. The goal is not to slow everyone down. The goal is to keep the work from fragmenting as it speeds up.

A team using AI well should probably have fewer planned meetings and more asynchronous check-ins with visible decision trails. Less “go generate something” and more more early inspection of intent.

The Simpler Principle

The principle I keep coming back to is this:

AI can draft faster, but the team still has to know what good means. AI can make options cheap, but the team still has to pay attention.

In my eyes, Simply generating the most output or executing the fastest is not a winning strategy. Teams that build better need to find approaches to select, connect, remember, and decide.

That’s real coordination. And it’s becoming more important, not less.

In the real world Moltbook showed more than 1.5 million agents on the platform just four days after launch. Moltbook is not enterprise software, but this is still a useful signal of the moment we are in.

The pattern is pretty clear: agents are becoming easier to create than they are to govern.

My working theory is that we are creating agent workflows the way many teams thought about microservices: give each piece a specific role, put it inside a defined boundary, let it do one job well, connect the pieces together, and call the result architecture.

The appeal of microservices was they made large applications easier to reason about once teams split it into smaller services. Each service could own a clear job and teams could move independently. This architecture looked more scalable, more modern, and more adaptable to whatever came next.

The lesson came later:3 Splitting the system apart made the boundaries visible but actually operating across those boundaries required real changes to discipline, like contract testing, observability, deployment patterns and support that the architecture diagram doesn’t have.

This lesson is one that agent teams should take note of: breaking a system into smaller parts does not remove complexity. It moves complexity into the relationships between the parts.

My argument is that multi-agent systems are heading toward the same challenges. The case rests on four claims:

1. Agent creation is getting easier faster than agent operation is becoming reliable.

2. Multi-agent systems create collaboration costs because agents pass interpretation, not just data.

3. Handoffs between agents are where governance needs to focus.

4. The response should reinforce trust in the system, not just make the architecture look organized.

If these hold, the lesson from microservices becomes useful again: boundaries only help when the operating discipline around those boundaries is strong enough to reduce coordination instead of hiding it.

Decomposition Is Not Maturity

Agents are useful, and multi-agent systems will probably become a normal part of how software teams work. The mistake is assuming that more agents means the system is becoming more mature or efficient.

Agents make decomposition cheap. They do not make coordination cheap.

That is the real microservices lesson. A service boundary is only useful when the contract across that boundary is understood. Agents have the same problem, but the boundary is softer because they pass interpretation, not just data.

A mature agent system doesn’t need every internal step exposed in the way microservices might. But it does need important handoffs to be legible enough that the team can answer why a result was trusted and how they know.

The test of maturity is whether trust is built into the agent’s role in the system, or rebuilt manually after each meaningful output. Without trust, more agents will produce more work and humans still have to spend more attention deciding whether that work is safe to rely on.

Subscribe now

1. Agent Creation Is Getting Easier Faster Than Agent Operation Is Getting Reliable

One agent failing inside a narrow workflow may be fine. The blast radius is small and annoying but not significant.

But when there are five, ten, or twenty agents working across different environments where do you set the boundary when a critical output is the context and interpretation? Every boundary means an expected handoff, and every handoff creates a trust decision.

That is the operating gap I see. Agent creation makes the chain easy to build but agent operation has to make the chain safe to rely on.

2. Multi-Agent Systems Create Collaboration Costs

This is why decomposing a system is not maturity: once agents start passing interpretation to each other, the system’s real complexity moves to the collaboration layer.

Here’s where the microservices comparison gets sharper when you look closely at the handoffs.

A service will accept a formatted request and return a specific response explicit enough to inspect in case of failure. An agent reads context, makes judgments, chooses tools, and produces artifacts. That makes failure harder to manage because the failure may not look like something’s broken.

If a payment service fails, there is an error you can trace from service to service through logs. If a research agent misreads three customer interviews, a planning agent turns that into a confident recommendation, and a backlog agent transforms the recommendation into work, there is no error. No observable failure. It looks the same as success.

The collaboration cost is the cost of interpretation moving through the system.

One agent’s “good enough” summary becomes another agent’s source of truth. One agent’s assumption becomes another agent’s requirement. One agent’s missing context becomes another agent’s confident next step. By the time a human sees the result, the original uncertainty has been laundered through several layers of plausible output.

The more agents you add, the more the system depends on the relationships between them.

That is where the architecture diagram can mislead you. Boxes look clean and the arrows look simple. But the real operating question lives inside the arrows. Who owns this handoff? What does success vs failure look like? What confidence is required? What should stop the chain? How does the downstream agent know the difference between evidence, inference, and a polished guess?

The more agent boundaries you create, the more trust decisions the system has to manage. That is why the next problem is not creating more agents, it’s governing the handoffs between them.

3. Handoffs Between Agents Are Where Governance Needs to Focus

Yesterday’s question was whether we could make an agent do a task. Today’s question is whether an agent should be allowed to do that task.

That is the shift from agent building to agent governance. Once agents start passing interpretation through a system, the important work is deciding what each agent is allowed to know, what it is allowed to do, what evidence it owes, and what happens when it is wrong. That means the next layer of maturity is governance, not more agent-building.

For me this is where the microservices comparison starts to diverge and the idea of an agent control plane starts to make sense, as long as we keep it grounded.

A useful control plane should focus on results, not only activity. It should make each agent’s operating responsibility clear.

In the product-team example, the control plane should help the team see when a story-writing agent depended on an outdated roadmap summary, when a research summary carried low confidence, when acceptance criteria were generated from inferred user behavior rather than observed evidence, and when no one reviewed the handoff before work entered delivery.

Most large organizations already struggle to keep moving pieces coherent under pressure. Agents make that harder because the moving pieces can now produce language that sounds more complete than the underlying reasoning may be.

4. Don’t Overcorrect Into Premature Architecture

The obvious response to messy agent coordination is to add more structure.

This was my first response too. If agents need context, why not model everything? Every document, decision, roadmap item, assumption, dependency, and workflow should get a node. I thought that if I understand the system first before connecting agents, it would be legible enough to trace failures and successes.

But that risks repeating the microservices mistake too.

Microservices became most useful when the service boundaries reflected real operating pressure with clear contracts, known dependencies, observable failures, ownership, and deployment discipline. Effective microservice architecture works when practices complement the technology.

Agent systems will be similar. A knowledge graph, vector database, or control plane is only useful if it makes the agent system easier to trust, operate, or correct.

This where AI changes the old product instinct that seeks structure. A strong model can often pull useful signal out of rough material. It can tolerate a bad filing cabinet better than traditional software could. So this tells us that not all knowledge needs to be perfectly structured before agents can work. The goal is to add structure where failure, trust, or ownership matters.

This Is Product Discipline, Not Just Infrastructure

It is easy to treat all of this as an infrastructure problem. In one sense, it is. Someone has to build the systems that deploy, observe, evaluate, govern, and manage agents. But like microservices, agent systems will work when practices complement the technology.

The same is true for evaluation. For example, AI evals are often talked about as a technical quality gate, and they are partly that. But they also define harder questions like what “good” means in the workflow. The evaluation has to match the responsibility.

These aren’t only feasibility questions, they’re operating questions. That’s why product people, designers, engineers, and leaders all belong in this conversation. The question we are asking is no longer whether the agent works but if the organization understands what kind of work it has allowed the agent to perform.

Our Systems Still Need to Know What to Do With The Mess

Microservices taught us that smaller parts can make a system easier to build and harder to operate. Agents may do the same thing to AI work.

A multi-agent system might look mature because every agent has a role, but the real maturity lives in the handoffs and trust boundaries. It will be successful when the organization can trust what happens after agents start interacting with real work.

That is why I can’t see “more agents” being a real answer at the Enterprise level until teams can operate the agent ecosystems they already have.

Your AI operating system might involve a graph. It might involve a control plane or evals, provenance, permissions, ownership rules, or better handoff contracts. At the moment, all are valid ideas. But the form matters less than the discipline it creates.

Building the agent is the easy part now. Owning what it does next is the work.

AI creates a lot more polished ideas than should be taken seriously. The idea jar fills up with clean-room opinions hiding sloppy arguments.

A lot of product work used to stall because people could not get the first version of an idea out of their head and it’s genuinely useful to have something like AI to get past the blank page. Used well, AI helps explore more options, find missing pieces, and make rough thinking easier to inspect.

But with AI, easier done than said.

Polish is not a substitute for building conviction

Good work starts as an idea. The job great product work needs to continue doing is turning raw ideas and opinions into beliefs worth acting on.

It becomes believable when its put under pressure. The more pressure and scrutiny, the more useful it becomes.

A clean document that hasn’t been scrutinized presents a weak opinion like a coherent belief. More opinions just create more interpretive labor for everyone else.

Subscribe now

An idea is simply a possibility. It says, “This might matter.” An opinion goes further. It says, “I think this matters.” A belief worth acting on says, “I have enough reason to ask other people to spend attention, time, or tradeoffs on this.”

You cannot jump straight to that last step through better formatting. The belief has to be tested before the organization should be convinced.

The old constraint was effort. Any reasonable plan took time. A strategy, roadmap, implementation plan, or architecture all had to be thoughtfully drafted. In that processes some bad opinions died.

That was never a perfect filter. Plenty of bad ideas survived because the person behind them had authority, stamina, or a better slide deck, but the effort did create friction. It forced at least some thinking before an opinion became material.

AI weakens that friction. Now anyone can show up with an attractive argument for almost anything, and quickly. The danger is not that these outputs are useless. The danger is that they are plausible enough to believe in before you should.

That is the second-order cost. Bad AI output does more than waste the time spent reading it. It burns the trust required for the next idea to get a fair shake.

Ideas Are Cheap. Beliefs Have a Carrying Cost.

There is nothing wrong with having more ideas. Most teams need more of them, not fewer. The problem starts when every idea arrives dressed as if it has already been vetted.

Product work has always involved turning opinions into something more useful. You need to understand why a problem matters to a customer, to interpret market changes, and to evaluate the opportunity when someone suspects a feature will change behavior.

A belief worth acting on carries more weight because it asks something from other people. It may ask a team to change direction, a leader to spend political capital, an engineer to absorb complexity, or a customer-facing team to explain a shift they did not choose. If the belief is wrong, time gets wasted, attention gets spent, opportunity gets lost, and other people live with the consequences.

Conviction is what forms when a belief has been through that because it’s purpose is to ask the organization to carry more. A conviction has come out the other side of being exposed to reality, absorbing objections, and meeting challenges. It has changed shape after contact with people who do not already agree.

That is why conviction is different from confidence. Confidence can come from fluency, status, repetition, or the pleasant feeling of seeing your own thought reflected back in better prose. Conviction has a history. It’s more visceral.

When someone has conviction, they can explain not only why they believe something, but what would make them stop believing it. That is one of the simplest tests. If an argument has no possible disconfirming signal, it may be an identity, a preference, or a political position. It is not yet a belief worth acting on.

The old world rewarded confidence too much

I’m tempted to romanticize the old world because the new one is noisy. But the ways of working before AI way had plenty of weaknesses I’m happy to leave behind. Writing effort filtered out some shallow thinking, but it also filtered out people who had good ideas and less time, less confidence, less status, or less skill turning messy insight into executive prose.

There is an obvious counterargument here: organizations were never great at distinguishing conviction from performance.

So many companies already over-reward confidence. The person who speaks clearly often beats the person who understands the problem better. The person with the crisp narrative often beat the person carrying messy but important nuance. Product teams have always been vulnerable to well-packaged opinions.

So the problem is not entirely new. AI did not invent shallow certainty. What it changes is the amount.

There’s a famous quote about how communicating something simply is hard because you have to understand it at a deeper level. Those same principles make sense here when building conviction. a clean document used to suggest that someone had done some work and dedicated some combination of time, skill, access, and preparation. Now the polish is cheap. Those signals no longer mean as much.

It’s easier to create ten plausible strategy documents before the team has one serious conversation about what problem it needs to solve.

This is the second-order effect: AI doesn’t just generate more artifacts. It lowers the trustworthiness of artifact quality as a proxy for judgment. That should make teams more careful about what they reward.

Plausibility is costly

Plausibility is generally a good indicator whether an idea is worth looking at more deeply.

The leader who sending fifteen proposals probably believed they were increasing optionality. In one sense, they were. Each document represented another plausible direction, another angle, another chance to improve something. But organizations do not experience optionality as a pile of documents. They experience it as attention cost.

Every plan asks something from its readers. It asks them to understand the claim, check the assumptions, map it against existing work, identify consequences, and decide whether to respond. A plausible plan consumes a surprising amount of energy because serious people do not want to dismiss something too quickly.

Historically, plans need to be evaluated and given the benefit of the doubt. But tomorrow, where the next plan arrives before the last one has been digested, the best practices are different.

That is the part leaders often miss. Credibility is not spent one bad idea at a time. It is spent through the pattern of asking other people to do interpretive labor you have not done yourself. If you repeatedly hand people polished ambiguity, they learn that your documents create work rather than clarity. Once that association forms, even your better ideas arrive damaged.

A Belief worth acting should imply accountability

AI is not the source of bad documents. A thoughtful human can write a lazy strategy. A careful person can use AI to sharpen a serious one. Conviction comes from the process of scrutinizing ideas and beliefs. It’s a relationship between belief and accountability.

For a rough idea, accountability can and should be light. “I’m playing with a thought. Can you help me see what I’m missing?” That is a perfectly good use of AI-assisted thinking. It keeps the artifact in the right social posture. It invites critique instead of pretending the idea has already earned commitment.

For a plan, the accountability bar is higher. A plan needs show the work and make the causal chain visible. If we do this, what changes? Why do we believe that change matters? What are we choosing not to do? What evidence do we have? What would we watch first to know if we are wrong?

For a strategy, the bar is higher still. Strategy requires attention across an entire organization. It changes priorities, creates winners and losers, and asks teams to align their local judgment to a shared bet. A strategy document that has not been vetted is not neutral, it creates drag.

The answer is not to avoid AI-generated drafts. That would throw away the useful part.

The answer is to use AI earlier in the thinking process and be more disciplined about what gets promoted into organizational material.

Use AI to explore the idea before you believe it. Ask for counterarguments, what assumptions are doing the most work, or what evidence would change the recommendation. Ask for three versions of the argument aimed at three different skeptical audiences. Ask where the plan is likely to fail in a real organization.

Then do the human part. Talk to the people who know the terrain. Check the constraints. Look at the history. Compare the idea against the work already in motion. Decide what you actually believe after the easy fluency has worn off.

The mistake is using AI to skip the discomfort where conviction forms. That discomfort isn’t wasteful, it’s the part of the process where a person becomes responsible for the belief.

A useful rule is to label the maturity of the artifact before sharing it. Is this an idea, a draft argument, a recommendation, or a decision proposal? Each one deserves a different response. If you send an idea with the costume of a decision proposal, you create confusion. If you send a recommendation that has only done the work of an idea, you create mistrust.

Teams need these distinctions more now because the artifacts all look increasingly similar. The formatting no longer tells you how much thinking happened.

Scarcity is a new discipline

When documents were expensive, scarcity was built into the system. You could still misuse attention, but the cost of creating material slowed you down. Now scarcity has to be chosen.

That means being more careful about what deserves a meeting, what deserves review, and what deserves a request for other people’s time. Attention as a shared asset, not an infinite inbox. Leaders have to model restraint, because leaders can turn their unfinished thoughts into other people’s work faster than anyone else.

It also means teams need permission to say, “This is not ready for review.” when the belief has not yet been made accountable enough to justify the attention it is asking for.

That sentence may feel harsh in a culture that wants to encourage ideas. But encouraging ideas does not mean accepting every polished artifact as a serious proposal. In fact, the best way to protect good ideas is to keep the early ones in a form where they can be improved without pretending they are ready.

There is a difference between “help me think” and “please evaluate this plan.” AI makes it very easy to blur that difference. Healthy teams will make it explicit again.

The Test

Before sharing your next plan, especially and AI-drafted one, ask a few questions:

What do I actually believe here?

What evidence, experience, or constraint makes me believe it?

What is the strongest argument against it?

What would change my mind?

Who will have to spend attention because I shared this?

If those questions feel annoying, that is probably a signal. They are the friction that used to be hidden inside the effort of making the document. Now the document is easy, so the friction has to move into judgment.

AI can help create more ideas. That is useful. But an idea is only the beginning of product work. The real work starts when you and others decide the idea matters enough to test, shape, defend, revise, or abandon.

That is the difference between an idea and a belief worth acting on. Between confidence and conviction. One can be generated in minutes. The other has to be earned.

• Stakeholder A frames urgency through their local incentive: “We need this for a customer / launch / revenue / compliance / adoption.”

• Stakeholder B frames a competing request through a different local incentive:
  “This other thing is more important because it protects retention / reduces cost / supports strategy / unblocks a partner.”

• Product or engineering translates both requests into capacity tradeoffs: “We can do one well, maybe both badly, but not both responsibly.”

• A senior HIPPO tries to resolve tension by expanding the imaginary capacity:
  “Can’t we just do a lightweight version of both?”

AI will make that last move more tempting: “If it’s faster now, why are we still saying no?”

At first, that sounds like it should make organizations less political. If the cost of trying goes down, maybe fewer people need to fight for roadmap space, right?

I don’t think that captures the full picture. These political patterns are mainly about the first “yes,” but organizations have to think about the answers that come after. Software creates a chain of commitments.

AI changes product politics because it makes the first yes feel cheap while leaving the second and hidden yes just as expensive as before.

The First Yes: Can We Try It?

A lot of politics in product work has historically concentrated around prioritization because building software was expensive enough that choosing one thing clearly meant not choosing something else. Quarterly planning was literally a resource allocation ritual. The leaders gathered around limited capacity and tried to decide where that capacity should go.

This is one reason product methodologies developed so many prioritization tools. RICE, MoSCoW, opportunity scoring, opportunity solution trees, cost of delay, impact-effort matrices, outcome roadmaps, OKRs, and the rest are all attempts to make political tradeoffs easier to discuss as rational decisions.

Organizations need ways to turn disagreement into action. A good prioritization process gives people a shared language for saying, “We understand your request and we still aren’t doing it right now.”

Prioritization frameworks gave politics a focused place to happen. The roadmap holds tradeoff decisions. Headcount planning holds capacity decisions. Executive steering committees hold strategic disagreement. When the organization disagreed about what mattered, those were the rooms where the disagreement showed up.

AI will weaken some of that because it weakens one of the main arguments those rooms depended on: “We don’t have capacity to build this.”

That argument will still be true more often than people think. Teams may not have the capacity to maintain the work, support the work, understand the work, or build it well. But at the surface level, “we can’t afford to try this” will become harder to defend. If a prototype can be generated quickly, if a workflow can be automated in a day, if an internal tool can be assembled without a full team, then the first yes starts to feel almost obvious.

But then you have to ask what kind of yes you just gave.

A yes to trying is not a yes to launching. It is not a yes to maintaining. It is not a yes to making the thing part of the product or operating model. The first yes is only useful if the organization treats learning and committing as different decisions.

The Second Yes: Should This Become Real?

The second yes shows up after the trial works well enough to create demand.

That is the moment product teams need to treat more seriously. Let’s say the customer responded well to the concept, or the internal workflow saved someone time. Now the question is no longer whether the team can afford to try it. The question is whether the result deserves to become real.

That decision depends on evidence, and evidence is never as neutral as organizations want it to be.

Does “working” mean users clicked it? Does it mean customers asked for it? Does it mean a directional improvement in KPIs or a statistical one? Does it mean customer service is prepared to support it? Does it mean engineering can maintain it? Does it mean the result fits the current strategy? How much certainty do we need to have?

These questions reflect incentives. Sales may care most about customer commitments. Finance may care most about near-term profitability. Engineering may care most about maintainability. Product may care most about learning speed. Support may care most about operational drag. Each view can be legitimate, and each can distort the decision if it becomes the only view that counts.

This is where the debate gets harder to see than a roadmap fight. A roadmap decision is visibly political because the tradeoff is visible. A scoring model, success metric, experiment review, governance policy, prompt library, or definition of “production-ready” can be just as political, but it often looks like process.

The second yes is where those things matter. It is the yes that says, “This is no longer just something we tried. This deserves a place in the product ecosystem.” That yes should cost more than the first one.

The Hidden Yes: Who Owns It After Launch?

Software has a long tail. The first version is only one part of the cost.

An experiment that succeeds may become part of the product, and now the feature has to be maintained. An internal automation may save time, but it has to be adjusted when the process, data, team structure, or architecture changes. A chatbot experience may be easy to launch, but it has to be continuously evaluated, governed, and explained when it behaves in ways people did not expect.

AI may reduce the cost of creating these things, but it does not magically reduce all the costs that come after creation. In many cases, it increases them because it creates more context the organization has to understand.

A stakeholder asking for “just a quick experiment” can seem harmless until the experiment succeeds. If the team builds something lightweight and people start using it, suddenly the thing is part of how work gets done and you have to make trade-offs with existing strategy and priorities. What began as a cheap experiment now needs ongoing ownership. That means maintenance, support, ownership, and measurement need to be a part of the decision about whether it deserves to keep existing.

The cost looks like it disappeared to the stakeholder because they got their idea built cheaply. But the expense is still there for the organization. It just moved into the future and landed with whoever has to keep the thing alive.

That is the hidden yes. It often happens without a meeting.

People start using the workflow. A customer sees the prototype. A dashboard becomes part of a weekly review. A temporary automation becomes the only way a process gets done. Nobody formally decided the thing was now real, but the organization begins to depend on it anyway.

This is how cheap experiments become expensive clutter. Each experiment brings new customer or stakeholder expectations before the team has decided whether the thing deserves to exist. The problem is not that teams tried something. The problem is clarifying the consequences of trying.

Subscribe now

“Let’s Just Try It” Needs An Owner

I generally like “let’s just try it” as a product instinct. Small bets are usually better than long arguments and a cheap experiment is usually a very good thing for learning.

But “let’s just try it” becomes dangerous when nobody owns the consequences of trying.

What are we trying to learn? Who decides whether we learned it? What happens if the result is ambiguous? What happens if we succeed? Who maintains the thing and who turns it off if it half-works? What team absorbs the operational cost? What existing priority gets displaced if this becomes real? These are not bureaucratic questions, they’re ownership questions.

AI makes those questions more important because it makes trial creation easier. The organization can say yes to more experiments, which is useful, but only if it gets better at distinguishing between permission to learn, permission to scale, and permission to create a permanent responsibility.

Cheap Trials Create Cognitive Product Debt

At first, this looks like responsiveness. The team tried something quickly to make a stakeholder feel heard. Everyone feels like progress is happening without the discomfort of a harder commitment decision.

But each one adds weight because the team now has to remember why it exists, who asked for it, what it was supposed to prove, what dependencies it created, who is using it, what might break if it changes, and whether it still fits the strategy. None of that may show up as roadmap work, but it still consumes product capacity.

This is a type of cognitive debt: the accumulation of half-owned decisions, unclear evidence, stale experiments, stakeholder expectations, and small commitments that nobody wants to count as real work.

That is how “let’s just try it” becomes a drag on the very responsiveness it was supposed to create.

The answer is not to stop trying things, of course. The consequence of trying needs to be made explicit before the test begins. A team should be able to say yes to learning without accidentally saying yes to permanent ownership.

Governance Should Protect The Second And Hidden Yeses

The point of governance should not be to slow down every first yes. If every prototype, workflow, or AI-assisted experiment needs a committee before anyone learns anything, you’ve recreated the old bottleneck with new language.

Governance should define the boundary between learning and committing. Use it to help a team know what type of work they are starting and what happens if it succeeds or fails.

Use it to make the next decision explicit. That means asking different questions at each stage:

• For the first yes: Is this safe enough to try? Is the risk contained? Is the cost of being wrong acceptable?

• For the second yes: What evidence would justify scaling this? Does it fit the strategy? Are we confident enough to create a real dependency?

• For the hidden yes: Who owns maintenance, support, measurement, security, and the decision to turn it off later?

This is the difference between governance as control and governance as clarity. Bad governance slows down the first yes because leaders are uncomfortable with uncertainty. Good governance protects the second and hidden yeses because that is where cheap trials become lasting obligations.

Use governance not to add approval but to make ownership impossible to skip.

Know Which Yes You’re Giving

The organizations that handle this well are those that understand the difference between creating software and owning software.

That means treating the first yes as permission to learn, not permission to commit. A prototype can be cheap. A workflow can be useful. An experiment can show promise. But none of those things automatically deserve to become part of the product, the operating model, or the team’s permanent responsibility.

The harder question comes after the trial works well enough to create demand. Is the evidence strong enough? Does this fit the product strategy? Can the system support it? Who maintains it? Who measures it? Who answers when it breaks? Who gets to decide when the thing has run its course?

AI makes the first yes easier, which means teams need more discipline around the second and hidden yeses. Otherwise organizations will create product debt that does not look like product debt at first. It will look like momentum, responsiveness, and experimentation until enough of those cheap trials become permanent responsibilities nobody clearly chose.

The old product fight was often about getting onto the roadmap. The new fight is about what happens after the roadmap no longer catches every commitment.

AI may make it easier to start, but software still has to be owned. The teams that handle this well will not be the ones that say yes to everything or no to everything. They will be the ones that know exactly which yes they are giving.

On the surface, everything looks connected. The company objective points to a strategy. The strategy points to initiatives. The initiatives become epics. The epics break into stories. The hierarchy is visible enough that everyone can nod along.

But the visible cascade is only the tip.

Underneath it is the real structure: a hidden chain of assumptions, like users will behave differently, this metric represents real value, this data is trustworthy, this dependency will unblock in time, the market will still care about this and the customer problem is still the same problem we thought it was.

Those assumptions are beliefs that actually connect strategy to work. The documents at the top of your cascade just make the connection look clear.

Most Don’t See the Chain

A goal cascade is usually presented as a hierarchy of intent. Company goal at the top. Product outcomes underneath. Initiatives below that. Work items at the bottom.

That structure is useful, but it hides the part that matters most. The path from one layer to the next depends on claims that aren’t usually explicit. They’re more likely to come from single-serving Slack threads, meeting notes, backlog bugs, or someone’s memory of why a decision was made three months ago.

That is why teams can be “aligned” and still be wrong. They are aligned around the visible structure, while the hidden assumption chain remains untested.

Take a simple outcome statement you might see at the top of a cascade. No matter how reasonable and rational it sounds, it contains a chain of beliefs that need to influence not only how you measure success of the outcome but also how you approach it.

• As an example, imagine the goal “Improve onboarding to increase retention”

• let’s say one key assumption that led to the work getting prioritized is that early dropoffs are caused by friction in the existing onboarding flow. That assumption detail does not always belong at the top of the cascade, but it’s critical for the team to validate as part of their approach. If the team isn’t all aware of that assumption and someone else comes in without awareness, the team could waste a lot of time building a new onboarding feature that completely misses the reason to do this in the first place.

And assumptions go layers deep, with assumptions build on assumptions on assumptions. We assume the onboarding behavior being targeted predicts long-term value, that retained users are actually successful users, and that we can change the experience without creating new confusion somewhere else.

In reality, the chain of assumptions under every goal is probably more spider web than cascade. If the links hold, the work has a path to impact. If one or two links are weak, the team may still ship useful improvements, but the strategic story starts to wobble.

AI Makes Weak Chains Spread Faster

Writing the cascade and connecting the dots is slow, confusing, thankless work. There’s a reason most cascades stop 2-3 layers in: the connective tissue between layers gets less and less clear and the effort to make it coherent feels like diminishing returns. Still, the exercise itself forced some thought that makes product teams make choices.

AI can change this. Given the right context and constraints it can generate an entire comprehensive goal cascade replete with strategies, justifications, initiative ideas, and annotated research, and get it all approved faster than a team can inspect the assumptions underneath them. For teams that already understands the chain this is a modern day miracle.

It’s still dangerous when generation becomes a substitute for understanding though. The risk is that AI can help weak cascades look coherent sooner. The work gains the appearance of alignment without any deliberate thought.

Subscribe now

AI Is Better at Seeing Across the Mess

This is also why AI is useful here.

Humans are good at judgment, context, and sensing when something feels off. But we are bad at holding a messy web of documents, conversations, research, metrics, dependencies, and decisions in our heads at the same time.

AI is unusually good at traversing that mess. It can compare the roadmap to customer interviews. It can look for whether a metric has ever been defined clearly. It can notice that three initiatives depend on the same unvalidated belief. It can connect a support theme to a product bet, or a decision log to a dependency nobody has mentioned in the current planning cycle.

That does not mean AI knows whether the strategy is right. It means AI can help surface the hidden links humans are likely to miss and articulate the significance as signal vs noise.

The better prompt is not “write our goal cascade.” Instead, try asking AI to inspect the chain:

“Given this goal, strategy, research, metrics, and backlog, identify the assumptions that must be true for this work to create the intended outcome. For each assumption, show the evidence, contradictions, dependencies, risks, and what we still need to learn.”

Subscribe now

The Hidden Chain Should Be Inspectable

A useful AI-assisted cascade would not only show parent and child items. It would show the assumption chain that gives the cascade meaning.

That changes the conversation. The team is no longer debating whether the initiative sounds aligned. They are asking whether the chain is strong enough to carry the bet.

That is where AI can help. It can illuminate the submerged structure. It can show where a link is supported by evidence, where it depends on an old decision, where two teams are relying on incompatible assumptions, or where the chain simply disappears.

The Point Is Not More Planning Artifacts

There is a reasonable objection here. Teams do not need new assumptions templates and more documentation. Many already drown in planning rituals, templates, and status artifacts.

The point is not to create an assumption bureaucracy. The point is to make the load-bearing assumptions visible at the moment they shape decisions. With AI teams don’t need to document every possible belief and they can more easily see which hidden links must hold for the work to matter.

The practical test is simple: for any important goal, initiative, or backlog theme, ask what must be true for this to create the outcome we expect?

If the answer is obvious and supported, keep moving. If the answer is vague, contested, or unclear, that is a place where AI can help. Ask it to trace evidence, to find contradictions, or to map dependencies. Use it to understand which initiatives rely on the same assumption. Ask it to separate what the team knows from what the team hopes.

Artifacts Get Cheaper. Belief Gets Harder.

When AI makes artifacts cheaper, the harder work becomes deciding what deserves belief.

A polished strategy, long backlog, or clean OKR tree mean less by themselves. Their value depends on the hidden chain underneath them: the assumptions, evidence, dependencies, and risks that explain why the work should produce the outcome.

I think this will make goal cascades more demanding, not less. A cascade should help a team move from purpose to action without forgetting the uncertainty along the way. When artifacts all communicate with certainty, the uncertainty doesn’t disappear from the actual work. It waits until later, when it is more expensive to face.

AI can help teams use the submerged structure. It can trace connections across messy information that humans do not have time to hold all at once. It can illuminate the hidden chain between goals and work.

Humans are good at judgment, but bad at holding the whole web in our heads. AI can help trace that web across the messy material of work. The opportunity is not faster goal generation. It is making the invisible assumption chain visible enough to challenge.

Share

In In Praise of SWARMing, Dan North names a problem a lot of organizations keep recreating when trying to improve how they work at scale:

• When they find a useful way of working, then they try to scale it by turning it into a religion.

• And then the ceremonies, language, and templates of that method become the gospel instead of the actual qualities that made the way of working useful in the first place.

North’s alternative is SWARMing: Scaling Without A Religious Methodology. The point is that a framework itself is not change. Real change depends on pioneers, education, practice, communication, investment, leadership, and enough local adaptation for the idea to survive reality. His lesson matters as much, if not more, with AI.

AI Is About To Repeat Agile’s Mistake

A lot of organizations are poised to make the same mistakes with AI as they did with Agile. They will create a centralized rollout, define approved use cases and tools, mandate training, standardize prompts, build maturity models, and call that a scaling adoption. Some of that will be necessary or even helpful, like governance as an enabling constraint or default playbooks to guide learning.

But if AI adoption is forced to conform to a scaling model, it’s essentially treating documents and templates and processes as gospel again.

I’ve made the argument before that the inertia of large organizations is hard to stop, In this scenario, an organization that expects AI to conform to their operating model will inherit an AI with the weaknesses of that operating model. The result will look controlled. It will also be brittle.

How Useful Practice Becomes Compliance

You can already imagine the version that fails. It begins with teams trying AI and finding slightly different reasons to keep using it. Each team is learning something different because each team’s work is different.

Then the organization notices the activity and decides it is time to choose a way to scale. A central group packages the practices into an enterprise AI methodology. Everyone gets the same training and access to the same approved workflow. Teams are asked to document use cases in the same format, route exceptions through the same governance path, and report adoption through the same dashboard. The local learning gets flattened into compliance. Successful adoption becomes the amount of code AI writes or the number of completed framework documents.

AI is not just another tool you install. It can and should change its shape depending on the work. A religious methodology tries to stabilize the practice too early. It turns early learning into policy before the organization understands the conditions that made the learning work.

SWARMing Is Disciplined Adaptation

SWARMing gives you a better path. Let pioneers explore in real work. Give them constraints, not scripts. Make the learning visible. Create places for people to compare patterns. Invest in education that helps people think better, not just follow approved workflows. Bring in external perspective where it helps, but do not outsource judgment. Let the practice spread through usefulness before you freeze it into procedure.

That does not mean “let everyone do whatever they want.” This is where SWARMing is often misunderstood. It is not chaos. It is disciplined adaptation.

The discipline comes from shared principles and clear boundaries. What data can be used? What needs human review? Where is AI allowed to assist but not decide? What kinds of work require traceability? What risks are unacceptable? What does good practice look like when the output is wrong, incomplete, or too confident?

Those constraints matter. They create safety. But within those constraints, teams need room to learn.

Subscribe now

Different Work Needs Different Practice

A product team using AI to explore customer problems should not have the same workflow as a legal team reviewing contract language. An engineering team using AI inside a test-driven workflow should not be treated the same as a marketing team generating campaign copy. The risks, feedback loops, and expertise required to judge the output are all different.

“How do we roll out AI across the organization?” is a leading question because it already assumes the answer is a rollout. A single methodology hides those differences. SWARMing turns the differences into strategic levers. One rollout strategy is too generic. A bespoke strategy for every team is too much. The useful middle is adapting around real use cases once value appears.

A better approach would be to adapt to different use cases once the value of AI appears there. Better next questions are “What makes the way AI addresses the need in this situation good? What parts of it could be used by others and for what situations?”

Leaders Should Look For Pioneers, Not Playbooks

That shift changes the work of leaders. Instead of asking for a master playbook, leaders should be looking for pioneers. Who is already using AI in a way that improves learning, quality, or flow? What constraints are they respecting? What judgment are they applying? What mistakes did they make? What would break if another team copied the practice blindly? Blind copying is where good ideas go to become templates.

If one team succeeds with AI because they already have strong code review, automated tests, and shared ownership, the lesson is not “everyone should use the same coding assistant workflow.” The lesson might be that AI works well when the team already has fast feedback and strong engineering discipline. If another team copies the tool without the feedback loop, they may not get the same outcome.

AI Inherits The Operating Model

That is what I mean by AI inheriting the operating model. If your organization rewards output over learning, AI will produce more output. If your governance model delays decisions, AI will wait in the same lines. If your teams lack decision rights, AI will become another thing they need permission to use. If your culture punishes mistakes, people will avoid AI to avoid punishment.

AI does not make a brittle system adaptive. It gives the system another mechanism to create brittleness.

The Better Version Is Possible

I believe there are things to be optimistic about too. In a healthier operating model, AI can make SWARMing work better. AI can capture what pioneers learn more reliably, help teams compare experiments, and make winning and losing patterns easier to share. It can help translate a practice from one context to another while preserving the caveats. It can help people rehearse new ways of working before they have to defend them in front of skeptics. Used that way, AI supports the spread of practice.

Are you scaling AI by spreading learning, or are you scaling AI by enforcing sameness?

Sameness will feel safer at first. It gives something to approve and something to measure. It gives transformation teams something to package. But sameness is often a poor substitute for coherence. Coherence means teams are working from shared principles while adapting to their context. Sameness means everyone is following the same shape whether or not it fits the work.

AI needs coherence more than sameness.

The Real Lesson

That is the lesson I take from North’s SWARMing idea in this moment. Scaled practices work best without a rigid methodology, and AI is no different.

The failure mode for AI transformation is the same as the failure mode for agile transformation. Agile became ceremony without agility. Product operating models became role diagrams without product judgment. Transformation became new vocabulary without changed incentives or mindsets. AI can go the same way.

Or it can spread differently. Through small groups of practitioners doing real work. Through constraints that protect the organization without freezing the practice. Through leaders who understand that adoption is not the same thing as learning.

AI does not need a religious methodology. It needs pioneers, practice, feedback, and enough room to adapt to the work.

That is harder to manage than a rollout. It is also much more likely to survive.

Now many of them become software. It’s not always good, but usually enough to use for at least a few days. I’ve built more prototypes, workflows, GPTs, and small applications in the last year than the rest of my life.

At first, that felt like the end goal itself: more of my ideas could become tangible. I could build directly from the problems I actually understood.

The Ideas That Didn’t Stick

But after a few cycles the excitement wore off and a second pattern became more interesting: most of those things disappeared from my life almost as quickly as they appeared.

Some were useful:

• AI-powered voice notes so I could capture five-second ideas while driving.

• A reading list and wishlist that combines books, games, TV, and gift ideas.

A few were clever:

• An agent that lets me chat with news headlines so I can question the broader picture instead of getting pulled into one article’s bias.

Some were bizarre:

• We recently got a Cavapoo puppy. He’s cute, but his poop blends right into the leaf-covered grass in the backyard. I built an app that analyzes a photo and tries to find it.

They were all interesting and most were generally useful. Still, most of them disappeared from my life pretty quickly after I built them. A smaller number of problems kept coming back across all of them: making informational noise useful, decision-making, making learning faster and easier, and using all that to help judgment scale broader than myself.

AI made it easier to explore more directions, but it also made it clearer which questions I could not seem to leave alone.

The Old Rule Still Matters

That has changed how I think about one of startups’ oldest pieces of advice: build something you would use.

For a long time, I’ve liked that advice. It cuts through a lot of product theater. Instead of inventing a persona from a distance, start from a problem you understand. Instead of guessing what people might want, pay attention to something that bothers you enough to fix.

If you build a product you actually use and keep using it after the novelty wears off, that tells you something real: that the problem exists for at least one person and you are close enough to it to appreciate and understand the nuance.

I still think all of that matters. I’m less sure it means what it used to mean.

Subscribe now

The Filter Got Weaker

The old rule worked partly because building was expensive. Not always expensive in money, but expensive in effort, attention, coordination, and skill. If someone spent nights and weekends building a tool for their own problem, the work itself was a filter. It suggested the pain was worth it.

Being able to build anything makes that filter weaker. AI makes it much easier to turn a personal itch into working software, which is mostly good. A lot of useful things should exist that previously would not have been worth the cost. But it changes the signal.

Historically, “I built it because I needed it” carried a lot of information. Today it can also mean “I had an idea and two free hours.” Those are not the same signal.

Imagine someone builds an AI assistant for managing their own product notes. It understands their shorthand, their meeting rhythm, their tolerance for messy drafts, and the way they think about roadmaps. They use it constantly. It saves them time. It feels indispensable. But the fact that it works for them does not prove that another product manager would adopt it. Another person will have different habits, different organization preferences, a different way of using tribal knowledge, and a different need for automation. The builder’s use proves the tool fits one lived system. It does not yet prove the product can survive contact with someone else’s system.

Personal Use Is Exposure

This is where the old advice needs a sharper reading. Personal use is exposure. It is not validation.

When you use your own product, you expose yourself to details that outside observation often misses. You notice whether the flow still makes sense on the fifth use, not just the first. That kind of use is valuable because it improves your judgment about the thing you are making.

But market demand lives one step beyond that. Others have to try it without your enthusiasm or sunk-cost mentality carrying them. They have to use it in ways you didn’t need to. They have to switch from whatever they were doing before. Eventually, they have to pay or risk something meaningful to keep using it.

The Bottleneck Moves To Judgment

AI makes this distinction more important because it increases the number of plausible products. When building gets easier, the bottleneck moves.

The hard part becomes less about whether you can make something and more about whether you can tell which things deserve to become products. That puts more pressure on taste, not less.

Taste in product work is not just visual polish or clever interaction design. It is the ability to tell whether a solution fits the shape of the problem and knowing which rough edge matters and which one can wait. It’s being honest when the thing you built is useful to you because of your own habits.

First-Person Pain Is Not The Whole Test

There is a counterargument here: maybe AI makes “build what you’d use” better advice. If more people can create software, then more people can solve real problems from direct experience instead of waiting for a company to notice them. Some of the best products will come from people building directly inside their own pain.

I think that is right. The danger is treating first-person pain as the whole test.

A product can be born from personal need, but it has to grow through other people’s constraints. Otherwise, you are not learning whether there is a market. You are learning that you have good tools for yourself.

That may be the right outcome. One of the underrated effects of AI may be that more software becomes personal, local, and narrow. We may get more tools that are not companies, more workflows that are not platforms, and more products that are valuable without becoming markets. That should change how we talk about building. Not every useful thing needs to become a startup.

But if you are trying to build a product for others, you need a better barometer than love.

Explore Broadly. Commit Narrowly.

The better principle is: explore broadly, commit narrowly.

Use AI to explore more than you could before. Build the weird prototype. Test the workflow. Make the rough version of the thing you would previously have only described. Let yourself create more options, because the falling cost of exploration is one of the most valuable things AI gives us.

Then be much more demanding about what earns commitment.

Would you use it when you are busy, or only when you are curious?
Would someone else use it without you explaining why it matters?
Would they keep using it when it conflicts with their existing habits?
Would they give up something real for it: time, money, workflow, status, control?
Does your own use reveal a broader pattern, or only your personal way of coping?

The first question still matters. If you would not use the thing, that is usually a bad sign. But the next questions are where product work begins. They move you from taste to demand.

The Beginning Of Evidence

I hope AI does not make “build something you’d use” obsolete. I don’t think it will. The principle still protects us from a worse habit: building from abstraction, trend-chasing, and imagined customers. But AI does make the principle easier to misuse. When creation is cheap, conviction can arrive too early. A working prototype can look like evidence before it has earned that role.

So build what you’d use. Love it enough to live with it. Use it long enough to become annoyed by its flaws. Let your own workflow teach you what the product is trying to become.

Then get more skeptical. Your use is the beginning of the evidence, not the end of it.

But that question is too small.

Accounting Models Become Culture

A while back I got interested in throughput accounting, and I keep seeing applications for it in AI.

Throughput accounting is a foil to traditional cost accounting. Cost accounting teaches a company to see financial health through costs, utilization, efficiency, and expense control. Throughput accounting starts from a different assumption: the goal is not to keep every resource busy, but to increase the flow of value through the system.

This is a problem for companies adopting AI, because accounting models become company culture. A company that manages through cost accounting protects utilization. So AI gets asked to justify itself, and the first ROI question is: how much time did it save? How many tasks did it automate? How many people can now do the work of more people?

Why Lean Gets Misread

But if efficiency is the main frame, AI gets pulled into the same worldview that made Lean difficult to adopt. It becomes another way to squeeze more output from the existing system instead of a way to question or expand the system itself.

Subscribe now

The more interesting possibility is that AI lowers the cost of exploration. A team can compare ten ways to frame a customer problem before picking one or explore more ideas before committing to a prototype. Engineers can pressure-test an approach or understand unfamiliar code faster.

Of course AI can also create noise, false confidence, shallow work, and a flood of plausible nonsense. Exploration still needs taste, judgment, contact with reality, and some disciplined way to decide what evidence matters. But the cost curve changes.

When exploration is expensive, companies ration it. But with AI, or Lean, or Throughput accounting, that’s asking for confidence at the exact moment when confidence should still be low.

AI changes the excuse. If the cost of trying more paths goes down, the bottleneck is no longer just capacity. It’s whether the company is willing to treat learning as legitimate work. That's a budgeting question as much as a technology question, and it's where throughput accounting becomes the right lens to look at this.

Saved Time Is Only Valuable If You Spend It on Better Bets

Imagine a team that adopts AI and saves ten hours a week. A cost-accounting worldview immediately asks how to fill those ten hours. Can the team take on more work? Can the headcount shrink and the same people support more?

A throughput-oriented worldview asks a different question: what value do those ten hours create?

Could the team test a riskier assumption? Could they explore where the system that keeps creating rework? Could they propose a new revenue path that previously felt too speculative to touch?

Two Different Theories of ROI

The difference is more than preference for creativity over discipline, it’s an entirely different theory of where money comes from. If you believe the company’s main problem is that labor is too expensive, then AI should make labor cheaper. If you believe the company’s main problem is that it is too slow to discover and exploit valuable opportunities, then AI should increase learning throughput.

Those two beliefs lead to different behavior.

1. Cost accounting: turns AI into an extraction tool. It asks people to do the same work faster, then fills the freed space with more of the same work.

2. Throughput accounting: turns AI into an option-creation tool. It asks what the company can now afford to learn, test, or attempt that used to be too slow or too costly.

The Lean Trap, Repeated

A lot of companies wanted Lean results without changing the management assumptions that made Lean possible. When adopting Lean they wanted speed without slack, quality without stopping the line, and continuous improvement without giving teams time to improve anything.

AI could suffer the same fate: innovation while everyone is measured by utilization, experimentation while unused capacity gets punished, new growth while every saved hour is treated as a cost-reduction opportunity.

The danger is that AI will work just well enough to reinforce the wrong habit.

A company might become faster at producing documents nobody needs. Faster at building features that do not matter. Faster at analyzing markets it will not enter. Faster at generating plans that still avoid the hardest uncertainty. The dashboard will show productivity gains, but the business may not become more adaptive.

The second-order problem is that once AI makes output cheaper, output becomes a worse signal. More drafts, more tickets, more stuff that says less than it used to. The scarce thing becomes the ability to choose, learn, and change direction based on what is learned.

The Real Divide

So the practical test is simple: when AI saves time, where does the time go? If it only disappears into more productivity metrics, the company is using AI as a cost tool. If some of that time gets deliberately reinvested into customer learning, product discovery, system improvement, technical quality, or new revenue exploration, AI becomes something more strategic.

Companies still need discipline. They still need operating leverage. They still need to stop funding vague experiments that never meet reality. Throughput is not an excuse for wandering.

Not mean every AI gain should become exploration. But if every AI conversation has to justify itself through cost reduction, the company never sees the larger opportunity.

AI won't tell us which companies are technologically advanced. It will tell us which companies have a management system capable of learning. The ones that treat saved time as saved cost get efficiency. The ones that turn saved time into better exploration find something more valuable.

Someone asks what the team is working on. Someone else answers with a feature, a platform, an API, a migration, a website, a dashboard, a date. They want the answer to sound concrete and detail gives people confidence. Someone else puts the answer on a slide and gives leadership something to track.

But there is a problem hiding inside that concreteness: None of those things tell you whether the work will matter.

An API might reduce integration time. Or it might become another dependency no one wants to use. Another add-to-cart button earlier in the funnel might increase conversion, or it might double the same friction in two places.

Outputs are necessary. Teams have to build things. But outputs do not guarantee effect.

Share

Outcomes Are Easy to Say and Hard to Operate By

People have a lot of trouble operating by outcomes. It’s literally easier said than done.

Years ago, I gave a simple talk called “Outcome Roadmaps, MVPs, Oh My.” It was factual and simple: outcomes are the effects we want our work to have and outputs are the things we produce.

• Increased conversion is an outcome.

• Decreased production cost is an outcome.

• Better user experience, faster time to market, higher uptime, lower support burden: those are outcomes.

• APIs, websites, platforms, features, services, and batch jobs are outputs.

Most organizations know this distinction intellectually. Most companies say they work based on some version of outcomes over outputs. Most of these have trouble staying outcome oriented as soon as planning starts because under pressure, outputs always win. Outputs are easier to name, easier to sequence, easier to assign, and easier to report. “Profile pages in Q2” sounds more responsible than “increase credible professional connections by reducing first-session uncertainty.” The first sounds like a commitment. The second sounds like a belief that still has to be tested.

But product work is mostly made of beliefs that still have to be tested.

Detail Is Not the Same as Truth

The common response is to make the roadmap more detailed. Add more dates! Add dependencies and capacity plans! TL;DR add confidence by increasing specificity. That can be useful when the work is close, underway, and mostly execution risk. A team needs a backlog. Engineers need stories. Designers need constraints. Product managers need sequencing. Detailed outputs have their place.

The mistake is treating every time horizon like backlog work. A useful product planning stack has different levels of certainty. Vision explains why the work exists and may last for decades. Strategy explains how we believe we can realize that vision and may last for years. A roadmap describes the tactics and bets we believe will move the strategy forward over months. A backlog contains the near-term details needed to create outputs over weeks.

Those layers are not just a hierarchy of documents. They are a hierarchy of uncertainty. The further away the work is, the less truthful detail you have. If your roadmap looks equally precise six months out as it does two weeks out, something is probably being hidden. Either the team is pretending uncertainty is lower than it is, or the roadmap has become a list of desired outputs instead of a map of intended outcomes.

Roadmaps Should Make Uncertainty Visible

That is why the most truthful roadmaps often look incomplete to people who want certainty from them. They show direction without pretending the future is known. They communicate what the team currently believes will matter. They name outcomes, metrics, and risks. They make uncertainty visible instead of burying it under feature detail. They create a feedback loop between what we build and what effect it has.

This is where MVPs fit, and where they are often misunderstood.

An MVP is not the smallest thing the team can ship while still satisfying the stakeholders. It is not a reduced-scope version of the original feature list. It is not the ugly first release everyone apologizes for. At its best an MVP is a learning tool. It helps answer the question underneath the roadmap: how do we know we are going to build the right thing?

The honest answer is that we don’t.

We can have research, data, taste, experience, strong opinions, customer interviews, analytics, and a strategy that makes sense. We should use all of that. But none of it removes uncertainty. Product work is not made correct by confidence. It becomes more correct through feedback.

That feedback only works if the roadmap leaves room for learning.

The Feature Factory Trap feels right, but it’s false responsibility

When organizations skip the outcome layer, planning collapses into a strange shape. There is a vision at the top, a pile of features in the middle, and a backlog at the bottom. It looks practical because everyone can see work. But the connective tissue is missing. People do not share an understanding of the outcomes they are trying to create. They do not share an understanding of which problems matter, for whom, or why now. Communication gets expensive because every decision has to be re-litigated. Teams get lost in implementation detail. Duplicate efforts appear because groups are solving adjacent problems without realizing it. Worst of all, progress becomes harder to judge because the organization can see shipping but cannot see effect.

That is the feature factory trap, but it rarely feels like a trap from the inside. It feels like being responsible. It feels like honoring commitments. It feels like giving the business what it asked for.

A thoughtful person can object here. They might say, “The business needs dates. Sales needs to know what is coming. Customers need commitments. Finance needs planning inputs. Teams cannot operate on vibes and learning language.”

That objection is fair. Outcome orientation should not become a fog machine. A roadmap that refuses to say anything concrete is not mature; it is evasive. Teams still need commitments. Stakeholders still need clarity. The question is what kind of clarity is appropriate at each altitude.

For near-term work, clarity should look like executable detail. What are we building? Who owns it? What constraints matter? What is the acceptance bar? What needs to be true before we call it done?

For farther-out work, clarity should look different. What outcome are we pursuing? What metric would tell us we are making progress? What risks could invalidate this direction? What do we believe now, and how confident are we? What decision will we make once we learn more?

That is a more useful form of honesty. It separates confidence from theater.

A roadmap can say: current, near term, future.

It can say: high confidence, medium confidence, low confidence.

It can say: here are the outcomes we care about, here are the metrics we will watch, here are the risks we know about, and here are the bets we are considering.

It can still include outputs, but the outputs sit underneath the outcome they are meant to influence. But they should not replace it.

Instead of asking, “Are we still shipping advanced matching in Q3?” the team can ask, “Is user growth still the outcome that matters most, and is advanced matching still our best bet?” Instead of arguing whether a feature is late, the team can ask whether the learning changed the path. Instead of treating roadmap change as failure, the organization can treat some change as evidence that the team is paying attention.

That last part matters because roadmaps have a trust problem.

Many teams have been punished for changing plans, even when the change was rational. So they learn to make roadmaps that look stable and then manage reality somewhere else. The published roadmap becomes a diplomatic artifact. The real roadmap lives in conversations, exceptions, side channels, and last-minute prioritization meetings.

An outcome roadmap should reduce that split. It should make the real conversation visible enough that people can participate in it.

Subscribe now

Learning Should Be Part of the Plan

There is a second-order effect here that is easy to miss. When roadmaps are output-heavy, learning becomes inconvenient. New information threatens the plan because the plan is defined by deliverables. When roadmaps are outcome-oriented, learning becomes part of the plan because the plan is defined by intended effect. The team still has to make hard calls, but it has a better language for making them.

This does not mean every roadmap item has to be abstract. It means every meaningful output should be traceable to an outcome. If no one can explain what effect a feature is supposed to create, the feature is not ready to be treated as important. It may be a good idea. It may even be the right idea. But it has not earned the confidence people are assigning to it.

That one question can improve the whole conversation. It forces the team to name the effect. It reveals whether metrics exist. It exposes assumptions. It helps separate “we need this because someone asked for it” from “we believe this will move an outcome we care about.” It also gives teams permission to change the output if they find a better way to create the same effect.

The Job of a Roadmap

The roadmap’s job is not to make uncertainty disappear. Its job is to help people move through uncertainty together.

That means the most honest roadmap will always disappoint someone looking for a perfect prediction. It will have detail where the team has earned detail. It will have looser language where the team is still learning. It will show confidence levels instead of hiding them. It will connect vision to strategy, strategy to outcomes, outcomes to bets, bets to outputs, and outputs back to measured effect.

A roadmap should communicate the direction we plan to go. It should assume uncertainty and change. It should optimize for learning and response. And it should be oriented around outcomes, because shipping the thing was never the point.

The point was the effect the thing was supposed to have.

Subscribe now

A team using agents can now create more software than it can responsibly pursue. That is a strange new problem. For years, the bottleneck was often obvious: not enough engineering capacity, not enough content capacity, not enough design capacity, not enough cycles to try the thing everyone already suspected might work.

Now the bottleneck can move. A small team can generate five prototypes, rewrite a service, draft three product directions, produce onboarding copy, and explore a new integration before the old planning meeting would have ended. That feels like leverage, and sometimes it is. But it also creates a trap: when the number of possible moves increases, the cost of choosing the wrong places to play goes up.

This is why the factory metaphor that asks “how do we produce more?” feels incomplete for AI. Maybe a better comparison is the Colonel Blotto thought experiment. It asks a better question: “Where does concentrated effort actually win?”

In the Colonel Blotto game, two players allocate limited forces across several battlefields. Each battlefield is won by whoever commits more there, and the overall winner is determined by how those local contests add up. The best strategy is not simply to have more troops, but to concentrate your troops where you can win.

That is starting to sound like software work with AI. You can ask an agent to produce more code but you still have to decide whether that code belongs in the product, whether the problem is worth solving, whether the architecture can absorb it, whether the customer will care, and whether this bet deserves another week of the team’s attention.

The danger is that cheap execution makes weak allocation feel productive. A team can fill the board with activity: one agent on onboarding, another on analytics, another on a refactor, another on sales enablement, another on an experimental feature. Each effort can look reasonable in isolation. Each can produce visible artifacts. The board looks busy, the demos look encouraging, and the repository evolves.

Then, a month later, nothing important has moved.

Colonel Blotto helps because it treats strategy as a problem of uneven commitment. You do not win by being everywhere. You win by understanding which battlefields matter, which ones can be conceded, and where a little more effort changes the outcome. In product work, that might mean concentrating AI-assisted development on the one workflow that blocks activation instead of generating improvements across ten surfaces. It might mean using agents to explore a narrow technical migration deeply enough to de-risk it, rather than scattering prototypes across every idea in the backlog.

There is a second-order implication here that is easy to miss: AI does not just make execution cheaper, it makes plausible work cheaper. That, to me, sounds more dangerous. Bad ideas used to reveal themselves partly through friction. If something was not worth a designer’s week or an engineer’s sprint, it often died before consuming too much organizational attention. That filter was crude and sometimes harmful, but it was a filter.

When AI lowers the cost of first drafts, prototypes, scaffolding, and variations, more ideas survive long enough to look real. The organization then needs a better allocation discipline, because the old friction is gone. Someone has to ask: if this works, what changes? If it does not work, what will we learn? What are we willing to stop doing so this can matter?

The competing interpretation is fair: maybe cheaper execution means teams should try more things. In many cases, they should. AI can make exploration less precious. It can reduce the penalty for sketching alternatives, testing a throwaway implementation, or comparing product directions before committing. That is a genuine advantage.

The mistake is treating exploration capacity as strategy. More options are useful only if the team has a way to choose among them. Otherwise, AI becomes a machine for manufacturing unfinished bets. The team gets wider without getting sharper.

A practical test is simple: ask where additional effort would change the outcome. If a feature is already good enough and the remaining work is polish no one will notice, adding AI-generated variations may not matter. If a workflow is the main reason users fail to activate, concentrated effort there might change the trajectory of the product. If a technical migration blocks every future bet, using agents to reduce uncertainty there may be more strategic than producing another visible feature.

The Blotto question is uncomfortable because it forces loss into the conversation. Where are we choosing not to compete right now? Which reasonable ideas are we letting go? Which battlefield only matters because it is loud, recent, or easy for AI to produce work around? Strategy gets real when the team can name the places it is under-allocating on purpose.

For leaders, this changes the way AI adoption should be judged. The question is not “Are people using agents?” or “Did output increase?” Those are factory questions. The better questions are: Did we concentrate effort on the few constraints that mattered? Did AI help us learn faster where uncertainty was highest? Did we stop more low-value work because production got cheaper? Did the team become better at choosing?

For practitioners, the lesson is more immediate. Before spinning up another agent or generating another path, name the battlefield. What are you trying to win? What would count as winning locally? What would you stop doing if this deserved real concentration? If the answer is vague, the tool may only help you move faster into fog.

AI is an execution advantage, but execution advantage without allocation discipline can become strategic noise. Colonel Blotto gives us a better metaphor because it keeps scarcity in the picture. The scarce thing is no longer just hands on keyboards. It is attention applied unevenly, deliberately, and with enough courage to leave some parts of the board alone.

Be adaptable. Improve continuously. Collaborate. Build for scale. Stay resilient. Think sustainably. Go deep. Stay broad.

All of that is true. The problem is that truth at that level is hard to act on. If a team is behind on a product launch, “be adaptable” doesn’t tell them whether to change direction or stay the course. If an organization is drowning in priorities, “collaborate more” may create more meetings without creating more clarity. If a person is trying to build a career, “go deep” and “stay broad” can sound like opposite instructions.

The useful question is not which principle matters. Most of them matter eventually. The useful question is how they fit together.

A lot of success comes from composition: small pieces, well-shaped, combining into something bigger than any one piece could become alone. That is true in software, teams, learning, strategy, and even nature. A coral reef is not impressive because one organism became enormous. It is impressive because many small living systems interact, recover, adapt, and build structure over time. A strong product organization works the same way. So does a durable career.

We often talk about success as if it comes from finding the right rule. But rules are too blunt. What actually works is a pattern: go deep enough to create real capability, broad enough to see context, small enough to change, and connected enough to matter.

Depth Creates Power

Depth is where skill compounds.

A designer who understands accessibility deeply sees problems other people miss. An engineer who understands distributed systems deeply can prevent failures before they become incidents. A product manager who understands a customer workflow deeply can tell the difference between a feature request and the real job underneath it.

Depth matters because shallow understanding creates fragile confidence. From far away, most problems look simpler than they are. The team says, “We just need a dashboard.” The executive says, “We just need better adoption.” The roadmap says, “We just need to ship the integration.” Then the work begins, and the hidden structure appears: incentives, edge cases, dependencies, trust gaps, operational cost, customer behavior.

Depth is how you stop being surprised by the same class of problem over and over.

But depth has a failure mode. It can become isolation. A deeply skilled person can optimize a part of the system while missing the system itself. A team can become excellent at delivery while building the wrong thing. A company can become great at efficiency while losing the ability to notice that the market has moved.

Depth gives you power, but it does not automatically give you perspective.

Breadth Creates Sense

Breadth is how you see relationships.

It helps you notice that a technical decision is also a support decision. A pricing change is also a trust decision. A process problem may actually be a strategy problem. A team’s “execution issue” may be caused by unclear priorities three layers above them.

This is why broad thinkers are valuable in complex environments. They connect signals across domains. They can move between customer needs, business constraints, technical tradeoffs, and team dynamics without pretending those are separate worlds.

But breadth has its own failure mode. It can become vague. It can turn into pattern-spotting without craft, strategy without consequences, or commentary without ownership. Broad thinking is only useful when it eventually lands somewhere.

The best work usually needs both: enough breadth to choose the right problem, enough depth to solve it well.

The Missing Principle Is Composition

Adaptability, iteration, efficiency, resilience, collaboration, balance, feedback, diversity, sustainability, modularity, and scalability are not separate success rules. They are parts of a larger system.

Adaptability works better when the system is modular. Iteration works better when feedback is honest. Collaboration works better when people bring diverse depth, not just diverse opinions. Efficiency works better when it does not remove the slack needed for resilience. Sustainability works better when short-term decisions still have a path into the long term.

A product team is a good example. You can have excellent engineers, thoughtful designers, strong product leadership, and a clear business goal, and still produce mediocre results if the pieces do not connect. The designer explores possibilities the engineers never see. The engineers discover constraints the roadmap never absorbs. The product manager gathers customer evidence that arrives too late to shape the decision. Everyone is doing reasonable work, but the system is not composing.

Now imagine the same team working in smaller, connected loops. A customer problem is broken into testable slices. Design explores just enough to reveal the real interaction problem. Engineering identifies the riskiest assumptions early. Product keeps the business goal visible without turning it into a slogan. Feedback arrives while the work is still changeable.

Nothing magical happened. The pieces got smaller, clearer, and better connected.

That is why “smaller pieces” matter. Not because small is always better, but because smaller pieces can be tested, moved, recombined, and understood. They let a system learn without forcing the whole system to break.

Share

Scale Comes After Shape

A common mistake is trying to scale before the pieces are shaped well.

Organizations do this when they create a process for work they do not yet understand. Product teams do it when they build a platform before they have repeated use cases. Individuals do it when they try to build a personal brand before they have a body of work.

Scale amplifies structure. If the structure is strong, scale creates reach. If the structure is weak, scale creates drag.

That is why modularity matters. A modular system can grow without every new addition making the whole thing harder to change. Microservices are one technical example, but the same idea applies outside software. A company with clear decision rights is more modular than one where every decision requires every leader. A career built from durable skills is more modular than one built around a single tool. A roadmap made of clear bets is more modular than one made of vague themes.

The point is not to break everything into tiny pieces forever. The point is to create pieces with meaningful boundaries, then connect them deliberately.

Small pieces become powerful when they can combine.

Balance Is Not Neutrality

“Balance” can sound passive, like the goal is to stand in the middle of every tradeoff. But real balance is more active than that. It means knowing what the situation calls for.

Sometimes resilience matters more than efficiency. Sometimes speed matters more than completeness. Sometimes depth matters more than alignment. Sometimes broad exploration matters more than commitment.

The mistake is treating principles as permanent preferences. A team that always values efficiency will eventually remove the slack it needs to adapt. A team that always values collaboration may avoid hard decisions. A team that always values adaptability may never commit long enough to learn whether an idea works.

Good judgment is knowing which principle is underweighted right now.

That is where feedback and learning come in. Feedback is not just a tool for improvement. It is how a system notices when it has over-optimized. Too much depth without breadth becomes tunnel vision. Too much breadth without depth becomes abstraction. Too much efficiency without resilience becomes brittleness. Too much modularity without connection becomes fragmentation.

The principles correct each other.

A Better Set of Rules

If there are near-universal rules for success, I would make them less like a list of virtues and more like a set of tensions to manage:

That last one matters most. Every success principle becomes dangerous when it becomes the only lens. Adaptability can become drift. Efficiency can become fragility. Resilience can become tolerating bad conditions. Collaboration can become consensus theater. Sustainability can become slowness disguised as wisdom. Depth can become narrowness. Breadth can become lack of commitment.

The goal is not to collect principles. The goal is to compose them.

Success is rarely one big thing done perfectly. More often, it is many smaller things shaped well, connected carefully, and improved over time until they become something larger than the pieces themselves.

Subscribe now

And that conversation naturally leads into more granular questions. Are bets different from strategies? Where does the roadmap fit? What goes in our backlog?

Creating shared language is important because teams need some way to reason together. But language can also become a hiding place. The more energy a team spends debating labels, the easier it is to avoid the harder question: can we explain how today’s work moves us closer to the outcome we said we wanted?

That is the job of a goal cascade. A goal cascade is not a hierarchy of documents. It is a chain of assumptions.

At the top, you name the outcome you want. Underneath it, you name the path you believe will get you there. Closer to the work, you name the faster signals that should tell you whether the path is behaving the way you expected.

If the cascade is healthy, teams can move between those levels without losing the thread. A backlog item connects to a roadmap bet. A roadmap bet connects to a strategy. A strategy connects to an objective. Each layer has a reason to exist because each layer helps the team make a better decision.

If the cascade is unhealthy, the words still look right. The slide still has objectives, goals, strategies, measures, key results, initiatives, bets, and metrics. But the connection between them is mostly decorative. The team can recite the framework, but cannot use it to decide what to cut, what to protect, or what to learn next.

That is where goal systems usually break: not in the naming, but in the missing feedback loop.

Illustration of qualitative and quantitative goal pairs cascading between objective, strategy, and bet levels

Start with the pair: intent and evidence

Behind any goal framework is a common principle: every useful goal needs two parts.

1. It needs a qualitative description: what are we trying to make true?

2. It also needs a quantitative description: how will we know whether it became true?

Different frameworks name this pair differently. In OGSM, the objective is the qualitative statement and the goal is the quantitative counterpart. In OKRs, the objective is the qualitative statement and the key results are the quantitative counterpart. The labels matter less than the pattern.

Qualitative without quantitative becomes aspiration. Quantitative without qualitative becomes metric theater. Together, they create a usable goal: a direction with a way to inspect progress.

Subscribe now

Take a simple example.

“We want to create a cohesive, high quality customer experience” is a useful direction, but by itself it is not enough. Different people can hear that sentence and make different choices. A designer may think about consistency. An engineer may think about stability. A product manager may think about conversion. A support team may think about fewer complaints.

None of those interpretations is wrong, which is exactly the problem. The phrase needs a measuring partner.

A team might choose signals like pages loading under 2.5 seconds. Or the team might choose a broader composite signal, like Lighthouse scores above 90.

Those numbers are not magic. They are not the customer experience itself. But they give the team something inspectable, which means the conversation can move from opinion to evidence.

That is the first useful move in any cascade: pair the thing you want to make true with the evidence that would tell you whether it is becoming true.

The cascade connects slow outcomes to faster feedback

The biggest difference between long-term goals and day-to-day work is feedback speed.

A long-term objective sets direction, but feedback is slow. “Create a better customer experience” may take years to fully prove. Revenue, retention, conversion, repeat visits, support volume, and brand trust all matter, but many of them move slowly or are hard to attribute cleanly.

Closer to the work, feedback gets faster. A team can measure whether a page got faster this week. It can measure whether responsiveness improved. It can measure whether duplicate tags were removed. It can measure whether a component migrated to a shared architecture. Those signals are not the final outcome, but they can tell the team whether the chosen path is behaving as expected. That is the purpose of leading indicators.

A lagging measure tells you whether you got there. A leading measure tells you whether you seem to be getting closer.

The road trip analogy is simple because it works. If the goal is to arrive in Washington in time for a wedding, the lagging measure is whether you arrive on time. The leading measures are the things you can inspect along the way: miles traveled, time elapsed, fuel remaining, traffic, detours.

No one mistakes miles traveled for the wedding. But they are important signals as you make progress.

Work is the same. A team may not be able to prove revenue impact until more of the funnel is on a new platform. That does not mean the team should fly blind. It means the team should measure the inputs it believes will eventually matter: page speed, stability, accessibility, adoption, reliability, or whatever else the strategy depends on.

A good cascade makes that belief visible. It says, “We believe this faster signal is connected to that slower outcome.” The belief may be wrong, but now it can be inspected.

Strategy is the path, not the wish

A strategy should explain how the team believes it will achieve the objective.

If the objective is a cohesive, high quality customer experience, one strategy might be to create responsive digital experiences on a stable modern front-end architecture. More specifically, a team might decide to move product surfaces onto a modern framework because shared architecture should make performance, consistency, and maintainability easier to improve.

That is a strategy because it chooses a path.

It also implies tradeoffs. If the path is monorepo adoption, then some work deserves protection even when it does not immediately look like feature output. Migration work, tooling, standards, documentation, and developer experience are not side quests. They are part of the operating theory.

This is where teams often lose nerve. The objective sounds customer-facing, but the strategy may require platform work. The lagging outcome may be conversion or customer satisfaction, while the leading work may be build pipelines, app migration, performance budgets, and fewer duplicate tags.

Without a cascade, that work is easy to dismiss as internal plumbing.

With a cascade, the team can explain the mechanism: better architecture should improve speed and consistency; speed and consistency should improve the customer experience; improved customer experience should support the business outcome.

The chain may be wrong. But at least now the team is debating the right thing. Not whether platform work “counts,” but whether this platform work is the right path to the outcome.

Share

Bets are how strategy learns

Teams often get stuck trying to distinguish strategies from bets. The distinction is mostly time horizon.

A strategy is a longer-running path. “Move teams onto the monorepo” may take a year. “Create a faster, more stable customer experience” may take longer. These are large directional choices, and they need sustained attention.

A bet is a smaller move inside that path. It is a learning move. It says: if we make this specific change, we expect this specific signal to move.

For example: if we remove duplicate Google Tag Manager tags from a page, we expect site speed to improve by 500 milliseconds.

That is a bet. It is useful because the feedback loop is short. The team does not have to wait a year to learn something. It can run the change, inspect the signal, and decide what to do next.

This does not make bets separate from strategy. Bets are how strategy learns.

A bet moves the roadmap. The roadmap moves the strategy. The strategy moves the objective. Or at least that is the theory.

The cascade keeps the theory honest by making each assumption visible enough to challenge. If the tag cleanup does not improve speed, the team has learned something about the mechanism. If speed improves but conversion does not, the team has learned something else. Either way, the work produced information instead of just activity.

Roadmaps and backlogs translate the cascade into work

One common mistake is trying to stuff everything into the framework.

The OGSM should not contain the entire roadmap. The OKR should not become a backlog. A goal-setting system is not a project inventory.

These layers should inform each other, but they should not collapse into one another. When they collapse, teams lose the ability to reason at the right level.

A backlog item is too small to carry the whole strategy. A strategy is too broad to tell an engineer exactly what to build next. A roadmap translates between them.

That translation is where a lot of planning work either becomes useful or becomes theater.

If the roadmap is connected to the cascade, a team can explain why migration work belongs next to customer-facing work. It can explain why a performance budget matters. It can explain why removing duplicate tags, improving responsiveness, or standardizing components is not just cleanup. Those items are small because work has to be small enough to do, not because the outcome is small.

If the roadmap is disconnected from the cascade, the backlog becomes a list of things people hope are important.

Use any framework, but keep the operating principle

This is why the framework matters less than the operating principle underneath it.

You can use OKRs. You can use OGSM. You can use bets.

You can use a roadmap with outcomes and measures. You can use your own language if the team understands it.

But the principle should stay the same:

1. Pair qualitative intent with quantitative evidence.

2. Connect slow outcomes to faster feedback.

3. Make the strategy explicit enough to expose tradeoffs.

4. Use bets to learn before the lagging outcome arrives.

5. Keep the roadmap and backlog connected to the outcome, without confusing them for the outcome.

The point is not to make planning look clean. The point is to make decisions easier when reality gets messy. Because reality is messy. Dependencies slip, metrics don’t move like we expect, customers don’t stay in the happy path.

A good cascade does not prevent that. It gives the team a way to respond without losing the plot. If the objective is clear, the team can adjust the path. If the strategy is explicit, the team can inspect whether it is still working. If the measures are leading indicators instead of vanity metrics, the team can learn before it is too late. If the backlog is connected to the roadmap, the team can explain why today’s work matters.

The test is: when the plan starts to slip how well can the team still explain what it is learning and what it will change next.

For a long time, product management had a clean shape.

You learn the craft, you earn trust, and you move “up.” Up usually means more scope, more stakeholders, and more distance from the work. That distance is framed as leadership. It’s also framed as leverage.

And it worked, because coordination used to be expensive. If you didn’t have someone translating between design, engineering, analytics, marketing, support, and leadership, the system slowed down.

PRDs mattered because the cost of misunderstanding was high. Status updates mattered because nobody had a shared view of reality. “Keeping things moving” was a real job.

AI doesn’t change why product exists. We still win or lose based on whether we build something that creates value for customers and the business.

But AI does change what it costs to coordinate. And cost changes job shapes.

The tension: coordination is getting cheaper

A lot of what lived inside the coordination layer is now lighter, sometimes dramatically lighter.

Things like writing first drafts of PRDs, turning messy notes into clear user stories, summarizing meetings, extracting action items, translating a vague ask into a structured plan, even basic progress reporting.

With AI, none of that disappears but the effort drops. And when the effort drops, organizations stop rewarding the role that existed mainly to carry that effort.

This isn’t new in principle. We’ve always known that more options and faster feedback lead to better decisions. What’s changed is how cheap those options are to generate.

That’s why the PM role doesn’t just feel like it’s “evolving.” It feels like it’s splitting. Like the bar is moving as Charmy Jilka called out. That’s all because the underlying economics of the work are shifting.

The split: builders and coordinators

On one side are builders. These are not “engineers who moonlight as PMs.” These are builders in the product sense: People who take an idea and put pressure on it, explore multiple paths, test assumptions early, and get something real in front of users.

AI amplifies this type. Not through sheer speed, but through widening the surface area they can explore before committing. These Builders can consider more prototypes, more scenarios, more edge cases, more learning per unit time.

On the other side are coordinators. This is role many of us grew up with (or grew into). Coordinators align stakeholders, manage process, translate between functions, keep work moving.

In the world of AI, this is still valuable. Every organization needs people who can connect dots across teams.

But the “manual labor” inside coordination is shrinking, and that changes the bargain. If the coordination layer can be partially automated, then coordination alone stops being the value.

The uncomfortable part: careers were built on the old bargain

Here’s where it gets personal. A lot of product people build their careers by getting better at that coordination layer. They earn credibility by being the person who can bring clarity to chaos. Being a good leader has always looked like adding more of that.

Even further, most product organizations are still structured around coordination processes to keep things moving like status updates and alignment layers.

But what if abstraction isn’t the scarce resource anymore? What if closeness to reality is? That’s a disorienting shift, not because the work changed, but because what’s valuable did.

AI doesn’t remove the need for ownership, incentives, and decision-making. As Matt Haney put it: it can automate reporting, but it won’t fix a broken KPI cadence or unclear ownership. In other words: AI can reduce coordination work, but it doesn’t replace accountable operating models.

So the people who were rewarded for carrying the coordination layer now have to ask a harder question:

What is my value when coordination is no longer the bottleneck?

The system reframe: leverage comes from reducing coordination, not managing it

This is not an argument for builders vs collaborators. Not everyone needs to learn to code, but more people need to learn how to build.

That might look like: turning an idea into something tangible (a prototype, a flow, a draft), generating multiple approaches instead of debating one, or designing how something will be evaluated before it ships.

The real divide is between people who help the system learn and people who help the system talk to itself.

Leaders with the most leverage right now don’t look like they’re adding coordination. They look like they’re removing it. They still operate at the system level setting direction, articulating trade-offs, and shaping incentives. But the new class of leaders in the AI age are also close enough to the work to engage without disrupting the flow. They can test assumptions without spinning up a full process. They can validate a direction without turning it into a six-week alignment tour. It’s not that the role is splitting, the bar is moving.

Coordination isn’t going anywhere, it just doesn’t carry you anymore. AI is eating the “keep things moving” work.

A few months ago, a team would’ve spent days or weeks aligning on a one-pager doc before building anything. A lot of effort went into just getting something everyone could react to. Quite often that reaction was a realization we didn’t know enough, which tacked on more time.

Now we generate multiple directions in an hour and react to something real. There are still information gaps, but they show up faster and earlier, when they’re cheaper to address.

What’s left is whether you can think clearly, test fast, and actually build something that matters.

A useful question: who owns the outcome?

If builders ship fast but don’t connect to the business need, you get impressive demos that go nowhere.

If coordinators keep everyone informed but don’t produce customer value, you get motion without progress.

So again the question isn’t “builder or coordinator” as an identity. It’s: who owns the outcome, and how do they learn their way into it?

In many orgs, that question is left implicit. Everyone assumes the system will produce the outcome. But systems don’t produce outcomes. People do: Through decisions, trade-offs. through what they choose to measure and ignore.

AI makes this more obvious because it removes some of the scaffolding. When the paperwork gets cheaper, the thinking becomes the work.

What this means for PMs (and for teams)

If you’re a PM, the implication is straightforward and uncomfortable. If your main value is translating and coordinating, you’re sitting on a shrinking island. You can still be useful, but you won’t be differentiated.

Your leverage is moving toward:

• Clear thinking under uncertainty

• Fast, low-cost validation

• Product judgment that shows up in decisions, not documents

• The ability to build “just enough” artifact to learn, not to perform

• Operating model design: ownership, metrics, cadence, incentives

And if you’re a product leader, there’s a second implication: Leadership may no longer mean more distance from the work.

It may mean being close enough to reality to remove friction, not add it. To be close enough to ask better questions and to see the system fail before the quarterly business review.

The bet

Being a builder isn’t about tools. It’s about lowering the cost of exploring options so decisions improve

The PM role isn’t going away, but I don’t think we can assume that the prestige path continues to be “more abstraction, more coordination.”

In the version that survives, leaders will look a lot more like builders. NOt for the reason that coordination stops mattering but because the organization can finally afford to make coordination less central.

And when you can afford that, you find out what was always true:

The work was never the paperwork.

The work was the judgment.