Tessl Shipped 10,000 Specs. None Help Your PM Write One.
Spec-driven development just got a serious infrastructure layer. The upstream PM authoring layer is still open.
Delvyn Studio Team
Product Team
Tessl just made the spec-driven market feel real. This month the company launched its Spec Registry and Framework, with 10,000+ specs in the registry, open beta access, and Guy Podjarny credibility behind it. That matters. It means serious engineering teams now have a place to store, reuse, and govern specs for AI agents. It also makes one missing layer impossible to ignore: none of that helps a product manager think through and write the spec in the first place.
The Same Gap Shows Up Everywhere
Tessl is not alone here. The new Every guide to agent-native product management says "the conversation is the work" and walks through a modern stack that includes Claude Code, GitHub Issues, Linear, PostHog, Stripe, Paddle, Datadog, Sentry, Logfire, Honeycomb, Canny, Featurebase, plus Every's own Spiral and Compound plugin. Productboard Spark now sharpens the same story with a new hero line, "The agent that works the way product managers do," and five skills that span opportunity discovery, feedback analysis, product specification, post-launch evaluation, and release notes. These are good products and useful guides. They still skip the same bottleneck: who helps the PM do the hard thinking that turns strategy into a spec worth executing?
Why the Upstream Step Matters More Now
Coding agents are no longer the bottleneck. Bad specifications are. If your team gives Claude Code, Copilot, or Cursor a vague spec, you get faster wrong code. If your team gives them a context-rich spec, you get leverage. That is why Marty Cagan's framing matters here. In Product Coaching and AI, he argues that models become useful only when they have "project instructions and your company's strategic context." That is the part AI still does not invent for you. Product judgment is still upstream of the artifact.
Tessl and Delvyn Sit on Different Sides of the Split
This is not a Tessl attack, and it is not a tool-swap argument. Tessl is where engineers store specs. Delvyn is where PMs author them. Tessl gives agents reliable downstream infrastructure: specs, guardrails, tests, and reuse. Delvyn gives PMs the upstream method for turning product thinking into an executable spec. Those are complementary jobs. In fact, Tessl's launch makes Delvyn easier to explain because it makes the downstream half visible. Once you can see the engineering-side registry, you can finally see the authoring gap in front of it.
What PM-Side Spec Authoring Actually Looks Like
In Delvyn Studio, the spec should not start from a blank chat window. It should start from the product context you already worked to create. The shipped workflow today is concrete, not vaporware:
- Start from a validated idea or OKR key result instead of a blank prompt
- Assemble product vision, strategy, guardrails, discovery, and acceptance criteria into the spec automatically
- Run the AI Specification Coach to check clarity and completeness before handoff
- Push the finished spec to GitHub Issues or Linear, where Claude Code, Copilot, or other coding agents can execute it
- Use Delvyn's MCP Server to expose live product context inside VS Code, Cursor, or any MCP-compatible IDE
A Better Interface for Product Judgment
Imagine Lena, a PM at a 25-person SaaS company, working on a retention feature. Tessl can absolutely help her engineers reuse the right downstream patterns once the spec exists. Spark can help summarize feedback. Every's stack can help instrument the launch. None of those tools replaces the moment where Lena has to decide what problem is worth solving, what tradeoff is acceptable, what the non-goals are, and how success should be measured. That is the job before the spec registry.
“We did not need another place to store specs. We needed a better way to think our way into one.”
The Stack Is Finally Splitting Cleanly
The emerging pattern is clearer now than it was even a month ago. Productboard Spark is converging on the PM workflow. Every is defining the agent-native operating loop. Tessl is building the engineering-grade spec layer. The open space upstream is the methodology-anchored place where PMs create the spec itself, grounded in vision, strategy, OKRs, discovery, and learnings. That is the slot Delvyn is built for. Use Spark if you like its workflow. Use Tessl if your engineering org wants a registry. Use Every's stack if it fits your team. But give your PM a better starting point than a blank prompt.
Write the Spec Before the Registry
Use Delvyn Studio to turn vision, strategy, discovery, and OKRs into agent-ready specifications before they flow to GitHub, Linear, or any MCP-aware tool.