Recently, I heard something that sounded like a punchline. It wasn’t.

In some software companies, developer performance is now measured not just by delivery or quality, but by how many AI tokens they burn each month. The more you prompt, the better your KPI. Tokens as progress.

The first reaction is obvious: why reward people for spending more? Tokens are not free. On the surface, this looks like incentivizing waste.

But look closer, and it gets more interesting. Not more correct, just more revealing. This is less a KPI than a lever to force a behavioral shift.

Activity Is Not Outcome. Even If It’s Measurable

As a KPI, token usage is a clean example of measuring activity instead of outcome. The distinction is not subtle. Tie evaluation to tokens, and you get more prompting, more interaction, more output. What you do not get is better software, faster delivery, or higher quality.

This is the familiar pattern: once a metric becomes a target, it loses its value as a signal. The system optimizes for the number, not the impact. From a distance, it looks like progress. Up close, it is mostly motion.

You are Not Buying Tokens. You are Buying Behavior

Yet companies persist. Which suggests the real goal is elsewhere.

What is really being purchased is not tokens, but a shift in behavior. The aim is to make AI interaction default, not optional. Left alone, most people stick to what they know, underestimate new tools, and avoid the friction of learning something that does not yet feel essential.

So the organization reaches for a blunt tool: remove the choice. Use AI, or fall behind. Eventually, enough people adapt, and the system shifts from experimentation to habit. It is not elegant, but it works. Until it doesn’t.

The Productivity Paradox Nobody Likes to Mention

The catch is that more output does not guarantee better outcomes. Developers can generate more code, product managers more documents, designers more options, journalists more content. At the organizational level, speed and quality do not always improve. Sometimes, they slip.

Output is not outcome. More code means more to review, test, and maintain. More content means more noise. More options mean more decisions. AI rarely removes work; it just moves it, often from creation to validation and correction.

There is also the perception gap. People often feel faster with AI, even when they are not. The interaction creates a sense of acceleration, while hidden costs pile up. This is typical of transition phases: the shape of work changes before the results do.

From Doing the Work to Supervising It

Underneath all this, the roles themselves are shifting. Developers move from writing code to orchestrating it, from direct problem-solving to supervising machine-generated solutions. Product managers shape and evaluate AI outputs. Designers explore wider spaces before narrowing in. Customer care agents supervise more than they compose. Even journalists, in organizations that limit AI in reporting, use it for distribution, summarization, and research.

The pattern is not replacement, but reallocation. New habits, new judgment, and new definitions of good work follow.

Where Forced Adoption Actually Creates Leverage

Forced adoption sometimes creates leverage, but only in the right places. Where work is repetitive, structured, and easy to check, and where mistakes are cheap, AI speeds up iteration. Product managers draft faster, designers explore more options, customer care teams respond more consistently, journalists repackage content across formats. The value is in acceleration, not in replacing judgment.

In these cases, the gain is speed and breadth of exploration, not the outsourcing of decisions. The path to better choices gets shorter, but the choices remain yours.

Where It Quietly Breaks Things

The same approach breaks down in areas that depend on judgment, context, or accountability. Decision-making, prioritization, editorial voice, and complex reasoning do not improve when forced through AI. Here, the tool adds friction. People game the metric, offload thinking they should keep, or spend more time fixing AI output than doing the work themselves.

This is where the original instinct holds: the KPI is wrong. In these areas, mistakes are expensive and quality is hard to measure.

What a More Mature Approach Looks Like

More mature organizations move on. The question shifts from ‘did you use AI’ to ‘did it matter.’ Activity gives way to outcomes, volume to impact. AI becomes just another tool, visible in the workflow only when it adds value.

Judgment returns, including the choice not to use AI when it adds nothing. Experimentation is separated from production. Over time, the organization builds capability, not just usage. The goal shifts from forcing adoption to making effective use unavoidable.

It’s Not Just About Developers

This pattern is not limited to software. The same dynamic plays out in product management, design, customer care, journalism, marketing, analytics. Forced usage speeds adoption where work is structured and execution-heavy. It quietly erodes quality where judgment and context matter.

The real mistake is not force, but lack of precision. Treat every task as equally automatable, and the results will be equally mediocre.

So Was the KPI Stupid?

As a long-term measure, it is hard to defend. As a temporary lever to break inertia, it sometimes works. The problem is when organizations stop at the metric and keep optimizing for tokens, long after the real goal — changing how people work — should have taken over.

In the end, this is not about tokens or even productivity. It is about reshaping habits. And that is always more complex, and more fragile, than any KPI can capture.

For years, product managers have relied on a comforting story. You are the glue. The mini-CEO. The person at the intersection of business, technology, and design. You orchestrate complexity. You make things happen. It sounds important, vaguely strategic, and above all, safe. Safe from reorgs, safe from outsourcing, and certainly safe from automation.

Then AI arrives. No drama, just quiet competence. It writes specs that are good enough. It summarizes research faster than any analyst. It generates ideas on demand. It builds prototypes in hours, not weeks. Suddenly, much of what once justified the role starts to look negotiable.

This is where the discomfort sets in. Not because product management is vanishing, but because some parts were never as essential as we liked to think.

Execution Is Collapsing. Judgment Is Not

One of the more obvious shifts is that execution costs are collapsing. You do not need a full team or multiple cycles to validate a simple idea. A prompt, a tool, and some patience are often enough. The barrier to building has dropped so far that ‘we do not have resources’ is starting to sound less convincing.

Cheaper execution does not make the job simpler. It just changes where the difficulty sits. When it is easy to build ten versions, the real work is deciding which one should exist. When iteration is fast, hesitation is harder to hide. When delivery is not the bottleneck, thinking is.

This is where many product managers start to struggle. Execution was always easier to measure. Judgment is not. You cannot hide behind velocity charts when the real question is whether you are even moving in the right direction.

The Myth of “Human Skills”

The response to this shift is predictable. The industry leans on a familiar story: human skills will save us. Empathy, intuition, emotional intelligence, internal authority. These are framed as the last defense against AI, the things only humans can do.

There is some truth here, but also a fair amount of wishful thinking. Most product roles were not built on deep empathy or rare intuition. They were built on coordination, communication, and structured thinking. Useful, but not uniquely human. And increasingly, not out of reach for machines.

Even intuition, often treated as something mystical, is usually just compressed experience. Pattern recognition built up over time. AI is already good at that. The gap is not as wide as we would like.

The real differentiator is less romantic. It is the willingness to take responsibility for a decision when the data is incomplete, the signals are mixed, and the outcome is uncertain. AI can suggest, simulate, and optimize. It does not carry consequences. Humans still do.

Organizations Are Not Getting Simpler

Another assumption does not survive contact with reality: that AI will make organizations simpler. Fewer people, flatter structures, less friction. It sounds logical. It is mostly wrong.

As execution gets easier, alignment gets harder. More ideas, more experiments, more people who want to contribute. The result is not clarity, but noise. Competing directions, overlapping initiatives, and a growing need to decide what not to pursue.

Stakeholder management does not go away. It gets louder. People still want ownership, recognition, influence. They still bring their biases and ambitions. Faster cycles only amplify this, because there is less time to build consensus and more pressure to commit.

This is where ‘internal authority’ starts to matter, but not in a therapeutic way. It is not about self-reflection for its own sake. It is about being able to hold a position, make a call, and move forward without hiding behind endless validation.

More Tools, More Work, Less Excuses

One thing that gets less attention: AI does not reduce workload. It just moves it around. When writing, analysis, and prototyping get easier, expectations do not stay flat. They expand. You are expected to explore more options, run more experiments, consider more variables, and do it all faster.

The work becomes cognitively lighter at the surface level, but strategically heavier underneath. You are no longer limited by what you can produce, but by what you can meaningfully evaluate. The constraint shifts from output to attention. This creates a different kind of pressure. Not the pressure of scarce resources, but the pressure of too many possibilities. When almost anything can be built, the real skill is deciding what should not be built.lt.

And that is not something you can outsource to a model.

What the Role Actually Becomes

If you strip away the mythology, the future product manager looks less like a mini-CEO and more like something less glamorous and more demanding: a professional decision-maker working under constant uncertainty.

You are not there to produce documents. AI does that faster. You are not there to gather information. AI does that at scale. You are not even there to generate ideas. AI has an endless supply.

You are there to define what matters in a sea of options, to ignore what does not, to make a decision before it feels fully justified, and to change course before failure is obvious. You are there to create direction where none is visible.

That requires clarity of thought, some product taste, and enough psychological stability to operate without constant reassurance. Not because therapy is the future of product management, but because the buffers that once absorbed uncertainty are disappearing.

The Uncomfortable Conclusion

AI will not replace product managers. That is the comforting part.

The less comforting part is what comes next. AI will remove the scaffolding that made many product roles feel more substantial than they were. It will expose who was relying on process rather than thinking, who was coordinating rather than deciding, and who was optimizing for agreement rather than outcomes.

In that sense, AI is not a threat to the role. It is a stress test for it.

If your value was tied to execution, you would feel the pressure. If your value is tied to judgment, you may find yourself with more leverage than before. For the first time in a while, the role starts to look like what it always claimed to be.

Not managing products. But making decisions that shape them.

Most organizations are not struggling with strategy itself. They are struggling with what they think strategy is.

Strategy gets treated as a fixed plan: define it once, align everyone, put it in a deck, and execute. The more stable it looks, the more strategic it feels. Predictability becomes a proxy for rigor.

And then reality happens.

New technologies emerge. User behavior shifts in ways no research predicted. Stakeholders change priorities mid-cycle. Budgets shrink without warning. Entire markets become harder (or suddenly easier) to reach. And quietly, almost politely, the plan stops making sense.

But no one wants to say it out loud.

So the organization keeps moving. Teams deliver against assumptions that no longer hold. Leaders make small adjustments, but the strategy deck stays the same. Roadmaps change, the story does not. The result is not failed execution. It is something quieter: the gap between what the organization says and what it actually does keeps widening.

We call this drift. More often, it is just denial with better branding.

The uncomfortable part is not that the environment moves too fast. It is that we expect strategy to behave like a plan, even when plans expire quickly.

If you treat strategy as something that must remain stable in its details, you are guaranteed to be wrong. The only question is how long it takes you to notice.

A more useful way to think about strategy is to separate two things that are usually mixed together: direction and decisions.

Direction is the part that should remain relatively stable. It is your sense of where you are going and why. It includes your mission, your target audience, your positioning, and the constraints you are not willing to violate. In many cases, these constraints matter more than your ambitions. They define the space within which you are allowed to operate.

Decisions are everything else. What you build, how you distribute it, which technologies you adopt, what you prioritize this quarter, what you drop, what you postpone, what you experiment with. This layer should not be stable. It should change constantly, because it is your interface with reality.

Most organizations blur these layers. They try to make decisions as stable as direction, then wonder why everything gets slower, more rigid, and less connected to reality.

The answer is not to give up on long-term thinking. It is to swap detailed planning for something more resilient: a system that adapts within clear boundaries.

Instead of betting on a detailed future, you set a clear direction, a few guardrails, and a way to judge new opportunities. You do not try to predict what you will build in two years. You define which moves fit, and which do not.

When a new opportunity appears (and it always does), you don’t ask whether it was in the plan. You ask whether it fits the system.

Does it serve the audience we care about? Does it strengthen our positioning or dilute it? Does it respect the constraints we’ve set for ourselves? Does it connect to something we are already trying to achieve, or does it require us to quietly change direction without admitting it?

If it fits, you adapt. If it doesn’t, you say no.

This sounds simple. In practice, it is where most organizations stumble. Not for lack of ideas, but for lack of discipline to say no — especially when the idea is shiny, well-funded, or politically convenient.

Ironically, adapting within boundaries is harder than planning. Planning offers the illusion of control. Adaptation means making uncomfortable choices, over and over.

At this point, someone usually says: “But isn’t this just another way of describing strategy drift?” Not quite.

There are two types of drift. One is unconscious and dangerous. It happens when small decisions accumulate without anyone checking whether they still connect to the original direction. Over time, execution and strategy diverge, and the organization keeps moving — just not in a meaningful direction.

The other type is adaptive. It happens when reality changes, and the organization responds. This is not failure. This is survival.

The difference is not in the movement. It is in the acknowledgment.

If your organization has changed direction but the strategy still claims otherwise, you do not have adaptability. You have fragmentation. Teams work from different assumptions, leaders say something else, and alignment becomes theater.

The fix is not to stop change. It is to make change visible. Even small shifts need to be named and reflected in the story everyone shares. Otherwise, you are running parallel strategies and pretending it is one.

This is where cadence becomes critical.

Not everything moves at the same speed. Direction should be stable, checked now and then. Objectives shift more often. Execution is always in motion. But the real discipline is this: review your assumptions more often than you rewrite them.

A lightweight question is usually enough: has anything changed that would make this no longer true?

If the answer is no, you move on. If the answer is yes, you’ve caught something early — before it turns into months of misaligned work.

And yet, even with all of this in place, many organizations still struggle. Not because the model is wrong, but because something more fundamental is misaligned.

Teams get rewarded for output, not outcomes. Leaders get attention for launching things, not for keeping the system coherent. Stakeholders push for more, rarely for less. In this setup, drift is not a bug. It is the system working as designed.

You can roll out any framework you like. If the incentives stay the same, so will the behavior.

In complex environments — especially those shaped by external constraints, multiple markets, and competing priorities — perfect alignment is not a realistic goal. Trying to achieve it often leads to over-centralization and loss of responsiveness.

A more honest goal is not perfect alignment. It is controlled divergence.

Different teams will optimize for different realities. Different markets will require different tactics. Different constraints will force different trade-offs. That is not a failure of strategy. That is the reality of operating at scale.

What matters is that all of this happens within a shared directional frame. The same “why,” even if the “how” varies significantly.

Strategy, in this sense, is not a plan to execute. It is a system to maintain. Constantly.

It does not eliminate tension between long-term intent and short-term reality. It makes that tension visible, manageable, and, if you are disciplined enough, productive.

The alternative is simpler.

Keep the plan. Ignore the changes. Call the misalignment “execution issues.”

And hope no one notices how far you’ve drifted.

There is a product principle that gets repeated, usually with a half-smile: no one reads anything. Not documentation, not emails, not UI copy, and definitely not news past the headline. It sounds like a joke, but it is really a design constraint. The uncomfortable part is not that it is wrong. It is that it is just accurate enough to shape how we build.

Somewhere along the way, we accepted a contradiction. We produce more content than ever — articles, explainers, threads, summaries — while knowing most of it will not be read. Not in any meaningful way. At best, it gets scanned, skimmed, reduced to a headline and a vague sense of what happened. At worst, it is replaced by a two-line AI summary that sounds confident enough to pass for understanding.

Yet in newsrooms and product meetings, we still talk as if depth is the default. As if the average user is moving patiently from paragraph one to paragraph twelve, collecting nuance, context, and background along the way. It is a comforting fiction. Operationally, it does not hold up.

The so-called Miller Principle, or at least its modern version, forces a different perspective. If no one reads anything, every extra sentence is not just ignored. It becomes a liability. It is a bet that the user will invest attention they do not have. Most of the time, they do not.

Now, place this reality inside news consumption.

We expect users to understand geopolitical nuance, historical context, and conflicting narratives. We expect them to distinguish signal from noise, fact from framing, reporting from opinion. And we package all of this inside a structure that assumes time, focus, and patience. Then we act surprised when the headline becomes the story.

This is not a failure of the audience. It is a mismatch between product design and human behavior.

The uncomfortable implication is that the headline is not just an entry point. For many users, it is the whole experience. Any nuance not present there is not just hidden or delayed. It is lost.

This leaves us with a quiet editorial dilemma. Do we optimize for accuracy or for attention? The industry has been trying to do both and often ends up with neither: headlines too vague to inform, articles too long to be consumed.

Now add AI, and the problem shifts. It is no longer just about attention. It becomes a question of what users actually know.

AI does not just shorten content. It rewrites it into something that feels finished. A clean paragraph, a few confident statements, sometimes even a tidy conclusion. Ambiguity disappears. The user gets an answer, no effort required.

And that is precisely the problem.

When AI simplifies, it does not just remove words. It removes tension and uncertainty. It smooths out the messy edges where real understanding usually lives. What remains is a version of reality that is easier to process, and therefore easier to trust.

We are entering a phase where users are not just skipping the article. They are skipping the existence of the article altogether.

In this world, the role of a news product shifts. It is no longer just about publishing content. It becomes about managing how much of reality survives the process of compression.

This is where things get uncomfortable for product leaders. The trade-offs become harder to ignore.

If you take the ‘no one reads anything’ principle seriously, the answer is not to simplify everything. It is to design for selective depth. Accept that most users will stay at the surface, but make sure the surface is not misleading, and that moving deeper does not feel like a penalty.

Right now, depth often feels like a penalty. Long articles, dense paragraphs, context buried out of sight. The product signals: if you want nuance, you pay with your time. Most users do not take the deal.

The real challenge is not to make users read more. It is to make every extra second of attention disproportionately valuable. The goal is a system where understanding is layered, not hidden behind a wall of text.

But here is the tension. The more efficient the experience, the easier it is to consume a simplified version and move on. Efficiency and understanding do not always align. Sometimes they work against each other.

This leads to a slightly uncomfortable question.

If no one reads anything and AI explains everything, what are we actually optimizing for?

If the answer is speed, we are doing well. If the answer is understanding, we may be designing ourselves into a corner where users feel informed without actually being informed.

That is a much harder problem than low engagement or high bounce rates.

It is a product problem. It is an editorial problem. And increasingly, it is a trust problem.

Jogging did not become mainstream because people suddenly discovered discipline. It became normal because the cost of ignoring physical health became visible, then hard to ignore. Now, not caring about your fitness is the exception, not the rule.

We could see the same shift with mental discipline. The ability to focus, to read deeply, to think without interruption might stop being assumed and start being recognized as rare. And as with physical fitness, what is rare tends to become valuable. The metric just changes from steps to minutes of undistracted attention.

The analogy is not perfect, but it is close enough to make people uneasy. We spent decades learning how to train the body. The brain, meanwhile, was left to fend for itself. Now, as our environment quietly shifts to make focus harder, we are only just noticing the side effects.

We Fixed the Body. We Outsourced the Brain.

Physical fitness did not become a movement because people woke up one day with more willpower. It happened because the downsides of ignoring the body became obvious, then embarrassing. Sedentary living and bad diets stopped being invisible. They became problems with names, metrics, and solutions.

With mental focus, we are still pretending nothing has changed. We act as if attention and depth are default settings, immune to environment. Meanwhile, we keep redesigning our world to make sustained thinking less likely, not more.

Focus did not vanish. We traded it away, bit by bit, for convenience.

Your Brain Eats What You Feed It

Modern content is not just available. It is engineered for frictionless, repeat consumption. Short loops, emotional nudges, infinite feeds. These are not bugs. They are the product.

At this point, the food analogy stops being cute and starts being literal. Ultra-processed food is built to be irresistible. Digital content is built to remove every barrier to consumption. The issue is not occasional indulgence. The issue is what becomes normal.

When most inputs require little effort, the brain adapts. It gets better at skimming, reacting, and switching. It gets worse at staying put, analyzing, or handling complexity. This does not feel like loss. It just feels like the new baseline.

Which is exactly how most long-term shifts begin.

AI as the Perfect Convenience Layer

If that were the whole story, it would be enough. But AI adds a new twist. It does not just distract. It substitutes.

For the first time, we have tools that can handle parts of thinking for us. Structuring ideas, summarizing, drafting, exploring options. These are no longer reserved for people.

This does not make us less capable by itself. It just makes effort optional.

And when effort becomes optional, it usually disappears unless someone chooses to keep it.

The pattern is familiar. First, friction goes away. Then effort. Then the skill itself fades, not because it is lost, but because it is no longer needed.

The Predictable Turn to Regulation

At this stage, the usual response is to look for bigger levers. If the environment is working against us, maybe the answer is to regulate platforms, restrict algorithms, or protect users.

This is a familiar cycle. When a behavior becomes common and starts to hurt, we reach for external controls. Sometimes, especially for younger people, this makes sense.

But attention does not become discipline by decree. You cannot outsource the hard part. No policy will make people pick complexity over convenience every day.

Environment shapes behavior. It does not erase choice.

From Capability to Signal

The next shift is not in policy. It is in what people notice.

Physical fitness used to be a signal. Then it became a baseline. Now, it is often just for show. The skill did not change as much as the story around it.

Mental discipline may take the same path, but in reverse. As distraction becomes standard, focus and deep thinking start to look strange.

And what stands out tends to become valuable. Not because it is new, but because it is rare.

A Different Kind of Cardio

The analogy is not perfect, but the mechanism is simple. Systems adapt to use. Skills that get exercised improve. Skills that do not, fade.

There is no single breaking point. Just a slow change in what feels easy, what feels hard, and what feels worth the effort.

It is not hard to picture a quiet room where people who once tracked steps now sit without devices, working on something slow and difficult. Not out of nostalgia, but out of necessity.

From running clubs to chess clubs. A different kind of cardio.

Most IT organizations have a pattern that is obvious if you look for it, but almost no one says it out loud.

The underdog who improves in public gets the praise, the promotion, the story. The steady high performer, the one who delivers without drama, fades into the background. Trusted, relied on, and eventually taken for granted.

It sounds fair enough. Growth deserves recognition. Effort should matter. Everyone likes a story with an arc. But look closer and it is less about fairness, more about how the system chooses what counts as performance.

Performance systems are not built to weigh underdogs against high performers. They are built to flatten messy, conflicting signals into a single story. And then reward whatever is most visible at the time.

Why this is not a people problem but a system problem

The real issue is not bias in the usual sense. It is structural confusion.

We ask one system to judge output and effort, consistency and improvement, visibility and impact, short-term delivery and long-term thinking. Each pair is a real trade-off. None of them can be averaged away, but most organizations act as if they can be compressed into a single number or a tidy conversation.

In practice, the system just grabs whatever signal is easiest to see at review time. In knowledge work, that signal is almost never the most accurate one.

This is how performance management quietly becomes a storytelling exercise.

Output vs effort: why activity wins over impact

Take output versus effort. In theory, results matter more than activity. In practice, results in software are hard to pin down. Work is collaborative, dependencies are everywhere, and some of the best contributions are the ones you never see: problems that never happen, incidents that never escalate, systems that quietly get more stable.

Faced with all this ambiguity, managers reach for proxies. Responsiveness, visible urgency, number of tickets touched, presence in meetings. These signals are not useless, but they are much easier to spot than the real impact.

So the person who quietly removes a whole class of production issues goes unnoticed, while the person who fights incidents in public channels becomes a hero. The system does not reward chaos on purpose, but it reliably rewards the attention chaos creates.

Consistency vs improvement: why stability becomes invisible

The same distortion shows up with consistency versus improvement. High, stable performance has a strange weakness: it becomes the baseline. Once something is seen as normal, it stops drawing attention. No one tells a story about the thing that just works, every time.

Improvement, on the other hand, is always visible. It has direction, contrast, and emotional pull. Someone who moves from average to good creates a story that is easy to tell and easy to remember.

Over time, this shifts the balance. Organizations start to overweight trajectories and underweight reliability. High performers are not punished, but they stop standing out. Their contribution is assumed, not examined.

Assumption is a fragile kind of recognition.

Visibility vs impact: when performance becomes influence

Visibility versus impact is where the system quietly turns political. Every organization says it values impact, but few invest in making it measurable. What is left is visibility: who speaks, who presents, who shows up at the right moments, who can explain their work well.

Communication matters. But when it replaces evidence, the rules change. Performance reviews become contests of influence, where a clear story can outweigh real contribution.

This is how glue work — mentorship, documentation, reliability, cross-team coordination — either disappears or gets misread. It is critical to the system, but unless someone tracks it on purpose, it loses out to more visible output.

Short-term vs long-term: the trade-off nobody tracks

Short-term delivery versus long-term capability is the tension that usually causes damage later. Shipping features and hitting deadlines create immediate, measurable results. Investing in architecture, reducing technical debt, or mentoring juniors pays off slowly and rarely fits into a single review cycle.

So the system does what it is built to do: it prioritizes what it can measure right now.

Teams get efficient in the short term and fragile in the long term. Learning slows, complexity grows, and eventually delivery starts to slip. When that happens, the usual response is more pressure on delivery, which just repeats the cycle.

Why adding more metrics usually makes it worse

At this point, the instinct is to fix performance by adding more metrics, more dashboards, more reviews. In reality, this usually makes the problem louder, not smaller.

The real issue is that performance systems are asked to do two incompatible jobs at once. They are used for administrative decisions — compensation, promotions, rankings — and at the same time for development, coaching, and growth.

These jobs need different signals and different interpretations. Admin decisions want stability and comparability. Development needs trends, potential, and context. When both are forced into the same box, the system gets inconsistent and easier to game.

Why high performers burn out in “fair” systems

There is another, less comfortable pattern here. High performers get more demand because they are trusted. At the same time, their output becomes the new normal, and recognition fails to keep pace with expectations.

This creates a familiar imbalance: high effort, high responsibility, low visible reward. Over time, this is a reliable path to burnout. Not because people are weak or overcommitted, but because the system slowly disconnects effort from recognition.

What a more coherent system actually looks like

A better approach does not start with new metrics or frameworks. It starts by admitting that performance is multi-dimensional, and that different dimensions belong at different levels.

Some signals make sense at the team or system level: delivery speed, reliability, stability. Others belong to the individual: decision quality, ownership, ability to simplify, contribution to team capability.

Once you separate these, evaluation stops being about squeezing everything into one score. It becomes about building a coherent, evidence-based view of contribution. Invisible work is made visible on purpose. Context is documented, not assumed. Sustainability is treated as part of performance, not an afterthought.

Back to underdogs vs high performers

The tension between underdogs and high performers does not disappear in this kind of system. But it becomes explicit, manageable, and less about who tells the better story.

And that is usually the difference between a performance system that feels political and one that feels fair.

Explaining your product to everyone at once feels efficient and transparent. In practice, it is one of the fastest ways to make sure no one actually understands what you mean.

We like the idea of a single story that works for everyone — users, stakeholders, engineers, leadership, partners. It sounds clean and professional. It rarely survives contact with reality.

These groups are not just different people. They think in different systems. Each listens for something else, filters information differently, and decides based on different signals. When you give them the same message, they do not align. They reinterpret.

That reinterpretation is where most product communication quietly breaks.

You launch a feature and write a careful explanation. You cover the user problem, business value, technical constraints, and some vision. It feels complete, so you share it widely.

Users ignore most of it. They want to know what changes for them right now. Stakeholders ask follow-up questions to assess risk and defend the decision. The team starts building but interprets the goal differently. Management scans, jumps to conclusions, and moves on. Partners miss how this connects to their systems.

Nothing dramatic happens. Alignment is lost.

The usual reaction is to say we need to communicate better. In practice, the problem is not clarity. It is targeting.

Good product storytelling is not about simplifying one message for everyone. It is about shaping different versions so each audience gets what they need.

Users are not interested in your reasoning. They want to see their situation reflected and understand how the product changes it. The moment you move from showing value to explaining context, you lose them. They are not judging your thinking. They are judging whether this makes their life easier, faster, or safer.

Stakeholders are not trying to use the product. They are trying to justify decisions. They need a story that holds up under pressure and can be repeated when challenged. Timing, alternatives, and evidence matter. If your story cannot be defended in a budget or prioritization discussion, it does not work for them.

Inside the team, the problem changes. Storytelling is not about persuasion. It is about precision. Vague goals create expensive misunderstandings. Phrases like ‘improve engagement’ or ‘enhance user experience’ do not align a team. They create space for multiple interpretations. A strong internal story removes ambiguity and makes success observable. If people describe the goal differently, the story has already failed.

Management looks for something else. Features matter less than the quality of decisions. They are evaluating how you handle trade-offs, assess risk, and prioritize under constraints. A story that only talks about opportunity and ignores what you are not doing or what could go wrong sounds incomplete. Clarity about limits builds more trust than optimism.

With partners, the gap is operational. They do not need your intent or reasoning. They need to know how things connect: what goes in, what comes out, who is responsible, and where the boundaries are. If that is not clear, they fill the gaps with their own assumptions. What you later call integration complexity is often just unclear communication.

Most teams ignore one audience: the future version of the organization. Months later, people change, context disappears, and decisions that once felt obvious become opaque. Someone asks why a certain approach was chosen, and the only answer is ‘it made sense at the time.’ At that point, the story was never told. What is missing is not the record of what was done, but the reasoning behind it — the constraints, alternatives, and trade-offs that shaped the decision.

Step back and a pattern appears. The product does not change. The facts stay the same. What changes is the question each audience is trying to answer. Users ask what this does for them. Stakeholders ask if it is worth it. The team asks what needs to be built. Management asks if this is the right call in context. Partners ask how to connect to it. The future organization asks why it ended up this way.

Trying to answer all these questions at once leads to messages that feel complete but land nowhere. They contain everything and emphasize nothing.

A more effective approach is less elegant and more precise. Before communicating, decide which audience you are addressing and what decision you expect from them. Shape the story around that decision, even if it means leaving other aspects aside.

This is where product communication gets uncomfortable. It stops being about covering everything and starts being about being selective.

You do not need a better, more polished, or more inspiring story. You need to aim it.

At this point, the “remote vs. office” debate feels less like a strategy discussion and more like a ritual. Leaders defend office presence as discipline. Employees defend remote work as freedom. Both sides are convinced they are protecting productivity.

In reality, most are protecting something else: their own comfort with how work used to be.

If a company needs people in the office to feel in control, the issue is not remote work. It is a lack of trust, clarity, and measurable outcomes. Office attendance does not solve that.

The myths we keep repeating

Let’s start with a few ideas that sound reasonable but don’t hold up well under scrutiny.

Remote work is often framed as a reward you earn. In practice, flexible work reduces attrition but leaves performance mostly unchanged. So remote work is less a perk, more a retention tool.

Presence is often equated with productivity. It is not. Presence gives visibility, and visibility is easier to measure than output.

There is also the claim that the office is only for brainstorming. That is only part of the story. In-person work also builds informal networks, speeds up onboarding, and supports mentorship. These are the invisible systems that keep organizations running.

Where remote work actually breaks

Remote work does not fail randomly. It fails predictably.

Remote work struggles when tasks are ambiguous, when tight coordination is needed, when knowledge is informal, or when fast feedback is required. It also fails where learning depends on observation instead of clear instruction.

You see this in collaboration patterns. Remote teams become more siloed. Cross-team interactions drop. People work more with their immediate group and less across the company.

Innovation drops when coordination is weak. Not because people are less creative at home, but because spontaneous exchange is less likely.

But when work is structured, measurable, and needs long focus, remote often matches or beats the office. Fewer interruptions. More control. Less performance theater.

The hidden costs of hybrid

Hybrid is sold as a compromise. In reality, it often combines the downsides of both models.

Uncoordinated office days mean empty offices or people commuting just to join video calls. Communication overhead grows. Meetings multiply. Calendars fragment.

Mentorship suffers quietly. Seniors spend less time transferring knowledge. Juniors lose informal learning. The cost shows up later.

Decision-making also suffers. Without clear rules, frustration grows. People see decisions as arbitrary.

Stop choosing. Start designing.

The more useful framing is simple: work is not one thing. It is a set of activities with different requirements.

Some tasks need deep focus and independence. Others need high-bandwidth interaction. Treating them the same, and putting them in the same environment, is where most organizations fail.

A more effective model looks like this:

• Remote is the default for execution. Clear tasks, defined outputs, measurable outcomes.

• Office presence is triggered by the work, not mandated. You come together when needed: ambiguity, cross-team alignment, onboarding, complex feedback.

When you come together, it is intentional and synchronized. Not optional attendance scattered through the week.

Replace presence with evidence

The final shift is uncomfortable but necessary.

Modern work cannot be managed by observation. It needs to be managed by signals.

Cycle time. Decision speed. Error rates. Time to onboard new hires. Retention.

These are harder to measure than attendance. But they are also harder to fake.

Once leaders trust these signals, the urge to see people working fades. So does much of the anxiety behind return-to-office mandates.

The actual deal

Remote work is not a privilege. It is also not a free-for-all.

The workable model is a simple trade:

• Freedom by default.

• Structure by necessity.

Not ideology. Not control. Design. And not the idea that a chair in an office is a performance system.

Every few weeks, a new wave of headlines arrives with a familiar message: AI is taking over journalism. Somewhere between conference slides, LinkedIn posts, and media think pieces, a number appears — 5%, 10%, sometimes much higher — suggesting that a growing share of news content is now written “by AI” or “with AI.”

It sounds dramatic. It is meant to sound dramatic.

The implied image is almost cinematic: invisible systems drafting articles at scale, quietly replacing human writers, reshaping the very idea of journalism. A reader scrolling through news feeds might reasonably assume that somewhere along the line, the byline has become… optional.

And yet, if you step inside an actual newsroom, the picture looks very different. Not less interesting — just less theatrical.

AI is indeed entering editorial processes at speed. But it is not marching through the front door, announcing itself as the new author of record. It is slipping in through side entrances — tools, assistants, small utilities — embedding itself into workflows in ways that are often invisible both to readers and, sometimes, even to the people describing them publicly.

Which raises a more precise question: when we say “AI is used in the newsroom,” what are we actually talking about?

What “using AI in the newsroom” actually means

The phrase AI-generated journalism suggests a binary reality: either a human wrote the article, or a machine did. In practice, the situation is far more nuanced and far more layered.

At one extreme, there are fully automated articles. These exist, but they tend to live in highly structured environments: sports results, financial earnings, weather updates, or election data. In these cases, the “article” is essentially a transformation of structured data into readable text. This is not new — variations of this have existed for years, long before the current generation of large language models.

At the other end of the spectrum is something much more common, but much harder to label.

A journalist writes a story, but uses AI to generate five headline options and selects one. Another journalist feeds a long interview transcript into a tool to extract key quotes. An editor asks AI to shorten a paragraph, adjust tone, or produce a summary for social media. A producer uses it to translate material or suggest alternative framing for a lead.

None of these scenarios fit neatly into “AI wrote the article.” Yet all of them are part of the editorial process.

This creates a wide, almost elastic definition of AI usage. The same newsroom might claim both “we don’t use AI to write articles” and “AI is deeply integrated into our workflow” — and both statements would be true.

Which is why the discussion about percentages often feels misleading. It compresses a spectrum into a single number.

To understand what is actually changing, it is more useful to look not at how much content AI writes, but at where in the process AI is most effective.

The tasks AI automates first — and why

AI does not begin by taking over the most visible or prestigious parts of journalism. It begins with the work that journalists themselves would gladly spend less time doing.

Transcribing interviews that stretch over hours. Translating material from one language to another. Condensing long reports into usable summaries. Generating multiple headline options under time pressure. Cleaning up grammar, tightening structure, shortening text without losing meaning.

These tasks are not trivial, but they are procedural. They require effort, time, and attention — but not necessarily deep editorial judgment.

And that distinction matters.

AI performs best where the output can be quickly evaluated by a human. A headline can be judged in seconds. A summary can be compared to the source. A transcript can be verified against audio. The human remains firmly in control, but the machine accelerates the process.

By contrast, tasks that require interpretation, contextual understanding, and accountability — deciding what the story is, which facts matter, how they should be framed — remain much more resistant to automation.

AI enters the newsroom not by replacing judgment, but by reducing friction. It removes the small delays that accumulate across the workflow — the minutes that become hours, the hours that become days.

And once those delays begin to disappear, something else happens. AI starts to spread into places where its presence is less obvious.

Where AI is used quietly

The most interesting part of AI adoption in journalism is not where it is visible. It is where it is not.

Public discussions tend to focus on the idea of AI writing articles. Inside newsrooms, much of the real impact happens earlier (and later) in the process.

Before a single line is written, AI may already be involved. It can help navigate large document sets, extract key points from reports, identify patterns across sources, or surface relevant material from archives. For investigative work, this is particularly valuable: not as a source of truth, but as a way to reduce the time needed to find where truth might be hiding.

None of this appears in the final publication. The reader never sees the hours saved. After the article is written, another layer of quiet activity begins.

A single piece of journalism rarely lives as a single piece anymore. It needs to be adapted — for search, for mobile, for social media, for newsletters, for different audience segments. Each of these requires slightly different wording, structure, or emphasis.

This is where AI is extremely efficient.

It can generate variations quickly, test different angles, produce summaries of different lengths, and adapt tone depending on the channel. Again, the journalist remains responsible for the content — but the distribution layer becomes increasingly assisted.

In effect, AI is not just participating in journalism. It is participating in how journalism moves.

What the real AI workflow in major newsrooms looks like

If you strip away the narratives and look at how large news organizations actually operate today, the workflow is less revolutionary than evolutionary.

The core remains intact. A journalist investigates, interviews, verifies, and writes. An editor reviews, challenges, refines. Accountability sits with people, not systems.

Around this core, however, a new layer has formed.

During research, AI may assist in processing documents or transcripts. During writing, it may offer structural suggestions or alternative phrasings. After writing, it contributes to headlines, summaries, and distribution formats. Throughout the process, it acts as a tool — sometimes helpful, sometimes ignored, occasionally wrong.

Importantly, it is rarely autonomous.

The idea that AI writes an article and a human simply approves it is not how most serious newsrooms operate. The direction is usually the opposite: a human creates the material, and AI supports specific steps around it.

This distinction may seem subtle, but it is fundamental. It defines whether AI is an author or an instrument.

For now, in most traditional news organizations, it is very clearly the latter.

A few conclusions

So how deeply is AI embedded in journalism?

Deep enough to matter. Not deep enough to replace it.

The more accurate picture is not one of sudden disruption, but of gradual integration. AI is becoming part of the infrastructure of news production: accelerating research, simplifying editing, enabling faster and more flexible distribution.

At the same time, the boundaries are holding. The closer we get to the core of journalism — facts, interpretation, accountability — the more cautious newsrooms remain.

This creates an interesting tension.

From the outside, it looks like AI is writing the news. From the inside, it feels more like AI is reorganizing the work around the news.

And perhaps that is the more useful way to think about it.

Journalism is not being replaced. It is being restructured — one quiet workflow improvement at a time.

Most product and engineering teams have people who fall into one of two groups.

The first group treats every stakeholder request as an order. A new feature? Yes. A last-minute change? Yes. Another urgent request from another department? Yes again. Calendars fill up, roadmaps get longer, and teams quietly work evenings and weekends to keep all the promises. The Yes-Man seems helpful and flexible, but eventually, deadlines slip, the team burns out, and everyone wonders who approved it all.

The second group is the opposite. Every request gets pushback. “Not in the roadmap.” “No resources.” “Come back next quarter.” Sometimes it’s just a polite no. Mister No protects the team from overload, but over time, stakeholders stop sharing ideas, innovation slows, and the product team starts to seem more like a gatekeeper than a partner.

Both attitudes make sense. One focuses on keeping stakeholders happy. The other focuses on stability and control. But both avoid the same uncomfortable task: negotiation.

The real job of product leadership isn’t just saying yes or no. It’s turning requests into priority decisions.

When someone asks for a new feature, the honest answer is rarely just yes or no. It’s usually something like, “Yes, if we move something else out of the plan,” or, “Yes, but that will push the analytics work back by three weeks.” The conversation shifts from approval to discussing trade-offs.

This is when priorities become real. When requests are considered alone, everything seems important. Every idea feels urgent by itself. But once you compare it to other planned work, the question changes from “Is this useful?” to “Is this more important than what we’re already doing?”

And that’s a much harder question to answer.

In practice, good teams make trade-offs clear as soon as possible. They show the roadmap, the backlog, and what the team is working on, along with available capacity. Instead of saying, “we’ll try to fit it in,” they explain each request in terms of time, effort, and impact. This isn’t to block ideas, but to bring clarity to the conversation.

At this point, something interesting often happens. Many requests get smaller. A “must-have feature” becomes “maybe a smaller version would work.” An urgent request turns into “maybe next quarter is fine.” Sometimes, two stakeholders realize they’re competing for the same resources and start negotiating with each other instead of pushing the team.

In other words, being transparent does half the negotiating for you.

Another key point is to separate ideas from commitments. Product teams should welcome ideas, but making commitments should be much harder. Anyone can suggest something new, but deciding to build it should follow the same prioritization process as everything else. This keeps the team from making accidental promises that turn into obligations.

This approach also takes much of the emotion out of these conversations. If a team just says “no,” the discussion feels personal and stakeholders feel rejected. If a team says “yes” but sacrifices its own capacity, resentment builds within the team.

But when the answer is, “here are the trade-offs,” the decision is no longer personal. It becomes about structure. The conversation shifts from asking for permission to discussing how to allocate resources.

Interestingly, many requests disappear once trade-offs are clear. When stakeholders see that their urgent feature would delay something else they care about, priorities become clear much faster.

Good product teams work differently. Instead of making promises or refusing requests, they set conditions. Every request goes through the same process: what’s the impact, what’s the effort, and what needs to be postponed to make room for it.

This approach has an unexpected benefit. Stakeholders start negotiating with each other instead of with the team, which is usually a much healthier dynamic.

So next time someone asks your team for something new, try not to be a Yes-Man. Also, avoid becoming Mister No.

Try something a bit more uncomfortable. Say, “Yes, we can do this. Let’s decide together what will no longer be a priority.”

At some point in every leadership role, you realize that your job is not to produce results. It is to translate reality.

Roadmaps, OKRs, and delivery plans are just tools. The real work often happens in more personal moments, like when you stand in front of your team, open a Zoom call, or write a Slack message and decide how to share the news:

• We won

• We lost

• We don’t know yet

How well you communicate shapes more than just morale. It affects trust, alignment, and long-term results. I have seen strong strategies fail because of poor communication, and average strategies succeed when the message was clear and consistent.

Most teams do not fail because of poor strategy. They fall apart because of mixed messages, such as excessive optimism, delayed candor, or silence when people need clarity.

Let’s talk about the good, the bad, and the ugly.

The Good

Good news looks easy. It rarely is.

A feature performs better than expected. Traffic grows. Leadership approves budget. A difficult project lands well with users. The numbers look good. The mood lifts.

The risk here is subtle.

Some leaders minimize success in the name of discipline: “Great, but let’s not celebrate too much.” The intention is focus. The effect is emotional flatness. Over time, people stop feeling that their work matters.

Some leaders exaggerate success. Every small win is called “a game changer.” Every milestone is “transformational.” This can feel exciting at first, but when reality sets in, people lose trust.

Good news is not about excitement. It is about pattern recognition.

If you share success without explaining why it happened, you are not leading. You are just reporting. And reporting is neutral. Leadership is interpretive.

• What exactly worked?

• Was it timing?

• Was it positioning?

• Was it cross-functional collaboration?

• Was it a risky decision that paid off?

Good news should make it clear which actions are worth repeating. It should help the team understand what success looks like. Credit should be given specifically, not just with a vague “great job, everyone.” Clear recognition builds pride and sets standards.

Celebration is useful. But reinforcement is strategic. Good news can boost energy if you handle it with discipline.

The Bad

Bad news is where leadership maturity becomes visible.

A deadline slips. A release underperforms. A budget is reduced. A strategic direction changes. A restructuring is announced.

There are predictable failure modes.

The first problem is the delay. Leaders hope the issue will go away or become less important, but that rarely happens. In the meantime, uncertainty spreads through the team.

The second problem is dilution. Leaders use soft language like “some challenges,” “temporary adjustments,” or “minor recalibration.” People pick up on the tone and sense something is wrong, but they cannot see the real problem. This makes anxiety grow.

The third problem is delegation. Leaders pass difficult messages down the chain. A manager might ask a team lead to share news that really came from above. The information may be accurate, but it does not feel like the right person is taking responsibility.

Bad news does not require drama. It requires structure.

• Here are the facts.

• Here are the constraints.

• Here is what we are doing.

• Here is what this means for you.

• Here is what remains uncertain.

Clarity reduces anxiety. Vagueness amplifies it.

Teams are surprisingly resilient when reality is explicit. What they struggle with is ambiguity disguised as comfort.

I have learned that the sooner you share bad news with context, the sooner your team can regain stability. If you stay silent, people create their own stories, and those stories are rarely positive.

Bad news, handled properly, builds credibility. It signals that you are not curating reality. You are sharing it.

The Ugly

The most complex category is neither success nor failure.

It is uncertainty.

Funding is under review. Strategic options are being considered. There are outside pressures that might affect your department. The market may be shifting, but it is not clear yet. A product experiment could change priorities or simply fade away.

This is where many leaders freeze.

Leaders worry about saying too much and being wrong later, so they say nothing. Sometimes they try to reassure the team too soon by saying, “Everything is fine.” But teams notice when something is off. They pick up on tension, see the signs, and read between the lines.

Uncertainty does not scare professionals. Lack of framing does.

The discipline here is subtle.

• Define what is known.

• Define what is not known.

• Set the next checkpoint, which is when you expect to have more clarity.

You do not need certainty. You need boundaries.

Sometimes the most powerful thing a leader can say is: “I don’t know yet. Here is what we are monitoring. Here is when we will revisit this.”

Authority is not built on omniscience. It is built on composure in ambiguity.

When uncertainty is acknowledged, teams can calibrate emotionally. When it is hidden, it grows in the shadows and turns into a rumor.

In my experience, unclear situations are when trust is either built or lost for good. In these moments, people pay more attention to what you do than what you say.

Sharing news is not a soft skill. It is a strategic one.

• Good news should reinforce what works.

• Bad news should clarify direction.

• Unclear news should define reality.

If you reflect honestly on your own leadership, which category do you handle worst?

• Is it the good news, because you move on too quickly?

• Is it the bad news, because you put it off?

• Or is it the ugly news, because uncertainty makes you uneasy?

The answer is usually personal. And rarely visible in a dashboard.

But your team always knows.

I believe in sticking to a clear work routine. Arrive on time, leave on time, respect weekends, and take your vacations. People with families, hobbies, and health concerns need this kind of structure.

But even so, I constantly catch myself checking email in the evening. Replying on Saturday. Clarifying something small during vacation. Not because someone demands it. Not because management pressures me. But because of a quiet internal calculation: “It is easier to fix this now than to deal with the consequences on Monday.”

Spending five minutes today can save two hours of trouble tomorrow. A quick answer can stop misunderstandings, and a fast decision can help others move forward. Operationally, this logic makes sense.

But this is where the trap starts.

When a few people keep acting this way, they slowly change what’s normal. Management notices quick responses, deadlines met, and problems avoided. The system looks efficient. But the hidden cost — personal time used to cover planning gaps — goes unnoticed.

Soon, weekend replies stop being rare and just become part of the routine. Someone who waits until Monday to respond might seem “less engaged.” The person who says, “I will finalize this over the weekend (despite a sick child at home),” starts to look like a quiet hero. It’s not officially required, but it’s quietly admired.

Hero culture is tempting. It feels productive, responsible, and grown-up. But often, it hides bigger problems like unrealistic planning, unclear priorities, not enough staff, poor delegation, or indecision from managers.

If deadlines are always saved by late-night work, the organization never learns to plan well. If getting things done depends on extra hours, the system doesn’t have enough resources. It just hasn’t realized it yet.

The hard truth is that many of us choose to take part in this cycle. It’s not because we’re afraid, but because we want to be efficient, professional, and believe that small actions now will stop bigger problems later.

And often, that’s true.

But lasting success doesn’t come from good intentions. It comes from setting clear boundaries.

I’m not saying we should become strict clock-watchers. Emergencies will happen. Product launches need extra effort. Sometimes, big problems mean late nights. Taking ownership is part of being a leader.

The real question is: are we just handling exceptions, or are we making them the new normal?

• If working on weekends is rare, it shows something urgent is happening.

• If weekend work becomes routine, it’s a sign that something is wrong.

Leaving the office on time isn’t lazy. It forces the organization to set better priorities, plan more realistically, and make real trade-offs instead of quietly taking up your personal time.

Still, next Saturday, I’ll probably check my inbox again.

This tension is real. The system rewards quick responses. I know that spending five minutes now can prevent a bigger mess later. But I also know that every small fix makes it more likely people will expect me to always step in.

Leadership isn’t just about fixing problems. It’s also about knowing which ones can wait.

The toughest boundary to set is the one with yourself.

Recently, I have heard people describe the future of work in dramatic terms. They say companies will soon have to choose between ‘expensive but productive AI’ and ‘cheap but slow humans.’ This idea is presented like a simple business decision: replace payroll with computers, swap salaries for hardware, and focus on efficiency.

This argument sounds convincing because it turns a complicated change into a simple choice. But the real situation is less dramatic. The best AI systems are not cheap. Advanced models use a lot of computing power. AI agents run many processes, use tools, and take time to reach results. Data centers and energy are limited. The most powerful AI is also often expensive to run. So, the choice is not just ‘AI is cheaper than humans.’ In many cases, it is ‘AI is more powerful, but not always cheaper.’

The real issue is not simply swapping expensive people for cheaper machines. It is about leverage. AI changes how much work one person can do, how much complexity a role can handle, and how much authority is needed for decisions.

So, instead of asking if AI will replace people, we should ask: which roles gain leverage as AI gets better, and which ones lose it?

The Real Situation: Human LeverageHuman LeverageHuman Leverage Quadrant

If we look beyond the headlines and think more broadly, we can map job roles using two simple factors.

The first factor is automation pressure, shown on the horizontal axis. This measures how structured and easy to measure the work is. If a task can be clearly defined, checked, and repeated, it can eventually be automated.

The second factor is human leverage, shown on the vertical axis. This shows how much decision-making, handling of uncertainty, and responsibility a role has. Jobs high on this axis do more than just complete tasks. They make choices, work with incomplete information, and face real consequences.

When we look at roles using these two factors, things become clearer.

In the bottom-right area, we find data entry clerks, scripted support jobs, and other routine roles. These jobs are in very structured settings and have little authority. It is not about intelligence. These roles just face the most automation pressure. As AI gets better, the value of repetitive work goes down.

In the top-left area, there are strategy leaders, senior product managers, and managing editors — people whose jobs mix uncertainty with decision-making power. These roles are not immune to AI, but they are harder to replace. AI can help with analysis, drafts, and simulations, but it cannot take on full responsibility or handle the politics of big decisions.

The most interesting area is the top-right, called the AI Leverage Zone. Here, we see product analysts, designers who use AI, and engineers who go beyond routine work. These jobs are structured but also have real influence. As AI gets better, these roles do not go away. Instead, they grow and use AI as a tool, rather than competing with it.

This is the key change. AI does not reward just intelligence. It rewards leverage. If your job is mostly about following set steps, AI will compete with you. If your job is about making decisions and setting direction, AI will help you do more.

This is a very different story from ‘AI versus humans.’ It is really ‘AI versus low-leverage work.’

Role Movement Under Increasing AI Capability

Now we reach the more complex and sometimes uncomfortable part. Job roles are not fixed points on a chart. They change over time.

As AI gets better, routine jobs tend to move lower and further right on the chart. These roles lose authority and face more automation pressure. This is not about right or wrong — it is about economics. When machines can do the same work at scale, the value of repetitive tasks drops.

Middle roles that mostly coordinate or pass along information, but lack real decision-making power, are also at risk. If a job is mainly about moving information between people or systems, AI will start to take over that work. Unless these roles gain more authority or strategic value, they will lose ground.

At the same time, roles that use AI effectively tend to move up. Engineers who build AI into systems become more influential. Analysts who manage AI models, instead of just making spreadsheets, become more valuable. Designers who guide AI tools, rather than creating everything by hand, increase both their output and their importance.

Even the top-left area shifts a bit to the right over time. Leaders who ignore AI risk losing their influence. Authority without technical skills slowly becomes just a title. The leaders who last will use AI in their decisions but still rely on their own judgment.

At this stage, a troubling pattern shows up. In the diagram, arrows in the top half mostly point upward, while those in the bottom half point downward. It seems like a story of growing inequality, with the successful gaining even more.

But this outcome depends on whether people and organizations can move up.

If people and organizations make it possible to move up, if structured roles gain AI skills and more decision-making power, then this model shows progress, not division. But if there is little mobility, then inequality will grow.

AI does not get rid of all jobs at once. It first removes low-leverage, internal roles. What is left are jobs that require higher-level judgment or very basic execution.

So the real question for all of us is not whether AI is coming. It is already here.

The question is both simple and challenging: Are we moving up in leverage faster than AI is improving in capability?

That is the real competition.

If you lead a product or engineering team, you have experienced this.

The organization runs smoothly. The newsroom publishes quickly. Deadlines are met, distribution grows, and nothing crashes during busy times. The system works.

No one mentions it.

But when something goes wrong — a story in the wrong section, a field filled out wrong, a workflow skipped, or a feature misunderstood — the reaction is quick and certain: “The technology failed.”

You realize it is not just about one incident. It is about a pattern.

In many organizations, especially mission-driven ones, product and engineering teams exist in a strange place. When things work, they are considered normal. When something fails, it becomes evidence.

Reliability has a strange effect: it makes itself invisible. The more stable your platform is, the less people notice it. Hundreds of successful publishing cycles seem ordinary. Smooth teamwork across regions is expected. High-traffic events without downtime feel routine. But none of this is actually routine. It is the result of architecture, infrastructure, and careful design decisions made years ago to prevent problems people no longer remember.

Still, reliability is rarely celebrated. People just assume it.

People remember the one failure, not the thousands of problems that were prevented.

There is also a more uncomfortable layer. When users ignore defined workflows, resist tools, misuse permissions, or simply choose convenience over process, it is often easier to blame the system than to confront behavior. Technology becomes the safest target. It does not argue. It does not feel offended. It does not escalate politically.

A subtle but powerful story takes hold: “If the system were designed properly, this wouldn’t have happened.”

There is some truth to this. Good design makes things easier. Strong user experience prevents many mistakes. Permissions and guardrails are important. But expecting technology to fully make up for human behavior is both comforting and unrealistic.

No road system can stop all reckless driving. No email client can prevent every message from going to the wrong person. No CMS can remove all judgment errors or rule-breaking. Technology can guide, but it cannot replace accountability.

If we do not clearly separate these issues, everything gets called a “tech” problem. When that happens, accountability becomes unclear, and the product team ends up bearing all the operational burden.

One simple change can shift the conversation: name the categories. When something goes wrong, separate platform defects from training gaps and from governance violations. Engineering owns defects. Knowledge gaps need training and support. Process violations need managers to step in. These distinctions are not about blame — they are about structure. Without them, stories become the main way people judge what happened.

There is another truth product leaders need to face. Being underappreciated is not always about unfairness. Sometimes it happens because your work isn’t being translated.

If you talk about your work in terms of tickets completed, refactoring, or infrastructure, but leadership cares about mission impact, audience reach, editorial speed, and risk, you are speaking different languages. Stability seems basic unless you show its impact. Saying “We optimized workflows” sounds technical, but “We reduced customer preparation time by nearly twenty percent” sounds strategic.

If you do not link the architecture to the mission, people stop noticing the architecture.

Product leadership also has a political side that many people do not like to talk about. In complex organizations, part of your job is to help people understand what causes problems. You need to define what counts as a system failure and what is a behavior issue. Make trade-offs clear before something goes wrong. Show the value of risk reduction, even if no one asked for it. If you only show up after things go wrong, people will link you to failures. But if you regularly explain how the platform supports the organization’s goals, you start to be seen as a strategic partner, not just a service provider.

Of course, not every organization just misunderstands technology. In some places, technology is always seen as a cost rather than as something that adds value. In these cases, better reporting will not change how people see it. The issue is not about being seen — it is about how people think.

This leads to a tougher, more personal question. Are you in a place that can change how it sees product work, or will it always treat infrastructure as something in the background?

This question matters because cultural debt builds up quietly. If your team keeps getting blamed for things they cannot control, morale drops long before you see it in the numbers. You can fix technical debt with time and money, but cultural debt grows quietly and is harder to fix.

Product leadership is not just about launching features or keeping systems stable. It is also about making sure everyone is clear on what the system does, what people are responsible for, and where accountability lies. If we do not set that clarity ourselves, someone else will do it for us.

And their version of clarity may not be generous.

Most project pain doesn’t show up with chaos or obvious mistakes. Instead, it comes quietly, as a familiar heaviness: another deadline that feels tight for no clear reason, another scope discussion that changes nothing, another delivery where everyone worked hard but still leaves tired and vaguely dissatisfied.

This is usually when people start blaming execution, communication, or alignment. Sometimes they blame the market or “the reality we’re in.” Almost never the real cause.

If this sounds familiar, it matters for a simple reason: this kind of pain builds up. It slowly eats away at credibility, energy, and trust until you only notice it when it feels normal.

Most of us have seen this pattern. A project starts with ambition and optimism. The scope is important, maybe even strategic. The deadline matters, often for outside reasons. The team is strong but “lean for now.” Everyone nods, understands the constraints, and agrees to “stay flexible.”

Yet somehow, all three sides of the triangle — scope, time, and resources — end up treated as non-negotiable.

This is where the trouble starts.

We often talk about the classic project triangle as something to balance. It sounds reasonable and professional. But balance is a comforting word that hides a hard truth: trade-offs aren’t balanced, they’re chosen or avoided. Avoiding them is still a choice; it just delays the cost.

I call this the Triangle of Sadness. Not because constraints are bad, but because pretending they don’t hurt is worse. The sadness isn’t in the triangle itself. It’s in the group decision to act as if commitment has no cost.

That’s why “marriage” is a better metaphor than “balance.” Marriage means exclusivity. If you marry scope, speed will suffer. If you marry time, ambition must narrow. If you marry fixed resources, you accept limits on both scope and pace. Any of these marriages can work, but you can’t secretly marry all three and hope no one notices.

What actually happens when we try is predictable. Scope quietly becomes tougher. Deadlines turn emotional instead of rational. Teams work harder. Quality slips. Temporary fixes become permanent. Heroics are praised. Fatigue becomes normal. Later, the project is called “challenging, but successful.”

This is usually when teams get blamed for not pushing back enough. That’s convenient, but mostly wrong. Teams don’t break the triangle. Organizations do, when they push unresolved trade-offs down and call it empowerment.

The real failure here isn’t delivery. It’s owning the decisions.

Someone, somewhere, wants certainty without paying for it. Leadership wants confidence. Product is asked to handle ambiguity. Delivery pays the price. Everyone stays polite. No one says the trade-off out loud. And when the project hurts, the triangle quietly makes the choice for you.

This keeps happening because the incentives are subtle. Optimism gets rewarded. Saying “we’ll figure it out” feels helpful. Naming trade-offs feels political. Ambiguity buys time until it gets expensive. By the time pain is obvious, it’s already seen as an execution problem, not a decision problem.

The irony is that none of this is new. The triangle isn’t a secret. Everyone knows about it. What’s rare is treating it as a real moment of truth, not just a diagram in a slide deck.

A project isn’t healthy just because it delivers everything on time with limited resources. That’s a slogan, not a strategy. A project is healthy when everyone can clearly say which side of the triangle was chosen, why, and by whom, and accept the consequences without surprise.

That kind of clarity doesn’t remove tension. It removes confusion. And confusion costs much more.

So here’s the uncomfortable question I keep asking: when your last project hurt, could everyone clearly name the trade-off that was made? Or did the Triangle of Sadness quietly decide for you while everyone stayed busy?

Because the triangle never goes away. It just waits until someone is honest enough to face it.

“Never let a good crisis go to waste” is often linked to Winston Churchill, though historians note he may not have said it exactly that way. Whether he did or not hardly matters. The phrase sticks because it’s true: crises change the rules. What seemed impossible yesterday can suddenly become possible, urgent, or even obvious.

In politics, people often view this idea with suspicion. A crisis can be used as an excuse to make decisions that would not pass in normal times. That view is not wrong. But in companies, products, and teams, the idea is less dramatic and much more practical.

Usually, organizations value stability above all. Roadmaps are treated as untouchable, and backlogs are managed with great care. Processes are protected like family traditions. People may agree something is broken, but it never seems urgent enough to fix. Then a crisis hits. Revenue falls, users leave, a platform policy changes, a regulator steps in, or a competitor makes a smart move. Suddenly, the same people who said “we can’t touch this” start asking, “what if we rebuild it completely?”

This is when product management proves its value.

A crisis makes priorities clear. Features that seemed “strategic” last quarter are revealed as unnecessary. Metrics that were once ignored can no longer be overlooked. Meetings get shorter, not because people improved, but because time now matters. In a crisis, the organization stops pretending to be perfect and shows its true nature: a group of people trying to get through tough times.

For product teams, this is both uncomfortable and powerful. Many decisions that were delayed finally get made. Old features that stayed only because “someone important once asked for them” are now questioned. Technical debt, once ignored, is now seen as a real problem. The crisis allows people to speak openly about issues that were only mentioned quietly before.

Of course, not every crisis leads to good results. Some teams freeze, some panic, and others work hard on the wrong things. “Never let a good crisis go to waste” does not mean acting without a plan. It means using the time when people are open to change to do what was needed all along.

There’s another hard truth. Crises show who was really thinking and who was just following orders. Product strategies that only worked in calm times often fail right away. The ones that last are usually simple: focused on users, strict about value, and careful with metrics. A crisis doesn’t create good product thinking, but it does take away the excuses that hide its absence.

Here’s the final irony. After a crisis ends, organizations quickly forget. Old habits come back. Emergency decisions become “temporary solutions” that last for years. The clarity disappears faster than expected. The real waste is not failing during a crisis, but surviving it and then acting as if nothing changed.

If a crisis happens, whether big or small, inside or outside the company, the worst thing to do is treat it only as a problem to fix. It’s also a chance for focus, leverage, and honesty. It’s painful and stressful, but it’s also a rare moment of truth.

In product management, honesty is rare. When it appears, it should not be wasted.

Let’s talk about KPIs. We may not love them, but they are always part of the conversation.

I like the term ‘perverse incentives.’ It may sound academic, but the idea is simple. You try to fix a problem by introducing a KPI. People follow the KPI exactly, but the problem actually gets worse.

A classic example is the Cobra Effect. During British rule in India, officials wanted to reduce venomous snakes in Delhi. They offered a reward for every dead cobra. The goal was clear, the incentive made sense, and the plan seemed perfect.

But then locals began breeding cobras at home. When the program ended, they released the now-worthless snakes. Instead of fewer cobras, there were even more than before. The KPI was achieved, but the real goal was lost.

Most experienced product managers hear this story, nod, and think, ‘Of course.’ Then they return to work and set up a KPI that does something similar, only with better charts.

You’ve probably seen KPIs for delivery speed that teach teams to treat quality as optional. Or engagement KPIs that push for features that are addictive, like junk food. Or growth KPIs that turn users into numbers to acquire, nudge, retain, and monetize, while trust gets ignored.

This isn’t because people are foolish or have bad intentions. It happens because KPIs are strong tools that influence behavior. They don’t just measure what’s happening — they change it. People focus on what you measure, not what you actually want.

The risky part is that KPIs seem objective and scientific. They fit neatly into dashboards and reports. Even when things go wrong, the numbers can look good for a long time. Velocity, output, and adoption may rise, but underneath, complexity, fatigue, and resentment can also grow — though those rarely show up in charts.

In product management, people often say, ‘what gets measured gets managed.’ But that’s only partly true. What gets measured gets optimized. If you optimize without good judgment, you risk creating your own cobra problem.

The hard truth is that many important product signals are difficult to measure with simple KPIs. Things like user trust, editorial integrity, long-term maintainability, and the difference between ‘people clicked’ and ‘people benefited’ are real, even if your dashboard can’t track them.

As a product leader, your job isn’t to ignore KPIs, but to keep questioning them. What behavior does this KPI encourage? What shortcuts might it allow? What would a smart, motivated team do if this number became their top priority?

If you can’t answer those questions, you’re not really managing performance. You’re running a cobra farm.

And sooner or later, the snakes will get out.

In every product role, someone eventually says, “Let’s do more research to be safe.”

It sounds responsible and mature, like something a good product manager should say. Sometimes, it’s the right move. But just as often, this is how decisions quietly die, buried under interviews, dashboards, and polished slides that change nothing.

This is where the idea of Expected Value of Information (EVI) helps, even if you never use the term in a meeting.

EVI is a simple idea. Information isn’t valuable by default; it only matters if it improves a decision. More specifically, it’s valuable if the expected improvement in outcomes is greater than the cost of getting that information, including time, money, and delays.

In product management, this matters because learning always has a cost. User interviews take time. Prototypes slow down delivery. Experiments use up engineering resources. Waiting for more data often means not shipping, not committing, and not learning from real-world feedback. EVI asks a tough question: what decision will actually change if we get this new information?

If the honest answer is “none,” then the expected value of that information is almost zero, no matter how interesting it seems.

Good product managers use EVI all the time, often without calling it that. Imagine you’re thinking about a feature that will take three months to build, but you’re not sure if users really need it. A week of interviews and a quick prototype might show the problem isn’t that big. In this case, that information could save months of work. There’s high uncertainty, a high cost if you’re wrong, and a low cost to learn — so EVI is very high. Here, research isn’t just justified; it would be irresponsible not to do it.

Now, consider a different situation. A third-party API you use is being shut down, so you have to migrate. There’s no other option. Running discovery workshops or user interviews won’t change the decision — the work has to be done. Any extra research might feel useful, but from an EVI perspective, it’s just for show. In this case, getting the work done matters more than being curious.

Prioritization is another area where EVI quietly sets strong product leaders apart from busy ones. Teams often debate whether to improve onboarding or build advanced features for power users. Both seem important. A small piece of information, like learning that 40 percent of users never finish onboarding, can completely change the roadmap. In that moment, a simple funnel analysis is extremely valuable because it changes the order of work, not just the team’s confidence.

EVI also explains why product strategy often feels slower and heavier than feature work. Strategic decisions are expensive, long-lasting, and hard to undo. Entering a new market, choosing a pricing model, or picking a core platform locks you in. The cost of being wrong is measured in years, not sprints. In these cases, even costly information can be worth it compared to the risks. A legal review, a pilot launch, or a partner conversation might seem slow, but their expected value is often very high.

Pricing decisions are a good example. Launching a new premium tier affects revenue, positioning, and trust. A fake-door test or a few tough conversations with real customers can prevent a very public mistake. When pricing goes wrong, it almost never fails quietly.

On the other end, some decisions lead teams to over-invest in learning. For example, a copy change on a low-traffic internal tool doesn’t need an experiment plan, research brief, and stakeholder review. In these cases, shipping and watching what happens is usually the smart move. The decision can be reversed, the risk is small, and the EVI of more information is close to zero.

EVI helps product teams avoid two extremes. One is analysis paralysis, where learning replaces decision-making. The other is reckless execution, where teams mistake speed for courage. EVI offers a better way: learn actively when it can change the outcome, and act quickly when it can’t.

The most useful EVI question isn’t “do we need more data?” but “what would we do differently if this turns out to be false?” If there’s no clear answer, it’s often smartest to stop researching and start shipping.

Information isn’t a virtue. Making decisions is.

For many teams, “firefighting” isn’t just a metaphor anymore. It’s what they do every day. When something breaks, a stakeholder complains, a customer is waiting, or a deadline is missed, everyone jumps into action. Meetings get canceled, important details are lost, priorities change quickly, and for a short time, everyone feels busy and important.

This is what firefighting often looks like: a serious bug found too late, a launch delayed at the last minute, or an urgent request that skips all the usual planning. Sometimes, a system only works because a few people know the hidden tricks. These situations bring excitement, stories, and sometimes even rewards. But they also create the false idea that this is how work should be.

Organizations handle firefighting in different ways. Some openly praise it, celebrating those who “save the day,” valuing being available over being sustainable, and mixing up stress with real importance. Others claim to dislike firefighting, but still set up processes that lead to more emergencies. Some teams even believe their problems are special, saying, “This one is different,” again and again.

The real causes of these emergencies are usually clear. They come from delayed decisions, unclear roles, poor teamwork, unspoken assumptions, fragile systems, and rewards for speed instead of careful thinking. Emergencies rarely happen because of one bad day. They build up from many small choices that seemed fine at the time.

Constant firefighting leads to more than just burnout, though burnout comes quickly. First, quality drops because fixes are rushed and don’t last. Then, trust fades as deadlines lose meaning and promises change. Long-term planning is pushed aside because urgent problems always come first. Over time, the organization gets good at reacting but loses the ability to think ahead.

Why is it so hard to set up work to prevent emergencies? One reason is that prevention is invisible — no one notices the problems that never happen. Prevention also means saying no, slowing down, and making clear decisions, which can feel uncomfortable, especially where being busy is seen as progress. Firefighting also gives people a sense of control, even if it doesn’t last.

Looking for root causes isn’t as exciting as fixing emergencies, but it works better. It starts by not rushing ahead. Ask not just what failed, but why it could fail in the first place. Ask which warning signs were missed, which assumptions went unchecked, and which risks were accepted without responsibility. Most importantly, ask if the organization learned anything or just got through another crisis.

Solving root problems needs strategies that may seem dull compared to emergencies. Make sure everyone knows who owns what, so issues don’t get lost between teams. Make work clear enough that problems show up early, not at the last minute. Build systems that fail in obvious and safe ways, not quietly and disastrously. And set up rewards so that preventing problems matters as much as fixing them.

Leaders are important here, but not as heroes. They set the tone by what they reward, allow, and overlook. If people see that escalation works better than planning, they will escalate. If last-minute efforts get praise but quiet prevention is ignored, emergencies will keep happening. Good leadership is less about putting out fires and more about making sure they don’t start again.

Team members also play an active role. Their habits, shortcuts, and silence shape how things work. Speaking up about bigger issues, keeping track of decisions, questioning fake urgency, and making time for real work aren’t rebellious — they’re professional. If a team never pushes back against chaos, it eventually becomes part of the problem.

The hard truth is that many organizations are hooked on firefighting. It feels busy, obvious, and emotionally satisfying. Solving deeper problems feels slow, unclear, and often goes unnoticed. But only real problem-solving can grow with the company. Only it makes room for strategy, quality, and people who want to stay for the long term.

Sometimes, you have to put out fires. But choosing to build a system that doesn’t keep catching fire is up to you.

Every few months, familiar headlines appear again: “The Death of Agile” or “Why Big Tech Is Quietly Killing Scrum.”

The headlines may change, but the message stays the same. Scrum is called outdated, Agile is seen as misunderstood, and somewhere a burn-down chart quietly vanishes from a Jira board.

Is any of this true? In part, yes. But it is not as dramatic as these articles make it sound.

What is really happening is not a revolution, but a slow and awkward step back. The core ideas of Agile — iteration, fast feedback, incremental delivery, and learning by doing — are still strong. What is fading is the version of Scrum that feels like a corporate ritual, with required sprint meetings, an obsession with velocity, endless story point debates, and calendars packed just to look busy.

Large organizations did not suddenly decide to get rid of Scrum. They found that, at scale, Scrum often creates more show than real value. When teams deploy all the time, priorities shift every week, and much of the work is unplanned or comes from interruptions, two-week sprints start to feel like pretending the weather is always the same just because the forecast meeting is on the calendar.

So, Agile is not dead. It has just moved into what you could call its ‘post-framework’ phase.

In this phase, most companies are not swapping Scrum for one new method. Instead, they are building ways of working that match their real needs, not just what coaches recommend. This is when you start to see a range of alternatives appear.

The first and most common change is moving to flow-based delivery, often called Kanban or, more honestly, ‘Scrum without the parts we were pretending about.’ This approach works best when work arrives unpredictably, like in platform teams, infrastructure, editorial tools, internal products, or anything close to operations. In these settings, trying to plan all work into sprints is unrealistic. Flow-based teams focus less on making promises and more on keeping work moving: how long tasks wait, how quickly they progress, and how often they reach users. This suits organizations that prefer steady productivity over dramatic sprint finishes and teams that are tired of explaining why ‘this urgent thing was not planned.’

Another change, especially in product organizations, is splitting discovery and delivery into a continuous dual-track model. This shows up when teams realize their main issue is not how fast they build, but whether they are building the right things. These teams can deliver quickly but often wonder why users do not want what they made. Continuous discovery lets product managers and designers test ideas and prototypes without holding up engineers, while delivery continues as a steady stream of clear work. This model works well for digital products with real users, strong analytics, and leaders who see learning as part of the job, not a distraction.

Another trend is the quiet rise of DevOps metrics as a way to manage teams. In many organizations, story points faded away not because they were wrong, but because they did not mean much outside the team. Executives never really understood velocity, and teams did not think it mattered. Flow and reliability metrics changed this. Measures like deployment frequency, lead time, failure rates, and recovery time are things that engineering, product, and leadership can all agree on. This approach works best for organizations focused on reliability, scale, and operational excellence, such as SaaS, media platforms, and infrastructure-heavy companies. It shifts the question from ‘Did you deliver what you planned?’ to ‘Is the system getting healthier over time?’, which is a tougher and better question.

On another level, there is organizational design, often described through ideas like Team Topologies. This is not just a team method; it is a recognition that no process can fix a poorly designed organization. When teams are overloaded, rely on others, and are unclear about who owns what, more sprint planning will not help. This approach is best for large organizations where coordination is harder than delivering work, and the main problem is mental overload, not individual speed. It is often adopted after years of trying Agile without understanding why things still move slowly.

Finally, there is a model that makes Agile purists uneasy: appetite-based planning, best known as Shape Up. This method works in product companies with strong leadership and stable priorities. Instead of keeping endless backlogs, teams define problems early and commit to a set time frame with flexible scope. It is not more flexible, but it is more decisive. It fits organizations that trust experienced product leaders and want fewer changes in the middle of a cycle. It does not work well where leaders cannot stop interfering with ongoing work, which, to be honest, is common.

Taken together, these models are not a new set of rules. They are a way out.

The main point is not that people are rejecting Agile values, but that they are rejecting fake Agile practices. Teams are tired of acting like uncertainty can be planned out, that velocity means value, and that meetings count as progress. Organizations are moving away from Scrum not because they dislike Agile, but because they are finally taking it seriously.

Scrum is not dead. It is just not the default answer for everything anymore. In a way, that might be the most Agile result of all.