The Surface Area Problem.Building got cheap. Distribution got expensive. Make every new surface earn its complexity.

Building got cheap. Distribution got expensive.

Every PM is putting on a builder hat. The next edge comes from thinking like a GM and a growth marketer. Building is no longer the scarce skill. Deciding what deserves to exist, where it should show up, how it gets chosen, and when to kill it is.

At the start of 2026, the distribution map for most applied AI products still looked familiar. You had the surfaces you owned: web, mobile, trad search, and perhaps AI chat through ChatGPT or Claude.

Six months later, that map is obsolete.

Chatbots became app stores. Coding agents became software buyers. Work agents became new operating environments. Products are increasingly discovered, selected, and invoked inside interfaces their makers do not own.

In recent conversations with operators, I keep hearing the same pattern. They do not lack AI tools or ideas. They have too many of both. Their constraint is deciding which workflows matter, where those workflows should live, what should be built versus bought, and who will maintain the resulting software.

One lesson I took from building applied AI at Webflow is that the demo is the easy part. The real product appears afterward: permissions, context, activity logs, evaluation, adoption, and ownership.

Three things changed.

The same product can appear on owned surfaces, inside systems of record, in answer engines, and through coding or work agents. That does not mean it should. Each step away from an owned surface can add reach while reducing control, attribution, brand visibility, and direct customer learning.

Your first job is to name what the surface is for. Is it where demand begins? Where a complete job happens? Where another agent calls your capability? If the answer is “all of the above,” the strategy is not specific enough.

Not every surface deserves a product.

Decide how much of your product a surface deserves before you write an integration spec. Every surface gets one of four modes.

Protocols can reduce the cost of showing up. They do not create a reason to be chosen. Protocols buy portability. They do not buy product-market fit.

Count the work that starts after launch.

A surface can have enormous reach and still be a bad investment. “The platform has millions of users” is not user pull. Before building, answer five questions in plain language:

1. Are people already trying to do this job here? Look for requests, workarounds, failed handoffs, and repeated prompts.
2. Can they finish the job here? Starting a workflow is not useful if the user cannot complete it or hand it off cleanly.
3. What remains uniquely ours? Name the data, workflow, or judgment the host cannot cheaply reproduce.
4. What trust work does it create? Include identity, permissions, audit, revocation, policy, and safe failure.
5. Who owns it after launch? Name the team, maintenance budget, support path, and the work you will stop doing to keep it reliable.

I have heard operators describe internal agents that cut hours of work to minutes and caught costly mistakes that people missed. In the next breath, they ask who will maintain those agents when requests pile up, APIs change, and a scrappy prototype becomes internal software.

The advanced teams are not asking whether they can build an agent. They are asking which workflows deserve one, how to prove value, and how to keep a portfolio of agents from becoming a portfolio of liabilities.

Build the core once. Make every surface earn its complexity.

This is the thesis behind Foo, the system I am building for agent-native product work. Tools, agents, and interfaces will keep changing. The durable value lives below them: company context, permissions, product judgment, and proof that the work actually happened.

A portable applied AI product separates five things:

1. Capability. The durable job your product performs, independent of where it is invoked.
2. Context. The customer data, history, instructions, and domain model required to perform that job well.
3. Trust. Identity, delegated permissions, policy, audit, revocation, and safe failure behavior.
4. Proof. Shared telemetry and evaluations that show whether the job succeeded and whether the agent did what it claimed.
5. Surface. A thin contract that translates a host’s inputs, actions, and outputs into the shared capability.

Centralize the capability, context, trust, and proof. Keep the surface thin until customer behavior justifies something deeper. A new interface should not create a new source of truth, permission system, evaluation stack, or version of your product logic.

I learned the importance of this at Webflow. Granular permissions and activity logs are not enterprise edge cases once agents begin acting across systems. They are the product. Without them, adding surfaces multiplies risk faster than reach.

The surface is rented. The capability, context, trust, and evidence must remain yours. Native is earned through repeated work, not announced in a launch post.

Measure whether the work got done.

Traditional product analytics assume the user arrives, starts a session, moves through a funnel, and converts. Agent distribution breaks that assumption. The host may select your tool, invoke it in the background, summarize the answer, and never send the user to your interface.

In one recent operator call, a CEO told me he did not trust his own AI team’s precise claims about hours saved. In another, a technically successful automation fell flat because employees did not adopt it. Output is not impact, and deployment is not distribution.

Replace the page funnel with a job funnel:

Useful metrics include:

• Successful jobs per eligible invocation, not raw calls
• Repeat use by customer and workflow
• Human corrections, overrides, and failed handoffs
• Incremental activated accounts from the surface
• Retention and expansion by first surface of use
• Maintenance cost per successful retained workflow

Compare the results with your owned experience and with a holdout whenever possible. Otherwise, a new surface can appear to grow while merely redistributing usage you already had.

Kill it. Keep it thin. Commit.

Every active surface review should end with one of three decisions. No vague “keep exploring.” No experiment that quietly becomes a permanent product line.

Watch sits before the active portfolio. A surface stays there until it earns even a thin test. For every surface you activate, record the user and job, a single owner, the full cost, the evidence required to continue, and a decision date.

An integration without a kill date is a permanent team commitment. A stopped integration is not necessarily a failed investment. If it answers an important question before you scale the maintenance burden, it has done its job.

Be easy to invoke. Be difficult to replace. Be disciplined about where you show up.