That is where most teams make a dangerous move. They reach for eval, Function, or Node’s vm module and tell themselves it is “sandboxed enough.”

It is not.

Node’s own documentation is explicit that node:vm is not a security mechanism and should not be used to run untrusted code. Worker threads are also not the right boundary for hostile code because they are designed for parallelism and can share memory. At the same time, Microsoft Agent Framework is built to let agents call external tools through function tools, so the clean pattern is not “run JavaScript inside the agent host.” The clean pattern is “make JavaScript execution a remote tool with a hardened execution boundary.” (Node.js)

That is the architecture this post covers:

• Microsoft Agent Framework in .NET
• A custom function tool exposed to the agent
• A tRPC call from the tool to a separate Node.js execution service
• Execution inside a locked-down isolate, not vm
• Explicit whitelisting of namespaces and packages
• Validation, time limits, memory limits, and auditable policy controls

The key design principle is simple: treat JavaScript execution as a privileged capability, not a convenience API.

The architecture

At a high level, the flow looks like this:

1. The agent decides it needs computation.
2. Microsoft Agent Framework calls a function tool.
3. The function tool sends a request over HTTP to a tRPC endpoint in Node.js.
4. The Node service validates the request with Zod.
5. The Node service creates an isolated execution environment.
6. Only approved globals and wrapped package facades are injected.
7. The code runs with strict limits for time, memory, and output shape.
8. The result is returned to the agent as tool output.

Microsoft Agent Framework supports function tools as first-class extensions to an agent, and tRPC gives you a type-safe RPC layer with input and output validation. That combination is ideal here because the .NET side stays thin and deterministic, while the execution policy lives in one place on the Node side. (Microsoft Learn)

First principle: “secure eval” is really “isolated execution”

It is important to be direct here. There is no magic secureEval() in Node.js. If you are executing model-authored or user-authored JavaScript, the safest practical pattern is:

• out-of-process execution boundary
• fresh isolate per run or per tenant pool
• no ambient filesystem or network access
• no raw require
• whitelisted host-provided capabilities only
• timeouts, memory ceilings, and payload size limits
• container and OS-level restrictions around the service

Why not use node:vm? Because the Node docs explicitly say not to use it as a security boundary. Why not just use worker threads? Because workers are concurrency primitives, not isolation primitives. A better starting point for JavaScript isolation in Node is isolated-vm, which exposes V8 isolates and is designed for running code in fresh environments with no default Node runtime capabilities. Node’s permission model can also further restrict the Node process itself. (Node.js)

The important nuance is this: even isolated-vm should be one layer, not the only layer. The strongest production posture is to run the execution service in its own locked-down container or workload boundary and assume defense in depth.

Tool contract design

Do not let the model send arbitrary source code and a free-form module list with no governance. Give it a constrained contract.

A good request shape looks like this:

import { z } from "zod";
export const ExecuteJsInput = z.object({
  code: z.string().max(10_000),
  input: z.unknown().optional(),
  allowedNamespaces: z.array(z.string()).default([]),
  allowedPackages: z.array(z.string()).default([]),
  expectedResultSchema: z
    .object({
      type: z.enum(["json", "string", "number", "boolean", "array", "object"]),
    })
    .optional(),
  timeoutMs: z.number().int().min(50).max(3000).default(1000),
});

This matters for two reasons.

First, tRPC is designed around typed procedures, and Zod-driven validation makes the boundary explicit. Second, you now have a place to enforce policy before any code gets near an isolate. (trpc.io)

The Microsoft Agent Framework side

On the .NET side, the tool should be boring. That is the goal.

Microsoft Agent Framework lets you expose custom logic through function tools, including by creating an AIFunction from a C# method. The agent does not need to know how tRPC works. It just needs a tool description that makes the capability understandable to the model. (Microsoft Learn)

A simplified example:

using System.ComponentModel;
using System.Net.Http.Json;
public class JavaScriptExecutionTool
{
    private readonly HttpClient _httpClient;
    public JavaScriptExecutionTool(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }
    [Description("Executes tightly sandboxed JavaScript for deterministic data transformation and calculation.")]
    public async Task<string> ExecuteSandboxedJavaScript(
        [Description("The JavaScript source to execute. Must return a serializable result.")] string code,
        [Description("Optional JSON input payload for the script.")] string? inputJson = null,
        [Description("Approved namespaces the script may access.")] string[]? allowedNamespaces = null,
        [Description("Approved package facades the script may access.")] string[]? allowedPackages = null)
    {
        var request = new
        {
            code,
            input = string.IsNullOrWhiteSpace(inputJson) ? null : System.Text.Json.JsonSerializer.Deserialize<object>(inputJson),
            allowedNamespaces = allowedNamespaces ?? Array.Empty<string>(),
            allowedPackages = allowedPackages ?? Array.Empty<string>(),
            timeoutMs = 1000
        };
        var response = await _httpClient.PostAsJsonAsync("/trpc/js.execute", request);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

Then you register it as a function tool with your agent. The architectural point is more important than the exact setup syntax: the agent host never evaluates code locally. It delegates execution to the hardened service. (Microsoft Learn)

The tRPC boundary

tRPC is a strong fit because it gives you typed procedures, validation, and a clean contract between the .NET caller and Node service. Even though .NET is not consuming generated TypeScript types directly, the Node service still benefits from strict schemas and a maintainable procedure surface. (trpc.io)

Example router:

import { initTRPC } from "@trpc/server";
import { z } from "zod";
import { ExecuteJsInput } from "./schemas";
import { runSandboxedScript } from "./sandbox";
const t = initTRPC.create();
export const appRouter = t.router({
  js: t.router({
    execute: t.procedure
      .input(ExecuteJsInput)
      .mutation(async ({ input, ctx }) => {
        return await runSandboxedScript(input, ctx.policyStore);
      }),
  }),
});
export type AppRouter = typeof appRouter;

This is where you can also add authentication, tenant context, rate limiting, audit metadata, and policy lookup.

The secure execution service

This is the heart of the design.

The mistake many teams make is trying to whitelist modules by exposing require. Do not do that. If you expose require, you are recreating Node inside the sandbox and dramatically expanding the attack surface.

Instead, preload and wrap approved capabilities in the host, then inject only those facades into the isolate.

That means your whitelist is not “the sandbox may import lodash.” It is “the sandbox may access a safe facade called packages.lodash that exposes only get, pick, and omit.”

That is a much better boundary.

Example policy registry

type NamespaceFactory = () => Record<string, unknown>;
type PackageFactory = () => Record<string, unknown>;
const namespaceRegistry: Record<string, NamespaceFactory> = {
  math: () => ({
    round: Math.round,
    floor: Math.floor,
    ceil: Math.ceil,
    max: Math.max,
    min: Math.min,
  }),
  dates: () => ({
    nowIso: () => new Date().toISOString(),
  }),
};
const packageRegistry: Record<string, PackageFactory> = {
  lodash: () => {
    const { get, pick, omit } = require("lodash");
    return { get, pick, omit };
  },
  decimal: () => {
    const Decimal = require("decimal.js");
    return { Decimal };
  },
};

Notice what is missing: no arbitrary imports, no filesystem, no fetch, no process access, no environment access.

Example isolate runner

import ivm from "isolated-vm";
import { ExecuteJsInput } from "./schemas";
export async function runSandboxedScript(
  request: z.infer<typeof ExecuteJsInput>,
  policyStore: PolicyStore
) {
  const policy = await policyStore.resolve({
    namespaces: request.allowedNamespaces,
    packages: request.allowedPackages,
  });
  const isolate = new ivm.Isolate({ memoryLimit: 64 });
  const context = await isolate.createContext();
  const jail = context.global;
  await jail.set("global", jail.derefInto());
  const safeNamespaces = Object.fromEntries(
    policy.namespaces.map((name) => [name, namespaceRegistry[name]!()])
  );
  const safePackages = Object.fromEntries(
    policy.packages.map((name) => [name, packageRegistry[name]!()])
  );
  await jail.set("input", new ivm.ExternalCopy(request.input ?? null).copyInto());
  await jail.set("namespaces", new ivm.ExternalCopy(safeNamespaces).copyInto());
  await jail.set("packages", new ivm.ExternalCopy(safePackages).copyInto());
  const wrapped = `
    "use strict";
    (async function () {
      const console = undefined;
      const process = undefined;
      const require = undefined;
      const module = undefined;
      const exports = undefined;
      const Buffer = undefined;
      const setTimeout = undefined;
      const setInterval = undefined;
      const userFn = async ({ input, namespaces, packages }) => {
        ${request.code}
      };
      return await userFn({ input, namespaces, packages });
    })()
  `;
  const script = await isolate.compileScript(wrapped);
  try {
    const result = await script.run(context, { timeout: request.timeoutMs });
    const copied = await new ivm.Reference(result).copy();
    return {
      ok: true,
      result: copied,
    };
  } catch (error) {
    return {
      ok: false,
      error: sanitizeError(error),
    };
  } finally {
    isolate.dispose();
  }
}

This is intentionally opinionated.

• The sandbox gets input
• The sandbox gets namespaces
• The sandbox gets packages
• The sandbox does not get Node
• The sandbox does not get require
• The sandbox does not get the environment

That is the right posture.

The isolated-vm project describes these isolates as separate JavaScript environments free of the extra capabilities that Node normally exposes. That is why it is a better primitive here than vm. (GitHub)

How whitelisting should really work

A lot of teams hear “whitelist packages” and think they should allow date-fns or lodash directly. That is still too coarse.

You want three policy levels.

1. Namespace whitelist

These are internal capability groups you define, such as:

• math
• dates
• currency
• tax
• normalizers

These are ideal for domain logic because they let you present stable semantic surfaces to the model.

2. Package facade whitelist

This is not raw NPM package access. It is a curated wrapper over a package.

Example:

const packageRegistry = {
  dateFns: () => {
    const { addDays, formatISO, parseISO } = require("date-fns");
    return { addDays, formatISO, parseISO };
  },
};

3. Tenant or tool policy whitelist

Even if a package exists in the registry, a given agent or tenant may not be allowed to use it.

That means final access should be the intersection of:

• globally supported capabilities
• tenant policy
• current agent policy
• current tool invocation request

That keeps the model from escalating its own power simply by naming more packages.

What “most secure method” means in practice

Here is the honest version.

If the code is untrusted, the strongest production pattern is not “just use a safer JavaScript library.” The strongest pattern is:

• dedicated Node execution service
• running in a separate process or container from the agent host
• Node permission model enabled where possible
• no filesystem permission unless explicitly required
• no network permission unless explicitly required
• no child process permission
• no raw module loading
• isolate-based execution inside the service
• per-request timeout
• per-request memory cap
• rate limiting and audit logging
• kill-and-recycle strategy for suspicious runs

Node’s permission model is now stable and is specifically intended to restrict access to resources during execution. That makes it a useful outer control around the execution worker process. (Node.js)

So the recommendation is:

Do not run JavaScript evaluation in the Microsoft Agent Framework process. Run it in a separate hardened execution service, and inside that service use an isolate with only host-injected safe facades.

Prompting the agent correctly

One subtle mistake is giving the model too much freedom in how it uses the tool. Your tool description should bias toward deterministic use cases.

Good use cases:

• schema normalization
• mathematical calculations
• JSON reshaping
• derived field generation
• deterministic validation helpers
• short business-rule transforms

Bad use cases:

• arbitrary web requests
• importing unknown libraries
• long-running workflows
• anything requiring secret access
• anything that should really be a reviewed backend feature

You want the tool to feel more like “dynamic formula execution” than “tiny remote code runner.”

Observability and governance

Once you add this capability, you need a paper trail.

Log:

• agent name
• conversation or run id
• caller identity
• code hash
• requested namespaces
• requested packages
• approved namespaces
• approved packages
• execution duration
• memory tier
• success or failure
• sanitized error output

Do not log secrets in payloads. Do log enough to reconstruct who ran what and under which policy.

This matters because the risk is no longer just technical. It is operational. A dynamic execution tool without auditability becomes impossible to govern at scale.

Where this pattern is worth it

This pattern is especially valuable when building agents that need deterministic computation without shipping a new backend endpoint for every micro-use-case.

Examples:

• tax calculation helpers
• document extraction post-processing
• migration mapping rules
• payroll normalization
• dynamic scoring or threshold logic
• transforming AI output into strict structured shapes

In all of those cases, JavaScript is the execution language, but policy is the product.

Final opinion

The wrong way to add JavaScript to an agent is to think of it as a convenience feature.

The right way is to think of it as a controlled runtime.

Microsoft Agent Framework gives you the right extension point through function tools. tRPC gives you a clean typed boundary. Node can host the execution service. But the part that separates a toy from a production design is this: never let the model execute inside your primary trust boundary, and never equate “sandboxed” with “safe” unless you can explain the exact layers doing the isolation. (Microsoft Learn)

That is the architecture I use.

They ask whether their teams are using it. They ask which model to standardize on. They ask whether agents are ready for production. They ask how quickly they can drive adoption.

That is all downstream. The real question is simpler and far more revealing: who on your team can actually direct AI, and who is starting to be directed by it? That is the divide I keep seeing in product and engineering organizations.

Some people use AI to expand their judgment. Others use it to avoid judgment. Some get faster while staying in control. Others get busy, impressed, and strangely passive. On the surface, both groups can look productive. Both can generate output. Both can show progress.

Only one of them is actually becoming more valuable. That is what is being referred to by some as The Steinberger Threshold.

I am borrowing the phrase from recent discussion around Peter Steinberger, but what matters is not the label. What matters is the shift it names. Steinberger is worth paying attention to because he has lived through multiple eras of software building, from deep technical craftsmanship to AI-native execution. The lesson embedded in his public writing and interviews is clear: the advantage is no longer just in doing the work yourself. The advantage is in framing the work, shaping the environment, inspecting the result, and deciding what happens next.

That is not prompt engineering. That is modern judgment. And that is why this matters more than another generic debate about AI productivity.

We are moving into a world where the cost of execution is falling fast. Agents can increasingly read codebases, edit files, run tests, summarize options, and handle meaningful chunks of delivery work. As that happens, the bottleneck shifts.

When execution gets cheaper, judgment gets more expensive.

That changes who stands out. It changes who scales. It changes who should lead.

The people who thrive in this environment will not be the ones who simply know how to use AI. That bar is dropping quickly. The people who thrive will be the ones who can define intent clearly, give the agent enough structure to move fast, and still know when the machine is wrong, shallow, overconfident, or drifting off mission.

That is the threshold. Below it, people let the agent set the pace, shape the work, and quietly narrow their thinking. Above it, people use the agent as leverage while keeping hold of direction, standards, and accountability.

This is not a tooling issue. It is a leadership issue.

The biggest mistake I see companies making is assuming AI adoption and AI capability are the same thing. They are not. Giving people access to powerful models tells you almost nothing about whether they can use them well. In fact, broad access can hide the problem for a while. Everyone suddenly looks more productive. More documents appear. More prototypes show up. More code gets written. More tickets move.

But velocity is a bad metric when the system can generate convincing motion on demand.

That is where executives get trapped. They see acceleration and assume capability has risen with it. Sometimes it has. Sometimes they are just watching the organization become more dependent on machine output without improving its ability to set direction or judge quality.

That is the real risk.

The person below the Steinberger Threshold is not necessarily junior. They are not necessarily non-technical. They are simply no longer fully in command once AI enters the loop. They delegate too early. They trust polished output too quickly. They confuse completeness with correctness. They let the system define the path instead of using the system to execute against a path they have defined.

The person above the threshold behaves very differently. They treat the agent like fast, tireless, sometimes brilliant labor. They know what outcome they want. They know where ambiguity is useful and where it is dangerous. They know when to tighten the frame. They know what needs review and what can be safely skimmed. Most importantly, they stay accountable for the result.

That last point matters more than people admit.

The best agent operators are usually not the ones writing the fanciest prompts. They are the ones with the clearest standards. They know what good looks like. They can spot weak reasoning. They can tell when the agent is optimizing for fluency instead of truth, or speed instead of soundness. They do not need to inspect every line, but they know exactly which lines matter.

This is why I think the rise of agents will reshuffle status inside product and engineering teams more than most people expect.

Some managers will struggle because they were already operating through abstraction without enough contact with the actual work. AI will expose that quickly. If you cannot define success in a way that a machine can execute against and a human can validate, your authority gets thinner.

Some engineers will struggle too, especially those whose identity is tied too tightly to personal output. AI does not care about your attachment to hand-crafted implementation if someone else can steer the machine to a better result faster.

And some people in the middle of the organization will rise quickly. They may not have the biggest titles. But they have taste. They can decompose messy problems. They can write clear acceptance criteria. They can create structure where others create noise. They can tell the difference between a useful first pass and a dangerous hallucination. In an agentic world, those people become force multipliers.

You can already see the outlines of this shift in the market. Companies are starting to act as though part of every team’s job is now translating work into something machines can execute. Whether you look at AI-first operating models, agentic coding environments, or the emerging idea of software factories, the pattern is the same: the bottleneck is moving away from raw execution and toward the ability to define, direct, and verify execution.

That is the Steinberger Threshold in practice.

So how do you figure out who has crossed it? Not with training completion rates. Not with prompt libraries. Not with AI badges. You run a scout mission.

By that I mean a real piece of work with enough ambiguity that judgment matters, enough structure that success can be observed, and enough consequence that the quality of direction shows up clearly. It should be something an agent can materially accelerate, but not something so trivial that the agent can stumble into a passable answer without supervision.

A good scout mission is not theater. It is a bounded business problem that exposes how someone thinks in an agentic environment.

Give them a real bug with messy symptoms. Give them a workflow that needs redesign. Give them a thin internal tool to build. Give them a reporting process full of edge cases. Then watch what they do.

Do they sharpen the objective before they delegate? Do they define acceptance criteria? Do they improve the environment with better tests, clearer documentation, or stronger context? Do they review the critical path or only the polished summary? Do they notice drift? Do they challenge the output? Can they explain why the result should be trusted?

Most importantly, when the agent gets stronger, do they become more decisive or more passive? That is the question.

Because that is what separates someone who is using AI as leverage from someone who is slowly handing over their agency to it.

My view is simple. The companies that win with AI will not be the ones with the most licenses, the biggest model budget, or the loudest transformation language. They will be the ones that identify who can actually operate above the Steinberger Threshold, then redesign teams, workflows, and leadership expectations around those people.

Because once agents become part of the execution layer, judgment becomes the scarce asset.

And scarce assets end up running the system.

When everyone can “do the thing” faster, the old product manager value proposition gets exposed.

Not because PMs are unnecessary, but because too many PMs have been operating as human middleware. In an AI-enabled team, middleware becomes friction.

Product management is becoming the bottleneck again, but not for the reason people think

Andrew Ng has been blunt about what he is seeing: engineering velocity is exploding, while product decision velocity is not keeping up. He has cited teams floating extreme staffing ratios like “1 PM to 0.5 engineers,” precisely because the constraint is no longer “can we build it,” it is “what should we build next, and why.” (The Washington Post)

That lands uncomfortably because it cuts through a decade of agile mythology. We convinced ourselves that tighter cycles and better rituals would make decisions faster. In practice, many teams just shipped smaller batches of indecision.

AI does not fix that. AI amplifies it.

If your org cannot make crisp calls on tradeoffs, positioning, risk, and sequencing, then AI turns your product into a slot machine. Lots of output, unpredictable outcomes.

The real shift: from writing requirements to engineering decisions

In AI-enabled teams, the PM’s center of gravity moves away from “capturing what we know” and toward “creating the conditions to learn faster than competitors.”

That is why the most valuable PMs are becoming:

1. System designers of feedback loops.
   If engineers can build ten prototypes this week, your job is to ensure you can get ten rounds of real feedback this week. Not opinions from internal stakeholders. Not a survey that takes a month. Actual behavioral signal, usability signal, and commercial signal. Ng’s point about product work becoming the bottleneck is basically a warning that many teams still run discovery like it is 2015. (LinkedIn)
2. Narrative owners who reduce ambiguity.
   AI makes it cheap to create options. It does not make it cheap to align a company. The PM’s job is to create a shared narrative that makes tradeoffs obvious. What are we optimizing for this quarter. What risks are acceptable. What customer segment wins. What we are explicitly not doing.
3. Outcome executives, not ticket shepherds.
   There is a reason the “PM as project manager” instinct feels so suffocating in modern teams. Dr. Bart Jaworski’s micromanagement critique hits because it describes a PM role that has quietly metastasized into dependency chasing and task decomposition, which is exactly the work AI will commoditize first. (LinkedIn)

Here is the uncomfortable truth: if your calendar is full of status checks, you are not leading product. You are compensating for a system that does not trust itself.

AI pushes PMs into an accountability gap, and you either own it or get sidelined

A lot of leaders are responding to AI by demanding “builder ratios,” fewer coordinators, more doers. You can see the cultural momentum in how companies publicly talk about AI expectations. Shopify’s CEO memo, widely circulated, framed AI usage as a baseline expectation and pushed teams to try AI before asking for more headcount. (Business Insider) Duolingo’s “AI-first” shift, including changes to how work is staffed, is another example of leadership trying to rewire the org around automation and leverage. (The Verge)

The implication is not “PMs are dead.”

The implication is: the org has less patience for roles that cannot directly accelerate learning and outcomes.

This is why the PM job splits into two archetypes in AI-enabled environments:

• The “product operator” PM who runs ceremonies, writes tickets, and translates between functions. AI eats a meaningful chunk of this, and orgs will push it into tooling, into the team, or into program management.
• The “product strategist and experiment leader” PM who sets direction, clarifies the bet, instruments the system, and drives rapid iteration with tight customer loops. This PM becomes more valuable, not less.

Most PMs want to believe they are the second archetype. Their calendars often reveal they are the first.

“But everyone can prototype now.” Exactly. That is why the PM must level up.

The PM in an AI-enabled team cannot be purely a non-technical coordinator. You do not need to be a production engineer, but you must be able to move at the speed of prototypes. Otherwise, you become the pacing item that Andrew Ng is warning about.

This is where “vibe coding” becomes a useful cultural signal. Andrej Karpathy’s framing captured what many teams are living: people can increasingly build by intent, using natural language to drive code generation. (on X)

If you are a PM and your superpower is writing a spec that takes two weeks to socialize, you will lose credibility in a world where a teammate can generate three working prototypes before your PRD is approved.

So what replaces the PRD as the PM’s leverage?

A tighter operating system for decisions.

What the best PMs are doing differently right now

They are not micromanaging delivery. They are not disappearing into strategy decks either. They are building a product learning engine that can keep pace with AI-accelerated execution.

Practically, that looks like this:

• They treat prototypes as questions, not solutions. Each prototype exists to answer one uncertainty: desirability, usability, feasibility, viability, compliance risk, adoption friction. If your prototype is not tied to a question, it is just expensive entertainment.
• They shorten the loop from build to signal. They ship behind flags, use concierge tests, run internal dogfooding with instrumentation, and put customers in front of flows weekly, not quarterly.
• They operationalize customer truth. AI can summarize interviews, but it cannot decide what matters. The PM owns the mechanism that converts messy qualitative input into clear product calls.
• They create decision hygiene. In high-velocity teams, the cost of a bad decision is not the decision. The cost is the cascade. PMs need lightweight decision records, explicit tradeoffs, and crisp “reversibility” framing so teams can move fast without becoming reckless.
• They make the team safer to move quickly. That includes guardrails for privacy, security, and compliance, especially when AI features touch regulated data. The PM is often the person who ensures “fast” does not become “fragile.”

The paradox: PMs must stop being the bottleneck by doing more “product,” not more “process”

If product management is becoming the bottleneck, the fix is not hiring more PMs to write more documents. It is upgrading the PM role into a higher-leverage function.

This is where the comparison to agile is useful. Agile gave us faster cycles, but many companies never built true empowerment. They created rituals around a command-and-control core.

AI will punish that model.

Because AI does not just increase speed. It increases optionality. And optionality without empowered decision-making becomes chaos.

So the question is not “what is the PM’s role in an AI-enabled team.”

The question is: can your PM function produce clarity, priority, and validated learning as fast as your engineers can produce code?

That mindset is legacy. It made sense when software shipped quarterly, lived behind corporate networks, and only a small slice of customers ever evaluated your security posture. It does not make sense in a world where your product is continuously delivered, deployed across a messy supply chain, and sold into procurement processes that treat trust as a first-class requirement.

Progressive teams stop debating whether security belongs on the roadmap. They design roadmaps where security is already inside the user journey, the platform, and the operating model.

Srajan Gupta captures the heart of the issue through the lens of security companies: security products are judged under pressure, not during polished demos, and traditional product thinking often fails when the stakes are highest. (srajangupta.substack.com) That observation translates cleanly outside “security products.” Your SaaS, your mobile app, your internal platform, and your API marketplace are also judged on their worst day: a breach, an outage, a bad permission model, or a compromised dependency.

When that day hits, nobody cares that your Q3 roadmap was feature-rich.

Why security keeps losing the roadmap fight

Security loses because most organizations treat it like a backlog category instead of a product property. In planning, features get narratives and champions. Security gets tickets and guilt.

That structural mismatch creates the usual failure mode: security is framed as “paying down debt,” and debt is framed as “optional until it hurts.” Then it hurts, loudly, and you pay in panic, churn, and deal friction.

There is a better framing: security is not a set of tasks you sprinkle in. It is a set of constraints and promises your product makes to users.

AWS has been telling the industry this for years, in plain language. The security pillar of the Well-Architected Framework is not a checklist you run after you build the workload. It is guidance for design, delivery, and maintenance. (AWS Documentation) That is product language, not just engineering language.

The same theme shows up in government and standards bodies: NIST’s Secure Software Development Framework (SSDF) is explicitly about integrating secure practices into your SDLC, because most SDLC models do not address security in enough detail by default. (NIST Computer Security Resource Center) In other words, if you do not deliberately wire security into the way you plan and build, it will not happen consistently.

And the market has moved from “best effort” to “secure by design.” CISA’s Secure by Design work pushes the idea that software makers should prioritize customer security as a core business requirement, not an add-on feature. (CISA)

This is the shift: security is now part of product legitimacy.

The fastest way to go “upstream” is to put security into the journey, not the sprint

When teams talk about “shifting left,” they often mean scanning earlier. That is necessary, but it is not sufficient.

Upstream security means you model risk at the same time you model value.

Security needs to show up in the same artifacts where product decisions are made: discovery notes, PRDs, wireframes, acceptance criteria, launch checklists, and go-to-market narratives. If the only place security appears is a Jira epic called “Hardening,” you have already lost.

Microsoft’s Security Development Lifecycle (SDL) is a canonical example of codifying security across phases such as requirements, design, implementation, verification, and release. (Microsoft) The big idea is not that Microsoft has more security engineers. The big idea is that the system forces teams to make security decisions early and repeatedly, not just at the end.

Here is what “security in the journey” actually looks like in modern products:

It shows up when the user first signs up and you decide whether “passwordless” is a convenience feature or a security control that changes your fraud model. It shows up when you design roles and permissions and realize that most breaches are not “hackers,” they are over-privileged accounts and confusing authorization paths. It shows up when you design audit logs and decide whether customers can prove what happened, not just guess. It shows up when you build integrations and realize your API is now part of your customer’s attack surface.

Those are product decisions. They shape usability, conversion, retention, and revenue.

Stop treating security as a tradeoff against speed. Make it a force multiplier.

The best security investment is the one that reduces cognitive load for teams and customers.

GitHub’s Dependabot security updates are a great example of this philosophy: instead of asking every team to manually track vulnerable dependencies, the platform can automatically surface alerts and create pull requests to remediate. (GitHub Docs) This is security as workflow design. It reduces toil and time-to-fix without turning every sprint into a negotiation.

Supply chain security is another domain where “security as product” is winning. SLSA (Supply-chain Levels for Software Artifacts) is framed as incrementally adoptable levels that help prevent tampering and improve integrity across the chain. (SLSA) The power here is not the framework itself. The power is the product thinking behind it: define maturity levels, make progress measurable, and give teams a path that does not require perfection on day one.

This is how you escape the tech debt trap. You build paved roads.

Security becomes a platform capability: automated scanning, dependency hygiene, secure defaults, policy-as-code, hardened templates, and straightforward patterns that teams can adopt without heroics. When you do this well, product teams ship faster because they stop reinventing security decisions for every feature.

Product management’s job is to make security legible

If you want security to be prioritized, you need to express it in the language the roadmap already rewards: user impact, business outcomes, and measurable risk reduction.

That does not mean fearmongering. It means clarity.

Security work often suffers because it is described at the wrong altitude. “Improve encryption” is not a product statement. “Protect sensitive documents at rest and in transit across download, share, and integration flows” is a product statement.

Progressive product leaders translate security into customer value and operational readiness. They treat a secure experience as part of the feature itself, not as a shadow backlog.

Frameworks like OWASP SAMM exist precisely to help organizations build a risk-driven, measurable security program across the lifecycle. (OWASP) You do not need to adopt every model wholesale, but you do need the discipline they represent: security maturity should be intentional and visible.

AI makes the “security is product” argument unavoidable

AI is accelerating shipping velocity, which is great until it accelerates vulnerability throughput too.

More importantly, AI changes your threat model. You are no longer only protecting data stores and endpoints. You are protecting prompts, tools, and agent workflows. You are protecting against misuse, not just bugs.

NIST has started extending secure development practices specifically for AI model development, which is a signal that security leaders are no longer treating AI as “just another feature.” (NIST Computer Security Resource Center) The organizations that win here will not bolt on governance after an incident. They will design AI capabilities with explicit guardrails, logging, and abuse cases from day one, and they will make those guardrails part of the user experience.

If your AI roadmap is all magic and no threat modeling, you are building a future incident response exercise.

What progressive teams do differently

They do not “prioritize security more.” They remove the conditions that cause security to be deprioritized.

They align product and engineering on a few non-negotiables:

• They define secure defaults as part of the product contract, and they treat deviations as explicit product decisions, not implementation details.
• They include abuse cases and threat modeling in discovery, so the “how could this be misused?” conversation happens before code exists.
• They bake security acceptance criteria into Definition of Done, so security is not something you remember, it is something you ship.
• They invest in platform capabilities that make secure behavior the path of least resistance, following the same automation logic that tools like Dependabot represent. (GitHub Docs)
• They talk about security in customer language, supported by recognized frameworks like SSDF, SDL, and Secure by Design, because trust has become part of how products are bought. (NIST Computer Security Resource Center)

Notice what is missing: the weekly fight about whether a security epic “steals” from feature delivery. That fight disappears when security is not a competing backlog. It is the way you build features.

The real competitive advantage is trust that compounds

In many markets, feature differentiation is fleeting. Trust is sticky. Teams that treat security as a product property win in three compounding ways.

They reduce existential risk because they are not gambling on luck. They ship faster because secure patterns and automation eliminate repeated decisions. And they sell faster because customers increasingly demand proof, not promises, and “secure by design” is becoming table stakes. (CISA)

If you want a modern roadmap philosophy, adopt this one: security is not what you do after you ship. Security is what makes shipping sustainable.

And once you internalize that, the question stops being “when do we schedule security?” The question becomes “how do we design the product so security is simply how it works?”

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.

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.

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.

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 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.)

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