From Using AI to Running AI: The Next Skill Gap

The biggest mistake leaders are making right now is framing the next era as a contest between humans and AI.

That is not what is happening inside high-performing teams. The real separation is already showing up somewhere else: between people who use AI and people who orchestrate it.

AI users get output. AI orchestrators get outcomes.

AI users treat the model like a clever intern. They prompt, they paste, they polish. Their ceiling is the quality of a single interaction.

AI orchestrators design a system where multiple interactions, tools, guardrails, and humans combine into a reliable workflow. They turn “a helpful answer” into “a completed job.” They stop thinking in prompts and start thinking in production.

You can see the industry converging on this. Microsoft is explicitly pushing “multi-agent orchestration” in Copilot Studio, including patterns for handoffs, governance, and monitoring because real work is rarely single-step. (Microsoft) OpenAI’s own guidance leans into the same idea: routines, handoffs, and coordination as the core primitives for building systems you can control and test. (OpenAI Developers) Anthropic draws a clean distinction between workflows that are orchestrated through predefined paths and agents that dynamically use tools, then spends most of its energy on what makes those systems effective in practice. (Anthropic) LangGraph has effectively positioned itself as the “agent runtime” layer for state, control flow, and debugging, which is exactly what orchestration needs when you leave toy demos behind. (LangChain)

This is why “AI literacy” is quickly becoming table stakes and then getting commoditized. Everyone will learn to prompt. Everyone will learn to generate code, slides, summaries, and drafts. That advantage collapses fast.

Orchestration does not collapse fast because it is not a trick. It is an operating model.

What an AI orchestrator actually does

Orchestration is not “use more agents.” Orchestration is the discipline of turning messy work into a repeatable machine without pretending the work is clean.

An orchestrator:

  • Breaks work into steps that can be delegated and verified, not just executed.
  • Connects AI to the real world through tools, systems, and data.
  • Designs handoffs, failure modes, and escalation paths as first-class product features. (Microsoft Learn)
  • Builds observability so you can debug behavior, not just admire outcomes. (Microsoft Learn)
  • Treats evaluation as a release gate, not a vibe check. (Anthropic)

That is why orchestration is showing up everywhere as “multi-agent,” “tool use,” and “workflows vs agents.” It is the same idea wearing different vendor hoodies. (Anthropic)

The uncomfortable truth: orchestration is where leadership lives

If you are a CTO, CPO, or head of product engineering, here is the quiet part out loud: orchestration forces accountability.

Prompting lets teams hide behind cleverness. Orchestration exposes whether you actually understand how value is created in your business.

Because the minute you try to orchestrate, you run into the real constraints:

  • Your data is scattered, permissions are inconsistent, and definitions disagree.
  • Your process is tribal knowledge, not a system.
  • Your edge cases are the product.
  • Your compliance needs are not optional, and your audit trail is not “we asked the model nicely.” (Microsoft Learn)

That is also why orchestration is a strategic advantage. It is hard precisely because it sits at the intersection of product, engineering, operations, security, and change management.

Why “AI users” will hit a wall

AI users become faster individuals. That is useful, but it is not compounding.

They save time on tasks that were never the bottleneck. They produce more artifacts, not more outcomes. They accelerate local productivity while the organization still moves at the speed of coordination.

Orchestration compounds because it scales across people. It turns expertise into a reusable workflow. It captures institutional knowledge in a living system, not in the heads of your best operators.

If you want a practical mental model, stop asking: “How do we get everyone to use AI?”

Start asking: “Which workflows, if orchestrated, would change our unit economics?”

A real-world smell test for orchestration readiness

If any of these sound familiar, you do not have an AI problem. You have an orchestration problem.

  • “We have great pilots, but nothing sticks.”
  • “We got a productivity bump, but delivery still feels chaotic.”
  • “We cannot trust outputs enough to automate anything material.”
  • “We are worried about security and compliance, so we are stuck in chat mode.”
  • “Everyone uses different prompts and gets different answers.”

Those are not model problems. Those are design problems.

The playbook: how teams move from AI use to AI orchestration

You do not need a moonshot. You need a workflow that matters, a thin orchestration layer, and ruthless clarity about quality.

  1. Pick one workflow with real stakes. Something with a clear definition of done. Not “research,” not “brainstorming.” Pick a job like triaging incidents, drafting customer responses with policy constraints, or converting messy inputs into structured records.
  2. Separate roles. Planning, execution, validation, and reporting should not be the same agent or the same step. That separation is the difference between a demo and a system. (OpenAI Developers)
  3. Build handoffs and guardrails, not a super-agent. Multi-agent orchestration exists because specialization plus controlled delegation is easier to debug and govern. (Microsoft)
  4. Make observability mandatory. Logging, tracing, and transcripts are not enterprise overhead. They are how you make AI behavior operational. (Microsoft Learn)
  5. Treat evaluation like CI. Define tests for correctness, policy compliance, and failure modes. If you cannot measure quality, you cannot scale automation. (Anthropic)

The new career moat

In the next two years, “good at prompting” will be like “good at Google.”

Nice. Expected. Not differentiating.

The career moat, and the organizational moat, belongs to the people who can do all of this at once:

  • translate business intent into workflows
  • connect tools and data safely
  • design guardrails and evaluation
  • ship systems that survive contact with reality

That is the orchestrator.

So yes, the gap will widen. But it will not be AI vs humans.

It will be AI users who generate more content versus AI orchestrators who design machines that reliably produce outcomes.

The Iron Triangle Is Back. AI Just Made It Sharper.

Every decade, the tech industry rediscovers a timeless truth and tries to dress it up as something new. Today’s version comes wrapped in synthetic intelligence and VC-grade optimism. But let’s be honest: AI did not kill the Iron Triangle. It fortified it.

For years we have preached that product decisions always balance quality, speed, and cost. You can choose two. The third becomes the sacrifice. AI arrives and many leaders immediately fantasize that this constraint has dissolved. It has not. It has only changed the failure modes.

AI accelerates coding. AI accelerates design. AI accelerates analysis. But the triangle still stands. What changes is which side collapses first and how painfully.

AI Makes “Fast” Frictionless and That Is the Problem

Teams adopt AI believing speed is now the default output. And in a sense it is. Prompt, generate, review, refine, and in minutes you have something that would have taken hours.

But the moment speed becomes effortless, the other two sides of the triangle take the hit.

Where things break:

  • Quality erodes quietly. Models hallucinate domain logic that engineers fail to notice. It compiles, it runs, and it is dangerously wrong.
  • Architectural discipline collapses. AI can ship features faster than teams can design scalable foundations. The result is a time bomb with fancy UX.
  • Costs compound through rework. The speed you gained upfront becomes technical debt someone must pay later, usually at triple the price.

AI made it easy to go fast. It did not make it safe.

AI Can Make Things “Cheap” but Often Only on Paper

Executives love AI because it hints at lower staffing costs, faster cycles, and higher margins.
They imagine a world where a handful of developers and designers can do the work of an entire department.

But here is the uncomfortable truth:

AI reduces the cost of creation, not the cost of correction.

The cheapest phase of a project is the moment you generate something. The most expensive phase is everything that comes after:

  • validating
  • integrating
  • securing
  • governing
  • maintaining
  • debugging
  • explaining to auditors why your model embedded training data into a client deliverable

AI does not make product development cheap. It simply delays the bill.

AI Promises “Quality” but Delivers Illusions of It

Platforms brag about AI-enhanced quality: fewer bugs, cleaner architecture, automated testing, smarter design. In reality, quality becomes performance theater unless teams evolve how they think, work, and review.

Common pitfalls:

  • AI code looks clean, reads well, and still violates half your constraints.
  • AI documentation is confident and completely fabricated.
  • AI test cases are shallow unless you explicitly direct them otherwise.

AI produces confidence without correctness. And too many leaders mistake the former for the latter. If you optimize for quality using AI, you must slow down and invest in human review, architecture, governance, and domain expertise. Which means speed suffers. Or costs rise.

The triangle always demands a price.

The Harsh Truth: AI Did Not Break the Triangle. It Exposed How Many Teams Were Already Cheating.

Before AI, many organizations pretended they could have all three. They could not, but the inefficiencies were human and therefore marginally manageable.

AI amplifies your ambition and your dysfunction.

  • Fast teams become reckless.
  • Cheap teams become brittle.
  • Quality-obsessed teams become paralyzed.

AI accelerates whatever you already are. If your product culture is weak, AI makes it weaker. If your engineering fundamentals are fragile, AI shatters them.

So What Do Great Teams Do? They Choose Deliberately.

The best product and engineering organizations do not pretend the triangle is gone. They respect it more than ever.

They make explicit choices:

  • If speed is the mandate, they pair AI with strict guardrails, strong observability, and pre-defined rollback paths.
  • If cost is the mandate, they track total lifecycle cost, not just dev hours.
  • If quality is the mandate, they slow down, invest in architecture, require human-in-the-loop validation, and accept that throughput will dip.

Great teams do not chase all three. They optimize two and design compensations for the third.

The Takeaway: AI Is Not a Shortcut. It Is a Magnifier.

AI does not free you from the Iron Triangle. It traps you more tightly inside it unless you understand where the real constraints have shifted.

The leaders who win in this era are the ones who stop treating AI as magic and start treating it as acceleration:

  • Acceleration of value
  • Acceleration of risk
  • Acceleration of consequences

AI is a force multiplier. If you are disciplined, it makes you unstoppable. If you are sloppy, it exposes you instantly.

AI did not remove the tradeoffs.
It made them impossible to ignore.

When Product Management Turns Into a Feature Factory

There is a point in every product organization where you can feel the shift. The roadmap gets longer. The backlog turns into a dumping ground for requests. The strategic narrative fades as the team becomes obsessed with throughput instead of outcomes. Somewhere along the way, product management stops being a strategic function and becomes a feature factory.

A feature factory is not just a bad habit. It is a structural failure. It is what happens when product managers are rewarded for saying yes, praised for velocity instead of value, and pulled into a cycle where their identity is tied to shipping rather than solving. The result is predictable. Teams build more. Customers benefit less. Companies lose ground and cannot explain why.

This post outlines how to identify when this shift is happening, what to do to avoid it, and the rare moments when accepting some feature factory behavior is the right move.

How to Identify a Feature Factory

1. Roadmaps read like grocery lists

A healthy roadmap is a narrative. It sets direction, creates context, and tells the story of where the product is going. When product management degrades into a feature factory, roadmaps lose this arc. They become tactical lists without a strategic spine.

2. Success is measured by output instead of outcomes

If conversations center on volume of shipped features rather than customer adoption, retention, or improved workflows, the factory is already running. Output becomes the proxy for impact and nobody notices when outcomes stall.

3. Product managers stop saying “no”

A strong product leader protects the product from noise. A weak one treats every request as valid and every stakeholder as a customer. When product management turns into a service desk, feature factory dynamics take hold.

4. Discovery becomes optional

A factory does not ask questions. It executes. When discovery is skipped, compressed, or treated as a luxury, the team is no longer building a product. They are manufacturing items that nobody validated.

5. The backlog is full of requests, not problems

The moment a backlog is dominated by “build X” instead of “solve Y,” you are dealing with a production line.

What to Do to Avoid the Feature Factory Trap

1. Establish a strategic narrative

Most feature factory behavior stems from the absence of a clear strategic point of view. Create a narrative that explains the future of the product and anchors decisions. Without strategy, execution becomes random.

2. Make problem statements mandatory

Require every feature request to contain a clear definition of the problem and the measurable impact. Without this rule, teams will overload themselves with solutions that lack purpose.

3. Treat discovery as a non negotiable discipline

Real discovery forces teams to question assumptions, evaluate alternatives, and validate outcomes. Build repeatable rituals for discovery and protect them with the same rigor used for delivery.

4. Communicate tradeoffs publicly

Feature factories thrive in silence. If leaders make tradeoffs visible and show what they are choosing not to do, teams will stop chasing volume for its own sake.

5. Drive incentives around client impact

If your performance culture celebrates shipping velocity, you will get shipping velocity. If you celebrate outcome velocity, you will get strategic progress.

When It Is Acceptable to Act Like a Feature Factory

There are rare moments when a factory mindset is both practical and necessary.

1. Stabilization periods

When the product has major reliability problems, the priority shifts to fixing issues as fast as possible. This is not strategy. This is survival.

2. Mandatory compliance requirements

Some obligations must be met. There is no strategic brilliance in responding to a new regulatory rule. Sometimes the right answer is to implement quickly and move on.

3. Short term commercial commitments

There are moments when a large enterprise client needs something specific to move forward. When the commercial value is clear and time bound, the team may need to operate with a delivery first approach. This should be done openly and with an understanding that it is temporary.

4. Technical debt reduction cycles

Technical debt requires systematic removal. These cycles often resemble factory work because the focus is narrow and execution heavy. The strategic value emerges later through improved velocity and quality.

In the end

A product organization that allows itself to drift into a feature factory is not simply making a tactical mistake. It is abandoning the core purpose of product management. Once the team becomes defined by volume instead of value, strategic clarity evaporates, talent erodes, and the product becomes indistinguishable from any commodity tool in the market.

The real danger is not that teams ship too much. The real danger is that they stop thinking. They stop challenging assumptions. They stop shaping the future of the business. They become efficient at the wrong things.

Leaders who tolerate this drift are choosing short term comfort over long term competitiveness. They are trading strategic advantage for a temporary sense of productivity. It is a quiet form of organizational self harm.

Great product companies refuse to operate this way. They treat strategy as a discipline, discovery as a requirement, and outcomes as the only scoreboard that matters. Anything less is not product management. It is administrative labor wrapped in a product title.

If your team feels like a factory, the problem is not capacity. The problem is leadership.

Idea to Demo: The Modern Operating Model for Product Teams

Most product failures do not start with bad intent. They start with a very normal leadership sentence: “We have an idea.”

Then the machine kicks in. Product writes a doc. Engineering estimates it. Design creates a few screens. Everyone nods in a meeting. Everyone leaves with a different movie playing in their head. Two months later, we discover we built the wrong thing with impressive efficiency.

If you want a practical, repeatable way to break that pattern, stop treating “demo” as something you earn at the end. Make it the thing you produce at the beginning.

Idea to demo is not a design preference. It is an operating model. It pulls product management and product engineering into the same room, at the same time, with the same object in front of them. It forces tradeoffs to show up early. It replaces vague alignment with shared context, shared ownership, and shared responsibility.

And in 2026, with AI prototyping and vibecoding, there is simply no excuse for big initiatives or even medium-sized features to stay abstract for weeks.

“A demo” is not a UI. It is a decision

A demo is a working slice of reality. It can be ugly. It can be mocked. It can be held together with duct tape. But it must be interactive enough that someone can react to it like a user, not like a reviewer of a document.

That difference changes everything:

  • Product stops hiding behind language like “we will validate later.”
  • Engineering stops hiding behind language like “we cannot estimate without requirements.”
  • Design stops being forced into pixel-perfect output before the shape of the problem is stable.

A demo becomes the shared artifact that makes disagreement productive. It is much easier to resolve “Should this step be optional?” when you can click the step. It is much harder to resolve in a doc full of “should” statements.

This is why “working backwards” cultures tend to outperform “hand-off” cultures. Amazon’s PR/FAQ approach exists to force clarity early, written from the customer’s point of view, so teams converge on what they are building before scaling effort. (Amazon News) A strong demo does the same thing, but with interaction instead of prose.

AI changed the economics of prototypes, which changes the politics of buy-in

Historically, prototypes were “expensive enough” that they were treated as a luxury. A design sprint felt like a special event. Now it can be a Tuesday.

Andrej Karpathy popularized the phrase “vibe coding,” describing a shift toward instructing AI systems in natural language and iterating quickly. (X (formerly Twitter)) Whether you love that phrase or hate it, the underlying point is real: the cost of turning intent into something runnable has collapsed.

Look at the current tool landscape:

  • Figma is explicitly pushing “prompt to prototype” workflows through its AI capabilities. (Figma)
  • Vercel’s v0 is built around generating working UI from a description, then iterating. (Vercel)
  • Replit positions its agent experience as “prompt to app,” with deployment built into the loop. (replit)

When the cheapest artifact in the room is now a runnable demo, the old sequencing of product work becomes irrational. Writing a 12-page PRD before you have a clickable or runnable experience is like arguing about a house from a spreadsheet of lumber instead of walking through a frame.

This is not just about speed. It is about commitment.

A written document is easy to agree with and easy to abandon. A demo creates ownership because everyone sees the same thing, and everyone’s fingerprints show up in it.

Demos create joint context, and joint context creates joint accountability

Most orgs talk about “empowered teams” while running a workflow that disempowers everyone:

  • Product “owns” the what, so engineering is brought in late to “size it.”
  • Engineering “owns” the how, so product is kept out of architectural decisions until they become irreversible.
  • Design “owns” the UI, so they are judged on output rather than outcomes.

Idea to demo rewires that dynamic. It creates a new contract: we do not leave discovery with only words.

In practice, this changes the first week of an initiative. Instead of debating requirements, the team debates behavior:

  • What is the minimum successful flow?
  • What is the one thing a user must be able to do in the first demo?
  • What must be true technically for this to ever scale?

That third question is where product engineering finally becomes a co-author instead of an order-taker.

When engineering participates at the start, you get better product decisions. Not because engineers are “more rational,” but because they live in constraints. Constraints are not blockers. Constraints are design material.

The demo becomes the meeting point of product intent and technical reality.

The hidden superpower: demos reduce status games

Long initiatives often become status games because there is nothing concrete to anchor the conversation. People fight with slide decks. They fight with vocabulary. They fight with frameworks. Everyone can sound right.

A demo punishes theater.

If the experience is confusing, it does not matter how good the strategy slide is. If the workflow is elegant, it does not matter who had the “best” phrasing in the PRD.

This is one reason Design Sprint-style approaches remain effective: they compress debate into making and testing. GV’s sprint model is built around prototyping and testing in days, not months. (GV) Even if you never run a formal sprint, the principle holds: prototypes short-circuit politics.

“Velocity” is the wrong headline. Trust is the payoff.

Yes, idea to demo increases velocity. But velocity is not why it matters most.

It matters because it builds trust across product and engineering. Trust is what lets teams move fast without breaking each other.

When teams demo early and often:

  • Product learns that engineering is not “blocking,” they are protecting future optionality.
  • Engineering learns that product is not “changing their mind,” they are reacting to reality.
  • Design learns that iteration is not rework, it is the process.

This is how you get a team that feels like one unit, not three functions negotiating a contract.

What “Idea to Demo” looks like as an operating cadence

You can adopt this without renaming your org or buying a new tool. You need a cadence and a definition of done for early-stage work.

Here is a practical model that scales from big bets to small features:

  1. Start every initiative with a demo target. Not a scope target. A demo target. “In 5 days, a user can complete the core flow with stubbed data.”
  2. Use AI to collapse the blank-page problem. Generate UI, generate scaffolding, generate test data, generate service stubs. Then have humans make it coherent.
  3. Treat the demo as a forcing function for tradeoffs. The demo is where you decide what you will not do, and why.
  4. Ship demo increments internally weekly. Not as a status update. As a product. Show working software, even if it is behind flags.
  5. Turn demo learnings into engineering reality. After the demo proves value, rewrite it into production architecture deliberately, instead of accidentally shipping the prototype.

That last step matters. AI makes it easy to create something that works. It does not make it easy to create something that is secure, maintainable, and operable.

The risks are real. Handle them with explicit guardrails.

Idea to demo fails when leaders mistake prototypes for production, or when teams treat AI output as “good enough” without craftsmanship.

A few risks worth calling out:

  • Prototype debt becomes production debt. If you do not plan the transition, you will ship the prototype and pay forever.
  • Teams confuse “looks real” with “is real.” A smooth UI can hide missing edge cases, performance constraints, privacy issues, and data quality problems.
  • Overreliance on AI can reduce human attention. There is growing debate that vibe-coding style workflows can shift attention away from deeper understanding and community feedback loops, particularly in open source ecosystems. (PC Gamer)

Guardrails solve this. The answer is not to avoid demos. The answer is to define what a demo is allowed to be.

As supporting material, here is a simple checklist I have seen work:

  • Label prototypes honestly: “demo-grade” vs “ship-grade,” and enforce the difference.
  • Require a productionization plan: one page that states what must change before shipping.
  • Add lightweight engineering quality gates early: basic security scanning, dependency hygiene, and minimal test coverage, even for prototypes.
  • Keep demos customer-centered: if you cannot articulate the user value, the demo is theater.
  • Make demos cross-functional: product and engineering present together, because they own it together.

The leadership move: fund learning, not just delivery

If you want teams to adopt idea to demo, you have to stop rewarding only “on-time delivery” and start rewarding validated learning. That is the executive shift.

A demo is the fastest way to learn whether an initiative is worth the next dollar. It is also the fastest way to create a team that acts like owners.

In a world where AI can turn intent into interfaces in minutes, your competitive advantage is no longer writing code quickly. It is forming conviction quickly, together, on the right thing, for the right reasons, and then applying real engineering discipline to ship it.

The companies that win will not be the ones with the best roadmaps. They will be the ones that can take an idea, turn it into a demo, and use that demo to align humans before they scale effort.

That is how you increase velocity. More importantly, that is how you build teams that are invested from day one.

Tunneling in Product Management: Why Teams Miss the Bigger Play

Tunneling is one of the quietest and most corrosive forces in product management. I was gifted Upstream by Dan Heath from a product leader, and of course it was full of amazing product insights. The section on tunneling really stood out to me and was the inspiration for the following article.

Tunneling is one of the quietest and most corrosive forces in product management. Dan Heath defines tunneling in Upstream as the cognitive trap where people become so overwhelmed by immediate demands that they become blind to long term thinking. They fall into a tunnel, focusing narrowly on the urgent problem in front of them, while losing the ability to lift their head and see the structural issues that created the problem in the first place. It is not a failure of talent. It is a failure of operating conditions and incentives that reward survival over strategy.

Product teams fall into tunneling more easily than almost any other function. Shipping deadlines, stakeholder escalations, outages, bugs, demos, and endless “quick requests” push teams into a survival mindset. When tunneling sets in, teams stop working on the product and start working for the product. Their world collapses into keeping the next release alive, rather than increasing the long term value of the system.

This post examines tunneling in product management, how to recognize it, and why great leaders act aggressively to eliminate it.

The Moments That Signal You Are Already in the Tunnel

Product managers rarely admit tunneling. Instead, it shows up in subtle but repeatable patterns. When I work with teams, these are the red flags that appear most often.

1. Roadmaps turn into triage boards

When 80 percent of your roadmap is filled with fixes, quick wins, client escalations, and “urgent but unplanned” work, you are not prioritizing. You are reacting. Teams justify this by saying “we need to unblock the business” or “this customer is at risk,” but in practice they have ceded control of the roadmap to whoever yells the loudest.

2. PMs stop asking why

Tunneling pushes PMs to accept problem statements exactly as the stakeholder phrases them. A leader says “We need this report,” and the PM rushes to gather requirements without asking why the report is needed or whether the underlying decision process is broken. When discovery collapses, product strategy collapses with it.

3. Success becomes defined as getting through the week

Teams celebrate surviving releases instead of celebrating impact. A product manager who once talked passionately about the user journey now only talks about the number of tickets closed. The organization confuses motion with progress.

How Tunneling Shows Up in Real Product Teams

Example 1: The never ending backlog of “critical blockers”

A global platform team once showed me a backlog where more than half the tickets were marked critical. When everything is critical, nothing is strategic. The team had allowed sales, implementation, and operations to treat the product organization as an on demand task force. The underlying issue was a lack of intake governance and a failure to push accountability back to the functions generating the noise.

Example 2: Feature requests that mask system design flaws

A financial services product team spent months building “one off” compliance features for clients. Each request seemed reasonable. But the real problem was that the product lacked a generalizable compliance framework. Because they tunneled into each request, they burned time and budget without improving the architecture that created the issue.

Example 3: PMs becoming project managers instead of product leaders

A consumer health startup repeatedly missed growth targets because PMs were buried in ceremonies, reporting, and release wrangling. The root cause was not team incompetence. It was tunneling. They simply had no time or space to do discovery, validate assumptions, or pressure test the business model. The result was a product team optimized for administration instead of insight.

Why Product Organizations Tunnel

Tunneling is not caused by weak product managers. It is caused by weak product environments.

Three culprits show up most often.

1. Leadership prioritizing urgency over clarity

When leaders create a culture where speed trumps direction, tunneling becomes inevitable. A team cannot think long term when every week introduces the next emergency.

2. Lack of a stable operating model

Teams tunnel when they lack clear intake processes, prioritization frameworks, definitions of done, and release rhythms. Without structure, chaos becomes normal and the tunnel becomes the only way to cope.

3. Poor metrics

If the organization only measures output rather than outcomes, tunneling is rewarded. Dashboards that track ticket counts, velocity points, or story volume push teams to optimize for the wrong thing.

How to Break Out of the Tunnel

Escaping the tunnel is not an act of heroism. It is an act of design. Leaders must create conditions that prevent tunneling from taking hold.

1. Build guardrails around urgent work

Urgent work should be explicitly capped. High maturity product organizations use capacity allocation models where only a defined percentage of engineering time can be consumed by unplanned work. Everything else must go through discovery and prioritization.

2. Make problem framing a mandatory step

Teams must never act on a request until they have clarified the root problem. This single discipline cuts tunneling dramatically. Questions like “What is your real desired outcome” and “What are the alternatives you considered” shift the team from reaction to inquiry.

3. Shift the narrative from firefighting to systems thinking

Tunneling thrives when teams believe the world is a series of unconnected fires. Leadership must consistently redirect conversations toward structural fixes. What is the design gap? What is the long term win? What investment eliminates this class of issues forever?

4. Protect strategic time

Every product manager should have non negotiable time for discovery, research, client conversations, and exploration. Tunneling destroys creativity because it destroys time.

The Hard Truth: You Cannot Innovate While Tunneling

A product team inside a tunnel may survive, but it cannot innovate. It cannot design the next generation platform. It cannot shift the market. It cannot see around corners. Innovation requires space. Tunneling removes space. As Dan Heath notes, people in tunnels are not irrational. They are constrained. They are operating under scarcity of time, attention, and emotional bandwidth.

Great product leaders treat tunneling as an existential risk. They eliminate it with the same intensity they eliminate technical debt or security vulnerabilities. Because tunneling is not just a cognitive trap. It is a strategy trap. The longer the organization stays in the tunnel, the more it drifts toward mediocrity.

The highest performing product teams have one thing in common. They refuse to let the urgent consume the important. They protect clarity. They reject chaos. They create the conditions for long term thinking. And because of that, they build products that move markets.

References

  1. Dan Heath, Upstream: The Quest to Solve Problems Before They Happen, Avid Reader Press, 2020.
  2. Mullainathan, Sendhil and Shafir, Eldar. Scarcity: Why Having Too Little Means So Much, Times Books, 2013. (Referenced indirectly in Upstream regarding tunneling psychology.)

Aesthetic Force: The Hidden Gravity Warping Your Product and Your Organization

Every product and engineering organization wrestles with obvious problems. Technical debt. Conflicting priorities. Underpowered infrastructure. Inefficient processes. Those are solvable with time, attention, and a bit of management maturity.

The harder problems are the invisible ones. The ones that warp decisions without anyone saying a word. The ones that produce outcomes nobody intended. These are driven by what I call aesthetic force. Aesthetic force is the unseen pull created by taste, culture, prestige, identity, and politics. It is the gravity field beneath a product organization that shapes what gets built, who gets heard, and what becomes “the way we do things.” It is not logical. It is not measurable. Yet it is incredibly powerful.

Aesthetic force is why teams ship features that do not matter. It is why leaders chase elegant architectures that never reach production. It is why organizations obsess over frameworks rather than outcomes. It is why a simple decision becomes a six week debate. It is taste dressed up as strategy.

If you do not understand aesthetic force, it will run your organization without your consent.

Below is how to spot it, how to avoid it when it becomes toxic, and the few cases when you should embrace it.

How To Identify Aesthetic Force

Aesthetic force reveals itself through behavior, not words. Look for these patterns.

1. The Team Loves the Work More Than the Result

When engineers argue passionately for a solution that adds risk, time, or complexity, not because the customer needs it but because it is “clean,” “pure,” or “the right pattern,” you are witnessing aesthetic force.

2. Prestige Projects Receive Irrational Protection

If a feature or platform strand gets defended with the same fervor as a personal reputation, someone’s identity is tied to it. They are protecting an aesthetic ideal rather than the truth of the market.

3. Process Shifts Without Actual Improvement

If a new methodology, tool, or workflow gains traction before it proves value, you are watching aesthetic force in action. People are choosing the thing that looks modern or elite.

4. You Hear Phrases That Signal Taste Over Impact

“Elegant.”
“Beautiful.”
“Clean.”
“We should do it the right way.”
“When we rewrite it the right way.”

Any time you hear “right way” without specificity, aesthetic force is speaking.

5. Decisions Drift Toward What the Loudest Experts Prefer

Aesthetic force often hides behind seniority. If the organization defaults to the preferences of one influential architect or PM without evidence, the force is winning.

What To Do To Avoid Aesthetic Force Taking Over

Aesthetic force itself is not bad. Unchecked, it is destructive. You avoid that through intentional leadership.

1. Anchor Everything to Measurable Impact

Every debate should be grounded in a measurable outcome. If someone proposes a new pattern, integration, rewrite, or workflow, the burden of proof is on them to show how it improves speed, quality, reliability, or client experience.

Opinions are welcome. Impact determines direction.

2. Make Tradeoffs Explicit

Aesthetic force thrives in ambiguity. When you turn decisions into explicit tradeoffs, the fog clears.
Example:
Option A is more elegant but will delay us eight weeks. Option B is less elegant but gets us to market before busy season, improves adoption, and unblocks another team.

Elegance loses unless it delivers value.

3. Demand Evidence Before Evangelism

If someone champions a new tool, standard, or strategy, require a working example, a pilot, or a small-scale win. No more slideware revolutions.

4. Reward Shipping Over Posturing

Promote leaders who deliver outcomes, not theory. Teams emulate what they see rewarded. If prestige attaches to execution rather than aesthetic purity, the organization rebalances itself.

5. Break Identity Attachment

If someone’s identity is fused with a product, codebase, or architecture, rotate responsibilities or pair them with a peer reviewer. Aesthetic force is strongest when people believe their reputation depends on decisions staying a certain way.

When To Accept Aesthetic Force

There are rare moments when you should allow aesthetic force to influence the product. Doing so without awareness is reckless. Doing so intentionally can be powerful.

1. When You Are Establishing Product Taste

Every great product has an opinionated aesthetic at its core. Some teams call this product feel. Others call it craftsmanship. When aesthetics drive coherence, speed, and clarity, the force is working in your favor.

2. When the Aesthetic Attracts and Retains Exceptional Talent

Some technical choices create a virtuous cycle. A beautiful architecture can inspire great developers to join or stay. A well crafted experience can rally designers and PMs. Occasionally, embracing aesthetic force elevates the culture.

3. When It Becomes a Strategic Differentiator

If aesthetic excellence creates client trust, increases adoption, or reduces friction, it becomes a strategic tool. Apple’s product aesthetic is not a luxury. It is part of its moat.

4. When Shipping Fast Would Create Long Term Chaos

Sometimes the shortcut buries you later. Aesthetic force is useful when it protects you from reckless short term thinking. The key is to treat it as a conscious decision, not a reflex.

Thought

Aesthetic force is not a harmless quirk. It is a silent operator that will hijack your roadmap, distort your priorities, and convince smart people to pour months into work that has no strategic value. Leaders who ignore it end up managing an organization that behaves irrationally while believing it is acting with discipline.

If you want a product team that delivers results instead of beautiful distractions, you cannot treat aesthetic force as a background influence. You must surface it, confront it, and regulate it. When you do, the organization becomes sharper, faster, and far more honest about what matters. When you do not, aesthetic force becomes the real head of product, and it will not care about your clients, your deadlines, or your strategy.

The gravity is already pulling. Strong leaders decide the direction.

#ProductStrategy #EngineeringCulture #ProductThinking #CTO #CIO

The leadership myth: “I just know”

In product engineering leadership circles, people love to talk about instinct. The knowing glance at a roadmap item that feels wrong. The uneasy sense that a design review is glossing over real risk. The internal alarm that goes off the moment someone says, “We can just replatform it in a few weeks”.

That instinct gets labeled “Spidey sense”. It sounds cool. It implies mastery. It suggests your leadership capability has evolved into a sixth sense.

But in practice, treating intuition like a superpower is one of the fastest ways an engineering leader can misjudge risk, overrule teams incorrectly, or derail prioritization.

The popular interpretation of “Spidey sense” as mystical foresight hides the real mechanism: pattern recognition built over years, now masquerading as magic. As one perspective puts it, intuition is simply “a strong feeling guiding you toward an advantageous choice or warning you of a roadblock”. (mindvalley.com)

Inside a leadership context, relying on that feeling without discipline can create more harm than clarity.

The uncomfortable truth: your intuition has limits

1. Your instincts reflect your past, not your present environment
A study on engineering intuition shows that intuitive judgment comes from familiar patterns, not universal truths. (onlinelibrary.wiley.com)

As a leader, your “sense” might be tuned to a monolith world when your team is operating in microservices. Or it might be shaped by on-prem realities while your teams build cloud native platforms.

If the context has moved and your instincts have not, you become the roadblock.

2. Intuition often substitutes for process at the exact moment you need more structure
Leaders fall into the trap of shortcutting with phrases like “I’ve seen this fail before” or “Trust me, this architecture won’t scale”. That feels efficient. It is not.

Product engineering leadership requires visible reasoning, measurable outcomes, and collaborative decision making. A product sense article puts it well: intuition can be a compass but is not a map. (medium.productcoalition.com)

Compasses help you orient. Maps help an entire organization move.

3. Intuition collapses under novelty
Product engineering lives in novelty: new cloud services, AI architectures, shifting security expectations, fast-changing user expectations. Research on the metacognition of intuition shows that instincts fail in unfamiliar environments. (researchgate.net)

As a leader, if you rely on intuition in novel or high-ambiguity situations, you risk overconfidence right when the team needs structured exploration.

Where engineering leaders should actually use intuition

A. Early risk detection
A raised eyebrow during a design review can be valuable. Leaders with deep experience often sense when a team is assuming too much, skipping load testing, or building a brittle dependency chain. That gut feeling should trigger investigation, not fiat decisions.

B. Team health and dynamics
Signal detection around team morale, interpersonal friction, or a pattern of missed commitments is one of the most defensible uses of leadership intuition. People rarely surface these problems directly. Leaders who sense early disruption can intervene before a team loses velocity or trust.

C. Prioritization under real uncertainty
Sometimes the data is thin, the timelines are compressed, and the decision cannot wait.
Intuition, shaped by past experience, lets leaders choose a direction and commit. But that choice must be paired with measurable checkpoints, telemetry, and a willingness to pivot.

A leadership article on intuition describes it as a feedback loop that adapts with new data.
(archbridgecoaching.com) The best engineering leaders operate exactly that way.

Where engineering leaders misuse intuition and damage teams

  • Declaring architectural truths without evidence
    Saying “that pattern won’t scale” without benchmarks undermines engineering autonomy and starves the team of real learning.
  • Using instinct to override user research
    Leaders who “feel” the user flow is fine even when research says otherwise end up owning failed adoption and churn.
  • Blocking progress with outdated mental models
    Your past experience is not invalid, but it is incomplete. When leaders default to “my instinct says no”, they lock teams into the past.
  • Confusing speed with correctness
    Leaders shortcutting due diligence because “something feels off” or “this feels right” often introduce risk debt that shows up months later.

The disciplined leader’s approach to intuition

1. Translate the sense into a testable hypothesis
Instead of “I don’t like this architecture”, say: “I suspect this component will become a single point of failure. Let’s validate that with a quick load simulation.”

2. Invite team challenge
If your intuition cannot survive healthy debate, it is not insight; it is ego.

3. Verify with data
Telemetry, benchmarking, user tests, scoring matrices, risk assessments. Leaders build confidence through evidence.

4. Tie intuition to a learning loop
After the decision, ask: Did my instinct help? Did it mislead?
Leaders who evaluate their own judgment evolve faster than those who worship their gut.

5. Make intuition transparent
Explain the reasoning, patterns and risks behind the feeling. This grows organizational judgment rather than centralizing it.

Closing argument

Spidey sense is not a leadership trait. It is a signal. It is an early warning system that tells you when to look closer. But it is not a substitute for data, rigorous engineering practice, or transparent decision making.

Great product engineering leaders do not trust their instincts blindly. They use their instincts to decide what questions to ask, what risks to probe, what patterns to explore, and where to apply pressure.

When intuition triggers structured action, it becomes a leadership accelerant. When intuition replaces structure, it becomes a liability.

Treat your Spidey sense as a flashlight, not a compass. It helps you see what you might have missed. It does not tell you where to go.

The PE effect on the Tax Industry

Private equity is not “coming” for the tax industry. It is already setting the pace, and 2026 is the year the gap becomes visible to clients.

The Thomson Reuters Institute put hard numbers behind what many leaders feel in the field: roughly half of the top 25 US tax, audit, and accounting firms have completed or are pursuing a private equity transaction. That is no longer a niche experiment. It is a structural shift.

What is fascinating is the split-screen reality inside the profession. The same research shows most professionals are not chasing PE. 57% say it is not even on their radar, and another 30% say they are not interested even if approached. The survey also breaks down how few firms are actually “in market” today: 5% completed a PE deal, 11% are actively looking (or plan to), 8% are open if approached, and 76% are uninterested or unprepared.

That divergence is exactly why 2026 will be a forcing function.

PE changes the operating model, not just the cap table. The report calls out why partners say yes: capital to modernize, automate, and consolidate, plus faster decision-making and more corporate leadership structures. It also highlights a blunt incentive: retiring partners can see payouts that are often two to three times higher than traditional internal buyouts. That money does not just reward the past. It funds the next playbook: AI, workflow automation, and acquisition-driven scale.

You can see the playbook in the market. Grant Thornton closed a “significant growth investment” led by New Mountain Capital in May 2024, explicitly positioning it to accelerate its strategy. (Grant Thornton) Citrin Cooperman became a case study in roll-up velocity after New Mountain’s 2021 investment, and in January 2025 it announced a new investment as Blackstone acquired a stake from New Mountain. (Citrin Cooperman)

Here is my bet for 2026: the winners will not be “PE-backed firms” versus “independent firms.” The winners will be firms that treat tax as a technology-enabled product and treat delivery as an engineered system.

In 2026, clients will increasingly buy outcomes, not hours. They will expect proactive, data-driven guidance, faster cycle times, and cleaner digital experiences. The firms that can invest aggressively in automation, data platforms, and AI-enabled delivery will compress turnaround times and expand margins at the same time. PE makes that acceleration easier because it can bankroll the modernization debt that partner-led models have historically struggled to fund at speed.

But PE also introduces real risk. Culture can get commoditized when ROI timelines dominate the conversation, and there are growing concerns about auditor independence as financial ownership structures evolve. If you lead a firm, you do not get to ignore that tension. You have to design around it.

If you are a technology leader inside a tax or professional services firm, I would frame 2026 as three non-negotiables:

  • Industrialize delivery. Standardize data intake, workflow, and quality controls so you can scale expertise without burning out your best people.
  • Invest like a product company. Build reusable platforms, not one-off solutions. Your differentiator is your system of work, not your slide deck.
  • Be explicit about trust. Independence, security, and governance cannot be “handled later,” especially when ownership models evolve.

The uncomfortable truth is that “standing still” is no longer a neutral choice. The Thomson Reuters report says it plainly: standing still is not a viable strategy. In 2026, the market will reward firms that can deliver faster, more predictably, and more digitally, while still protecting the core trust that makes tax work valuable.

If you are leading a firm that is not taking PE, what is your counter-move this year: an ESOP, strategic M&A, bank financing, or a real commitment to self-funded modernization?

Because clients will not care how you funded the transformation. They will only feel whether it happened.

Revealed Preferences vs Stated Preferences: The Silent Killer of Product and Organizational Strategy

Every product and engineering leader has seen this pattern. A room full of smart people declares:

  • “We want fewer priorities.”
  • “We will follow the operating model.”
  • “This initiative is the top strategic priority.”
  • “We are committed to data-driven decisions.”

Then, within days, behavior contradicts what was said. Side work appears. Priorities shift. Leaders quietly push their pet projects. Teams say yes to everything. Decisions made on Monday fall apart by Thursday.

This gap between what people say and what they do is the difference between stated preferences and revealed preferences, a concept rooted in behavioral economics from Paul Samuelson and Gary Becker.

Stated preferences are what people wish were true. Revealed preferences are what they act on. Organizations that ignore this gap drift. Organizations that confront it deliver.

How to Identify Revealed Preferences Inside Your Organization

1. Follow the time, not the talk

Calendars reveal priorities better than strategy decks.

Andy Grove captured this in High Output Management, noting that leaders often claim architectural work is vital while spending all their time on escalations. [Link]

At Google, teams optimized for leadership product reviews, not roadmaps. Those meetings became the real forcing function. [Link]

2. Look for quiet work multipliers

Yahoo pre Marissa Mayer is a classic case. Leaders stated they supported focus while creating hundreds of priorities behind the scenes. [Link]

3. Examine who gets rewarded

Values are revealed through promotions and praise.

Netflix states this clearly in its culture memo: “Values are shown by who gets rewarded and who gets let go.” [Link]

If heroics get rewarded while platform discipline gets ignored, heroics become the true preference.

4. Check what gets escalated

Teams escalate what they believe matters. If pet projects escalate faster than roadmap work, the hidden priorities are obvious.

5. Listen for the quiet “yes, but”

  • “Yes, we support the model, but I need this done outside it.”
  • “Yes, we want fewer priorities, but we need this exception.”

Chris Argyris documented this pattern as “espoused theory versus theory in use.” [Link]

The truth lives in behavior, not statements.

How to Avoid the Trap: Turning Revealed Preferences Into Better Decisions

1. Stop accepting verbal alignment as alignment

Amazon solved this by requiring written alignment through six page narratives. [Link] If someone will not commit in writing, they are not aligned.

2. Run decision pre mortems

Based on Gary Klein’s research, pre mortems force hidden risks and incentives into the open.[Link] Ask:

  • What behavior would contradict this
  • Who benefits if this fails
  • What incentive might undermine it

3. Build friction into special requests

Atlassian and Shopify use portfolio scorecards that require public tradeoffs for every exception. [Link, Link] This prevents hidden work from overwhelming teams.

4. Tie every priority to measurable outcomes

Google’s Project Aristotle showed that clarity and structure drive performance. Link Metrics force real preferences into daylight.

5. Ask for preferred failure mode

The UK Government Digital Service used this approach to uncover real priorities, often revealing that speed and usability mattered more than perfect accuracy. [Link]

When to Accept Revealed Preferences Instead of Fighting Them

1. Accept it when executive behavior is consistent

If leaders consistently act one way, that behavior is the strategy. Microsoft under Steve Ballmer said innovation mattered, but behavior optimized for Windows and Office. Satya Nadella highlighted this in Hit Refresh. [Link]

2. Accept it when culture contradicts the stated strategy

Clayton Christensen’s The Innovator’s Dilemma shows that organizations follow cultural and economic incentives, not aspirational strategy. [Link]

If firefighting culture dominates, you will get firefighting, not platforms.

3. Accept it when it reveals real power structures

The real org chart is the list of who can successfully redirect a team’s time.

4. Accept it when it reflects external pressure

Fintech leaders stated that velocity mattered until regulators forced compliance to become the true priority. [Link]

Sometimes the revealed preference is survival.

Delivery Happens When You Lead With Reality, Not Rhetoric

Every organization claims it values delivery. Yet delivery consistently fails in the gap between what leaders say they want and what their behavior actually supports.

If a leader claims focus but adds side work, delivery slips.
If a sponsor claims predictability but changes scope constantly, delivery stalls.
If a steering group claims platform maturity but rewards firefighting, delivery dies.

Delivery is not about tools or talent.
Delivery is a revealed preference problem.

Organizations deliver when behavior aligns with the strategy.
When calendars match the roadmap.
When exceptions have a cost.
When incentives reinforce the plan.

Great organizations feel calm and predictable because behavior supports commitments.
Weak organizations feel chaotic because behavior contradicts them.

Closing the gap between stated and revealed preferences is the single most important delivery intervention a leader can make.

Delivery Is What You Prove, Not What You Announce

Every organization carries two delivery strategies:

  1. The one written in slides.
  2. The one enforced through behavior.

Only the second one ships.

If you want real delivery, build around what people actually do.
Hold leaders accountable to behavioral alignment.
Confront contradictions early.
Design your operating model around reality, not aspiration.

Once behavior and strategy match, delivery stops being a goal and becomes the natural byproduct of how the organization works.

From Middle-to-Middle to End-to-End

Most product organizations are structured to work middle to middle. Product managers gather requirements from the market, engineering teams build features, customer success teaches clients how to use them, and support handles escalations. It is an elegant theory of specialization. And yet, in practice, this model often creates distance from the reality of the problem being solved.

The result is predictable. Products become polished abstractions of customer needs rather than tools that solve real work. Teams optimize for roadmaps instead of outcomes. Everyone is busy, but few are solving the actual problem in the environment where it exists. Velocity, ironically, slows.

This is where forward deployed engineers change everything.

What Forward Deployed Engineers Are

Forward deployed engineers are technical practitioners who sit directly in the workflow of the customer environment. They operate where the real work happens. They are not receiving requirements secondhand through a product manager translation layer. They see the work. They see the constraints. They see the friction. And they can change it.

This model is not theoretical. It has been battle-tested.

The term “forward deployed” has roots in consulting engineers embedded in critical operations. The difference is that now this model applies to software products that are not simply tools but operational systems for entire industries.

The Structural Shift: End to End vs Middle to Middle

When engineers work directly with customers, the company moves from middle to middle (internal teams trading artifacts) to end to end (engineers embedded where value is created and value is delivered). This rewires incentives.

The goal is no longer to ship features. The goal is to remove friction from the customer journey. Every day. Continuously.

Organizations that embrace this model are being honest about the nature of software. Software is not static. Software is the operational model of a business. It has to reflect real workflows, real constraints, real incentives. The only way to do that is to put engineers in the real environment.

Ben Thompson has written about the power of integration when companies own the full problem surface: https://stratechery.com/2020/the-end-of-the-beginning/

Forward deployment collapses the gap between intention and reality.

Why This Compounds

Forward deployment creates:

  • Shorter feedback loops
  • Real customer empathy
  • Outcome alignment
  • Systems-level understanding

This is the foundation for compounding advantage. Learning loops accelerate. Context depth compounds. Solutions reflect the real system rather than an imagined one.

The Cost

None of this is free.

You have to hire differently. Not just strong engineers, but engineers comfortable with ambiguity, autonomy, and external-facing collaboration. You have to measure differently. Value delivered matters more than story points burned. You have to empower teams.

The Bet

If you view software as a finished product, forward deployment looks inefficient.

If you view software as the operating system of your customers’ business, forward deployment is the only rational structure.

The companies that win over the next decade will be the ones whose engineers work where the work is, who ship change into reality, and who build end to end.