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 also too small.

Accounting Models Become Culture

A while back I got interested in throughput accounting. I’m not an expert. I haven’t taken courses on it, and I haven’t watched it operate inside a company firsthand. But it’s an idea I’m curious about, and I see more and more applications for it in the world of AI.

The way I understand it, throughput accounting is partly 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 will be a problem for companies adopting AI because accounting models become company culture. A company that manages through cost accounting starts to protect utilization. So AI will be asked to justify itself, and the first version of the ROI question will probably be: 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

There is value in that. Some work should get cheaper. Some repetitive work should go away. Some workflows really are just slow versions of things machines can now help with.

But if that 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 interaction patterns before committing to a prototype. Engineers can pressure-test an approach or understand unfamiliar code faster.

None of that is automatically valuable. 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 naturally ration it. They ask for a business case before the learning has happened. They ask teams to prove the opportunity before giving them time to understand it. They ask for confidence at the exact moment when confidence should still be low.

AI does not remove that problem, but it 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 this is where I see throughput accounting as a valid idea to explore.

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 tickets? Can the headcount plan shrink? Can the same people support more projects?

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

Could the team test a riskier assumption? Could they explore where to improve 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 very different behavior.

1. The cost accounting belief 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. The through accounting belief 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

This is where the Lean comparison matters. A lot of companies wanted Lean results without changing the management assumptions that made Lean possible. They wanted speed without slack, learning without variation, quality without stopping the line, and continuous improvement without giving teams time to improve anything.

AI could suffer the same fate.

Companies may want AI outcomes without changing the budgeting logic around the work. They may want innovation while measuring everyone by utilization. They may want experimentation while punishing the appearance of unused capacity. They may want new growth while treating every saved hour as a cost-reduction opportunity.

The danger is not that AI will fail. The danger is that it 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.

That is the second-order problem. Once AI makes output cheaper, output becomes a worse signal. More drafts, more tickets, more research summaries, more prototypes, and more strategy documents may say less than they 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 probably 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, then AI has a chance to become something more strategic.

This does not mean every AI gain should become exploration. 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.

But if every AI conversation has to justify itself through cost reduction, the company may never see the larger opportunity. It will ask the tool to make the existing machine cheaper instead of asking whether the machine is pointed at the right opportunity.

That is the part I keep coming back to. AI may not tell us which companies are technologically advanced. It may tell us which companies have a management system capable of learning. The ones that treat saved time only as saved cost will get efficiency. The ones that can turn saved time into better exploration may 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.

Most teams think agent skills are just a better way to save prompts. That misunderstanding is going to break how they scale AI.

Better prompting is not why this category exists. It exists because large language models are generalists, while real work is local.

Your company has a codebase, a style, a release process, a risk tolerance, a customer promise, a bunch of half-documented edge cases, and a long trail of hard-earned judgment about what “good” looks like. The model does not wake up knowing any of that. Out of the box, it knows the broad patterns of software, writing, analysis, and reasoning. It does not know your team or your habits, practices, or preferences.

That gap is what this category is trying to close. The opportunity is not just better outputs. It is better transfer of judgment.

I’ve already seen teams hit this wall. One person has a “magic” setup that produces clean, reliable output. Another tries to replicate it and gets something slightly off. A third copies a few prompts from Slack and ends up with something slightly different again.

Everyone is using AI. Nobody is using it the same way. And nobody can fully explain why the outputs differ.

This category exists because organizations need a way to turn tacit judgment into portable context.

The real problem is not “better prompting”

Most people first encounter AI skills as a convenience layer. You install one that writes better tests. Another that reviews pull requests in your house style. Another that helps with release notes. Another that explains a codebase to new engineers.

From the outside, it looks like a bundle of reusable instructions, which is accurate but incomplete. A good skill is not just a reusable prompt. It is a decision policy in miniature.

It says:

1. Here is what to pay attention to.

2. Here is what to ignore.

3. Here is how we define quality.

4. Here is the order of operations.

5. Here is what “done” means in this environment.

That matters because the value of AI at work is rarely “the model knew something clever.” The value is usually “the model behaved in a way that matched the team’s expectations without needing to be re-taught every single time.”

That is a coordination problem, not a model problem. And coordination problems create categories.

Subscribe now

Why this category showed up now

Since AI emerged, teams could get away with treating tools as personal productivity software.

One person had a good prompt. Another had a better system prompt. A third built a little snippet library. None of that had to be standardized because the tools were mostly used by individuals, in isolated workflows, with low organizational visibility.

That phase is ending.

Now AI tools are being used to write code, summarize tickets, propose architecture, generate tests, review diffs, draft docs, and shape internal decisions. That means their outputs are no longer private drafts. They are entering shared systems.

The moment that happens, teams run into five problems at once:

1. Consistency: People want the assistant to behave similarly across users and tools.

2. Distribution: New teammates need the same setup without Slack archaeology.

3. Governance: Someone has to decide which instructions are trusted.

4. Maintenance: Skills drift as the codebase, process, and org change.

5. Security: A markdown file that can steer an agent is not harmless just because it is readable.

Once those problems appear, a category becomes inevitable because the coordination burden is real.

Why generic AI is not enough

A common reaction is: “Won’t the models just get better and better until this is unnecessary?”

Yes, they will get better. But that does not remove the need.

Smarter general intelligence does not erase local operating context. In some ways, it makes that context more important. The more capable the model becomes, the more leverage there is in steering it toward the right defaults and away from the wrong ones.

A stronger model can write more code faster. That only increases the cost of a bad instruction set.

This is why the category should not be framed as a workaround for weak models. It is better framed as interface infrastructure between general intelligence and specific environments.

The model supplies broad capability. Skills, manifests, scanners, sync flows, and conventions supply local control. Those are different jobs.

Most teams will fail here for a boring reason

They will treat skills as content when they should treat them as operations. Content is easy, operations are hard

Teams will install a bunch of clever skills, share them in a chat thread, maybe commit a few to the repo, and then declare that they are “using AI well.” But most of what they will actually have is scattered advice with no owner.

That approach fails for the same reason unmanaged documentation fails. I think this will be the dominant failure mode in the category.

The problem is upkeep. Almost every team can generate ten useful AI skills in a week. Very few teams can answer these questions three months later:

• Which of these skills are still current?

• Which ones are mandatory versus optional?

• Which are safe to trust?

• Which were written for a different workflow that no longer exists?

• Which outcomes got better after adoption?

• Who is responsible when the assistant follows outdated instructions?

If nobody can answer those questions, the team does not have a skill system. It has a pile.

Why the best teams will think about this like dependency management

The important shift is a psychological one. The best teams will stop asking, “What cool skills should we install?” and start asking:

• What repeated judgments are worth standardizing?

• What context should travel with the project instead of with a person?

• What instructions are important enough to version, review, and distribute?

• What guardrails do we need before these instructions touch production work?

This is where the real opportunity starts to become visible. The teams that win here will not just install better skills. They will build better systems for distributing, updating, and trusting them.

That is why package management, manifests, sync flows, and scanning matter so much. They are not just implementation details. They are signs that the category is maturing from personal hacks into team infrastructure.

If skills become operational, they need the same things as any other dependency: versioning, distribution, scanning, trust. That’s the gap tools like Skulto are trying to fill.

The deeper reason most teams struggle

Most organizations are bad at turning tacit knowledge into explicit systems. That weakness existed long before AI.

Teams say things like “Jane just knows how to handle migrations safely,” or “You kind of learn what good looks like after a while” or “There are edge cases here, but it is hard to explain,” or “We don’t really have a checklist. People just know.”

AI skills expose that weakness because they force a choice.

Either you make your operating judgment explicit enough to encode, or you keep paying for rediscovery in every prompt, every review cycle, and every new hire ramp.

That is uncomfortable. It’s much easier to buy a tool than to formalize a standard.

So many teams will fail because they do the easy part: adopt the interface for skills, manifests, or marketplaces then stop before the harder work of deciding what their assistants should actually be taught.

side note: security is not a side note

One reason the category exists, and will keep growing, is that these files are not passive. They shape behavior. In agentic workflows, behavior is power.

That means the trust model matters. Teams that would never curl | bash random shell scripts are still surprisingly willing to drop unreviewed instruction files into an assistant that can inspect code, run commands, and propose changes with authority. They see markdown and assume “harmless.” They should not.

The marketplace explosion increases the value of scanning and provenance, not decreases it. More supply is good for discovery, but it also expands the surface area for bad assumptions, malicious instructions, and low-quality cargo culting.

This is another place where the opportunity splits in two. One layer of the market will help people discover skills. Another layer will help teams trust them. Those are not the same job.

The general lesson is larger than any one tool: If a file can steer an AI agent inside a production environment, that file belongs in your operational trust model.

So why does this category exist?

Because organizations need a layer between raw model capability and local execution.

They need a way to package judgment, to distribute context. To keep teams aligned across tools and to audit what their assistants are being taught.

That is the category. Not “prompt libraries.” Not “AI tips and tricks.” Not “power-user customization.”

A new operating layer for making general-purpose models useful inside specific systems.

Share Product AF

What the winners will understand

The teams that get value here will treat skills the way mature engineering orgs treat other important interfaces. They’ll keep the useful ones close to the work, version what matters, review what gets shared, measure whether the instructions actually improve outcomes, expect stale skills to become liabilities, and distinguish discovery from distribution.

Most teams, at least at first, will over-install, under-govern, and confuse novelty with leverage.

That is normal for a new category. But it also means the long-term winners in this space probably will not be the teams with the biggest skill libraries. They’ll be the teams with the clearest operational discipline around what their AI systems are allowed to learn, reuse, and trust.

But that’s a much less glamorous story than “the marketplace has 350,000 skills now.”

The bottom line

This is why this category is here to stay. Not because prompts needed a better home, but because teams need a way to manage how their systems behave.

The moment a skill becomes important enough that you want everyone to use it, you’re no longer talking about personalization. You’re designing an environment. And environments come with requirements: standardization, distribution, maintenance, and trust.

Most teams will stop short of that.

A smaller group will do something harder. They’ll treat judgment like infrastructure. Something that can be encoded, versioned, distributed, and trusted.

That’s why Skulto’s place in the category. That’s the leverage.

If you want to go deeper on the technical side, Adam Cobb’s piece on why package management and scanning still matter after marketplace growth is here, and TJ Maynes’s piece on why a manifest matters for team-wide skill coordination is here.actually what would you recommend

Here’s how to use it

Open Source GitHub: https://github.com/asteroid-belt/skulto

Install: brew install asteroid-belt/tap/skulto

The reason we created it has less to do with tools and more to do with how work actuall flows. We built it because today when teams use AI its hard to adhere to standards and write code with consistent quality.

I’m not a technical person. You might not be either. So I want to explain why I’m excited about AI skills, and why I think Skulto can matter even if you never plan to write code.

Last year, ChatGPT added Projects.

It allowed you to group related conversations, come back later, and the system would carry some memory of what you were working on. It wasn’t perfect, but for the first time, it didn’t treat every thread as if it were your first.

That moment stuck with me because it made something obvious: when AI remembers more, you can do more with it.

Many conversations about AI focus on better prompting. IMO that isn’t where the real friction shows up. The real issues are in the second, third, and fourth time you have to remind it of your intent, constraints, and taste. It sucks when you put hours into a conversation only to realize you solved part of the same problem yesterday in a different thread. Now your options are all bad. You either abandon today’s progress or rebuild the same context again in your new thread.

It’s like having the same meeting over and over again or debating the same things repeatedly. Individually, that’s frustrating. For teams, it’s stagnating.

When context resets, teams lose focus and can’t work efficiently. With AI one person’s setup never quite matches another’s. Two people ask the same question and get different answers. And no one can point to a shared source of truth for what “good” looks like.

Share

I care about context because that’s how quality accumulates through context. For any software team, quality comes from context that carries forward, not one-off moments of brilliance.

Over time, teams learn where their standards sit. They learn which constraints protect quality and which ones are just noise. They develop a shared sense of judgment that survives more than one session, sprint, or release.

Applying that of accumulated contextual knowledge is what makes lasting quality. You can see it in writing as tone that holds across drafts, in design as component libraries and style-guides that prevent inconsistent experiences, or in product work as decision rights that don’t need to be re-litigated every time.

Most AI tools today interrupt that process.

They treat each interaction as a clean room. People may learn, but the system doesn’t. As a result, the AI’s output quality suffers even when the team knows better.

Where Skulto fits

Last fall, Anthropic added Skills.

At first glance, it looked like a way to organize prompts. But it offered a potential way to finally help AI remember more and allow teams to do more with it.

Skulto came out of running into that idea repeatedly while trying to work with multiple AI agents on teams.

We are setting a foundation. Before you can preserve context, you need a way to see what you’re reusing. You need a way to manage skills across agents, understand what they do, and trust that they won’t do something unexpected. Without that foundation, “memory” is just another abstraction layered on top of chaos.

Skulto is building that foundation.

Skulto is an open source registry (free marketplace) of AI skills where teams can discover, inspect, and manage skills, then use them across the agents they already rely on, whether that’s Claude, ChatGPT, or something else.

What Skulto actually does today

In practice, Skulto is a CLI and TUI app (so yes, it requires a small amount of technical comfort) for discovering, inspecting, installing, and managing agent skills across different AI agents.

It exists to solve the problem that once teams use more than one agent it becomes hard to tell what’s trusted, what’s been modified, or what’s safe to reuse.

Here’s what Skulto does, and why each part exists:

• A single control surface (CLI + TUI): One place to manage skills so shared practices don’t fragment across tools.

• A real starting library: 420+ curated skills and six starter skills so teams can align around examples instead of inventing from scratch.

• Search inside skills: Find what a skill actually does by searching its instructions, not just its name.

• Tag-based browsing: Explore skills by intent rather than repository structure.

• A built-in skill creator: Turn an idea into a reusable skill using structured specifications instead of ad-hoc prompting.

• Security scanning: Automatically scan skills for risky behavior so reuse doesn’t require blind trust.

• Works across agents and projects: Install globally or per project, with updates kept in sync so learning stays portable.

• GitHub repository support: Add, scan, and update any repository from the CLI instead of copying and forgetting.

• Offline-first behavior: Skills continue to work even when conditions aren’t perfect.

We are the only product on the market that scans skills for nefarious code, and the only one that combines a command-line interface with a managed database of skills usable across multiple agents. That matters because without trust in skills, reuse fails long before context is even needed.

Skulto is focused on making reuse safe, visible, and manageable. That’s the groundwork. Context can’t compound if the building blocks aren’t stable.

When those blocks are in place, quality has something to build on. And when that happens, teams can finally move forward instead of paying the same learning costs over and over again.

If you’ve ever felt that the best part of your team’s process is the part the tool doesn’t remember, you already understand the problem. The opportunity now is to design for continuity, and see what becomes possible when quality has somewhere solid to live.

Subscribe now

I hope you try it out. Tell me what you build.

Open Source GitHub: https://github.com/asteroid-belt/skulto

Install: brew install asteroid-belt/tap/skulto

Leave a comment

Suddenly, all the ideas and small tools I’d always carried around in my head felt doable. Things I’d previously dismissed as “not worth the effort” now felt within reach.

Through sharing my excitement with engineers I know I began to notice how every developer carries a set of preferences honed into instinct, like how tests should be written, tabs versus spaces, how much abstraction feels right, what “clean” means, where to trade safety for speed, and so on.

Those preferences work beautifully at the individual level. But on a team where building is collaborative they have to do more than coexist: they have to overlap constructively, complement each other, and sometimes give way.

As I shared, it became clear that AI tools don’t seem to help much with this. And I’m starting to wonder if that’s why we don’t hear more stories about teams AI-coding together at scale.

Where I see inconsistencies accumulate

Let me show you what this looks like in reality. Last month, I watched three developers on the same team each use AI to add error handling to different parts of their application.

• Developer A’s AI-generated code threw custom exceptions with detailed context objects.

• Developer B’s code returned Result types with explicit error enums.

• Developer C’s code used simple boolean returns with errors logged internally.

Or consider testing. One developer’s AI generated comprehensive unit tests with extensive mocking. Another’s produced integration tests that spun up a full database for each test run. A third leaned on property-based tests with randomly generated inputs. Meanwhile, the rest of the team’s AI-generated code often shipped with minimal or no tests at all.

This team’s CI pipeline was a Frankenstein’s monster with some tests running in milliseconds, others minutes, and new developers had to adopt multiple testing philosophies and toolchains just to contribute.

These are more than style issues a linter can fix. They’re architectural decisions that teams normally negotiate explicitly but that AI makes implicitly, file by file, developer by developer.

AI fits individual style better than collective agreement

My inspection keeps coming back to the belief that software only survives because coding is deeply collective, and that the real craft of building durable systems lives in the tension between individual expression and shared constraint.

Good teams aren’t aligned because everyone thinks the same way, but because they’ve negotiated a set of agreements they can rely on one another to honor.

AI tools, as they exist today, seem to fit cleanly into only one side of that equation. They adapt beautifully to individual style, mirroring how you think and reinforcing your instincts.

But good teams depend on consistency more than cleverness, and on predictability more than brilliance. What AI lacks is participation in the collective work teams do around the code to build that consistency.

How could AI be better for teams

Recently, I’ve been thinking about AI Skills as a way the economics and constraints of team coordination might change. What seemed “not worth the effort” before might be more within reach than ever. The question becomes: how do teams make their shared preferences tangible enough that AI can participate without dissolving it?

I see three emerging directions worth exploring:

Explicit team context through Skills. Instead of each developer configuring their AI individually, what if teams created shared Skills that encode the decisions they’ve already made together? A “Backend Error Handling” skill, for example, could specify: “Use custom exceptions in the API layer, result types in the domain layer, log but don’t throw in background jobs.” This treats AI less like a solo assistant and more like a new team member who’s been onboarded into team conventions.

AI-augmented code review focused on consistency. Most teams use AI to generate code, but its value might show up just as much on the review side. A skill that knows team patterns could help with PR review to make the inconsistencies easier to catch. A reviewer juggling multiple PRs might miss a subtle shift in error-handling style but an AI that knows the team’s usual patterns wouldn’t. This reframes AI from “code producer” to “alignment aid.”

Skills as living team agreements. If Skills become visible artifacts that teams discuss, refine, and version control alongside their code, they start to function like living agreements. The conversation changes from “what did you tell your AI?” after the fact to “what should our shared Skills encode?”. When testing practices drift, you update the Skill and everyone’s AI adapts together.

None of these are complete solutions. The tools barely exist yet, and the practices are still being invented. But they share a common insight: the problem isn’t making AI smarter at writing code in isolation. It’s making our collective agreements visible and enforceable in a world where much of our code is generated rather than hand-written.

The real challenge to think about next

AI doesn’t mind idiosyncrasies or provisional decisions. In fact, it often amplifies them. That’s a feature when you’re working alone and a liability when you’re trying to build something with other people that lasts.

The work of alignment has always been part of software teams. What’s changing is how easy it is to bypass that work while still producing something that looks plausible.

The question isn’t whether AI can help individual developers be more productive. It clearly can. The harder question is whether we can design AI-assisted workflows that make team agreements more visible.

I don’t think this is a solved problem yet. But I’m increasingly convinced it’s the one that will determine whether AI coding tools will simply keep individuals moving faster or actually help teams think together.

They're not universal truths. But they've helped me navigate messy situations, get unstuck faster, and make clearer decisions in ambiguous work.

1. Start simple, then extrapolate from there

So many things in life are hard to grasp quickly. New ideas are everywhere from interpersonal dynamics to product strategies to technical systems. It takes time and effort to understand it all.

When I started my career, I constantly felt like I was playing catch-up because every new detail seemed to require this enormous mental investment. I'd obsess over all the information, trying to master it all at once. I'd get stuck in this loop of "I need to understand every variable before I can move forward." Then a few weeks or months later, I'd do it all over again. I see coworkers and friends fall into this trap over and over again.

Eventually I realized is that most things, no matter how domain-specific or complex, can be distilled down into something simple. And once I got good at finding analogies, it unlocked something game-changing: fundamental principles or patterns are shared across almost everything. If you spot the common foundation, you can learn everything fast and deeply, without actually needing all the details.

Take coding. At its simplest, functions exist to do one of only two things: write new information or read existing information. There are a million different gradients between the two, but if you zoom out far enough, it's only these two patterns.

• Reading: understanding existing logic, consuming data, tracing flows.

• Writing: creating logic, mutating state, expressing intent.

Similarly, there's a moment in any technical problem where you're either creating new logic or trying to understand existing logic. Writing mode is generative. Reading mode is interpretive.

Am I creating something new? Or understanding something that's already been created?

That same zoom-out lens works in decision-making too. Not everything has one right answer. And that brings me to the next paradigm.

2. The difference between facts and frames

I've noticed that most problems are approached as if they have one objectively correct answer. But in reality, they don't. This fallacy has led me into so many endless debates, draining meetings, and decision paralysis.

How many times have you sat in a room where people argue about the "correct" strategy, user flow, or team structure? Experience doesn't turn anyone into a fortune-teller, and most high-confidence assumptions are nothing more than strong opinions.

So here's a small trick that's kept me out of a lot of rabbit holes. Anytime you have a problem to solve, or if you start to get into a pissing contest over a specific solution, think:

• Is this something that has one right answer? (math, compliance, binary processes)

• Or is it interpretive? (user experience and motivations, "is this MVP enough?", org dynamics, etc.)

If it's the former, the answer is knowable, so finding the answer might be worth it.

If it's interpretive, you'll never find a right answer in advance. In these cases, start trying out different possible answers and see which solves your problem. Looking for a right answer is a waste of time.

And just because something's interpretive doesn't mean it doesn't matter. Or that it can't be measured.

3. Not all outcomes are measurable

No matter how many dashboards you monitor, how significant your A/B tests are, or how many commas are in your salary, some of the most important successes simply can't be quantified. I don't mean to be philosophical. This is practical.

The absence of a measurement doesn't mean the absence of impact.

I'll never forget what Janice Fraser told me: "A mistake people always make is thinking goals have to be measurable." Not everything that matters comes with a number attached.

Think about it: Every action ripples outward. Some effects show up immediately in your analytics. Others take months to surface. And some of the most profound results like building a reputation, making yourself or people trustable and resilient, or helping others learn life skills may never translate cleanly to a chart.

As someone who works in product development, this paradigm is essential. We've all sat through meetings where someone demanded "measurable outcomes" for inherently nuanced work. While metrics matter, over-quantifying can actually diminish what you're trying to achieve. It's like trying to measure a friendship by counting text messages…you miss the entire emotional landscape.

When we force-fit complex realities into neat numbers, we often optimize for what's countable rather than what counts. Sometimes the most important signals come as tiny attitude shifts or very gradual movements, not data points.

If you only value what you can track in a spreadsheet, you'll miss half the system. The most valuable data sometimes isn't a number at all, it's a pattern you notice, a shift in behavior, or simply a feeling that something has changed.

Other Mental Models I Come Back To

The three paradigms above are my personal go-tos, but they're part of a bigger toolkit I've built over time. Here are a few mental models from others that have stuck with me and shaped the way I think:

• For uncovering fundamental truths: First Principles Thinking helps you break down problems to what's undeniably true before rebuilding from there.

• For acting on opinions while staying open to change: Strong Opinions, Weakly Held is a mindset that balances decisiveness with humility.

• For making relative (not binary) product decisions: Compare & Contrast Decisions is a great framework from Teresa Torres for choosing between options instead of chasing an illusion of "best."

• For knowing when to act and when to wait: Real Options helps you delay decisions until the last responsible moment without losing flexibility.

• For identifying what's blocking value delivery: Theory of Constraints helps you spot the single biggest limiting factor in a system so you can improve the whole by focusing there.

These paradigms aren't revelations. But they're reliable.

They've helped me cut through the swirl, decide faster, and focus on what actually matters, especially when everything around me feels messy, ambiguous, or emotionally charged.

Maybe they'll do the same for you.

Here’s one that’s been on my mind lately.

For years, I’ve been dealing with the long tail of a high school sports injury. With nerve damage and chronic pain I’ve spent years rotating around rehab strategies like physical therapy, strength training, HIIT, and more. All of it helped a little, but nothing stuck. Lately, I’ve been training something called Functional Patterns (FP).

FP…is different. It doesn’t work isolated muscle groups or brute strength. It’s focused on teaching the body how to move again intentionally, systemically, as a whole.

FP is slower, more intentional, and more methodical. It’s about teaching the body to move in total alignment through posture, tension, and timing. Not just repetition, but functional movement.

Naturally, I started seeing the parallels to product work. And the more I looked, the more it held up.

Because when you look at the dysfunctions of product development and the constant voices promoting the best frameworks and methodologies, I see the same pattern I saw in my own body: strength in some areas, deep compensation in others, and a lot of unaddressed dysfunction reinforced by well-meaning routines.

A Kinesthetic Product Org is built with a felt sense of how we move, where we’re drifting, and what needs attention.

Subscribe now

What Is Posture in a Product Org?

In the body, posture isn’t about standing up straight. It’s about creating systemic stability through structural alignment of how weight is distributed, how tension is stored, and how energy flows through the system. Good posture makes movement and applying force efficient. Bad posture makes everything harder.

In product teams, posture is strategy. Not the deck, the alignment. Posture is teams being able to apply the right amount of force and energy to any given situation.

If your product org feels like it’s fighting itself (think competing priorities, lack of risk-taking, absence of decision-making, constant rework) you likely have a posture problem. You're expecting teams to move fluidly without enabling them to work together. You’re compensating for lack of alignment.

Like the body, you can’t fix posture by solving one of the symptoms. You have to train the supporting systems.

What’s Breath?

In FP, breath isn’t only breathing. It’s the act of re-stabilizing under pressure. Breath acknowledges and regulates tension, realigns posture, and directs how you move next.

Breathing is rhythmic. Without it, posture breaks down during movement and it creates more dysfunction.

For product orgs, breath is akin to the habits that maintain strategic alignment. It’s how you retro. It’s how you listen to feedback loops. It’s how you respond and how you adjust to improve alignment.

In both FP ad product, breathing should become second nature. Of course, product teams that don’t breath don’t collapse. But they will drift out of alignment, moving with no sense of direction. They might execute but can’t explain why.

Breath is how your org remembers what it’s doing while in motion.

Awareness doesn’t come from more flowcharts

You can diagram a system all day but that doesn't mean you can feel it. Just like you won’t learn how to ride a bike without getting on an trying it, mapping out dependencies or adding swimlanes won’t fix how teams interact.

That’s one trap: we mistake one-off maps for embodying it. Diagrams are helpful, but they’re snapshots. Good movement is a dynamic feedback loop.

FP reminded me that alignment isn’t proven on paper, it’s felt under pressure. The best product orgs have strong body awareness. They know when tension is healthy, when movement is drifting, and when it’s time to reset.

I struggle to articulate this model precisely because it’s not one-size-fits-all. Think of it like your neuromuscular system: health isn’t about memorizing stretches. It’s about moving well, sensing misalignment, and adjusting often. It’s more about discipline than dogma.

A Kinesthetic Product Org sustains that cycle. It doesn’t depend on any one methodology but it always comes back to how it moves.

The Core Mechanisms

These are the embodied dynamics every healthy org needs to sustain forward motion:

• Breath: Reflection rhythms. Your capacity to realign while in motion.

• Tension: Potential energy. The friction between priorities and perspectives that creates stored power.

• Elasticity: Adaptive strength. Your ability to flex and focus effort without breaking.

• Posture: Strategic alignment. The integrated structure that holds all motion together.

Together, these form the rhythm of how an org moves. Breath → Tension → Elasticity → Posture → back to Breath.

The Awareness Practices

This is how you know it’s working:

• Postural awareness: Can you feel drift before the metrics say so?

• Breath discipline: Do your teams pause before reacting or do they react and chase requests?

• Functional feedback loops: Can you sense which parts fail under pressure, and why?

• Embodied knowledge: Can your teams anticipate issues before they’re measurable? Have you trained that organizational proprioception?

This is how I think we move from systems thinking to embodied practice. It’s less about what you document. More about what you feel.

Share Product AF

Functional First Principles

1. Focus small, intentional movements

In FP, it’s it’s about making small adjustments with control. You don’t rush reps or stack on weight to feel progress. It looks really easy from the outside. Even I’ll catch myself thinking, “this can’t possibly help.” And then I’m drenched in sweat.

It reminds me of how good product work happens. You don’t earn long-term leverage by pushing harder. You do it by making precise, high-signal adjustments that set up future movement. Your roadmaps are honed through progressive overload, not a pre-seeded to-do list.

I once worked with a team building an internal platform. Stakeholders loved the long-term vision but didn’t want to start small. Every foundational starting point was blocked because it did not create the “value” of the long term vision. "That feature is not for us," they'd say, "let's focus on the big things we’re all excited about." They weren’t allowed to build stabilizers. Trying to push weight with bad form stalled them for over two years.

2. Integrate movement across planes

Real movement is 3D. In FP, you’re always moving forward, twisting, stabilizing. The big muscles might visible move you, but it’s the deeper, hidden muscles that stabilize you. If any part overcompensates, others collapse.

What's fascinating is how product orgs are no different, excet the planes here are dellivery, discovery, and strategy. When you separate them, you create weird imbalances and the system has to compensate. This might look like research getting buried, or like designers being left out, or roadmaps ignoring reality. Over time these things compound into dysfunctions that eventually lead to injury.

I’ve seen teams spend weeks on discovery, then never revisit it again. Or ship something technically brilliant that no one can maintain. Or chase metrics that don’t match the problem. That’s all the same thing: overtraining one plane while ignoring the others.

Functional movement means your entire org system is stable during motion, the visible and hidden muscles flexing and firing together.

3. Tension and elasticity create power

In FP, tension is potential waiting to be used. The right amount of stored energy lets you move fluidly and explosively. With too little tension you collapse and with too much you strain.

The same goes for product orgs. Healthy tension (between strategy vs. delivery, today vs. tomorrow, speed vs. safety) creates resilience. Functional teams know how to hold that tension and translate it into forward motion.

Breath helps here too. Reflection is how you learn to tell the difference between productive strain and misalignment. It’s what lets you redirect energy rather than leaking it.

Most orgs are overtrained in the wrong direction

Like gym bros skipping leg day, a lot of product orgs are overdeveloped in the show muscles like velocity, demos, and dashboards. And they’re undertrained in the stabilizers that sustain progress like discovery cadence, cross-team trust, decision hygiene, and strategic alignment. They’re all biceps, no core.

Functioning well isn’t about pushing harder, it’s about moving smarter. That means improving how your system coordinates: how decisions flow, how information transfers, how feedback loops close. It’s the interplay between discovery and delivery, short-term execution and long-term vision.

At least that's what Functional Patterns taught me. And it's a mindset product orgs should train for too.

how can your team move more like a system with awareness and intention?

You don’t need stronger teams. You need an org that moves better.

Instead of looking at how each team is working, keep an eye out for alignment across them, set up points for inspection, and help them focus their push ⇆ pull energy well.

If you liked Be a Weed, this is the next layer. Resilience isn’t much more than enduring change, it’s adapting to it in motion.

If you liked Real Options, this is the embodied version. Sensing tension and elasticity tells you where to push and where to flex.

If you liked Velocity ≠ Progress, this is what progress actually feels like.

Train your org like you’d train a body. Odds are, you don’t need more strength. You need better movement.

Subscribe now

“Inspire customers with a valuable experience and delightful products.”

“Ensure the purchasing experience is trusted, intuitive, and frictionless.”

“Make finding the right products easy and fun.”

For people who aren’t used to clear outcome statements, it might not be obvious that despite sounding strategic, these outcomes are all fluff. If your teams are actually expected to operate from outcomes, they need to understand what those statements mean clearly enough to make tradeoffs, advocate for what they need, and connect work to strategy without second-guessing it. Outcomes that aren’t fully understood aren’t good enough to steer by.

The “outcomes vs outputs” distinction is one you’ve probably come across, but it’s often misunderstood. Just because outcomes are more abstract than outputs doesn’t mean they can’t be concrete. This assumption is the trap I’ve seen in nearly every “outcome-driven” organization: a fuzzy outcome gets written, a detailed plan gets built in its name, and teams start executing. Then the outcome is forgotten and never gets clarified, because there’s already a plan, right?

That’s an outcome mirage. A fuzzy outcome plus a specific plan kills autonomy while giving the illusion of it. No one can say what success is beyond executing to plan.

Clarity must be built

While leading the product practice at a large retail technology org, I had a chance to try a different approach. The org had been through the usual transformation: outputs to outcomes, project to product, delivery to discovery. Everyone spoke the right language but the impact hadn’t materialized. Teams were building a lot, but not tying it back to a coherent outcome.

We brought in DoubleLoop, a platform purpose-built to make strategy usable instead of aspirational. Unlike tools that live downstream of outcomes (roadmaps, project trackers, dashboards), DoubleLoop sits upstream, helping leaders and teams translate fuzzy vision into structured drivers, signals, and metrics that guide day-to-day work. Through that partnership we noticed something striking. The teams delivering the fewest outcomes weren’t confused about the work, they were confused about how the work connected to the goal. They had tactics, but no usable strategy. Not because they hadn’t been given one, but because the strategy hadn’t been clarified in a way they could use.

DoubleLoop’s scaffolds gave us a way to reverse-engineer clarity without having to rewrite vague goals. Outcome trees allowed teams to map from ambiguous phrases down to specific levers and measures they could influence.We didn’t publish templates. We started at the top.

Our thinking was if teams are expected to deliver outcomes, then leaders have to know how to define outcomes that actually mean something. That takes practice and ownership. It can’t be phoned in. It has to be built by them, not bestowed.

So we asked SVPs to articulate their domain’s outcomes. And what we got were well-meaning but vague statements like “We help customers shop seamlessly digitally and in-store.”

At this point, we had a choice: try to rewrite the outcome with the SVPs, or leave it as-is and teach their teams how to pull clarity from it. We chose the latter and stumbled across something I think is pretty powerful.

Operative phrases are your way in

An operative phrase is a directional word, like ‘fast’, or ‘delightful’, or ‘trusted’, that signals intent but hides the specifics. It’s where we were able to focus teams to start unpacking things. No matter how generic the outcome, we found that operative phrases gave teams something to start with.

For example, from the above outcome we pulled out two operative phrases: “seamless” and “digital and in-store.” Each phrase acts as a signal to flag attention and help focus for the groups and relevant teams below. Who owns the online experience? Who owns in-store? What does “seamlessly” mean, specifically? Is that different for the two contexts?

Helping teams ask these questions was about making strategy usable, not just wordsmithing. Operative phrases gave teams a way into the strategy instead of just nodding along.

An example of cascading clarity with operative phrases.

One of the clearest examples came from a platform team. Their group’s outcome, “network connection is reliable, available, and strong so the company can operate”, was a good start. But it wasn’t translating and the team kept disagreeing on priorities.

So we asked them to reflect on what “reliable”, “available”, and “strong” mean in their context and which was most important for their team, then we entered it into DoubleLoop’s AI builder, which parsed the operative phrases and proposed a structured outcome tree within minutes.

• Top node (Outcome): Reliable delivery of value to internal teams

• Middle nodes (Drivers): System uptime, time to recovery, incident volume, platform usability

• Base layer (Signals & Metrics): 99.9% uptime, average recovery <15 min, P95 support response time, usability survey scores

Suddenly, their vague outcome became a usable map. The team could see how different priorities would affect their goals, how they were already tracking, and where they had gaps. And more importantly, they built it so they felt more ownership.

Because the team built it themselves, with just enough scaffolding, they understood and trusted what it meant. Suddenly, their vague outcome became a usable map. The team could see how different priorities would affect their goals, how they were already tracking, and where they had gaps.

Subscribe now

Language, leverage, and operation

Zooming out again, once leaders and teams identified their operative phrases they could build outcome trees that meant something. And by inviting everyone to view the map they were creating living strategy artifacts linked to data and updated as reality changed.

This is what working with outcomes really looks like. It’s not the same muscle as defining outputs or drafting action plans. Those come later. First, you have to do the work to make strategy legible. That means defining your drivers and signals. What levers do we control? What signs tell us we’re making progress? How will we know when we’re stuck?

Only then will you be able to use outcomes effectively. Teams need shared language to spot over-investment, argue for under-measured risks, and have those conversations without defensiveness before tying plans to intent and aligning roadmaps to leverage points.

This is where most outcome rollouts fall flat and they get written off. Outcomes are supposed to create shared focus and real autonomy. But when you skip the clarity part you end up with hollow objectives and vague key results. You get:

• “Delight our customers”

• “Drive platform reliability”

• “Improve business outcomes”

No one’s going to argue with these, but no team could succeed with criteria so vague.

How to use operative phrases in the wild

One thing I took away from using operative phrases is that you don’t need to be a part of a transformation initiative to make it a habit. Anyone can do this and it works in so many situations. You don’t need a workshop. Just curiosity and the nerve to ask.

1. Listen for vague alignment. When you hear a statement like, “drive value,” “support the business,” “improve the experience,” or “ensure reliability,” don’t just nod.

2. Extract the operative phrases. Look for the squishy adjectives, verbs and abstract nouns that aren’t objective.

3. Cascade them into action. For each phrase, ask: How is this relevant to what I own? What’s observable? What’s measurable? What’s misunderstood? Even one level deeper can make a huge difference.

Most teams don’t fail from a lack of ambition. They fail from a lack of shared meaning.

So the next time someone hands you a vision statement that sounds good but doesn’t help you move, don’t nod. Ask what it means. That’s where clarity starts and the moment strategy starts to become operational. Whether it’s on a whiteboard or in a platform like DoubleLoop, the real work is making the abstract specific. Clarity isn’t a nice-to-have, it’s the foundation of real autonomy.

Share