Stop Waiting for Forms. Start Listening to Events.

Developers do not buy software through sales reps. They buy it through terminal logs at 2 AM.

They run your docker compose. They read your docs. They push your code to staging. By the time someone on your sales team sees an email address, the evaluation is already over.

They either bought it or abandoned it three weeks ago.

This is the developer-led buying trap. You think you have a lead generation problem. You actually have an instrumentation problem.

I spent 70 minutes running public telemetry and docs patterns on SigNoz, the open source observability platform, to see where commercial deals quietly slip through the cracks.

Here is the exact breakdown.

The silent signals

Before a developer ever talks to sales, two things happen.

First, an engineer changes jobs into a target account. Second, that company lists three open SRE roles in the same month.

Neither is intent. Both tell you where to look.

The real intent happens in the documentation.

Most teams treat docs traffic as vanity volume. That is a mistake. An engineer reading generic setup guides means nothing. An engineer searching your docs for “Datadog exporter migration” or “collector memory limits” is not browsing.

That is an active migration project with an allocated budget.

The problem

Self-hosted deployments mean developers running docker compose on a Tuesday night, with no form anywhere in the journey. Catching commercial intent inside that motion, using only what's already paid for (HubSpot, Segment, Slack, a warehouse), is the real constraint. Four tools. Not five.

I worked it as six connected pieces, each following the same shape: what I’m assuming, what I’d do, what it costs. A separate appendix site has the reasoning behind all of it: buyer journey, event spec, signals reference, scoring rules, stack wiring, and a page of judgement calls explaining every deliberate omission.

The buyer journey

Before anyone touches the product, two things are worth watching: a past user changing jobs into a company that fits the profile, and a company posting several SRE or platform roles at once. Neither is intent on its own. Both tell you which accounts to watch.

From there, three stages:

Technical awareness. GitHub stars, forks, and depth into the scaling, security, retention and RBAC docs specifically, not general docs traffic. It moves forward on a PR push, a new tool in the stack, or a migration signal — removing a Datadog SDK, adding OpenTelemetry instrumentation.

Product activation. A local docker compose deployment, first telemetry pings. It moves forward when package downloads across npm, Docker, pip and Maven show up together with continued high-intent docs behaviour.

Commercial qualification. The account hits a real limit — performance, scale, a retention threshold, a request for SSO or RBAC. This maps onto SigNoz’s actual paid gates, so it’s the stage where usage becomes a sales trigger instead of a hope.

The clearest signal in the whole journey isn’t any of those three stages. It’s someone searching the docs for “SigNoz vs Datadog exporter” or “OpenTelemetry collector migration.” That’s not a lead. That’s a project with a budget that started before anyone in sales knew about it. SigNoz already ships a Datadog migration tool and lists “switch from Datadog” as a named use case, so the search intent maps onto a motion that already exists.

Every conversion point in this journey is an event, not a form. Which is also the cost of the whole approach: it ignores top-of-funnel volume on purpose, and it will look thin next to a marketing dashboard that counts page views.

coring: the trigger rule

One High signal fires outreach. Two Medium signals stacked at the same account, with a decision-maker present, also fire. A Weak signal never does, no matter how many times it repeats. A LinkedIn click that lands on the site goes to retargeting, however often it happens.

Who fired it matters as much as what fired. Technical influence and budget authority are separate things: a “SigNoz vs Datadog” search from a Staff SRE outranks a VP browsing the pricing page. The SRE is the trigger. The VP is the closer. When two High-tier accounts compete for attention, role convergence breaks the tie — engineers plus a budget-holder title active at the same account beats engineers alone.

Signals don’t decay at one rate either. Frustration signals (a paid ceiling hit, an error on the migration doc) go stale in about a week. Deadline signals (a renewal date, a migration in progress) get more urgent as the date closes in. So the queue isn’t first-in-first-out.

I wouldn’t ship a weighted score on day one. Giving an economic buyer 3x the points with no conversion data yet is a guess dressed as a model. Phase one is instrumentation: capture the signals, tag every closed-won and closed-lost with what fired and when. Phase two lets that data set the weights.

The score itself should never be a bare number. It should carry its reasons:

82   VP Eng hit the Datadog migration doc twice this week
     three engineers from the same domain active
     retention at 80% of limit

A senior rep can audit that in five seconds and overrule it. A newer rep can follow it.

Scoring systems don’t usually die because the maths is wrong. They die because experienced reps don’t trust a black box and quietly stop opening it. So the override is worth keeping: when a rep ignores a low score and wins the deal anyway, that disagreement tells you more than a hundred correct predictions did.

Tool 1 — the funnel dashboard

The live funnel dashboard tracks the five stages from the buyer journey: Awareness, Acquisition, Activation, Retention, Commercial Trigger. 8,240 GitHub-and-docs touches this window, narrowing to 47 migration-intent accounts and 22% of those converting to an opportunity.

Every volume metric sits next to a quality metric, so a spike from a Hacker News post doesn’t get mistaken for growth. GitHub-to-docs is up 1.8 points month over month, which reads as good until you see time-to-first-signal got 14 minutes worse in the same window. The headline metric across the board is time to first signal, not volume at the top.

The data here is illustrative. Nothing on it claims a real SigNoz activation rate or close rate — I don’t have that data, and a made-up number presented as theirs is the one mistake in this whole exercise that can’t be walked back

Tool 2 — the signal ops board

signalopz

The signal ops board answers a different question than the funnel: not whether the motion is working, but whether the signals are being acted on, and how fast. Median time from a High signal to first touch was 9 hours against a 24-hour target — last week it was 14. Queue depth shows 6 unassigned accounts sitting there, which is its own kind of leak.

Four lanes, each meaning something specific:

High — fired, acted on, has an outcome. Northwind: migration doc hit twice, VP Eng title present, touched in 3 hours, replied.

Medium — real, but not enough alone. Litware has an AWS integration connected and needs one more Medium plus a decision-maker before it moves.

Unknown — something happened and nobody can say yet what it means. Four visits from one company ASN, no identity. Watched, not routed. Nobody gets an email from this lane.

Fast action — what’s already gone to Slack, sorted by how cold it’s getting. Newest first, nearest deadline first, then everything else oldest first so nothing sits for a week untouched.

The board is also where the reply-rate breakdown lives: a migration doc hit plus a pricing-card view converts to a reply at 4 in 12; the same doc hit with no card view converts at 2 in 12. That’s the kind of thing you only see once you’re tracking the pairs, not the individual events.

Tool 3 — the sequence that waits for a reply

Only accounts passing the trigger rule enter the sequence. A LinkedIn click that lands on the site is a Weak signal and never gets in, however many times it happens — it goes to retargeting instead.

Two signals feed this sequence most often: a hit on the Datadog migration page, or an account approaching its paid-plan ceiling. Step one is a founder-sent email with a personalised cost card — {{Contact > costCard}} pulls each account's own estimated Datadog spend against SigNoz Cloud, computed per lead rather than written once and sent to everyone. "Someone at {{Company}} hit our Datadog migration docs twice this week. Ran your numbers at your service count. Here's what that costs on both."

Then it waits three days and branches on one condition: has this person replied. Yes — stop the campaign, push to HubSpot, a human takes it from there. No — a LinkedIn invitation on day six, a chat message on day eight. The sequence gets out of the way the moment a real conversation starts, rather than firing on a schedule regardless of what the account just did.

What I left out on purpose

No fabricated numbers. The funnel dashboard runs on illustrative data throughout. Nothing claims a real activation rate, churn rate, or close rate for SigNoz.

No new tools beyond two. Four tools were already in place. That’s a test of whether you can run what’s already paid for, not an invitation to rebuild the stack. Every tool you add is a bill, a login, and something one more person has to learn, usually at the same time they’re learning the signals. So the bar was simple: name the gap the four tools can’t close, then add the smallest thing that closes it. A warehouse passed, because the score has to be computed somewhere that can do joins and the CRM can’t. Redis didn’t pass. A second CDP didn’t pass. Each one solves a problem that doesn’t exist yet.

Two stages, not four. Picking two that work by different mechanisms (product-event emails, signal-triggered sales follow-up) says more than covering more of the funnel with the same mechanism repeated.

Before any of it ships: find out what fraction of users are self-hosted, what fraction of closed deals came from a migration signal, and whether docs traffic is tracked at page level. Those three answers decide how much of this plan survives contact with the real data.

What stuck with me

The write-up went back to SigNoz and got read closely — opened eight separate times across three people over two days, well past a single skim.

What I took from building it, separate from where it leads: developer-led buying isn’t really a sales problem. It’s an instrumentation problem first. Get the events right — GitHub activity, docs depth, package downloads, the specific page someone hit — and the scoring, the sequencing, even the tooling choices mostly fall out of that. Get the events wrong and no amount of weighting or automation fixes it