Your engineers already did the competitor research

A backend engineer on a team I worked with spent two days last spring wiring up a competitor's API for a migration tool. Rate limits, auth model, webhook retry semantics, which objects they expose and which they conspicuously don't. He wrote it all in a Jira ticket, shipped the integration, and closed the ticket.

Four months later, product marketing built a battle card claiming the competitor "lacks a real API." It didn't lack one. It had a good one with a hard ceiling on write throughput — which is a much sharper thing to say in a deal, and which one person in the building had known since March.

That gap is not a tooling problem. It's a staffing assumption, and it's wrong.

Competitive intel hires the wrong department

Look at who runs competitive intelligence at almost any B2B SaaS company. Product marketing, usually. Sometimes a product manager with spare cycles, sometimes a founder, sometimes a strategy analyst. All of them read the competitor's public surfaces from the outside: pricing page, positioning, launch posts, review sites.

None of them have credentials. Engineers do. Engineers signed up for the competitor's free tier to test an integration. Engineers read the API reference closely enough to notice the deprecated endpoints. Engineers hit the rate limit, filed the support ticket, and got a real answer from a real solutions engineer on the other side. Every one of those is primary research that a marketer cannot replicate by reading a landing page, and it's already been done — for free, as a side effect of shipping something.

The assumption is that engineers are too expensive to spend on competitive work. The reality is that they already spent the time. The company just never collected the output.

The surfaces engineers read are the honest ones

Marketing pages are written to be read by buyers. API docs are written to be read by machines and the people who talk to machines, which means they get updated when the product changes, not when the positioning changes. Same with changelogs, status pages, SDK release notes, and error message catalogs.

An engineer evaluating a competitor's integration notices things a positioning review never will. Which fields became required. Which endpoints are versioned and which are frozen. Whether the SDK has a half-implemented module for a product line that hasn't launched. Whether the OAuth scopes hint at a permissions model built for enterprise buyers they don't yet have. Whether the status page splits incidents by region in a way that tells you where their infrastructure actually lives.

That is not soft signal. It's the closest thing to a roadmap a competitor publishes, and the people who read it fluently are on the other side of the org chart from the people writing the competitive brief.

Nobody asks, because "intel" sounds like homework

Here's why this doesn't fix itself. The way most programs try to include engineering is by broadcasting: a #competitors Slack channel, a monthly newsletter, an invitation to "share anything you notice." That's an open-ended ask with no deadline, aimed at people whose entire working culture is built around closing well-specified tickets. It gets ignored, and everyone concludes engineers don't care about competitors.

They care fine. The ask is just malformed. "Tell us anything interesting" is not a task. "You integrated with their API last quarter — what surprised you?" is a task, it takes four minutes, and it produces a usable answer. The same pattern shows up with support queues: the signal was always there, the collection mechanism was the thing that didn't exist.

There's also an incentive problem worth naming honestly. Engineers who found something damning about a competitor's architecture have no reason to volunteer it, because volunteering leads to being pulled into a deck review. Make the extraction cheap and the reporting invisible, or don't bother.

Ask narrow questions, and only after something happens

The version that works is unglamorous. When an engineer touches a competitor's surface for any reason — an integration, a migration script, a bake-off, a customer asking why the two products disagree — someone asks three specific questions within a week, while it's fresh. What did you have to work around? What did they make easy that we make hard? What's in their docs that isn't in their product yet?

The trigger matters more than the cadence. A standing monthly ritual produces nothing, because most months no engineer touched a competitor. A trigger fires exactly when there's something to collect.

This is also the boundary where tooling earns its keep and where it doesn't. Seeto watches public surfaces continuously and reports what changed as discrete events — a new endpoint in the docs, a rewritten integration page, a changed status page structure — so the change itself doesn't depend on someone happening to look that week. What it can't do is tell you the write throughput ceiling your engineer hit in March. That came from using the thing. The tool tells you when to go ask; the engineer tells you what it means. Treating either one as the whole program is how you end up with a battle card that's confidently wrong.

None of this requires headcount, a new tool, or a program. It requires believing that the most useful competitive research in your company has already been done by someone who wasn't asked to do it — and going to find them. Your competitor's product has been evaluated by your team. Go read the ticket.