Follow No Goose Absolutely

There is a Chinese proverb that applies to every early-stage enterprise AI company right now: pluck a feather from each passing goose, but follow no goose absolutely.

When you have four engaged customers asking for four different things, the natural instinct is to chase each request. One wants deterministic workflow agents for on-call automation. Another wants staff augmentation for non-engineering teams. A third wants composable agents that hand off work to each other. They are all reasonable requests. They are all informed by real pain. And if you follow all of them simultaneously, you will build three different products when you should have built one.

The tension is real. A founder I spoke with recently put it plainly: his team was complaining they had built too broad, but he would rather be too broad than too narrow. The risk of narrowing too early is that a single customer — especially a reasonably sized enterprise paying six figures — defines your product as a point solution for the one thing they care about right now. Nobody explicitly asks you to become a point solution. They just keep filing tickets about their corner of the product, and gravity does the rest.

Put a ten-person dev team up against three or four hundred-thousand-dollar customers and everything gums up. Real enterprises find every little bug and make it important. The surface area of a broad product multiplied by the expectations of serious buyers creates a combinatorial explosion of work. The team feels it as a complaint about scope, but the actual problem is the absence of a mechanism for synthesizing customer input across accounts.

The Customer Who Stress-Tests Everything

The most instructive design partners are not the ones with clean setups. They are the ones managing real entropy. Consider a healthcare tech leader who inherited three acquired companies being consolidated into one platform. Three source control systems — GitHub, GitLab, Bitbucket — being migrated to GitHub Enterprise. Code in Java and Python living in the same repos. HIPAA constraints that lock down database access behind IP whitelists. A PE firm looking over their shoulder, potentially invested in a competitor, requiring a clear justification for every tooling decision.

This is the customer who will find every seam in your product. The Bitbucket integration that silently fails to sync repos. The MR review bot that posts comments as the user instead of as itself. The usage dashboard that shows zero when it should show token counts. The model selection page that offers no guidance on which model fits which task. Each of these is a small thing. Together they are the difference between a product that works in a demo and a product that works in an enterprise.

The instinct is to treat these as support tickets. They are not. They are design input. When a customer says "I need to enforce coding standards across 360 repos spanning three languages and two continents," that is not a feature request — it is a constraint that reveals whether your product architecture is right. When they ask "how do I make the agent use the Python skill for Python code and the Java skill for Java code without me specifying it every time," that is a question about whether your skill system is composable or just decorative.

The Fix Is Structure, Not Heroics

The fix is not to ignore customers. It is to create a venue where customer input gets synthesized instead of serialized. A design partner program with real ceremonies — biweekly syncs, shared prototypes, structured feedback — forces you to see the overlapping shape across divergent requests. Without that structure, each new customer conversation becomes a gravitational pull toward a different roadmap. You do not see the full graph. You just see the latest request, and you start building toward it. Then another request arrives, and you pivot again. The result is a product that serves nobody well.

What separates a design partner program from ordinary customer support is the bidirectional commitment. The customer agrees to start small — one person testing end to end before expanding to seven direct reports, then maybe twenty-five. They agree to file bugs with context, to test early-access features behind feature flags knowing they might break, to share their internal tooling landscape honestly. In return, the company assigns a dedicated engineer to their shared Slack channel, builds custom MCP integrations when the standard ones fall short, and gives them early access to features like cloud-based dev environments and new UI layouts before they ship broadly.

This is not charity. The customer who is consolidating three acquired platforms onto one stack will surface integration edge cases that no amount of internal dogfooding will find. The customer whose PE firm is also looking at Factory AI will force you to articulate your differentiation clearly — not in a pitch deck, but in a live debugging session where you are trying to get Bitbucket repos to sync. The customer who needs to prove ROI to non-technical investors will tell you exactly which usage dashboards and governance features are missing.

Infrastructure Bets vs. Product Surface

The infrastructure underneath — sandboxes, cloud-based dev environments, multi-cloud support — those bets are safe. You need them regardless of where the product surface lands. The trend toward cloud-based development machines, where every PR comes with a suspended environment that has the right memory and environment variables already configured, is a good example: it serves the PE firm that just inherited 360 repos and the fintech that needs 128 gigs of RAM to run their stack. The infrastructure is general. But the experience layer on top, the thing customers actually touch, needs validation before you pour concrete. The difference between a pickup truck and a minivan matters a lot when you are building the engine. And right now, most early-stage agent companies are building engines without knowing what vehicle they are designing.

The product surface questions are the ones that design partners answer: Should skills be auto-invoked based on file type, or should the user specify them? Should agent reviews post as the user or as a bot account? Should enrichment agents run on ticket creation or wait for a status change? Should the platform recommend which model to use for which task, or leave it to the user? These are not technical questions. They are product questions that only emerge when real people try to use the tool in real workflows with real constraints.

The Switching Cost Problem

What makes this moment dangerous is that enterprise AI customers churn fast. A company can spend six months deeply integrated with your tool and ditch it overnight for something marginally better. Developer-facing agent tools have near-zero switching costs because the core interaction — prompt to code — is identical everywhere. Transparency and full customizability are real differentiators, but only if customers can see them. The stickiness comes from workflow, from UX patterns that non-technical users adopt and refuse to abandon. That is where the product surface matters most.

A customer who has built six agents, connected three source control systems, configured triggers across Jira and GitLab, and trained their team on a particular review workflow is not going to switch easily — but only if the experience is good enough that they actually got that far. The design partner program is what gets them that far. Without it, they hit the first broken integration, file a support ticket that takes three days to resolve, and start evaluating the competitor their PE firm already has a relationship with.

There is a related trap for companies that chose cockroach mode — small teams, long runways, disciplined burn. The logic is sound. But in a space flooded with big money, cockroaches can get caught. Competitors who raised aggressively and hired fast can catch up to an early lead in a single year. The cockroach survives, but survival is not the same as winning. The design partner program matters here too: it is the mechanism that lets a lean team punch above its weight by building exactly the right thing instead of building everything.

So build the infrastructure. It is the right call. But run the design partner program in parallel. Show customers provocative prototypes — rough, opinionated sketches of what the product could be — and watch which ones spark real conversation. The customers who are willing to collaborate on the future of your product are the most valuable asset you have. Use them. Just do not follow any single one of them off a cliff.