There is a failure mode that kills more early-stage platform companies than bad technology or bad timing: building in a vacuum. The pattern is always the same. A team ships infrastructure that is genuinely good. Customers show up with diverse use cases. Each customer pulls the product in a slightly different direction. The team, eager to retain every account, follows every request. Six months later they have built three different products and none of them are complete.
The alternative is not ignoring customers. It is structuring how you listen to them. A formal design partner program — biweekly syncs, shared prototypes, explicit agreements about what you are building together and what you are not — creates the discipline to pluck a feather from each passing goose without following any single goose off a cliff.
The customers who matter at this stage are the ones with good taste about where the market is going. Not good taste in button placement — good taste in the sense of understanding how teams will operate in eighteen months. Those customers are rare. When you find them, the relationship should be structured enough to extract real signal rather than a feature request list.
What you show design partners matters as much as what you ask them. Provocatypes — prototypes designed to provoke conversation rather than demonstrate functionality — are more valuable than polished mockups at this stage. Show a customer a screen that is nothing but a chat box and watch what happens in their head. Show them a workflow builder with deterministic and non-deterministic nodes stitched together and watch what they reach for. The goal is not to validate a roadmap. It is to discover what the roadmap should be.
The two most common customer archetypes right now illustrate why this matters. One wants workflow-driven agents — deterministic steps mixed with LLM calls, parsing alerts, asking for human approval at specific gates. The other wants agents as staff augmentation — research handing off to PRD writing handing off to ticket creation. Both are valid. If you chase both without a unifying product shape, you build neither well. I've argued elsewhere that agents are about to break out of engineering — that breakout is exactly when the unifying primitives matter most, and design partners are how you find them before the market does.
Sources
Related Essays
From Agent to Platform: Why the GTM Is Services-Shaped
There is no winner-take-all platform in agents. The GTM is services-shaped, the harness is commoditized, and coding-agent companies have a narrow window to pivot before the floor falls out.
Follow No Goose Absolutely
Design partner programs prevent enterprise AI companies from building three products when they should have built one.
GTM Mesh: Closing the Gap Between Ad Click and Revenue
The space between an ad click and a revenue event is where most go-to-market motions lose the plot. Static landing pages cannot fix it. A mesh of agents can.
Key takeaways
- The failure mode that kills more early-stage platform companies than bad technology is building in a vacuum, then over-correcting by following every customer request.
- A formal design partner program — biweekly syncs, shared prototypes, explicit scope — creates discipline to extract signal without losing direction.
- Provocatypes beat polished mockups. Show a customer a chat box and watch what happens in their head. Show them a workflow builder and watch what they reach for.
- The two dominant customer archetypes — workflow-driven agents and staff-augmentation agents — are both valid. Chasing both without a unifying product shape means building neither well.
FAQ
What is a provocatype, and why does it beat a polished demo?
A provocatype is a prototype designed to provoke conversation rather than demonstrate functionality. At an early platform stage, you are not validating a roadmap — you are discovering what the roadmap should be. A blank chat box or a half-built workflow editor reveals what customers actually want far better than a finished mockup ever does.
What customer archetypes are emerging in the agent platform market?
Two dominate. The first wants workflow-driven agents — deterministic steps mixed with LLM calls, parsing alerts, consulting playbooks, asking for human approval at gates. The second wants agents as staff augmentation — research agents handing off to writing agents handing off to ticket-creation agents, with humans sitting in a needs-review queue all day. Both are valid; they may share the same primitives.