The other day, I came across a LinkedIn post that asked a series of careful questions about AI’s economic future.

Examples: What if AI coding becomes so expensive that hiring humans is cheaper again? What if companies build products on unit economics that break when subsidised plans end? What if employees become so AI-dependent that their cognition atrophies? What if rising costs create a closed talent pool — only those already employed can afford to learn the technology?

The post ended: “No doomer. Just trying to understand risks better.”

I replied in a comment that the answers are unknowable in the formative years of any transformative technology — and that using unknowability as a reason not to act is itself a position. It doesn’t feel like a position. It feels like really smart. But it isn’t neutral, and it isn’t as safe as it assumes.

Let me break it down a bit.

Jevons’ Paradox and the cost fear

As a lot of people know, in 1865, the economist William Stanley Jevons observed something quite counterintuitive about the steam engine. As steam engines became through wider use and accessibility became more efficient, and thus requiring less coal to produce the same output, total coal consumption went up, not down.

That’s the paradoxical law: Efficiency makes a resource economically viable for more use cases. More use cases means more usage. More usage means more infrastructure investment. More infrastructure investment drives further efficiency and cost normalisation.

Jevons called this the rebound effect. We now call it Jevons’ Paradox, and it has held across nearly every resource-technology pairing since. (One discussion, of course currently is: Is AI breaking the matrix, is it the black swan, the ultimate discontinuity, the end game of all innovation that ends this law, e.g. because work becomes meaningless and thus only and finally we don’t have a clue at al what’s going on. As interesting as that may be: well - if we all die, we will all die, right? So that extreme is not that interesting to watch and think, ironically.)

Applied to AI: the fear that “AI coding will become too expensive” assumes a static economy. If AI coding becomes more efficient — which is the direction of every technology after adoption begins — it becomes viable for more use cases, which drives usage growth, which drives infrastructure investment, which normalises costs over time. This happened with computing, with cloud storage, with internet bandwidth. The cost concern gets the direction of travel backwards.

And if AI stays expensive? Then only the highest-value use cases survive, which is a market working as intended. That’s not a catastrophe. That’s selection.

Ultimately, beyond any of that detailed reasoning, take my prediction: Even if OpenAI and Anthropic will economically die, the tech will stay. So better get used to that.

The historical cascade

Let’s ask the same questions about other transformative technologies.

The printing press. Gutenberg, 1450. Did it have exclusively positive effects? No. It enabled mass propaganda, accelerated religious conflict, destabilised institutions that had held power for centuries. The Reformation was partly a printing press story. So were some of the bloodiest wars in European history. Was it society’s task to manage the consequences? Yes. Did we do it well or quickly? Libraries took centuries to build. Copyright law came 250 years later. Censorship battles are still ongoing. Did the negative effects and the incomplete management stop economic engagement? No. Books, newspapers, mass literacy, knowledge spread — unstoppable from the moment it started.

Electricity. The Current Wars between Edison and Tesla were a literal industrial battle over standards, involving deliberate electrocutions of animals in public demonstrations to discredit a competitor’s system. There were fires, deaths, monopoly battles, and decades of pollution from coal-powered generation that still hasn’t been fully resolved. Did society develop building codes, safety standards, grid regulation? Yes, imperfectly, over decades. Did it stop? No. Electricity reached into everything.

Cars and traffic. Approximately 1.35 million people die in road accidents every year globally. Urban air pollution from vehicle emissions remains a public health crisis. Entire city architectures were redesigned around the car at enormous social cost — displacement, inequality, lost public space. Seatbelts weren’t mandatory in most countries until the 1970s. Emissions standards came even later. The regulation has been partial and perpetually behind. Did that stop adoption? More cars exist today than at any point in history.

The pattern is consistent. Were the effects exclusively positive? Never. Is it society’s task to manage the downsides? Yes. Do we always manage it well? No. Does that stop economic engagement? No. Must the economy continue engaging? Yes. Can innovation be contained? No.

The problem with using the unknown as a brake

This is the flaw in “No doomer, just understanding risks.” (And no pun to the person written that LinkedIn post, we exchanged nice DMs afterwards.)

Using unknowability as a reason not to act looks like caution and insanely smart. It is a position — a bet that the unknown will stay unknown, that costs will stay high, that the higher-order value container won’t emerge. That is the speculative claim. Smart framing doesn’t change what it is.

But it’s worse than just being a losing bet. It’s self-defeating.

Consider the specific risks the LinkedIn post raised. Cognitive atrophy — employees who can’t function without AI. The protection against this isn’t avoidance. It’s learning how to work with AI without losing your own judgment. That knowledge is only available from inside the practice. You cannot develop it from outside.

Or the risk of a closed talent pool — only those already employed with AI access can develop competence. Waiting makes this worse, not better. The gap between those engaging and those abstaining compounds over time. Every month of “let me wait until I understand the risks better” is a month of compounding disadvantage.

Or the unit economics risk — products built on AI that become unviable if costs rise. The companies that will navigate this best are the ones deeply familiar with the technology, building the flexibility and optionality to respond. That knowledge isn’t available from the outside.

In every case: the risk you’re trying to avoid by waiting is made worse by the waiting. The protection against AI-related risk is not less AI experience. It’s more.

In more simple terms: even if you are “against” AI and want to avoid the risks, you better lean in t learn the etch. Else you have no chance to harness it responsibly.

What the historical examples actually teach us

Gutenberg didn’t give societies the option of not adopting the printing press. The societies that mattered — that shaped what came next — were the ones that engaged with it, understood it, built institutions around it, learned to manage it.

The same with electricity, with cars, with the internet.

The negative effects were real, obvious and simply can not be negated. They also can not be avoided fully. The societal management was and will always be imperfect. None of that is in dispute. But the question was never whether. It was always how. And “harm can be done” is used as a useless, helpless brake, simply signalling an assumed higher, better morale. Virtue signalling. No bit will touch my code. Have fun with that position in the real economy, outside of a tiny niche. Think vinyl: great for enthusiasts, but not a huge thing.

The “how”question is the only question available with AI.

Not: should we? That’s a done deal, like it or not. And it’s not a decision any individual or company makes, but it’s done by the same dynamics that made the printing press, electricity, and cars inevitable.

The question is how. How do you engage intelligently? How do you build knowledge that lets you influence the how-society-manages-this conversation, rather than watch it from outside? How do you size the bet appropriately as part of your life — staying in without betting the house?

Treating the unknown as a brake doesn’t give you safety. It gives you less information, less capability, and less influence over exactly the outcomes you’re worried about.

A defensible position

Treat it as a bet. It’s not recklessness — it’s accuracy. You are placing a bet either way. The question is whether you’re placing it consciously.

Size the bet relative to your capacity. You don’t bet everything on year one of any infrastructure wave. You stay in long enough to find what becomes possible — browsers didn’t exist before the internet; SaaS didn’t exist before cloud; the higher-order AI container hasn’t been found yet.

Build knowledge, not avoidance. The knowledge of how to work with this technology, how it fails, where it adds real value, where it creates new dependencies — that’s the only real protection against the risks being raised.

The Gutenberg option — opting out of the printing press — was never available to the societies that created what followed and build upon it (e.g. widespread education). The electricity option was never available. The car option was never available.

The AI option isn’t available either. The only question is how you engage with what’s already in motion.

Most of us and practitioners in companies right now are in exactly that phase with AI. They’ve got their setup dialed in. Custom instructions. A few skills. Everyone is heroic about them (“look at my skill!”). Maybe a structured Claude project or two. It works. They feel fast.

The most advanced build their agentic Chief Of Staff, even share it on github.

And then, at some point, we all hit the ceiling. It can’t go on like this. All of this needs to become shared, and we need the infrastructure to share it.

I see it in my AI-augmented PM course. Participants come in as individuals. They learn to work systematically with AI - on research, on strategy, on prioritization. By the end of the course, they ace it. All of them. Real progress.

But then all of them come up with the one realization: “I’m going to go back and be an island.”

And everyone in the room recognizes it. Immediately. In that moment.

Because the organization hasn’t moved yet. Teammates still work the old way. The AI doesn’t know what the product team decided last quarter. The marketing brief lives in someone’s head. Strategy exists as a slide that was shown once in an all-hands and never written down properly.

The individual got faster. The organization didn’t. Welcome to yesterday.

The problem is not exactly new

This is a human problem first problem - and it existed already without any AI.

(The objections you will read later on are also orthogonal to the topic of AI)

It’s simple: If you want someone to work in your direction — human or AI — you have to make sure they have your information. In a form they can actually use. That they understand. The implications of that are the same whether “someone” is a new hire, a contractor, or a model running in your SDLC pipeline.

For a human, we think it’s easier to patch the gaps. We are more resilient. But: Are we? Most suffering in companies exist because we are actually not.

Even for humans, then: You answer questions. You have context from two years of working together. A smart person infers the rest and adjusts. Organizations rely on this mechanism constantly. (This is also why so much context leaves the building every time someone quits.)

AI can’t do any of that. It needs the information written down. Precise. Accessible. In a form it can process and act on.

So when teams try to use AI at scale and it produces misaligned output — that’s usually not an AI problem. It’s an information problem that was already there. AI just stops pretending it doesn’t exist.

I’ve watched organizations that weren’t particularly process-oriented suddenly become very interested in structure and “standards”. Not because a consultant told them to. Because they saw what happened when AI finally had something solid to work with. The output difference is stark enough to make its own argument. If you get greedy on leveraging AI, you get greedy on process and standards.

On the upside, AI rewards organizational clarity. On the downside, it punishes confusion and unclarity with the same precision. It amplifies both directions.

Your room and the living room

There’s a mental model I keep coming back to, because it gets the dynamic exactly right.

Think of two spaces.

Your room is yours. You experiment . You try out a new AI setup, draft a positioning idea, play with a prompt, develop a heuristic. Nothing in your room is a commitment. It’s your sandbox. Working fast and dirty there is a feature, not a problem. Nobody should tell you how to arrange your own room.

And you need your room. You can not start thinking freely in the shared context. It’s teh same problem, I described in earlier posts: My brain freezes when I have to start on the developers command line. In the settled infrastructure. That’s for later. My room only carries my own constraints.

The living room is shared. It’s what everyone works from — the marketing team, the engineer, the product manager, the AI agent running in your pipeline. What’s in the living room is agreed upon. Truth. It’s the strategy that’s been decided, the brand tone that’s been validated, the technical constraints that are real. It’s the context your AI reads when it needs to work in the same direction as everyone else.

The asymmetry matters: what’s in your room is your business. What’s in the living room is everyone’s business. The living room has rules.

And there’s a process that defines how things move between your room and the living room. You don’t just dump your room into the living room when you’ve had an idea. Or don’t have your dirty, sweaty sports dress lying on the sofa in the living room. You try things. You discuss. When there’s actual agreement — not just “nobody objected” but real alignment — it gets committed to shared truth. That act of commitment is the moment where “I think we should do this” becomes “this is what we do now.”

Before the commit: your freedom. After the commit: your right to be heard when someone ignores it.

You want someone to follow your “truth” - or you even insist on it? - it’s your obligation to commit and explain and make sure it’s understood.

That distinction is the line of accountability. It’s simple. It scales across organizations of any size. And it works whether your “living room” is a Git repository, a well-maintained Confluence space, or something else — as long as it’s genuinely shared and genuinely up to date.

It is really simple. Rationally.

The friction - real and imagined

That’s the simple model. And I can already hear the objections — because I hear them every time this topic comes up. Last week at AI Camp Berlin it was the same. A lot of attention, a lot of friction. Three sessions from three people on the same topic. I’ll take that as evidence that something real is at stake.

The first wave of friction isn’t about tools. It’s about the model itself.

“Who keeps the living room? Who decides what goes in?” Reasonable question. The answer: the team does, together. Which means someone has to care. There’s usually one person per organization who takes this seriously — call them the guardian of the living room. Not an enforcer. Just someone who notices when the shared context is stale, contradictory, or missing, and does something about it.

“We already have Confluence and nobody reads it.” Yes. Because Confluence is a dump, not a living room. The difference isn’t the tool. It’s the discipline of keeping it current and the expectation that people actually use it. An unmaintained living room is just another room.

“You can’t expect this from the CEO.” I find this one interesting, because it conflates the tool with the ask. The ask isn’t “learn Git.” The ask is: if you want a hundred people — or a thousand — to work in your direction, you have to make your direction-giving documents available to them. That’s it.

“I told them in a meeting” stopped being a strategy before AI was here to stay. It just used to work better, because humans are good at patching gaps from memory and inference. AI can’t do that. The meeting wasn’t in the context. It might as well not have happened. The truth isn’t shared in the repo, then it does not exist. No way around it. Simple. Show me an alternative, if you don’t like it, modulo details.

What the infrastructure actually looks like

The living room needs content. Specifically: the context that any discipline might need from any other.

Strategy. Positioning. Tone guidelines. Technical constraints. User research findings. What “done” means for your specific product. Who the user actually is and what they struggle with. Each discipline maintains its own layer — product writes for engineers and AI, marketing writes for product and AI, design writes for everyone. Everyone reads everything. The AI reads everything.

The key question for any document: Does someone else — or an AI — need this to work in the same direction as me? If yes, it belongs in the living room. If it only helps you personally, it stays in your room.

But if your -hopefully - highly efficient, tuned up AI fed production machine needs the info, there’s now way not to enter it into the infra. You might as well throw the whole agentic acceleration out of the window.

In practice, it looks something like this:

Each discipline writes its own layer. All disciplines read all layers. The AI reads all layers. That’s the whole system. (Yes, I do know that skill under .claude are not organized in layers, take this sketch as conceptional, please, and let’s not dilute the discourse.)

Alongside the context, you share the tools. Custom skills, prompt patterns, agent configurations that the team has developed and validated. Not every experiment from every room — only the ones that have proven themselves worth sharing. The skill a PM built to synthesize research faster shouldn’t stay with that PM. But it shouldn’t go into the living room until it reliably works for others too.

The result, of course, compounds. Every discipline makes every other discipline’s AI work better. The marketing context helps the product AI. The engineering constraints help the design AI. Context shared deliberately is context that doesn’t have to be rediscovered from scratch every time someone starts a new conversation.

About those three Git commands

Talking about friction: The tool question always comes up eventually. “Not everyone can be expected to know Git.”

I find this argument strange — not because Git is trivial, but because of what we’ve already normalized. People in organizations manage password managers, VPN configurations, SSO setups, two-factor authentication, enterprise access control systems. Nobody says “you can’t expect a marketing manager to deal with SSO.” It’s just infrastructure. You learn it because it gives you access to what you need.

Three Git commands — commit, push, pull request — are genuinely less complex than the average enterprise access management workflow. And they give you a shared, versioned, auditable living room in return. That’s not a technical luxury.

But here’s the thing: not everyone has to do it themselves. Someone on the team can handle the mechanics. The CPO doesn’t have to run git push. They do have to write down the strategy. Those are different problems, and only one of them is actually hard.

Git is the human excuse. The real question is simpler and harder: do you want a real living room, or not?

The real unlock

The teams that figure this out don’t just get better AI output. They get a clearer organization. And they will ace execution and minimize exhaustion.

Because you can’t write a decent positioning.md or a shared product strategy document if you haven’t actually decided what your positioning or strategy is. The act of writing it down — clearly enough that an AI can act on it — forces the conversation that should have happened anyway.

That’s the forcing function.

Not “AI does the work.” Not “AI replaces the thinking.” Just: AI makes it very hard to keep pretending your organization is aligned when it isn’t.

If you’re a solo act right now — that’s fine. That’s where all of this starts. The ceiling is right before you, though, and you’ll hit it. The teams pulling ahead aren’t just better at prompting. They’ve figured out how to share context deliberately. How to make their work legible — to each other, and to the machines working alongside them.

That’s the next game now. Forget about the fog of “should we do this”.

And these days, he is one of the best devs driving AI use to the max and bing able to verbalise the change that’s happening. In one of my last posts, I looked into all the reports of how Boris Cherny and his team write software and came up with the term option storming. In the case of Simon Willis, it’s much easier to distill

• how he works,

• what it means for companies trying to get there and especially

• what learnings are hidden in this style of working for PMs.

If you like to study the sources, here is the whole video.

Simon Willison is not great at what he does now because he learned a couple of new tricks and hacks. he’s good because he knows what good looks like, and he basing his productivity on 25 years of pattern recognition, architectural taste, and engineering judgment he now throws at these tools. As he puts it: “Using coding agents well is taking every inch of my 25 years of experience as a software engineer.” Without that foundation, he’d be another mediocre AI engineer producing mediocre slop, just at higher speed.

That’s the first thing PMs need to understand. AI doesn’t replace expertise. It amplifies it. People getting the best results aren’t the ones who learned the newest tool first. They’re the ones who brought the deepest judgment to the table. Just like Simon is a good AI developer because he always was a good developer, those PMs will be great AI-PMs who know the trade. Sitting in front of Claude Code do augment your PM work, teh first rule to be successful with Claude’s output is: you have to know what good looks like, else all you produce is trash. But lots of it.

Now here’s what that means for us. A couple of topics and insights, transferred to our jobs.

Code is cheap. Not software. Code.

Writing code used to be the bottleneck. You’d hand a spec to engineering, wait three weeks if you were lucky. Same thing now - three hours, max. Simon : “Today, probably 95% of the code that I produce, I didn’t type it myself. I write so much of my code on my phone. I can get good work done walking the dog along the beach.”

But cheap code is not cheap software. Cheap code just moves the bottleneck. It moves it in two directions at once. That’s really basic Theory of Constraints.

Down into infrastructure: testing, quality, reliability, security. All the things that make code actually usable in production. Someone still needs to figure out if the thing works. If it’s safe. If it doesn’t break what you shipped last week.

And, secondly, up into decisions: what to build, why to build it, for whom, in what order. Taste. Judgment. Strategy. That’s PM territory. And it just became the scarcest resource in the room.

and that’s why you now need to understand how AI sped up coding works now. It changes the interfaces. It changes how handover and connection between product work and engineering work is happening. You need to understand how engineering works to be able to best leverage it. And this is now fundamentally changing.

“We’ve taken the writing code bit and we’ve massively accelerated that,” Simon says. “Now the bottlenecks are everywhere else.”

And we are part of that “everywhere else”.

Hint: While it is true that job descriptions become more polyvalent and generalist (or: M shaped people) will be in higher demand, and thus Product Management has the chance to go into more tactical and strategic directions at the same time, you should beware to try to become a paid designer, analyst and developer at the same time. The mental will become unbearable and we talk about that later in this article.

Option storming: prototype more, decide after

A major shift is that prototyping is now basically free and that changes the PM approach drastically.

Simon - his strong suit was always prototyping, now this is meaningless, not a differentiator anymore. He now prototypes three different ways a feature could work. Not one. Three. Because it costs almost nothing. Then he experiments, tries them, sees which sticks. “Any sort of feature that I want to design, I’ll often prototype three different ways it could work because that takes very little time.”

That’s the real core designer task: “Look at this, a little more in this direction, a little more of that?”

Think about what that does to how we make product decisions. We used to filter ideas early because building was expensive. We had to be right before we built. Our “intuition” was really just a filter born from scarcity. We killed ideas not because they were bad but because we couldn’t afford to try them.

Now we can afford to try them. All of them. So we need less filtering upfront and more judgment after the fact. Less predicting which idea will work and more recognizing which one does work when we see it running.

I call this option storming. Don’t pick the winner from a list. Build several. Watch them. Let the answer reveal itself.

“A UI prototype is free now,” Simon says. “Anyone who’s doing product design and isn’t vibe coding little prototypes is missing out on the most powerful boost.”

But at the same time, the complexity hits us a t a different stage: “You’ve got three options now instead of one. How do you prove to yourself which one of those is the best? I don’t have a confident answer to that.” His best guess? The old-fashioned way. Get a real human on Zoom, screen share, watch what happens. “You can tell the AI to simulate your users. I don’t think that’s credible.”

Intuition was always just bias mistaken for experience. Now you don’t need it as a filter anymore. You need it as a lens — to see what’s working → but only once you’ve built it.

A year of less focus, more learning

Simon’s New Year’s resolution of this year is different: “Every previous year, I’ve always told myself, this year I’m going to focus more. I’m going to take on less things. This year, my ambition was take on more stuff and be more ambitious.”

That’s counterintuitive. But it’s the right move when the landscape is shifting this fast. This is not a year for rigid plans and clean OKRs. This is a year for leaning into the tools, dealing with AI on the ground level, learning on the go. Not a ton of structure. More reps. More experiments. More surface area.

Because right now, the only universal skill is being able to roll with the changes. And that’s valid beyond Simon. Have fun planning focus this year.

This is draining. That matters.

The dark side of the new game:

“I can fire up four agents in parallel and have them work on four different problems. By 11am, I am wiped out for the day.”

Simon Willison. One of the most productive engineers alive. Wiped out by 11am. And he’s not alone. Steve Yegge, one of the other AI coding wizards, discovering all the new technologies, called it the AI Vampire effect.

AI is supposed to make us more productive. Give us more time. Let us sit around. Delegate Admin and focus on what matters, what makes us human. Instead, the people most into AI are working harder than they’ve ever worked. There’s an element of gambling and addiction to how we’re using these tools. People are losing sleep. Setting off agents at midnight. Waking at 4am to check results. While Boris Cherny and the Claud Code team hand us remote control, so we “g, touch grass”.

This is a massive context change. On the macro level: your entire industry is restructuring. On the micro level: every task you do feels different than it did six months ago. That’s draining in a way that doesn’t show up on a task list.

The smart companies won’t just fire people to “save money” with AI. They’ll figure out that the bottleneck moved to human cognition and attention. They’ll build systems that account for that. The ones that burn out their best people for short-term throughput will regret it. (While probably too late, again. Dumb before AI → dumb with AI)

On a personal level, this needs to be dealt with. Not pushed through. Dealt with.

The 90/10 split

Kent Beck said it best, already a couple of years ago: “ 90% of my skills now have zero, value, the other 10% have 1000x value”. Yes, and that’s Kent Beck.

As a society and as individuals, we need to figure out which is which. Most of what we did as knowledge workers was execution. Translating decisions into artifacts. Writing the spec. Building the deck. Formatting the report. Drafting the email. That’s the 90% that just got cheap and lost value to the LLMs- let them handle it. Proudly.

The 10% that exploded in value? Judgment. Taste. Knowing what to build, when to stop, what to kill. Reading a room. Understanding a user. Making decisions nobody else will make.

Which leads us to the one thing AI fundamentally cannot have.

Agency as the moat

“I would argue that the one thing AI can never have is agency,” Simon says. “It doesn’t have human motivations. Sure, you can tell it to make more money or whatever, but it’s never going to be able to decide on its own what makes sense for it to act on next.”

AI agents have no agency. Zero. They can execute brilliantly. They cannot decide what matters. They cannot care. They cannot commit to a direction when the data is ambiguous and the stakes are real.

That’s what we do. PMs, designers, Management, humans - we decide what problems to take on. Where to go. What to ignore. That’s agency. And it’s the one irreplaceable human skill in a world where execution is getting automated.

Invest in your own agency. The rest is tooling.

The middle gets squeezed

Thoughtworks gathered a bunch of engineering VPs to figure out who benefits most from AI. Their finding: experienced people and beginners. The experienced ones amplify and leverage on decades of judgment. The - AI native - beginners ramp up faster than ever — Cloudflare and Shopify hired a thousand interns each because onboarding that used to take a month now takes a week.

Who is in trouble? Mid-career. Not senior enough to have deep expertise to amplify. Not new enough to get the onboarding boost.

This is true for PMs and designers too. New people who are AI-native ramp up fast. Senior people leverage decades of pattern recognition. The middle is exposed.

So what do you do if you’re in the middle? Lean in harder. Embrace the new tolls and techniques. You don’t wait for the company to figure it out for you. You use these tools to take on more ambitious work, learn faster, build judgment faster. Close the gap or get caught in it.

What a PM should do now

What does all of this mean for a mid manager, a strategist, finally and foremost a PM? Learn a harness. Claude Code, Cursor, Codex — pick one or two. Get comfortable. The specific tool matters less than building the muscle of working with AI agents.

But know this: it’s not about the harness. Learning the tool is not about learning the tool. It’s about how you think with it. Simon doesn’t get great results because he picked the right tool. (He’s actually switching between them a lot.) He gets great results because he knows what to ask for, when to push back, and when the output is wrong.

We can now go downstream into coding and upstream into strategy. But just because you can doesn’t mean you should. Choose wisely aligned with your profile, your context, your ambitions. Becoming a paid developer is probably not the move. Becoming a PM who can prototype, test, and ship without waiting for a sprint? That’s the move.

Concretely, things Simon’s work suggests PMs should be doing now: prototype features yourself before writing a spec. Build three versions, not one. Use AI for the first two-thirds of brainstorming, then push past the obvious. Run your own research — feed context to Claude and let it synthesize. Hoard what you learn: techniques that worked, experiments that failed, prototypes that surprised you. Store them somewhere you trust. Feed them back into future work. “The AI is absurdly good at reusing context you make available to it.”

Test ideas with real humans, not simulated ones. “You can tell the AI to simulate your users. I don’t think that’s credible. I don’t think you’re going to get as good results from ChatGPT pretending to click around on your prototype than you would from an actual human being.”

Lean in, embrace that change, enjoy the ride and be ambitious. This is the year.

The dark factory: questions we couldn’t ask before

The Extreme idea.

StrongDM, a legitimate security company, ran an experiment.

Two rules:

• Nobody writes code.

• Nobody reads code.

Everything is AI agents. In production. → For security software.

They built swarms of simulated employees in a simulated Slack channel, making requests 24 hours a day. “Hey, could somebody give me access to Jira?” Thousands of simulated users testing the software around the clock. $10,000 a day in tokens. They built their own simulated versions of Slack, Jira, and Okta because the real ones have rate limits.

It’s insane. And it asks questions we couldn’t even begin to ask before: How do you know your product is good if no human is reviewing the code? How do you build quality without human eyes? What does a QA department have to look like when it never sleeps and runs on API calls?

These aren’t really engineering questions. They are also product questions. They are strategy questions. And they’re coming at us fast.

The Challenger disaster is coming

Simon has been predicting what he calls the “Challenger disaster of AI” for three years. It hasn’t happened yet. But the logic is obvious.

“Lots of people knew that those little O-rings (of the Challenger) were unreliable. But every single time you get away with launching a space shuttle without the O-rings failing, you institutionally feel more confident in what you’re doing.”

Or just as experienced Skit Tourers always get closer to the edge, because - hey, it worked out fine until here.

We’re doing the same with AI. Using these systems in increasingly unsafe ways. We’re still getting away with it, feeling more and more confident. “We’ve been using these systems in increasingly unsafe ways. This is going to catch up with us.”

His “lethal trifecta” for any product: private data plus exposure to malicious instructions plus the ability to send data back to an attacker. If your product has all three, you have a problem no matter what AI guardrails will reliably solve. “You can get to 97% effectiveness on those filters. I think that’s a failing grade.”

We will probably not prevent the disaster to happen. But we can be aware. And we can learn from it when it comes.

People want to augment themselves

Open Claw went from first line of code to Super Bowl ad in three and a half months. Hundreds of thousands of people set it up even though it’s non-trivial, not secure, and actually messy and not really fun (don’t ask!).

The signal is out there ein the open: people desperately want a personal AI assistant that can actually do things. Read their email, take actions, figure stuff out. They’ll tolerate terrible UX and real security risks to get it.

Give my AI those claws!!!

Look at Anthropic’s Claude — reacting in real time, taking actions, remembering context. Look at every company scrambling to build their own version. It’s not about fulfilling simple feature requests. They’re noticing the basic human needs expresses beneath: remote control over the complexity of your own life.

Just like the smart phone was not about smartness, but safety, reachability and ubiquitous information. Now these smart phones become really smart and they have claws.

For PMs, this is a goldmine of signals. What people tolerate tells you what they crave. The unsafe things people do with AI (like setting up OpenClaw unprotected and giving it root access, something you don’t give to your college normally) tell you what the safe version should be. “If you can build safe OpenClaw, that’s a huge opportunity. I don’t know how to do it. If I knew how to do that, I’d be building it right now.”

Read those signals. Build for those needs.

Agency and exhaustion

Let’s close where we started.

Simon Willison is one of the best engineers in the world. He’s shipping more than ever. He’s more ambitious than ever. And he’s exhausted by 11am.

The tools are extraordinary. What they demand of us is also extraordinary. Not typing. Not building. Deciding. Judging. Holding context. Making calls. Caring about whether the thing actually works for real people.

That’s agency. That’s what makes us matter. And it’s the one thing that doesn’t scale with compute.

Invest in it. Protect it. Don’t burn it out chasing the dopamine of one more agent run at midnight.

The AI doesn’t get tired. You do. And your judgment when you’re exhausted is worth exactly nothing.

Nico Noll: Actually Using Product Data – with AI

Nico Noll has been a product specialist for years. Has trained hundreds of PMs – inside companies, in workshops, as a coach. And is now building his own thing: Product Analyst AI. A tool born from his own pain: years spent as a PM where data was theoretically available but practically out of reach.

The core idea is simple yet structural: product data exists in almost every company. But nobody really uses it to make decisions. The bottleneck isn’t the amount of data – it’s access and interpretation.

I am regularly giving trainings for Product Managers on how to live the new PM work augmented by AI - using Claude Code. It’s about PM work, not simply learning the tool.

Next cohort "AI Augmented PM"

The Data Gap in Product Management

Tracking runs. Events get logged. Mixpanel, Amplitude, PostHog, Google Analytics – at least one of them is almost always in the stack. But when a PM really wants to know which behavioral patterns predict churn, which users drop off after onboarding, which segments behave fundamentally differently – they’re waiting on a data analyst, a dashboard, or both. Both options: slow, expensive, often simply not available.

Nico experienced it as a luxury when he was a PM at Xing: a frontend analyst and BI analyst always on hand. That’s the exception. The rule: either no data team, or one that’s constantly overloaded.

Thesis 1: Most product decisions happen without current, granular data – not because the data is missing, but because access is too cumbersome. Granular questions take weeks. So they mostly don’t get asked.

Thesis 2: The real problem isn’t a technology problem. It’s an access problem disguised as an analysis problem.

What Product Analyst AI Does – and What It Doesn’t

No “vibe analytics” – no throwing a CSV into ChatGPT and hoping for the best. Instead, a system with clear guardrails: generalized statistical functions on one side. Company-specific context on the other.

The approach: separate what can be generalized (statistical methods, calculation logic, segmentation functions) from what is company-specific (event names, business definitions, segment structures). Both together create a system that delivers reliable answers.

What works today: everyday product management questions. How many users show this behavioral pattern? How does churn rate differ across our segments? What happens on average in the first 30 days after signup?

What doesn’t work yet: the exploratory two-hour sessions with a senior data analyst. The complex strategic analyses. That’s deliberately not the goal – Pareto logic. 80% of the questions teams ask daily are answerable. That’s where you start.

Thesis: When the same question comes from the CEO and from the PM, the same answer has to come out. That’s the difference between a tool for real decisions and one that just delivers the feeling of having analyzed something.

Context Engineering – The Real Differentiator

This gets technical. Worth it.

An LLM without context makes assumptions. And does so with alarming self-confidence. Markus shares a good example: reviewing a bootcamp curriculum. ChatGPT without specific context produces generic output. Then name the deep technical errors, ask again – suddenly the model says it has now activated the necessary knowledge and can actually go deep.

The LLM knows what it needs. It just usually doesn’t get it.

What Product Analyst AI builds because of this: a context layer. What do the event names actually mean – because they often aren’t called “conversion_event” but some cryptic string. How does this company calculate churn rate? Which segments come up again and again? Which metrics are already defined?

All of this gets built out once – currently still manually during onboarding – and then provided to the agent as structured context. The agent pulls context and calls deterministic calculation functions. Combines both. Delivers reliable answers.

Thesis 1: Prompt quality matters less than context management. Whoever builds in context in a structured way gets dramatically better results.

Thesis 2: The people already getting real value from AI, and those saying “it’s all generic” – they differ almost exclusively in how well they manage context.

Data Access for Everyone – Not Just Product

Customer Success wonders whether the upsell from last quarter is even being used by an account. Sales wants to know which customers are showing churn signals. Marketing would love to see which features actually drive activation. All of that is in the data.

But Mixpanel access is usually only for product. And even there, people often don’t really know what’s inside the data.

That’s the bigger picture behind Product Analyst AI: not just serving PMs, but enabling data access for all teams in the company. Without everyone having to learn Mixpanel. Without filing a ticket to the data team. Without waiting three weeks.

Thesis: Most companies have a data access problem – and mistake it for a data analysis problem. The fix isn’t building more dashboards. The fix is making questions directly answerable.

AI in the Entrepreneur’s Daily Life – What’s Really Changed

As a two-person founding team, Nico and his co-founder can now do work that would have either been left undone or required external resources a small team simply doesn’t have.

Concretely: filtering 5,000 relevant companies from a LinkedIn connection list. Automatically qualifying new signups – which company do they work at, what problem might they have, are they a fit? A Python script that would have meant half a day of manual work now gets built in minutes.

Nico says it plainly: it has revolutionized every part of his work. Not in the sense of “I don’t have to think anymore.” Quite the opposite – the quality of his own thinking is now the bottleneck, not the execution of manual tasks.

Thesis 1: AI doesn’t take away jobs. It enables work that simply didn’t happen before – because the resources weren’t there.

Thesis 2: With AI support, you don’t become more efficient at what you were already doing. You can suddenly do things that were simply out of reach before.

The Addiction Factor – and Why Distance Still Matters

Nico runs. A lot. Trail running in the mountains whenever possible. And he travels. Montenegro, Bali. Not as a break, but as a necessary change of contrast.

The background: when repetitive work disappears and almost only strategic thinking remains, mental clarity becomes the real bottleneck. Before, you could “switch off your brain and just do.” That’s no longer possible.

At the same time: AI tools have an extreme addiction factor. Fast results, constant dopamine hits – bang, result. Another iteration, bang, better. Markus directly compares it to social media. And hits a nerve.

Naval Ravikant has a fitting tweet: “Play long-term games with long-term people.” That’s exactly the opposite of the hustle-ADHD currently running through AI circles.

Thesis 1: The more powerful AI tools become, the more important the rhythm around them becomes. Whoever doesn’t actively shape that, burns out.

Thesis 2: Staying outside your own bubble matters strategically right now – not just personally. Living only inside the AI-early-adopter world means losing the feel for what most people actually need and understand.

Signal vs. Noise – How Not to Lose the Plot

Everyone has FOMO right now. The biggest names in the space included. The question is no longer whether you’re missing something – but how to stay able to act anyway.

Nico’s answer: find three or four people who don’t share opinions but show how they do things. Follow them. Tune out the rest.

Thesis: Going deep on AI tools tactically is one of the most strategic moves you can make right now. Whoever understands how these tools actually work has a fundamental advantage – just like at the rise of the internet or mobile.

The ideal they work towards is: people literally create their software futures by speaking them out loud.

People don’t need to understand what I unpack here, they feel and experience it naturally - and that’s what makes it so addictive to many.

Watch any video of the Claude Code team at work. Multiple terminals open. Parallel threads running. Experiments spun up and lots of them killed right away.

On the surface: hyper busy. ADHD style — which they even mention themselves.

That reading hides what’s actually going on. And decoding what’s underneath the cool story is worth a few minutes. Because it reveals something most teams haven’t understood yet. And probably won’t for a while.

What you’re watching is the visual signature of a completely different way to build things. They call it engineering. I’d call it option storming.

Brainstorming is dead. Long live option storming.

Brainstorming assumes execution is expensive. So ideas get filtered early — by discussion, by judgment, by committee. Most things die before they touch reality.

“IT is the place where nice things go to die” Remember that? That might be a thing of the past.

Option storming turns this upside down.

When execution is cheap and speed is insane, you stop filtering before the experiment. You run the experiment. Any experiment. Now. The moment it crosses your mind. Let reality do the filtering.

That might sound subtle and obvious at the same time. And it changes almost everything.

The Claude Code team operates on exactly this logic. They execute basically every thought they have. Ideas that didn’t work 6 months ago? Try again. People starting work on that team are explicitly confused about the perceived “waste.” The answer: Why not? Cost of re-testing: trivial. There’s high chance the environment changed: new models, better agents, different usage patterns: 100% real. Let’s see, give it a try. Nothing to lose.

Historical rejection becomes weak evidence when the world keeps moving.

And that explains a lot more than just code. Unfiltered observation of customer complaints on social media. Insights from dogfooding inside Anthropic. Let’s just follow all signals. Now. What’s there to lose, again?

All early filters are gone. Why do deep user research when it’s faster to create the reality, look at it, and keep or dismiss? What’s the actual value of overthinking? That’s why it feels so alien.

If you’re still running design sprints to decide what to build — you’re solving last decade’s problem. The bottleneck moved. You just haven’t noticed.

The 3D chess behind the scenes

The simplified story goes: AI writes code, engineers review, productivity goes up.

Totally true. And totally missing the point. Three games are running at the same time.

Layer 1: Build the product.

Layer 2: Build the tools to build the product.

Layer 3: Build the exploration infrastructure that makes discovery cheap enough to sustain Layer 1 and 2.

That’s the meta. That’s what those open terminals represent — parallelized discovery threads, each one probing a different part of the design space.

The engineers aren’t just building software. They’re designing the machine that builds the software that becomes the machine. Claude Code.

And they’re doing it inside the machine.

Claude Code builds Claude Code. The development environment is recursive. You’re observing agents, inside the system, while evolving the system. What seems like engineering is research lab work with tight integration gates, working on a moving target.

The necessary background skill they built: leveling exploration code to production quality. So what gets created as an experiment can simply go live. That’s where the guardrails come in — so the code doesn’t need to be reviewed. One stage less. Again.

Hold that moment: They removed the review stage by making exploration production-grade. Rather than that being a local process improvement it really creates an entirely different architecture of work.

How this puts the customer at the center

In this model, internal reasoning is now only secondary input. The primary guide:

• usage patterns

• friction in real workflows

• feedback from people actually using the thing, e.g. from internal dogfooding (Finance guys use it? Let’s create Claude Cowork for them. Because we can. Security? Let’s include a VM, who cares? Let’s see that thing. 10 days? Why think about it?)

The loop becomes: user signal → option implemented → real usage → keep or discard.

That’s why products built this way feel unusually well-tuned. They are not designed and filtered by assumption, but shaped by many small empirical corrections. Evolutionary selection can now finally win over big design upfront. Because: why think now? This is the next level of giving up the idea of control. Change user behaviour? Why? We can just give them what they need.

The shift to real evolutionary design of the machine that builds the machine — that’s the actual achievement. Not the code. Not the terminal count. The loop.

The real competitive advantage

What’s hard here isn’t generating ideas. Everyone can generate ideas.

What’s hard:

• building fast evaluation loops

• detecting real signal in the noise

• filtering coherently

• integrating what survives without creating chaos

The core competence moves from ideation and early-stage filtering to creating all options simultaneously and filtering as late as possible. Remember this: the core ability is now to filter as late as possible (or rather necessary!). The whole decision of what makes sense moves to the stage where the thing actually exists.

That is the revolution behind this.

It’s a pattern that shows up whenever generation becomes hyper cheap. Hardware: think Shenzhen where physical prototyping got so cheap that decisions moved to after the thing existed: cheapest prototypes enable late decisions. Software: think what’s happening right now.

The public narrative around “AI writes code” buries the real insight.

It’s not about the generation. It’s about what you do with the explosion.

The most powerful teams in these environments stop thinking of themselves as builders.

They become designers. More of this. Less of that. More like this? Let me look at the actual thing. And when the LLM doesn’t solve a use case cleanly? Never mind. Next one. The deficiencies of the models barely matter when your exploration surface is this wide.

That’s the game.

Most people watching from the outside are still counting terminals.

But here’s the part nobody wants to hear. If your business depends on fulfilling concrete promises — not exploration but delivery on commitments already made — this model might not work for you. At all. The Claude Code team can do this because their product IS the exploration tool. It’s turtles all the way down.

So the real question isn’t “how do I copy what Cherny’s team does.” The real question is: does your business model allow for massively parallel discovery? And if it doesn’t — would you dare to shift it so it does?

Because that’s where the divide is forming. And it’s getting wider fast.

What you needed to hear

What Cherny’s team is really working on, knowingly or not:

“The moment I think it, it exists”. Voice mode is just the latest approximation. If you think it and can speak it: it will exist.
And that’s what makes people so addicted to the tools.

People don’t need to understand what I unpack here, they feel and experience it naturally that they literally create their software futures by speaking them out loud.

The picture is the answer, honestly.

Nobody has the AI answers yet. (Altough I start thinking that’s just a thing we keep saying. probably we know more than we acknowledge.) The books aren’t written. But we already know something that works in the moment: something works: people sitting together, fiddling with a laptop, building their first agent. And the next and the next. Just doing it, no overthinking. No committees, no processes. The moment the first agent runs, changes everything. If you achieve that moment with a CEO, the whole company is accelerated. That tactic is the strategy of the moment. Everything else is second rate in this moment.

Note: I am currently offering a course for PMs on how PM work looks like now. It’s starts with learning the tool, then having it build your system, then doing your job like in the future. 4 weeks, starting 13 March 2026. Click if interested, ignore of not.

More info

Insane Questions, insane height of falling

Where does AI lead your company? Your career? Society? What’s the end game?

Is it the singularity? Does it kill jobs, or does it only shift work around in dimensions unseen? The back pushers, who still try to deny it entirely. “It’s not as good as humans”. (Sure, but who cares? It’s amazingly betters in parts. It’s always on, it’s eager. It’s productive as hell.) You have complete polarisation: Some predict the future with perfect certainty. Then the doomers. The hype attention economists. All opinion, no answer.

Funny note: A week ago or so I was on a LinkedIn thread in which people complained about people complaining they have a hard time working when the tokens don’t keep coming. To them that seemed like bragging. They couldn’t imaging that there are people, working professionals, in systems that rely on tokens.

The predictions contradict each other. It’s not that people are stupid but because this thing is still partly unknowable right now.(Again, I think it became much more predictable since maybe 3-4 months. The monster showed it’s head: It can pragmatically can do more that we thought.) We’re in 1995 internet territory. The infrastructure is here. The value systems on top of it are not. We’re all fumbling.

And I mean all of us. Me included.

The simple pattern that I see working over and over again

The solution of the moment is absurdly simple.

Given the enormity of the question, one would expect the answer to be equally enormous. A grand strategy. A transformation program. A 200-slide deck from McKinsey. A three-year roadmap. All the overthinking you can imagine. Brainiac work through and through.

Nope.

Ironically overthinking and waiting and “perfect” of course is the recipe for disaster.

The one thing that actually works is comically small and absurdly trivial: Two people. Some people. One room. A couple of laptops. Fiddling. Tinkering. Maybe building their first agent. Struggling, ups, downs.

It’s part of my job currently because I think one of the best things we can socially do and in socialising our talents is that. Sit with people, open a laptop, and start. No other agenda: let’s see what this thing can do for your actual work. No demo. No presentation. Nothing smart. Just work with actual “context”.

Let it roll, and things happen. Insights come flying. What the thing can do, what it can’t (yet?) do, what it means for the org, where the current org hits the limits of the new thing. Just like that. It’s not that hard.

Once agent runs and does funny, or productive, or awesome or trivial things, the same person who five minutes earlier said “I can’t do this” or “CLI - that’s not for me” watches their messy spreadsheet get analyzed (20$ of tokens but a forecast like no other in the last 12 months), backlog structured, meeting notes synthesized (but now everyday, all of them. Oops, a new productive habit). Something that would’ve taken them half a day, now swooshing down in seconds. After the second it’s not magic anymore. It’s the new normal, a level for their data, their context, their problem. And addictive. No turning back.

That second changes things. I’ve seen it dozens of times now. It’s the same face every time. A mix of “holy shit” and “wait, what else can this do?”

I had a call with 15 strategists (you know: strategy being an art and all), denying the new toy, showing them analyses the thing did in minutes and 15/15 wanting to apply it next week.

Pandora’s box

If that person is a team lead, the team changes. If that person is a CEO, the company changes.

What the Forst agent actually does is mostly irrelevant. It’s a switch of the mental model. The idea of what’s possible just changed trajectory. After that, it doesn’t come back down. Agents then mean agency.

Pandora’s box opening. For better or worse. Because not everything is easy now. The person with the new won agency now starts seeing the entire workflow with from a different vantage point. Every repetitive task, every weekly report, every data pull that took three hours or was depending on the availability of that expert that never has time. Boom, from pain point to candidate.

And the ones who don’t have that moment? They’re still debating whether AI is “ready” or “reliable” or “safe enough” and focusing what it can’t do” and how “its not human at all” and how the other bubble is just “without any responsibility". Which are valid questions. But they’re questions you can only answer by doing it. Not by reading about it. And then, maybe knowingly, still own that position, earned from practice.

We’re touching maybe 1-5% of what AI can do

That’s volume and areas. I’m guessing of course. The remaining 95-99% aren’t an about knowledge, they are mainly about not applying practice. They are waiting for a pioneer just doing it and being surprised that it actually works. my next big bet is middle and top management. All the heroics, all the dirty work, figuring out the signal in the noise. The whiter the collar, the ironically better the AI is in filtering. And the clearer our vanity in discussing wordings for week, while the AI still gets the same signal, becasue the information content remains the same. The weeks of discussion were about socially coding the thing. Tribal rituals.

The people I work with are all smart. Many of them are senior. They’ve read the articles. They’ve seen the demos. They know, intellectually, that AI is a big deal. But knowing and doing are two different planets. The gap between “I’ve seen a ChatGPT demo” and “I built an agent that checks my strategy docs against reality every morning” is enormous. And you can’t close it by reading more articles. The thing that makes the difference now is not IQ, but leaning into practice and knowing it’s a strategic move.

The responsible position

Those in positions to decide must open the windows for this. Not next quarter. Not after the “AI strategy” is finalized. Now. Rather under- than overthink. Just like 1995. Those who won built, they didn’t think that mich. That came later, in exploitation times.

CEOs: build programs that let your people practice. Not one-off workshops. Not a lunch-and-learn. Actual time, actual tools, actual problems. Rituals, habits. Weekly. The ROI will be obvious within weeks. And the ones who practice will tell you things about your business that no consultant will.

Schools: teach kids now. They’re already using it anyway. The question is whether they learn to use it well or whether they stumble into it unsupervised. That’s not a technology question. That’s an education question.

Universities: shift your curriculae. I talked to a professor recently who still teaches the same software engineering course from 2019. 2019. That’s seven years and an entirely different reality ago. Students deserve better. Now.

Parents: show it to your kids. Sit with them. Build something together. That’s the laptop-in-a-room thing again, just at the kitchen table. This is better than the toy robots. It’s a ton of fun next to the learning.

Not tomorrow. Now. Today, this evening. That’s not even rushing it, and I don’t talk FOMO!

The absurdity

It makes me laugh every time I think about it:

The strategic questions AI is putting at our feet are astronomical. We’re talking about the restructuring of work, of education, of how decisions flow through organizations, of what jobs look like in five years. These are society-level questions. The kind that usually require commissions, think tanks, policy papers.

And the best strategic response right now? Sit in a room. Open a laptop. Build something. Together. See what happens.

Absurdly tactical.

If you are currently trying to figure out what is the next change or what you or your team or even your company could adopt, trying to understand the direction from the vantage point of the extreme, that already exists, might help.

Disclaimer: We probably don’t really know what they are really doing over at Claude. I tried to compile as much as I could and give a honest summary of what I found.

“Vibe coding” started as a name for AI-assisted prototyping. It has since become a label for everything - including the careful, structured work of the engineers who are actually pushing the frontier. The resulting confusion creates a ton of division and is worth clearing up. It creates an idea that there is production code without clear architecture, guardrails and constraints. The idea that code is only reviewed on the feature, not line level (what Shapiro describes as the psychological hurdle between level 2 and 3 - out of 5 - on his “vibe coding scale”) is fear inducing. Studying what Cherny (creator of Claude Code) and others are doing is telling a bit of the story of how their work is actually zero Yolo, but highly disciplined, structured and responsible. Also, it gives a bit of a peek into what future teams look like and how they align.

Andrej Karpathy coined the term “vibe coding” in early 2025. The idea: fully surrender to the AI. Stop reading diffs. Just describe what you want and see what comes out.

It caught on fast because it matched a “vibe” that was in the air, something polarizing, because it looked magical at the time. It was democratizing and at the same time, without guardrails, totally irresponsible. Tools were Lovable, Bolt, v0. Build a landing page in 20 minutes. Ship a prototype in an afternoon that would’ve taken a week before. That version of vibe coding is out there, still and has useful, limited applications. But then a lot happened and the label remained stuck to everything.

Karpathy moved on, and especially the people around Cherny at Claude moved on, and in his own way, also Kent Beck (see some quoted from him below). moved on

Until now that creates some fog over the debate, as any serious AI-assisted development got called vibe coding. Which is a problem. Because what Karpathy originally described - and the workflows the people at the actual frontier developed since then and execute everyday - are two different things entirely. Karpathy moved on, the team creating Claude Code moved on a lot, heck: Kent Beck moved on. Let’s see where they moved to.

What Boris Cherny Actually Does

Short version: research first, plan second, annotate until it’s right, then, and only then, implement. Humans check the thinking before any code runs. And then check again when the feature is built. If it works: fine. If not: next iteration. Good code is taken for granted and not being checked as the production pipeline is optimized through guardrails to ensure that.

Boris Cherny built Claude Code. He uses it like this.

Before any code gets written, he writes a research doc (you could call this PM work, he writes the spec for the feature). Claude reads the relevant parts of the codebase, documents what it understood. Cherny reviews it. As long as the understanding is wrong, no code is produced. Garbage in, garbage out - that doesn’t change when the code is written by an AI.

Next: a plan, ending in plan.md. It shows file paths, trade-offs, code sketches, which Cherny annotates directly, corrects constraints, kills what’s out of scope. Claude then updates the plan. They go back and forth until it’s right.

And only then does he say: “implement it all.” So: until here: plan mode and then the famous one-shot based on the iterations until a good spec was reached.

My course on PM work in Claude Code

The explicit instruction during planning is “don’t implement yet.” That’s one important guardrail. The agent can’t lock into wrong assumptions before a human has checked the thinking. The switch from “don’t implement yet” to “implement it all” is 0-1, but to get there is highly iterative. The one shot is the result of those careful iterations. Then he looks at the result and like a designer or a tailor, he iterates again to say “a bit more of this, a little bit less of that”.

During implementation, continuous typechecks and tons of guardrails are running. Tests are written first, based on the specs. Short, operational corrections. No architecture discussions at this point. If it goes the wrong direction, he doesn’t debug it to death. He reverts, in the worst case, he throws it in the trash. Re-scopes. Hard reset. Move on.

At any given moment he has 5 to 10 agents running in parallel. some of them in Claude Code, some in the browser, some on his phone. Balancing the work on a git worktree. Some tabs just get killed if the direction was wrong. That’s the default of Cherny and his team. And (yes, currently just) a couple of other teams. 90-100% of their code is written like this. Pull requests on the rise as well.

The Misunderstanding of the old Agile community: “But we proved spec driven coding does not work”

It should be obvious, but the word “spec” alone drives instincts - hundreds of pages of PRDs, waterfall, defining the outcome of the next 9 months: But here, the “spec” is for one iteration. Maybe an hour. Not eternity, not a sprint. Not even a day.

If it doesn’t work, depending on the outcome, you throw it away (totally wrong direction) or iterate on it. Cherny has multiple simultaneous attempts going precisely because he expects some of them to fail. The cost of a wrong direction is a closed tab, not a failed sprint.

This is not the same spec-driven design as “normal” teams practice it. The spec isn’t a contract. It’s a hypothesis. You test it. If it’s wrong, write a new one. Same word, different semantics.

What survives iteration isn’t the spec, but the judgment about what to spec in the first place.

Vibe coding as a word is already done

When Karpathy described vibe coding, he was describing exploration. Build something to see if it’s even worth building. Don’t worry about production. Don’t worry about edge cases. Just explore.

That was ok and it still is. But it’s not what happens when you ship real software.

What Cherny, Karpathy himself in production contexts, and, a bit with more hesitation or just “searching”, Kent Beck are working toward is something different: code generated at scale, with humans making judgment calls at the feature level.

Line by Line is gone and taken care of by “the machine”. Not even function by function. But: does this feature do what it should? Is the plan right? Is the architecture sound? Is this the right thing to build at all?

Those remain human decisions. What they say is that “taste” is more important than ever. Probably it’s more than that, and calling it taste is a sign of humility. It’s a well trained skill.

The implementation is increasingly mechanical. The judgment isn’t. So, there’s vibe coding and there is context engineering or whatever the word of the week may be. Different things.

The Five Levels of Vibe Coding

This is Dan Shapiro’s framework for where people currenrly stand with AI. Five distinct stages, each one requiring the human to step further back from the code:

• Level 0 - Spicy Autocomplete. AI finishes your lines. You’re still writing the software. Fewer keystrokes, same job.

• Level 1 - Coding Intern. You hand the AI a scoped task: write this function, refactor this module. You review everything that comes back. AI does tasks. Human does architecture.

• Level 2 - Junior Developer. AI handles multi-file changes and navigates the full codebase. Human still reads all the code. Shapiro says 90% of self-described “AI native” developers are here, thinking they’re further along.

• Level 3 - Developer as Manager. The relationship flips. You direct, the AI implements. You review at feature/PR level - not line by line. Most developers get stuck out here, because the psychological blocker is huge: let go of the code.

• Level 4 - Developer as Product Manager. You write a spec. You leave. You come back hours later and check if the tests pass. You’re not reading the code anymore. You’re evaluating outcomes. Almost nobody writes specs good enough for this yet.

• Level 5 - The Dark Factory. Specs go in. Working software comes out. No human writes code. No human reviews code. The factory runs lights-out. Barely anyone on the planet operates here.

L2 → L3 is the crucial and hard step. Level 5 probably Nirvana, but an Utopia, the place most of us don’t reach very soon.

What do teams look like now?

Claude Code started as a one-person project (Cherny) plus Sid Bidasaria. Now it’s ~10 engineers (judging on the output and outcome, they’re quite a lot more already this week?). Cowork - Claude Code for more general knowledge work - is also a ~10 people team (or was, a couple of weeks ago, when it was built in a couple of days).

There are roles. PM, design, data, engineering. But the boundaries are dissolving. The APIs between roles become less clear. Everyone goes more up- and downstream at the same time. Everyone codes. The PM writes code. The designer writes code. Half the sales team at Anthropic uses Claude Code weekly. The whole org dogfoods. They all improve the production chain.

Formal sprints don’t seem to exist. But what replaces the coordination overhead?

A partial answer lies in shared artifacts. CLAUDE.md files in the repo, team conventions, common mistakes, guidelines. Slash commands that embed shell steps and pre-approved permissions so agents can move fast without constant back-and-forth. Learnings from PRs fed back into those shared docs. Architectural decisions, “best practices”, learnings get “coded” into the machine and the shared infrastructure right away. Strategy and decisions are shared in .md files.

What used to be a recurring debate about shared practices, has become shared infrastructure.

Code review: Claude does the first pass, including security review. Humans approve. Every PR, same flow. ~95% of Claude Code’s own codebase was written by Claude Code. PR throughput reportedly went up ~67% as the team doubled.

Take those numbers with appropriate skepticism, they are self-reported and hard to benchmark. But the direction is clear.

There’s no clear PM-to-Dev ratio. No role in its pure form without some coding. The team isn’t organized around handoffs anymore.

“Heard the story of a programmer who didn’t want to use a genie because they would lose their programming skills. My dude, someone handed you a chainsaw and you are saying nah I’ll just keep using this cross cut saw because I don’t want to get weak” - Kent Beck

What’s the shift?

What looks like vibe coding from the outside is a carefully constructed pipeline, a finely honed machine.

Research artifact. Plan artifact. Annotation loop. Mechanical implementation. Continuous verification. Revert if wrong.

The trick is that the visible part looks so casual, probably for the sake of marketing: “here’s what I want.” “A third of my work is happening on my mobile phone in the mobile interface of claude code”. Sounds close to not being serious, but is to be taken into context. The interface doesn’t matter, it’s just a small window into a huge context and supporting scaffolding. The invisible, unattractive part is discipline: which decisions are human, where are the gates, what gets reverted when.

It’s the opposite of YOLO.

It’s a peek into what’s possible in engineering under the new conditions. The tools changed. The fundamentals, understand the problem, control scope, verify the output, learn from failure, didn’t.

The people who are best at this aren’t the ones who let go the most. They’re the ones who figured out where exactly they need to stay in control.

Why This Matters

Understanding how the extreme works already today is important for two aspects:

(I) There is a lot of disbelief and misunderstanding on how this can work and the narrative is often met with “this is just marketing” without looking deeper into why it works, where it works.

(II) There is a lot of discussion going on that this (being whatever vibe coding interpretation) is not as productive as claimed, which is often coming from people looking at it without full information and from an angle of “how does my work look like today”. Tinkering shows the way currently.

“Try It! The thing about rapidly changing, brand new tools is that nobody knows the answer to any of the questions you are likely to have. Exploristan is the Land of Try It.

Try it and then share. We’re all wondering.” - Kent Beck

(III) Most importantly: There are a lot of studies which are interpreted as “this” causes an undue amount of stress for people. Which is right. But the environments mentioned in those studies themselves did not react to this new way of work. “This” causes two things: a lot more context switching (not what humans are good at) and more ambiguity due to dissolving roles, more work options up- and downstream at the same time, thus more potential for confusion. The task for work environments is to set up new structures and rituals that create guard rails against burn out and support the new level of speed. Not everything that can be done, should be done. help structure the workday of workers according to the new challenges. But for that the new way of work first needs to be understood.

Sebastian Heide Meier zu Erpen and André Neubauer had me on their podcast. HMZE Beyond Vibecoding, episode fifty. Anniversary time, hat an honour to be the gust! We - of course - talked about AI, product development, and strategy. Went deeper than I expected.

A few things slipped out that made even me pause. Here’s the extract. Unfiltered.

TLDR

AI isn’t just changing how code gets written. It’s changing how decisions flow, which roles still make sense, and how close leadership needs to be to reality. Most companies are currently running the assembly line with the wrong model on it. And the line is running.

(Use English subtitles if necessary)

The Top Theses

1. Claude Code is the worst product name of all time

2. McKinsey reports are no better than an AI analysis fed with random documents

3. Middle management is about to become the real bottleneck — and the actual death blow

4. Two-week sprints don’t make sense anymore

5. 90 % of your skills became worthless — overnight

6. Strategy is becoming more important, not less

7. The information content of your strategy documents is so low that your wording debates are irrelevant

8. Decisions need to land in the infrastructure files today. Not once a quarter.
   

What’s Behind It

1. Claude Code is not for code.

Probably the worst product name ever. You read “Code” and think: not for me, I’m not a developer, next. And in doing so, every product person, strategist, COO, and CEO is missing the most powerful tool they could have right now.

I use it every day. Zero lines of code. I analyze user interviews. I build agents that check back-briefings against strategic briefings. I draw conclusions from Slack channels, Git commits, strategy docs. I filter out in real time where things are going sideways in the company. Every morning.

The trick compared to regular chat: your context is always there. You set it up once — who’s the company, what’s the market, what strategy are we pursuing — and it sticks. Every conversation. Every agent run. Once you’ve worked this way, regular chat is almost unbearable. Having to re-explain everything from scratch every time. Intolerable.

Björn Schotte gave me the decisive push: Forget the Lovable and Bolt toys. If you’re serious, go straight to Claude Code or Cursor. Because then your deliverables are right next to the developer. In Markdown. Directly pushable to Jira or Linear or wherever the hell you need them. That’s the actual point.

2. McKinsey reports are no better than an AI analysis.

Sounds provocative. I mean it. (And yes, I know they’re selling social safety, not actually great reports ;)

I throw in random documents. From all levels. Strategy slides. Back-briefings from middle management. Slack messages. Git commit metadata with descriptions of what they’re supposed to support. No clean set. No curated dossier. Just the stuff that’s there. And then I ask: What does this company actually want? What is it actually doing right now?

What comes out is so to the point that I have a communication problem. Not a quality problem. People get defensive immediately. “That’s not what we meant.” “But we were trying to.” “That’s not fair.” All true. Nobody intentionally did anything wrong. The analysis doesn’t say that either. It just says: You want this. You’re doing that. There’s a delta. We should talk about it.

The terrifying part: Zero politics. Zero deference to hierarchy. Zero agenda. Just what’s in there. Incorruptible. I’ve seen a lot of McKinsey bullshit in my life. The hordes come in, you’re four million poorer, they’re there for a quarter, they come back with a report — and I swear it’s no better than what a “random analysis” produces. Sometimes worse. Because it’s softer. Because it’s more political.

The biggest problem isn’t the quality of the analysis. It’s: How the hell do you communicate this to humans? When something is so much to the point, the normal human reaction is “duck for cover” first, no matter how smart people are. I’m working on that part. But the raw material is brutal.

3. Middle management: The death blow.

The CEOs /COOs currently hunched over their layoff spreadsheets are thinking about it backwards. They’re looking at: Where do I cut production costs? Who’s expendable? And they’re completely missing what the next bottleneck will be.

When your developers are so empowered that you can build 20 variants of five features a day — what slows you down then? Not the tech. The sluggish process around it. The committee that meets once a quarter. The absurd decisions that get painstakingly poured into presentations. Some assistant, some COO office rolling it out across the company over the next three months. And at the end, a fraction of it arrives as a Markdown file on the developer’s desk. Those are two systems that have nothing to do with each other anymore.

Picture VW. The assembly line is running — with the wrong model on it. Because the decision to retool is stuck somewhere on the third floor. It’s been decided, it’s been engineered, it’s sitting right there — but nobody’s retooling. Tough luck. Wrong car produced. That’s exactly what’s happening right now in every company that’s building speed on the development side without touching the decision architecture.

Bitter pill, especially for middle management: When your production speed dictates the pace, it doesn’t matter how useful the intermediate layers are — they’re slowing things down. You need systems so direct that decisions don’t trickle through five levels and create drift five times over. Very few layers. Or hyper-efficient ones supported by AI.

The jobs that existed aren’t as useful as they were. That’s not a judgment. That’s physics.

4. Two-week sprints: Goodbye.

Back to basics. The core principle from the original paper “The New New Product Development Game” — the ur-text that all Scrum people reference — was overlapping phases. Not sequential. Simultaneous. That was the dream.

What the sprint did: pack that ideal into a two-week container so reality could cope. Teams needed to sync. Stakeholders needed rhythm. Reviews needed planning. The sprint was a compromise with slowness. Nothing more, nothing less.

Now you have perfect overlap. Design in the morning, build at noon, review in the afternoon, ship in the evening. Not as a metaphor. Literally. What’s a two-week sprint supposed to do there? Probably even a daily sprint doesn’t make sense. You probably have a morning shift and an evening shift. Or just complete flow. Which was always the dream anyway.

And when work moves that fast — the problem of keeping oversight multiplies. Without end. That’s why you need the daily check: Is what’s being built right now going in the direction of the markers? Not once per sprint. Every day.

5. 90 % of your skills: Worthless. Overnight.

Kent Beck wrote this two or three years ago. 90 % of his skills lost their value from one day to the next. The remaining 10 % multiplied a thousandfold. That was bold back then. Today reality is staring you in the face with it.

Look at the specializations that emerged over the last 15 years. Product Marketing Manager. Product Owner. UX Researcher. Frontend Specialist. Backend Specialist. The list is absurdly long. All of it was an answer to complexity. If one person can’t know everything, then at least one person per thing. Sounds reasonable. It was. It isn’t anymore.

These specialized skills almost all fall into the 90 % zone. You can get the stuff done. Not perfectly. But good enough for the next step. And “good enough for the next step” in a system that improves every day eventually becomes “better than the specialist.” This isn’t future tense. It’s happening now.

What’s in the 10 %: Setting direction. Holding context. Noticing when the system is running wrong even though it’s running fast. Tolerating ambiguity. The human stuff. Figuring out your own 10 % — nobody can do that for you. But I wouldn’t wait forever.

6. Strategy: Now more than ever.

You might think: If everything’s so easy now, I’ll just do everything. 20 features a day. 100 variants. Why bother with strategy? Let it roll let the good times come..

That’s exactly when you need clear markers. Who are you? What don’t you do? James Bond doesn’t do just anything. James Bond does James Bond things. Coca-Cola does Coca-Cola things. eBay took years to explain to customers that you could now also buy directly. Not because the tech was hard. Because the identity shift was horror. Customers came for auctions. “Buy now? What? That’s practically fraud.” It took forever. Then classifieds got added. Another 5 years of explaining. Changing identity isn’t “oh, let’s just add that too.”

And the Elon Musk stuff everyone celebrates? Expensive car first, then mass market. That’s not genius. That’s the playbook for entering an expensive market that requires heavy investment. Of course you don’t start with the cheap car. How would that work? It doesn’t throw off enough for R&D. You can’t do it any other way. It’s a strategic pattern, not brilliance. 20 years later, if it works, everyone writes: Obviously, the guy’s smart. Nope. Standard playbook with good execution.

Marker-Options-Work resolves exactly this tension. Markers are identity — slow. Options are the ways to express that identity — medium speed. Work realizes the options — fast. The three layers must be coherent. Always. And the faster the work gets, the more often you need to check whether the coherence still holds. Not less often. More often.

Pace Layering explains it best: Fashion can push 200 collections a year because commerce, infrastructure, and politics underneath are stable. Zara doesn’t think about trade law. Doesn’t have to. It’s just there. You can only be fast at the edge — customer-facing — if you’re brutally stable on the inside. That’s the tension. And whoever can’t hold it flies apart.

7. Your wording debates are bullshit.

This epiphany hurt the most. Myself. My own vanity.

I throw strategy documents into the AI. The good version. The bad one. The latest draft. The one before. And then I ask: What does this company want? What is it doing right now? The answer: Exactly the same. Every time. Regardless of the wording.

The information content of these documents is so low that it makes zero difference whether you take the polished version or the first rough draft. Debated for months. Went over the phrasing one more time over red wine the night before. The final review meeting on Sunday before the offsite. All of it irrelevant. Zero difference. The direction is the information. Not the sentence.

And the humble insight behind it: The team feels better because they found this great wording. Maybe the drift goes one way, maybe the other. But operationally it makes zero difference. All those final polishing loops — irrelevant. Let that sink in.

Strategy isn’t unimportant. The energy is just completely in the wrong place. On phrasing instead of direction. On the paper instead of what happens after. And the strategist says: “I’m the artist here. I know how to maneuver people into position. We obviously need another two-day offsite.” No. You don’t. What you need is daily exchange between the layers. That’s the real work. The rest is theater.

8. Decisions into the infra files. Today. Not next month.

The most concrete thing from the conversation. And probably the most radical.

If you decide something today, it’s in the context documents for your agents and developers today. Not next month. Not after the next quarterly. Today. The machine is running. It needs the information to build the right thing. If it doesn’t have the information, it builds the wrong thing. Fast. A lot of it. Wrong. That’s VW with the wrong model on the line. Except the line runs ten times faster now.

I meet daily with the companies I work with. Mornings. Brief. Listen: What happened? Where is something going in the wrong direction? Where do we need a decision? And then not: Build a deck, prep the quarterly, roll it out. Instead: Straight into the infrastructure. Into the system prompts. Into the context docs. Into the dev environment. Today.

Sounds exhausting? It is. For humans. For systems, speed is irrelevant. And the COO I’m supporting with these experiments is absurdly faster — because he’s not waiting for some quarterly update to make its way through three layers. He sees what’s happening. Daily. He acts. Daily.

The side effect: Founders and CEOs report getting a completely different sense of control back. For years most of them built an increasingly indirect company. Another 20 developers. Another ten layers of middle management. Another structure, another one. Everything they did was buy a company they could steer less and less. And it annoyed most of them, if they’re being honest. Now they suddenly see again: I can steer directly. How great is that? Founder mode back. The problem is just that a few people need to be reshuffled. Because the jobs they had aren’t that useful anymore.

To Close with the beginning

We’re all fumbling around. That was the first sentence in the episode. Still true. Nobody knows what the organization looks like in three years. Same as during the internet revolution. Same as with mobile. The higher-order system that triggers Jevons Paradox and actually creates massive new jobs isn’t here yet. We’re building electric candles when there could be floodlights.

Until then: Figure out which of your skills are the 90 %. Automate them yourself. Don’t wait for someone else to decide that for you. Then focus on the 10 % that actually make you valuable.

Get into it. Today. Regardless of your role. It barely matters which tool you pick. Just pick one.

Not “explore AI.” Not “form a committee.” Not “wait for the enterprise version.”

Enable. Everyone. Now.

This is also the responsible thing to do. Your workers will depend on this skill in the future. Not enabling them now is negligence , you’re probably “waiting for the right moment.”

What makes me say this? Something happened! And there’s no doubt about it anymore.

The breakthrough is undeniable

Andrej Karpathy — co-founder of OpenAI, former head of AI at Tesla, Stanford PhD — wrote in December: he went from 80% manual coding to 80% agent coding in a single month. He says AI still makes mistakes. It overcomplicates some things. Consumer LLMs are sycophantic. But going back? No way.

Ryan Dahl — creator of Node.js, the runtime that powers half the internet — wrote on X: “The era of humans writing code is over.” (see image at top)

I’m intentionally not citing the CEOs of big AI companies. Altman, Amodei, Huang — they have skin in the hype game. Karpathy and Dahl don’t. They’re builders. Practitioners. They are selling no AI, they are finding out how to work with for us. They are high level users, looking into the future. When they say the game has changed, we can listen.

You can disregard the hype and still arrive at the same conclusion.

I’m running a free Zoom session next Wednesday, 25 February 2026, 9am Berlin time where I set up Claude Code from absolute zero — empty folder, blinking cursor — to a running PM workflow in one hour. After the call, you receive all the resources and the video to follow along.

Register Here

This is about more than code

Claude Code is the worst product name ever. The change is not for coders exclusively.

And right now, there are two bubbles out there.

Bubble one: People deep in agentic systems. Building workflows, automating the boring stuff, getting results that shock even themselves.

Bubble two: People firing off 20 ChatGPT prompts a day, thinking this is what AI can do. Frustrated by the results. Exhausted by the copy-paste cycles. Rebuilding context from scratch in every chat window.

The gap between these two bubbles is massive. And it’s growing every day.

Two moments that open minds

I’ve seen two specific moments that make people change perspective.

Moment 1: Seeing an orchestrated system in action.

Someone sees what happens when you set up an agentic system properly. From the ground up, with proper file structure, context and your real documents: strategy, interview notes, CEO briefings. No more copy-pasting between 20,000 documents. No more rebuilding your specific world in every chat window and cursing at the chat that it should casually remember. You set it up once. It knows your world. And it just works. Repeatedly.

Moment 2: Seeing the actual results.

This one is was harder to digest for me - and a bit of a soul crusher, honestly that cost me some vanity and time.

The real world example is a PRD, generated in a couple of steps from user interview notes. I assumes it’s generic. Surface-level. AI slop.

And yes, factually, a human could probably create a better one.

But when I start making a fair comparison to what actually happens in real life, it looks a bit different.

First, the AI-generated PRD is much better than you’d assume. Why? Because the context is there. Company strategy, goals, user research, constraints — all of that informs the output. The AI produces something with actual, surprising substance.

Humans could create a better one. But - surprise - they usually don’t. Time and effort. It’s the system, stupid.

What really happens in my life: I ask a PM when we can discuss the next product based on that research. Answer: two weeks. Then in 13 days, the evening before, he sits down and creates a version that barely survives our first conversation. Not great.

But two weeks ago, I already had a good, not great, PRD we could have discussed. We could’ve just started from there. Early friction instead of late mediocrity. Better results earlier, less risk later.

Same story everywhere. Evaluating features. Strategic review of a roadmap. Detecting drift between what the CEO wants and what you’re actually delivering. None of the AI results are perfect. But always good enough to start the discussion earlier and get to the relevant friction early and spot on.

The surprise: AI is better at abstract than you think

Here’s what really caught me off guard. The more strategic the topic, the better AI seems to perform. That takes the last bit of myth and human vanity out of the system.

A lot of the abstract soul-searching - weeks of debating the right wording - is vanity. The minute details make less of a difference than we think. They’re just vibes. The people on the work floor want to know what to do. Indicating the direction is good enough.

As Karpathy says: the main effect isn’t speedup. It’s expansion. You suddenly do things you wouldn’t have done because they weren’t worth the effort before.

That’s exactly what I’m seeing on the PM side. The work doesn’t simply get faster. The scope of what’s possible changes. You can now actually be more strategic.You can work talk to stores more and be more strategic. Everything we ever wanted. “Gestalten statt Verwalten” - my point since ten years. And it’s coming.

In fact, there’s little excuse left.

One hurdle remains

Even when both moments happen — when people see it and believe it — there’s still one last, huge wall that people run against:

Setting up your own system from zero. Empty folder to organized files. Terminal running. First agent executing. Spending that first hour. Getting comfortable. Creating the habit.

That’s where a lot of people are not simply getting stuck, but they don’t even get started.

But here’s the relief: it’s not hard. It’s only unfamiliar.

What this means for companies

Back to the top. The good news: the benefit is mutual.

The company gets more output, better quality, faster cycles. The workers get a skill that will define their career for the next decade.

How often does that align so nicely?

Not enabling your people now isn’t cautious. It’s negligent. The “right moment” was a few months ago. The second-best moment is now.

I’m running a free Zoom session next Wednesday, 25 February 2026, 9am Berlin time where I set up Claude Code from absolute zero — empty folder, blinking cursor — to a running PM workflow in one hour. After the call, you receive all the resources and the video to follow along.

Register here

PMs don’t have enough time, the role is over-defined. PMs need an always on senior assistant. The good news: You can build one. On your own. In Claude Code. You can’t code? No problem.

This article shows you what’s possible and that actually nothing should hold you back.

The example: Roadmap reviews, feature scoring and automated production of wireframe prototypes. All to engage in the crucial conversation early and often.

Meet me next Wednesday, 11 Feb 2026, 9am, Berlin time, to see it live and ask questions.

Register for free here

Short Preview (longer version below)

The Gap

The bottleneck of PMs was never the lack of tools or frameworks or techniques. We get lost in story splitting and the hundredth approach to that, while strategy is lacking due to missing quality time, deep work. AI augmentation through the use of — most of all Claude Code — has come to a point where that bottleneck is self-inflicted. We don’t have to wait for humans taking time for us when the perfect PRD, the final roadmap have been written. We can spar from the get go. Without tools like Claude Code, only using an LLM for chatting, this is tedious. Context has to be set up for each chat anew. The results have to be copied and pasted all over the place. With Claude Code, context is permanent, the tool works on our files and the handover to the devs is exactly that: we share the files.

To show the possibilities, I built such a thing. In four hours. Without knowing how to code.

The system is not the point. The fact that anyone can build one is the point.

The Situation

A PM sits in a room full of opinions. Stakeholders want their feature. The CFO wants margin. The CTO wants debt cleaned up. Everyone has a version of what the roadmap should look like. And the PM is supposed to synthesize all of that into something strategic — with no one around to tell them straight what the roadmap actually says.

No always on senior assistant. No second opinion. No one who looks at the whole thing without an agenda and goes: “You’re overcommitting on Horizon 1. Your capacity is at 200%. And this feature request from sales? It doesn’t even connect to your strategy.”

That doesn’t happen. Because everyone in the room has skin in the game. And the PM ends up navigating politics instead of making decisions.

So I built something more clinical, surgical for that.

What I Actually Built

It’s a system that solves a very specific (well, at least three ;) problem a lot of us have over and over again.

It connects to a roadmap in Airtable, pulls the data, and does a strategic review across a couple of angles. Actual analysis. What are the biases of the roadmap? The system shouts the analysis at me. In two minutes. Not days, weeks. Short-term cash or long-term bets? Am I overcommitting? Ignoring something obvious? And it suggests decisions. Not “consider this” — actual “do this or stop doing that.” The tone is “you should change this in the next 24 hours.” It even remembers the last conflicts and reports progress or decline.

In another flow, it ranks my stakeholder feature requests. Stakeholders can actually deliver requests through a form. (It could also connect to Slack or mail.) Every request gets weighed against the company context, the capacity, the strategic direction. Signal vs. noise. Sorted.

Next level: I can use it as a gating filter. You want your feature on my roadmap? Fine. But first, the system generates an analysis of your idea’s impact. And you — the stakeholder — need to spend a couple of minutes refining it. Based on the machine’s questions (which btw. make a surprisingly lot of sense). If you’re not even willing to engage with an AI’s take on your own idea, the idea is history. No conviction, no feature. That alone kills half the noise before it reaches me.

If a request passes my bar — and I define what that bar looks like — the system generates a wireframe prototype. On the spot. Not next week. Not after a design sprint. Now. I can take that wireframe into a conversation with the stakeholder and change it live, while we’re talking. Discuss, iterate, refine — in real time. In the system. I can even talk to the system to get the prototype changed.

This Creates Quality Time For You

All of that sounds like a lot. And it is useful. But the real impact is simpler.

I get support on the admin level.

The review, the ranking, the wireframes — they’re not final answers. They’re conversation starters. I use them to kick off discussions earlier, with something concrete on the table instead of gut-feel arguments. The human is always in the loop. Always. The AI doesn’t decide anything. It gives me ammunition and prepares me to have better conversations faster, now. Not in two weeks.

An always-on senior assistant at work. It doesn’t decide. It prepares you to decide. No context setup necessary. I actually type “/strategic-review” and the result is here in two minutes. No more copy / paste, upload, and other nasty tasks. It’s just there and knows and ready to help.

Most people still get it wrong about AI in product work. It’s not about removing the human. It’s not. It’s about the human walking into the room with the always-on senior assistant’s notes in hand — unbiased, strategic, relentless — and then doing what humans do best: discuss, negotiate, decide. It’s about more communication, earlier and more frequent.

Augmentation, with the human in the loop, not automation.

The crazy development speed up will make you the bottleneck, even more

If your engineers have not taken over on the right side yet, they will. The speed of software development, love it or hate it, will increase 10x or 100x. For some it already has. The knowledge is not yet evenly distributed. The idea still receives some hate. But economy will win.

This makes our job the bottleneck, even more. We are already running behind for reasons of an overloaded role. It will become worse.

Which is required when the software engineers are becoming 10x faster, and that’s honestly underdoing it. That means: We need to speed up, level up our game and use AI to the max: early, feedback-based on outsourced standard and admin work.

The good news: That’s what we always wanted. More time for the required, crucial conversations, leading to the best decisions.

It’s Not About This System

I built this for me. To solve my actual problem. Not to sell it to you. I can’t even.

It’s about showing what’s possible. Here is your always-on senior assistant you never had. Without an agenda, without politics, without ego. You can build one now. For your context, your strategic questions, your company. Set the context up once and here it stays. Always available. Surprisingly hyper smart. No vanity. Patient to do your admin work for you. The kind of review that used to require an expensive external consultant or a brutally honest colleague — you can get a solid first version from AI. In minutes. And then do what you always should have done: talk to people about it.

Not enough people switched already. It’s hidden in plain sight. Just like a lot of things in these early AI days. If you start now, you’re still early. In a year you will be behind.

The Barriers

The build. Because I know exactly what the first reaction is: “Cool, but I can’t do this. I’m not technical.”

I wrote my last code probably 20 years ago. Maybe more. I’m not a developer.

And I intentionally made this harder than it needed to be. I wanted database access — my roadmap lives in Airtable — and design capabilities — the wireframe generation — in the same system. Just to see how far I could push this. With Airtable, Claude, and Cursor.

Four hours. Build and test. The whole thing.

The only real mistake I made: the AI convinced me to use Python-based API calls to connect to Airtable rather than MCP. I should have pushed back. MCP would have been freer, cleaner. But I trusted the suggestion, ended up with Python scripts I honestly don’t fully understand — and it still worked. I know, though, MCP would feel much more free and explorative. This might sound like gibberish to you, but when you experience the explorative nature of this way of work, you will realize that predefined API calls feel like 2024. Or stone age. (Lesson learned: next time, MCP first. Don’t let the AI talk you into the complicated path when the simple one exists.)

Four hours. Database connection, strategic analysis, wireframe generation. For someone whose last coding experience involved Internet Explorer being state of the art.

That much about barriers. It’s not about “look what I can do.” If I can do it, you can do it. Gatekeeping is over. If a non-coder can wire up a database, strategic analysis, and design generation in an afternoon — the only thing standing between you and your own always-on senior assistant or high-quality insight is the decision to start. You will dance circles around the people who don’t use this.

See It Live

There’s a Zoom cast next Wednesday, February 11th, 9am Berlin time. I’ll walk through the system, show how it works, and you can ask anything. Challenge me. Tell me why it wouldn’t work for your context. I’m curious.

Register for free here

The tools are here. The barriers aren’t. Four hours and a decision — that’s all it takes to stop navigating politics and start making decisions.

→ 10 user Interview notes

→ pain point analysis

→ initial PRD

→ amazon Style Press Release

→ User Story Map

with as much or little human in the loop. I take that more as an example of what is possible in non coding flows in Claude Code.

I’ll demo that live in the live event. Join if you don’t know how to things like that in Claude Code yet. While you can do all that in the chat interface, the results are 1) much better in Claude Code because you can b) structure the input mich more, c) can update that input, d) repeat as often as you like and basically have a focus of e) automating the whole thing as much as you want.

Anyways, overall, the outcome isn't perfect. It shouldn’t be: The human in the loop invited at every step and should be the voice of reason.

But: This flow in Claude Code takes 10 minutes, not 1 or 2 weeks.
In real life, the discussion could start today or tomorrow, not next week - as would probably be the normal answer of most PM / POs I know.

Subscribe now

The question isn't: Does it replace the PM?
It's: What do you do with the time you're winning?

The point isn't that the flow is possible.
The point is the automation with human in the loop.
The repetition.

More info in the gallery below. Including sign up details.

For those who don't yet know how to do this: I show this simple flow live.
Cozy corner: watch, ask questions, get an impression if this is for you.
Wednesday, 28 Jan, 9am, Berlin time. Happy to meet you!

If you already work in Claude Code: Don't come. You'll be bored.
If not: Link / QR code in the carousel and comments.

If spots get tight, practitioners prioritized over non-practitioners.

Short overview video of the flow below.

• from analysing (in this case ten) user interviews

• to creating a PRD out of the identified problems / needs the customers mentioned

• transforming this to an amazon style press release and finally

• an initial user story map.

Short run through (caveat: It’s in German, but YouTube subtitles should work well)

The same thing can ofc be done in Claude Code - the much more prominent tool currently. I am doing a lot of strategy work in Antigravity due to its better built in memory. (Basically Antigravity without a lot of work has a better “understanding “ of drift in intent and decisions without doing a lot of work.) But none of that is needed and the transfer of this “system” to Claude Code would be trivial.

As you see, each step would also be possible to do in any chat interface. But as context gets bigger - in this case in one of the folders, the company strategy, principles, options they are working on etc. are laid down - the more complicated it gets to load the context again in a simple ChatGPT chat interface. Ofc,, the magic of the automation only starts for repeated execution of the same task. So, in this case: new interviews → next run.

Longer version with more explanation:

Important: Of course, the human in the loop can directly change all output documents at all times to inject knowledge and wisdom into the flow.

I will soon also make video of the more strategic work I am doing in these systems. Let me know what you are interested in and what you’d like to see!

And a short version with 4 quick statements from Matthew E. May, Christian Riedel, Mohammed El-Nabulsi and Tim Steigert.

The great people who contributed:

• Matthew May,

• Christian Riedel,

• Mohammed El-Nabulsi,

• Tim Steigert,

• Sohrab Salimi,

• Kerstin Neumann,

• Holger Nils Pohl,

• ✨ Büşra Coşkuner,

• Patrick Sauerwein,

• Konstantin Diener,

• Jan Hegewald,

• Dominique Winter,

• Tim Klein and

• Stefan Roock

Thanks to all.

Have fun with the video! What were your challenges and consequences?

Factors: Macroeconomic volatility or even downturn in which no one decides and buys. This is contrasted with the relentless pace of AI disruption and insanely accelerated geopolitical shifts. This has fundamentally altered the nature of strategy. The default response of organizations is often one of strategy-by-panic: an immediate, existential temptation to give up all former plans and rebuild from the ground up.

Or, the wave of AI adoptions:

• ChatGPT wrapper: “We need something AI.”

• Surprise: No customer value created.

• Realization: Real customer value is more than simply throwing AI on your product.

• The chase: Agentic dream, the vibe coding flash… you name it.

It’s easy to lose your way.

This impulse for radical, untethered change is the source of strategy nausea. A desperate pursuit of speed that ironically results in paralysis: The organization loses its ability to distinguish between signal and noise. Everything is noise. Value is hiding in plain sight, and the goal—who we are—is covered in dust. Hard to remember. The vision is dying on a graveyard of wisdom in our documentation system. Instead of giving direction, we sacrificed our hard-won identity for market fashion and pressure.

The core thesis of resilient strategy is counter-intuitive and dialectic: Strategic speed is achieved not by eliminating stability, but by doubling down on it. To adjust quickly and coherently, you must first preserve and protect your core identity.

Beyond the read: Mastering Strategy Execution

The principles and insights expressed here at “The Intentful Company” form the philosophical basis for my 12-week Blended Learning format: The Strategy Collective.

If you are ready to move from reading about strategy to owning it, the Collective is designed to give you a quick start in execution, deep insights into anchoring this role within your organization, and the path to becoming the go-to expert on this topic within your job environment and career.

The Format: Highly curated content, self-study modules, and small group coaching calls.

➡️ Learn more about the curriculum and cohort details here. If you have any questions on how to be part of the Strategy Collective, simply contact me.

The MOW Framework: Balancing Inertia and Agility

Any good strategy (framework) does this, but the property of balancing inertia and nimbleness is a first-class citizen of my MOW Framework (Markers - Options - Work). It provides a system necessary to manage this eternal tension between organizational inertia and market agility. It segments your strategy into three constantly coherent, interconnected layers, each operating at a different velocity:

1. Markers (Identity and Purpose)

The Marker represents your organizational identity, core purpose, and long-term positioning. It answers the question: Who are we, and why do we exist? Who are we and who are we not? What is our Identity?

The Marker’s most essential property is Inertia (Trägheit). Markers are slow, by definition. Thus, they must be difficult to change, and only adjusted in the face of existential necessity, not in response to simple quarterly market swings. The Markers are your strategic anchor; they are the gravitational center required to ensure all quick reactions are still heading toward the same destination. An organization that frequently changes its Marker is one that has abandoned strategy entirely.

Example: Apple does not change its identity on a yearly basis following some trend. They changed from Apple Computers to Apple once, signalling that computers are not the focus anymore, while becoming a personal device and digital service behemoth.

Markers can easily be understood by looking at a person. What makes me me? I was always a sportsman, MTB rider, runner. My kids changed that and my identity. While I still did some sports on the side, I did not identify as a sports- but as a family man. Now, that my kids grew older, I changed back to sportsman, although on a different level: more focusing on health than performance and competition. My identity defined what I am doing. The ways to express my identity are the options I have. As a sportsman, I now do workouts 5 to 6 times a week again. Habit follows identity. But I can’t follow all of them. I need to choose.

2. Options (Paths and Possibilities)

Options represent the concrete, mid-term paths and strategic bets designed to strengthen or realize the Markers. This is where Product Strategy lives.

In contrast to Markers, Options must be Nimble (Flink). They should be generated and evaluated as a portfolio of potential pathways, adhering to the principle of low downside, high upside. Strategic maturity is profoundly visible in the quality and agility of the Options layer. It involves treating significant resource investments not as locked-in expenditures, but as Real Options—investments that retain the right, but not the obligation, to pivot or scale based on rapid validation.

Hint: Options management well done in hindsight looks like master strategy. In fact, no one creates a strategy that predicts the future, and thus is a five-year masterpiece. Great strategy is always the whole of committing to options in the direction of our Markers, one by one. No one option will be winning. It is the cumulative effect of realizing the right options piece by piece that creates value.

3. Work (Flow and Execution)

The Work layer is the daily, operational process required to execute and realize your current, validated Options. It includes all agile (or non-agile) practices (Scrum, Kanban, etc.) and execution streams.

The primary objective of Work is Flow (Fluss). This layer must operate at maximum speed and efficiency. Crucially, the Work is not simply “doing stuff”; it is the mechanism of execution that validates the Options. Work provides the rapid feedback loop necessary to determine which Option should be scaled up (reinforcing the Marker) and which should be discarded (preserving resources).

Engine of Coherence: The Cost of Incoherence

The MOW Framework makes coherence a first-class system and helps to design and test for coherence at all times. The three layers are not organizational silos; they form a tightly coupled, closed-loop system of communicating vessels.

• Work realizes the Options.

• The realization of Options reinforces or strengthens the core Marker.

Note: The framework is agnostic towards the marker being a future vision or a wish for now on purpose. If you wish to express the wish for change, define your future markers as a friction to today’s state and choose options accordingly. If you want to reinforce who you are, have Markers remain even more stable and choose options according to that.

When the three layers M-O-W are falling out of alignment, when the Work being executed does not genuinely feed the current Options portfolio, when the Options are inconsistent with the core Markers, the organization suffers from incoherence. The employees sense that immediately. The resulting lack of clarity is killing sense of achievement, satisfaction with work and finally denies purpose. This is the root cause of the Strategy-Execution Gap and results in wasted resources, team fatigue, and an inability to respond effectively to external challenges.

Strategic discipline means meticulously protecting the slow-moving Markers from direct operational influence and ensuring dynamic alignment between Options and Work. Thus your organization gains the fundamental capacity to handle market disruption without losing its identity, ensuring that strategic speed is always true to the ultimate goal.

The idea of a stable core enabling nimble choice of actions is heavily influenced by the brilliant concept of Pace Layering by Steward Brand (which may be one of the next topics).

In business, avoidance is the silent, pleasant killer.

Avoidance defined

Avoidance is: Avoiding the hard discussions, the friction necessary to create clarity, for the sake of social peace. Avoiding conflict by playing it “nice.” Avoiding the awkward moment of breaking with what feels like chill and peace, when a decision should be made.

Being part of many leadership groups I know this awkward feeling too well myself: leaving a meeting all smiling, drowning pseudo-agreements, and a vague sense of alignment. While each one goes back to their department, telling their story of decisions that were made, keeping up their own narrative. Now we have 5 truths and 5 narratives. Let’s have fun by extrapolation the non-agreements to our whole work force. A week or a month later, disaster strikes and reality brutally shows: we were not aligned, we avoided the clarity, because it felt better, the vibes felt more chill.

Avoidance felt peaceful in the moment. But the corporate equivalent of not opening your bills doesn’t make the problem go away. It just boomerangs back at you harder, later.

Avoiding avoidance with cadence

Of course here I need to refer back to the only silver bullet in my life: cadences (read about them more deeply in “Cadence or Die”). Cadences are the best medicine against avoidance. The harder avoidance, the faster the cadence, the more frequent the meetings.

And remember: Cadence meetings are not vibe meetings. They are not status meetings. Not therapy sessions for leadership anxiety. Cadence meetings are decision meetings. Repeat after me: cadence meetings are decision meetings.

They exist for one purpose only: to create clarity. Nothing more, nothing less. Clarity for everyone in the organization.

Everything else - exchange, monitoring, status updates - can exist as a part of the meetings but for the sole purpose of supporting the only outcome that counts: decisions creating clarity.

Keep your sensor systems up, and when the unclarity triggers are perking: clarity must be rebuilt. But motivational speeches really don’t help at all. Discipline does: structure and rhythm. The harder the problem, the more frequent the meetings. The deeper the avoidance the more radical the solution.

Why not have daily C-Level meetings if the issue has deep roots?

It doesn’t feel nice, but remember: no one’s to blame, the high cadence is not punishment but a solution.

Decisions, not tasks

One of the most common misunderstandings is that cadence meetings are about tasks. In these meetings, often people are waiting to get organized. Nope!

These meetings are not about tasks. Tasks are a downstream problem to be solved (maybe by the same people, elsewhere): projects and programs, which are reactions to decisions.

In cadence, we deal with: decisions → expected outcomes → responsibilities.

Once a decision is made, execution begins elsewhere (but stays connected like communicating vessels). We will watch outcome and stay informed but execution is not the issue we manage here.

That’s how clarity travels through the system without being diluted.

Avoiding avoidance

Some things I think about when trying to counter avoidance

1. Short cycles force contact with reality.

Avoidance is amplified by long gaps - where stories rewrite themselves.

High frequency kills that drift. Every well conducted meeting (remember: decisions, not vibes) hits the participants on the head like a hammer. It’s not pleasant, not supposed to be. It just works.

The harder the avoidance pattern, the shorter the required frequency. It needs to feel, at least slightly, annoying. Otherwise, we’re back to avoidance and giving it excuses.

2. Decisions as the only output.

Every cadence ends with decisions made, deferred (explicitly), or killed.

Anything else - “good talk,” “great discussion” - is just noise (ironically to be avoided).

Closing with decisions is the habit we create.

3. Repetition exposes inconsistency.

Saying the same things out loud every week reveals drift. Repetition often feels stupid, especially to the one repeating. Until there is a decision and the narrative holds, we repeat and reframe until we have clarity.

4. Documented memory prevents the narrative and goal posts from moving.

A written recap is the backbone of alignment and the required one shared truth. (No misunderstanding: disagreement is welcome, friction is needed but with the goal of decision and clarity.)

No write up → multiple truths → everyone tells their own version at home.

Documentation isn’t bureaucracy and can be lean - but it’s required and countering myth.

5. Predictable confrontation reduces fear.

When these meetings are the place and time for friction, bringing the heat is not exposure anymore. It’s a weekly practice that is expected as part of your work.

Cadence normalizes required healthy conflict as a routine for hygiene.

Thus the opposite of avoidance is not aggression but rhythm.

6. Cadence replaces “niceness” with clarity.

“Being nice” protects fake relationships by protecting the illusions of alignment - because it feels good, although the receipts are waiting.

“Being clear” protects real relationships by protecting truth.

Cadence operationalizes that difference.

7. Cadence as mirror of intent.

If a leadership team can’t keep up the decision rhythm, it’s not simply an alignment issue. It’s a leadership issue of dealing with reality.

Avoidance hides intent. Cadence brings it back, and puts it to the test every week or whatever your cadence is.

Avoidance wins when cadence disappears

Avoidance is not a moral failure of leadership, especially not of the individual, it’s a systemic failure of not setting up the right structure.

With a lack of a designed rhythm that forces decision and feedback, avoidance naturally fills the void.

Entropy always rises without energy being fed into the system regularly. Thus intent decays not because people are stupid or ill intended or simply change their mind, but because they stop meeting with enough rhythm to maintain the shared intent and keep it clean.

Done right (and I’m not saying it’s simple) cadences are more than a management technique. You can make them your company’s heartbeat.

It’s hard to do, it can’t be outsourced and it can’t be faked.

The slide back effect when avoidance takes over, makes companies feel aligned rather than being aligned.

Which is when you start losing your strategy until only reaction is left.

You feel the insane drop beneath you, the planks are wobbling, cables are swaying, wind is catching you. Your soul and body are exposed. Fear is 100% natural. Still nearly everyone makes it across and once you’ve done it, the fear is replaced by familiarity. The exposure is normalized.

That’s where we are with AI. It feels dangerous, unpredictable, full of risk. FOMO and urgency escalate. But then, step by step, it becomes normal.

While the last two posts laid out the context of wild predictions and opened up the parallel to 1995 – pre the Internet revolution – this post is about that paradox: why awareness is a must, but panic is useless. Why hype and prophecy don’t help, but hands-on learning does. What helps is trusting your acquired foundation and being hyper aware of new options and grabbing some once a good one comes around the corner.

Stuck between hype and disillusion: Discovery time, not ROI

The numbers seem damning: According to most of the studies, the value creation around AI projects in companies fails in 80% – 95% of cases / projects. Some people think that’s a terrible number. I think that’s normal. People are learning when and where to apply AI step by step.

The first wave was simply using LLMs directly and wrapping a conversational interface or a chatbot around whatever service or product one provided. It’s the most straightforward, most direct way. But most of the time this simply ignores the customer: Does the customer want to have non-deterministic behavior, does he want a conversational interface? Does it make things better or worse? Or does it solve our own problem as a provider, that we actually don’t really know what the customer wants and think the LLM will figure it out and thus customize our mass product for our customer. But that’s not how things work. It does not solve a new customer problem. Mostly it solves an old problem, but worse. Gartner sees this wave of GenAI already on the “Trough of Disillusionment.”

The hype thing these days – still on the up – are agentic systems. As I said: Agents always follow quickly, because it’s a very tech idea. We can do it, so we build it and it satisfies the tech world dream of building autonomous machines. But for what? While this might open up new use cases, it will certainly not satisfy end users’ needs, given the limitations of LLMs listed above. Except in non-mission critical contexts. But then, it’s also really complicated.

The topics “agentic” and “AI-ready data” (being the basis of the work of agents) are listed in the phase of “Peak of Inflated Expectations.”

Vibe coding is already declining. And while the talk of the town is getting rid of those nasty human devs and customer agents, reports of what’s working successfully and sustainably are not overwhelming. A ton of CTOs are probably currently recalculating their 2026 budgets.

Interlude: price of tokens?

A funny, not often talked about side topic that I really like is the price of tokens. Currently no one selling tokens is making money off them. All of them are burning money and no one has a clue how OpenAI will ever become cash positive. The current business model is hope, and I don’t mean this cynical or negative. We need those pioneers. But in my fantasy, the day will come where a) those providers will realize that there is a certain vendor lock-in and b) that they could raise the prices for their tokens. Just like in cloud computing, the cost will rise. In cloud, companies first found that having people simply trigger the next instance and all that dynamic being unmonitored had a huge negative effect on cost (COGS). Providers realized that packaging and bundling and other ways of nifty price increases are a big deal. The same will happen to the price of tokens once the lock-in is sealed. Let’s see what this means for the millions of tokens that companies now blow liberally through the ether.

AI won’t go away. Just like the Net in 1995. The problem is you don’t yet know what works for you. Just like us in 1995. The way to deal with it is: go play. It is 100% essential that you make your whole company AI knowledgeable. It does not have to be very directed. You just mingle in AI and observe and become AI-literate. If you see one, commit on a small bet. And another one. You just need to show up, stay close to the development. You cannot miss it.

Three steps to keep up

1 – Immerse the whole company in AI

Involve the whole company in understanding AI. From payroll (“how can we reduce unnecessary manual routine labor?”) over marketing (“automated market and channel tracking?”), support (“which tickets are repetitive enough for AI to handle and can engineering help us automate?”) to finance (“in which areas of reporting can AI’s pattern recognition help us without dangers of hallucinations?”) and engineering (“how can we support other departments with our tech knowledge in reducing toil and how can we responsibly handle code with the support of AI, where does AI completely change our technical options?”).

2 – Treat it as discovery, not instant ROI and extraction

It will feel unsatisfactory. To some it will feel too fast, to some too slow. Too extreme, too undecided. It doesn’t matter too much. By focusing inside on reducing repetitive human labor first, you will instantly see some very pragmatic benefits and learn the technology and also its boundaries hands-on rather than from paper or LinkedIn half-knowledge.

By immersing yourself, be highly aware of bigger options to use your acquired knowledge towards outside-facing options: to really improve your customers’ lives.

This requires a strong stance on the next point:

3 – Stay anchored on your original vision and customers

All of this works only if you are stable in your vision and strategy. Stick to your vision. Stick to your niche, to the customer problems you want to solve. It’s tempting to get distracted by new options. It’s expensive and mostly damaging to simply switch the problem space. Your customer knows you for a certain problem you are solving. Stick to your long-term goals and be creative on short/mid-term options where there is an obvious bet. Stick to the rule that a good option has huge upside and low downside. Which firstly means that it can’t sink the ship. Don’t be blinded by tech optimism and change long-term trajectory for short-term enthusiasm-based tech solutions. It never pays off. Discipline is the word. It now pays off to have been explicit in your vision and what makes you different from the competition. Don’t surrender those past efforts.

Stay aware, act normal

Those who had the first successes after 1995 did not know what they were doing. They totally fulfilled the

“Stockdale Paradox”: “confronting the brutal facts of your current reality while maintaining unwavering faith that you will prevail in the end”!

Another one of those dialectic truths. Go all in with heads off, not knowing the outcome but hoping for the best. It sounds like handwaving and haha-ing our way through life, but remember: there is no certainty except: AI is here to stay and you better learn to co-exist. But there is no direct way to making it a success. You need to learn and be aware.

When the only certainty is uncertainty: Don’t listen to the prophets – instead immerse yourself in the uncertain reality (you know it best), look for small bets, fast learning, and the humility to be wrong. That’s how revolutions are not only survived – but used for your good.

In part 1 of this mini series, I laid out the current state on AI predictions. They not only vary wildly but often contradict each other, going in opposite directions.

That is in part due to invested interests of some actors. But it’s also because the future of AI and its impact on society is unknowable.

Yet. As the rise of AI is often compared to the last big revolution — the Internet — I reflect back on how that time felt. I was deeply involved in some pioneer work back then. My angle is subjective, but it might reveal a couple of things:

It was all done a) in the moment, and b) it took longer than you might think to go from beginnings to explosion. And: after the explosion (and after recovering from the dotcom bubble deflation), everything was different and looked so clear. It wasn’t clear at all before.

Here we go:

Time Machine → 1995, “beginning of the Internet”

“Those who cannot remember the past are condemned to repeat it.”

The last revolution some of us might remember is the arrival of the Internet. I am old enough to vividly remember it and that might also be the reason why some of this reads like an “old man rant.”

I still remember reading a book about all the Internet protocols before HTTP. It was wild. You had finger, of course NNTP (newsgroups), WAIS for some kind of search, telnet, Archie (!), WAIS and for each of them you were required to use a different “program.” While reading the book I dreamed of an everything program that served all these protocols. What feels like a couple of nights later, HTTP (invented in ca. 1989, 1991 first implementation with a server (httpd) and a browser, 1993 Mosaic released, mid 1990s “explosion” of websites, arrival of Netscape, Amazon, Yahoo launch …)

At the time, most of us in our university institute were working on what was an early version of Siri. It was kind of successful but also practically unsatisfying. The theory worked but the limitations of “compute” at the time were so tight that it was a good demo but that’s it.

With the Internet coming around the corner, we tried to sort out more practical problems from thereon, some of them might seem absurd in hindsight, like: A project I was working on tried to solve the problem that you just don’t know what’s behind an internet link. Once clicked, what would happen? It seemed like a crazy dangerous remote control on the negative side, insane access on the positive side. Would clicking that link crash the universe, launch a nuclear bomb? Or would you rather see some fancy pic, read the latest news? Probably someone had clicked that link before you and might tell/warn you what would happen. So we built a system which enabled users to “annotate” links so that you wouldn’t be surprised. Of course this was an idea from academics for academics and it never took off.

We had no clue about how value would be created

Serendipity stepped into the room in the form of our Chinese colleague Ben-Hui who complained about the first existing search engines not indexing Chinese documents. So he built a robot system to retrieve Chinese documents. For that to go mainly after Chinese docs, another colleague built a language detection based on Markov Chains and yet another one built the indexer etc. After a while it was figured out that doing the same for German documents would actually be a good idea, given the fact that we were located in Germany. That was the FLP search engine which became flipper which became fireball. Fireball then became the springboard of a company which those involved with the first version of fireball founded (except Ben-Hui who was employee Nr. 1). It was a wild time and the people who engaged us to build the thing for Gruner & Jahr swapped over to AOL Germany. And here we were, building the whole front and backend for AOL Germany (yes, the famous Boris Becker “bin ich schon drin?”-campaign, and then as well for Netscape Germany. (We also received “Nie wieder Nachtschicht” T-Shirts as a present after successfully delivering the whole machine. We also forgot to configure the caches well, so after the press conference, the whole site went down, we switched back to the old site and then got back to our new fancy site a day later or so, well …)

Random Agent Anecdote: During that time I left that institute for another one for maybe 2–3 months and engaged in the next big hype of the time and helped build a platform for mobile agents. Something that sounded really great in theory but no one actually needed. In Berlin alone at the time there were three “startups” (that name didn’t exist yet) focusing on building mobile agent platforms. I don’t know what happened to them, but the idea died out. It basically came from the fact that Java (the programming language) had a concept of “mobility” built in that allowed you to send executable software somewhere else, have it executed and come back to you. I am just telling this because it seems that “agents” are always the second thing that comes up …)

It was the wild west. Just like today. Very few people, though, ran around with certainties. To us, the world was like a candy store. Designers turning their work from print towards the Internet built expensive “agencies” with a multiple of our daily rate — we were just dumb developers, the nerds. No one understood at all what we were doing. We were basically useful idiots in the business game. We heard that the Samwer brothers had some other people a couple of blocks further develop what would become Alando.de, the German eBay clone that eBay would eventually acquire to start eBay.de. I can’t even remember if we were asked at all to get involved, but talk in our hallways was that we were totally not interested. The Samwer’s did not speak our language to say the least and being really pragmatic dev guys, we thought simply copying something is basically very stupid and not value generating … haha.

Meanwhile companies like mobile.de and autoscout24.de (car classifieds), immoscout24.de were founded. Really simple lookup-stuff. One of them was also acquired by eBay, the other ones created their own holding structure.

Very much later, models like PayPal and Skype were created. Both acquired by eBay as well. PayPal was bought for ca. 2.5 billion. At the time a record-breaking internet acquisition and eBay was laughed at a lot for that acquisition. Especially as it failed to fulfil the promise of “connecting buyer and seller even better.” (They never even tried.) But funny enough, it was sold for a multiple. Not a great deal, but far, far from a loss.

We had no clue how work would change

I was mainly heading the development that built all the stuff for AOL / Netscape. All of a sudden I had a beautifully mixed role of leading a huge room full of developers, getting a daily call from the client’s project manager (Walter!) at 11am. “Project Manager” was one of the important titles at the time. There was no “Product Manager” or PO. (I was also years later hired into my little part of the eBay universe based on my reputation as a project manager for whatever reason. Only to get rid of the whole project management department a couple of months later.) The first book on Agile we read and that delighted us was by Kent Beck on Extreme Programming. When Scrum came around, we said it’s like XP, but for managers.

Of course it was a huge problem trying to figure out what AOL users would expect when logging in. Some things were obvious: News (one of the problems of the time was to deliver the news quicker than others. When the Concorde disaster of Flight 4590 happened in 2000, the cynical discussion in our circles was: who was technically able to deliver the news first, incl. pictures, hopefully videos and all). So, we developed a lot of gimmicks to see and test what would stick. At the time, what stuck was pretty basic: Weather, latest news, hottest news, all of that backed up with images … We tried to learn more on figuring out what people needed and little literature existed, next to “requirements engineering.” Software development wasn’t really obsessed about the user at the time.

Predictions would have been wild

OK, let me stop. Here’s the point. At the time we were simply too busy “inventing” the Internet and creating the opportunities. None of us even predicted the crash of the bubble in 2000 / 2001. We just went through it.

Yes, we were looking for ways to get closer to a customer to learn what he needs. Yes, we were surprised to meet people who had studied business and had MBAs who became our clients. But none of us saw the role of the Product Manager coming.

2008: The first books on Product Management

And, surprise, in our space, the first relevant books on the topic were certainly:

• 2008 - Marty Cagan: Inspired: How To Create Products Customers Love (At the same time I was working in the eBay bubble and I am quite certain that what is described was not how eBay worked. Anyhow, it was a great book and it helped us to have more classical business people and project managers accept basic principles of (even agile) Product Management, Customer Focus etc.)

• 2010 - Roman Pichler: Agile Product Management with Scrum: Creating Products that Customers Love. Roman also published a book before in 2007 that was on “Agile Project Management” but already with a focus on product.

Contrary to what people tell today — that Product Management was an established job or role since ages: nope. Not in our field. In hardware, in production, for sure. But we had to discover that first. Even to the point that in 2012 I was so unsatisfied with the state of Product Management education and coaching that I founded my own company in that field. We also heard reports from the bigger companies in the US that similar roles existed, that much is true.

To give you a bit of a timeline of the role of the Product Manager in software/digital contexts:

Early origins in software

• 1970s (IBM, HP, others): Roles existed that mixed product marketing and technical specification, but not yet called “product management.”

• 1980s (Microsoft): Microsoft created the Program Manager role (distinct from Project Manager) around the mid-1980s, explicitly modelled around P&G’s brand managers, but adjusted for software: PMs wrote product specs, translated customer needs, and sat between dev and marketing. By the launch of Windows 3.0 (1990), Program Managers were central at Microsoft.

• 1980s–1990s (Silicon Valley): Other software firms (Oracle, Intuit) began using “Product Manager” as a formal role, often more business/customer-focused than Microsoft’s “spec-owner” model.

Mainstreaming in digital

• Mid-1990s (U.S.): With the rise of the internet, Netscape, Yahoo, and Amazon adopted PM roles. By ~1997, “Product Manager” was becoming a recognized tech title in Silicon Valley.

• Germany / much of Europe: The role arrived later. In 1995, German software houses usually had “Projektleiter” or Produktmarketing, but not “Product Managers” in the Silicon Valley sense. The formal title/product discipline only became common in Germany around the early 2000s, spreading with the dotcom wave.

So, while the software PM role emerged in the 1980s at Microsoft as a Program Manager and spread in Silicon Valley by the 1990s, in Germany and Europe it was still mostly unknown in 1995 and the concept only became common in the 2000s, with the arrival of internet startups.

Future, hidden in plain sight

Although we were working on the things that would later work in the Internet, it had not yet crystallized for us to be sure and get a feeling of knowing.

It took a lot of serendipity and work and observing to lead us from annotations to search to content to news to e-commerce.

No one was dead sure about e-commerce becoming the thing. At least not about how huge. We had doubts. But someone had to do it. And as it was clear it had to be done, there were pioneers going onto exactly that bet. And the burst of the dotcom bubble expressed that much-needed path more clearly. For some bigger bets, it was too early. When we saw something we found most of it interesting, but there was no precedent which gave us a sense of the potential. And the potential could not be measured in the real-life analogue (eBay — classifieds).

Everything was a bet with open outcome. We also saw a lot of investment going on around us. And there was little correlation between investment and success. In fact, we saw huge investments fail and we were involved in the software development of some of those platforms, with and without success. There was no pattern.

The Push required Technological Advances

From static to dynamic web

In hindsight, though, it is clear and obvious that also some technological progress beyond infrastructure was required to provide an experience that worked for people outside of our nerd bubble.

HTTP was the basis, mass communication and ubiquity of static web pages.

Developing all sorts of use cases that make sense as static web pages.

Search, News. Everything video was still complicated, because of limited bandwidth and infrastructure. The easier things were successful at the time, because that was what worked under these conditions. What worked was mostly not a really great wild idea, but some projection of what worked in the real world, filtered through the then existing internet capabilities. Also anything classifieds, long tail, short tail, whatever dimension up and down.

A lot of things that we and others tried did not work because the idea wasn’t great but the experience sucked. When JavaScript and Ajax came around, everything changed. It started part two of the gold rush and finally the Internet Bubble was fixed again.

All of a sudden, dynamic pages enabled us to build actual applications in the browser. The stateless HTTP protocol was not limiting us anymore. The question if it makes sense to sell shoes, fashion, all sorts of things that require more of an experience, went away. As Ben Thompson of Stratechery would say, the point of integration moved from the operating system to the web browser.

Google went all crazy when they figured that out. They also solved cheaper hosting and storage. This helped them to go all in on disruption “of the margin of others”. They threw all kinds of dynamic apps like spaghetti on the wall to see what sticks. And following their philosophy that money is an unlimited resource, they gave it all they got: Free mail with a ton of free storage? No problem. Free maps, with better resolution, navigation and what have you? Disrupting the more traditional mapping services that still tried to figure out how to move to the net at all? Why not? Their own browser to become independent of MS? Google Wave, then Google Docs? Sure thing. At the time most verticals were afraid that their margin would be Google’s next chance.

I could go on and on. All I want to say is: None of this was knowable or predictable. As much as it is clear in the rear mirror.

Back to today, Back to AI predictions.

I provide all this context to explain how early we are in the journey of AI and how predictions still need to be off. The predictions are so far spread because the future is so uncertain. And it does not make a lot of sense to rely on a specific set of predictions. That angle is too narrow. What we can derive from the past, though, is what kind of acting makes sense in unpredictable times.

On the question if “will there be jobs left” it would be super soothing if just someone knew what’s coming. But no one can. The answer depends on whether AI follows the path of all big innovations until now or if it is the black swan that behaves totally differently and finally breaks the matrix.

How innovations until now always (!) created more jobs in the long run was as follows. The innovation (book printing, electricity) gets cheaper over time. Thus it becomes more accessible. This means it can be used a lot. Because of that, higher level systems can be created on top of that innovation: Light on top of electricity, super expensive in the beginning, unimaginable that the whole world would be illuminated through electricity. Books get cheaper: Knowledge and education becomes democratized, everyone gets smarter, which creates a whole new knowledge industry and finally advances in civilization. E-commerce is discovered on the top of the “Internet” and enabled by dynamic web pages.

Currently, AI is the infrastructure. The mistake that most pundits make is to confuse that with the higher level, value-creating system and predict based on AI. That’s why based on sheer opinion and imagination, the interpretation of AI’s impact is net positive and enthusiastic or net negative and dark.

Bets on value-creating systems are relatively primitive and do not solve the issues of LLMs: Connecting the LLM to search, e-commerce etc. That’s just a faster, slightly better internet. With some risks on top. Agentic systems: That’s just a couple of wild LLMs with all the built-in dangers going wild. There is not a lot of new value generated. Most is just replacement or speed up.

Maybe the value-creating system is already around and we don’t see it. Hidden in plain sight. Just like before the dotcom bubble. Maybe we only need a tiny bit of tech innovation on top, like Ajax, to get to a breakthrough.

Once the breakthrough is here it will be blazing fast, an explosion.

This concludes part two, in which I try to lay out that we are re-living 1995 and not yet post 2000. The next part will cover what to make of it. What are reasonable and responsible ways to act in such a time of uncertainty?

In 1995 we were busy building the plumbing — and had no idea what would run through it. That’s where we are with AI today.

The topics are

• why predictions on the endgame of AI are currently futile and thus, why so many false prophets are around.

• how I compare this to making Internet predictions in 1995 (which was useless) vs. 2000 (not useless) and finally

• what does this mean, how can we responsibly act as a human or a company in those times.
  
  Without further ado, here we go!

The Golden Age of Wrong Prophets

There are a lot of experts out there with a lot of predictions and advice. Where will AI go? How will it change employment or not? How does it change your role in your company? Etc.

What I am saying is the following:

Those who think they know everything, know nothing.

It’s just not the time for certainties, as uncomfortable as it may be. But thinking in certainties will lead you in the wrong direction. To explain a bit further, I’ll later go back in time, way back … to 1995.

My point is that viewed in parallel to the “development of the internet” it’s 1995, not 2000 - or even 2005 - and that means: we know nothing yet. Especially the prophets. So better not listen to them.

To also make this a bit of constructive and not simply “we have no clue, so duck and cover”, I’ll also mention what good practices are in times of “we know nothing”.

Let’s go for the ride!

It drives me crazy

It’s one thing that a ton of people that can read the letters “A” and “I” are now all of a sudden experts in AI (even though they don’t know the source of hallucinations in LLMs or why they can’t go away (at all)). Worse, there are also experts that give you generalized advice on how your role, your job will change. And what, following their advice, accordingly you have to do and change. Some of them are happy to sell you a freshly curated “AI for X” program. Some are simply out for reach and influence. The LinkedIn post hastily run through an AI of course. Automated probably. You sense it. No actual knowledge required. Where there is a gold rush (although as with any gold rush - and this is just a gold rush for some - the crooks are not far off the trek to the mines).

Disclaimer: AI is great! This is not to criticize AI as such, but the social systems around it. I love AI, I use it all the time. This text is simply to give context and understanding to the hype around. To be critical of AI and embracing the current state of AI and using it is not mutually exclusive. I know it’s tough to get the nuances across and this not to read “AI sucks” - but I genuinely embrace AI.

State of Predictions

It’s wild, to say the least. A little zoom into the range of predictions floating around:

• As a Product Manager you do not have a chance to get another job without being proficient in vibe coding.

• There will be no more Product Managers in n years

• The Product Manager will become a technical role and morph with the developer role

• We will have 99% unemployment by 2030.

• As any other innovation before, AI will create new jobs and creative opportunities.

• If you don’t invest now, it will be too late.

• The bubble is near.

• SaaS, especially B2B: From “finally it works” to “the SaaS model is over, everyone can easily build their own applications”.

• it goes on and on …

Anecdote on experts: Before Nate Silver changed his business model from Baseball career/value predictions to politics and election prediction, he studied if experts actually give good predictions. He watched hundreds of interviews and analyzed them in hindsight and the basic outcome was: asking an expert is like throwing a dice and pundits have no better rate of successful predictions than non experts. That told him everything he needed to know to dare the jump into politics. At least he had data and a model that worked in one sector. And that was before the “LinkedIn-I am-an-expert-since-two-months” area.

This should give you some background on the reliability of the predictions on AI and what I documented above shows the “dice” element: A lot of those statements are mutually exclusive. They can not all be true at the same time.

Interlude: Limitations of the technology

While trying to squeeze the lemon, most pundits casually forget to mention the current state of technology:

LLMs, the backbone of the current wave, have the following unsolvable issues or “features”:

Unsolvable issues / features:

• Hallucinations: LLMs make stuff up, basically to fill the void in the probability distribution. This is the result of the core architecture of LLMs and can not be solved. (Yes, I know about the paper that on first look reads like this could be solved (and by the right experts it is also cited as such), but all the paper describes is how hallucinations can be better mitigated.)

• Non-Determinism: LLMs inherently produce non-deterministic output and this need not be seen as a problem, depending on the use case. Guidelines might be: the more open ended a task is (writing copy, storytelling, emails, creating images) non-determinism is potentially a feature. The more regulated the use case or context is, the bigger the issue: regulated environments, medical analysis (the great success cases you hear about in medical analysis, diagnosis etc. are in general not LLMs but specific, highly specialized more classical ML/AI solutions, etc.) If you are a bit more of an expert, you might have heard about the temperature setting in LLMs which dials in the “entropy” aka the level of non-determinism of LLMs. But setting it to zero, does not mean determinism.

• Hallucinations and Non-Determinism: A huge part of the appeal of LLMs is actually based on those two properties. LLMs without hallucinations and on determinism would very, very often answer with “I don’t know”. While these properties are not built in intentionally, what they provide is the core of the general applicability of LLMs and as such are the basis of their success: anyone can ask anything and get some kind of a satisfying answer. The more non-determinism and hallucinations, the less there would be mass appeal and a sensation of “this helps” and surprise and anthropomorphism (”oh, this talks like a human”). It is a business decision regarding mass appeal to intentionally make use of hallucinations and non-determinism on a certain level, but both can not be reduced to zero.)

• Prompt injection: It is very easy to influence an AI’s output in the prompt. You have certainly realized that AIs tend to approve of your opinion. It goes further. You can of course “dictate” or at least heavily influence a certain output. Cases are documented where applicants hide a message to potential LLMs used in the screening process to prioritize their CV and put it closer to the top of the stack. While this is a relatively harmless example, you can easily imagine scenarios which are not harmless at all.

• Training data leakage

• Bias inheritance

• Energy costs

• Copyright issues

• … the list goes on and on.

Go ahead and use AI to your will, but know what you are using and if you want to bet your existence or company based on these boundary conditions.

Based on this, the experts cited are not that much to blame for the fuzziness of statements. We can very well blame them for blasting out their opinions as facts, though.

And that’s why the wild predictions about AI today remind me a lot of the internet’s early years. To see why, let’s rewind to 1995 … in the next part … hope to see you there.

Before big workshops (a concept I don’t really like, main reasons: height of falling, lack of emergence), everyone comes in thinking they are the ones having it all figured out, while the other ones ....

The workshop starts, the room is full of performative posture - the opposite of clarity.

This changes everything:

The right facilitation sets a different tone early that changes everything. Try to shake up the room and have them bath in the complexity and uncertainty.

“Today we don’t show how much we figured out.”

“Today is for realising that none of us have fully figured it out - instead, we’ll figure it out together.”

“Then we commit. Together.”

How it works:

It breaks vanity and puts the complexity of the task in the center.

It replaces silent guessing and implicitness with shared exploration. It changes form “everything is my head,” to everything needs to be explicit and shared openly to come to a solution.

It sets an enabling environment which lets friction, discussion and decisions emerge, in shared ownership. It creates lightness that replaces the silence and pretending.

This move doesn’t take time.

It might take guts.

That’s my idea of an “ice breaker” but not the tree-hugging, feel good ones.

In the end it creates a solution shred and endorsed by all. A good sign is: No one can remember who contributed which part of the solution.

Every company strives for direction, but what is it actually driven by? Beyond the obvious mission statements and quarterly goals a powerful force is hidden. This deeper concept, which I call Intent, sparked two crucial questions in last week's live Substack call: what is it, how does it differ from traditional strategic terms, and can it ever lead to negative outcomes?

More Than Documents: Intent as Your Company's True Drive

In the complex environment of "company life" and especially of corporate strategy, ambiguous, overloaded terms like "vision," "mission," and "goals" are required elements. They are intended to meticulously lay out what a company aims to achieve and where it's headed. Yet, my conclusion is to position Intent as a concept above all others. I see it as the powerful, dynamic force within the organization, way beyond mere written statements – which are still necessary and very helpful – to define a company's true drive. But what exactly is this "intent," how does it differ, and what separates its empowering influence from a potentially toxic one?

A Step Up From Backstage: Embracing the Elusive Core of Corporate Drive

I see Intent as the more ephemeral and, if you like, emotional aspect, while vision, mission, goals, or even my own "Markers" are more formal and really explicit.

Imagine a musical score – precise notes, rhythms, and dynamics, precise to the note. The composer tries to express what’s in his head and his imagination by use of a very formal language. He knows he can't express everything, but at least the formal “correctness” of what he hears. He knows and suffers from what is missing in his transcription – the intrinsic, unavoidable gap between the formal score and the ephemeral emotions, soul, and creativity it tries to express. While he might be in awe of what a master can create from the sheet, he also fears the limitations of formal notation to capture his full artistic intent and spirit. While a recording would offer ultimate precision, it wouldn’t scale for an orchestra, which requires a more formal, collaborative guide for its sub-elements in the process of “studying” a musical piece. The score is a very conscious choice, a very conscious compromise that is required to make the music accessible to more musicians and listeners. This is akin to a company's vision, mission, and goals: explicit, written, and clear.

Now, imagine the interpretation of that score by a brilliant orchestra, loading it up with emotion, nuance, and a driving purpose that isn't explicitly written on the page. This is where "intent" lives. That intent being ephemeral also makes it so vulnerable.

Thus, in our business context, "Intent" can be defined as:

• The Underlying Purpose and Desired Outcome (The "Why"): Beyond the what (goals) or where (vision), intent goes deeply into the fundamental reason why those objectives matter. It’s the core reason why anyone wanted to found this company, to have this impact on the world. It's sheer core motivation, the driving force that fuels all actions.

• Aspiration and Ambitious Direction: Intent often points to an audacious, challenging future state (or even better, in idealized design: a better current state) that stretches beyond current capabilities or immediate plans. It's about winning competitive battles, achieving market leadership (winning in Roger L. Martin’s Play To Win framework), or even fundamentally reshaping an industry.

• Emotional and Intellectual Energy: Far from a passive statement, intent is charged with commitment and drive. It's the emotional and intellectual force that mobilizes individuals and the entire organization, a deeply held conviction rather than just a strategic declaration.

• Implicit Guiding Principles for Action: While vision and goals are explicit, intent often implicitly guides daily decisions. It's the "spirit" of the strategy, allowing for improvisation and adaptation. When individuals understand the core "why," they're empowered to determine the "how."

• Focus on Continuous Improvement and Adaptation: An intent-driven company is inherently dynamic. Its underlying purpose pushes it to constantly learn, adapt, and seek new ways to achieve its core objective, even if the specific pathways evolve.

Cultural Depths: Where Intent Hides in Your Organization

This understanding of "intent" finds a direct parallel in Edgar Schein's levels of organizational culture. Schein describes that culture exists on three levels:

• Artifacts: The visible, tangible elements (e.g., office layout, dress code, symbols). These are like the explicit "musical score." Consider a company in Hamburg whose outstanding office culture was so drastically expressed in its artifacts that visitors instantly 'felt that difference' upon entering the office. This level of culture, while impactful, in itself doesn't guarantee long-term success.

• Espoused Values: The stated beliefs and norms (e.g., mission statements, company values, philosophies). These are the declared interpretations. Required: probably, weak on its own: for sure. Exhibit: Motivational posters in companies are on this level. They can easily come across as very cynical, as soon as there is even a tiny gap between words and action.

• Basic Underlying Assumptions: The deepest, often unconscious, taken-for-granted beliefs, perceptions, thoughts, and feelings that truly guide behavior. These are rarely discussed, are difficult to observe from within, and are the ultimate source of values and actions. This is the realm of the intangible and tacit. Which also leads to myths like “you cannot influence this” or “you can break it by writing it down.” But that’s just bad handling and a weak understanding of this concept.

Because artifacts and espoused values are so explicit, companies often over-index on them, striving for perfection and creating theatrics, while the underlying assumptions remain neglected.

Our definition of "intent" aligns most closely with Schein's "basic underlying assumptions." Like these assumptions, a company's true intent is often:

• Intangible, Tacit, and Hard to Describe: It's felt and acted upon more than it's explicitly articulated in everyday conversation.

• Deeply Ingrained: It represents the collective, often unspoken, understanding of "how we do things around here" and "why we truly exist."

• A Powerful Driver of Behavior: It shapes how individuals perceive problems, make decisions, and interact, even when no explicit rule or value is present. It is the fundamental mental model for how the organization solves problems of external adaptation and internal integration.

Thus, when a company is "driven by intent," it means its foundational, often unarticulated "why" has permeated its collective consciousness, becoming a powerful, almost unconscious, guide for action, even beyond the explicit statements of vision, mission, and goals.

With all the risk of sounding esoteric: the worst mistake you can make is to mistake intent with the more explicit levels of artifacts and espoused values. Intent is the ephemeral, tacit, and intangible part. Dialectically, though, companies need to master the art of artifacts and espoused values (and much more: operations) to help Intent survive.

Beyond Semantics: Differentiating Intent from Goals & Vision

Using our musical analogy:

• Vision (The Aspirational Destination): This is the grand, overarching melody or Leitmotiv – what the ideal future (or even better: present) looks like (e.g., "To be the global leader in sustainable energy"). Intent is the passion and conviction behind wanting to reach that destination, the intrinsic drive that makes the vision a compelling, imperative reason to act. Intent is the "I need to see the world like this" of the founder once he imagined the world changed by his idea.

• Mission (The Purpose / What We Do): This represents the specific instrumentation and core rhythm – what the company does, for whom, and how it creates value (e.g., "To provide reliable, affordable, and clean energy solutions through innovative technology"). Intent provides the depth and conviction behind the mission, the belief in why this mission is vital and why the company is uniquely driven to fulfill it.

• Goals (Specific Targets): These are the individual notes or movements within the symphony – specific, measurable targets (e.g., "Increase market share by 15% in three years"). Intent is the motivational force propelling these achievements, understanding why these goals are chosen and fostering the unwavering commitment to overcome obstacles. If goals are the "what to do," intent is the "why we will do it with everything we've got."

In essence, while vision, mission, and goals provide the explicit blueprint, intent is the dynamic, driving force – the "why," the "spirit," the "unwavering commitment," and the "interpretive guidance" that transforms that blueprint into a living, adapting reality.

To wrap it up: Intent is the tacit, intangible, more emotional force, the drive behind everything. Vision, Mission, Goals, Plans are the expression of that intent. While very small groups might easily align around intent alone (early startup, e.g.), the bigger an organization becomes, it requires strong and disciplined explication to be able to scale. If you have hundreds or thousands of employees, Intent does not scale; the founder cannot reach everyone. That’s why now we need to go for the risk of documenting Intent – knowing that Intent cannot be fully captured (see "The Musical Score"). The explicit documentation is now necessary but not sufficient.

Understanding the Shadow Side: When Intent Turns Toxic

In the call, we also touched the question of “Is Intent exclusively a good thing?” And of course, the answer is a screaming loud “NOOO!”

“The path to hell is paved by good intentions!”

While a shared intent can be profoundly unifying and empowering, it carries a critical risk. For Intent to have a chance to remain helpful, an organization needs at least:

• A sensor system connected to the outside world

• A sensor system to stay internally connected

• Balanced Autonomy & Interdependence: Departments and other units need a balance between being internally focused to 'do their job' and maintaining focused exchange with other units at defined interfaces. This is the crucial balance between Autonomy and Interdependence.

Without these feedback and input systems, the very power of intent can morph into something destructive, having an organization turn into a cult. The difference is the presence or absence of robust, challenging feedback, signaling, and sensor systems. As socially comfortable as it might feel for an organization to avoid internal or external friction, this isolation risks turning it into a tribal, undifferentiated, hyper-aligned system, slowly dying in unawareness of crucial changes.

Healthy intent creates unity, empowerment, resilience, and innovation. Toxic intent, often seen in cult-like environments, turns up when:

• Intent Becomes Dogma: The initial healthy, convinced, and fresh core "why" becomes an unchallengeable, absolute truth. What was once new and revolutionary turns static and resistant to challenge, transforming an open system into a closed, reactionary one. Questioning the fundamental intent now isn't tolerated, removing feedback systems to signal if it's unrealistic, harmful, or obsolete.

• Blind Obedience: Leadership's interpretation of the intent becomes the only valid one. Employees are expected to follow directives unquestioned, even if they intuitively feel something is wrong or ineffective. "The ends justify the means" becomes a dangerous mantra. "Does this make sense?" becomes a career-limiting thought.

• Suppression of Dissent and Critical Thinking: Constructive criticism, diverse opinions, and challenging assumptions are viewed as disloyalty or a lack of commitment. Groupthink dominates, and information contradicting the prevailing narrative is ignored.

• Isolation and Us-vs.-Them Mentality: The intense internal focus on intent leads to viewing external stakeholders (competitors, regulators, even customers) with suspicion or as obstacles to the "higher purpose."

• Charismatic Leader and Dependent Followers: The intent becomes inextricably linked to a single charismatic leader. Followers become dependent on this leader's interpretation and approval, losing independent judgment.

It’s important to understand and embrace that Intent is a very brittle, sensitive, and potentially transient animal. To maintain it in good shape should be the highest attention of a company’s leadership, and it requires strategy, clarity, discipline, and organizational excellence, the bigger the organization becomes. That’s why I chose Intent as the ideal roof under which all the things I will write about live together and make coherent sense.