#Metrics
Articles about Metrics — exploring patterns, best practices, and real-world implementations in production systems.
6 posts tagged with metrics. ← All posts
Without measurement, GTM is guessing — you can't tell a channel that works from one that flatters you, a healthy business from one quietly bleeding, or whether your last change helped. But GTM measurement has a trap engineers fall into from the opposite side: drowning in dashboards of vanity metrics that feel rigorous while missing the two or three numbers that actually decide whether the business works. This closing post is about measuring what matters — and the unit economics that separate a real business from an expensive way to lose money.
Without measurement, GTM is guessing — but the engineer's trap is drowning in dashboards of vanity metrics that feel rigorous while missing the two or three numbers that actually decide whether the business works. This is about measuring what matters — and the unit economics that separate a real business from an expensive way to lose money.
Before you can score an LLM, you have to decide what "good" even means for your task — and that choice determines everything downstream. Metrics fall into a few families, from exact string matching to reference overlap to semantic similarity to task-specific checks, each measuring something different and each with blind spots. Picking the wrong metric is worse than no metric: it gives you a confident number that points the wrong way.
Before you can score an LLM you must decide what "good" means — and that choice determines everything. Metrics fall into families (exact match, reference overlap, semantic similarity, task-specific), each measuring something different with different blind spots. Picking the wrong metric is worse than none: it points confidently the wrong way.
Turning red-team attacks into metrics you can act on and track over time — attack success rate, coverage, severity, and trend — plus the honest limits of what any of those numbers can tell you.
Turning attacks into metrics: attack success rate and why it's subtle, scoring success (rule/classifier/LLM-judge with its biases), coverage across the taxonomy, severity weighting, tracking trends per model/prompt version, and honest reporting of residual risk.
Subscription businesses changed what "revenue" means. When customers pay every month instead of once, a whole new vocabulary appears — MRR, ARR, churn, net revenue retention, the Rule of 40 — and these metrics, not the raw P&L, are how SaaS companies are actually judged. For any engineer working at or evaluating a subscription business (which is most software today), these are the numbers that matter, and the logic behind them explains why SaaS companies behave the way they do.
Subscription businesses changed what 'revenue' means. When customers pay every month instead of once, a whole new vocabulary appears — MRR, ARR, churn, net revenue retention, the Rule of 40 — and these metrics, not the raw P&L, are how SaaS companies are actually judged.
"Half the money I spend on advertising is wasted; the trouble is I don't know which half" is a century-old lament that still captures marketing measurement's core problem. Engineers, arriving with a "measure everything" instinct, often assume the answer is just better tracking — and then discover that the most valuable marketing (brand, demand creation, word-of-mouth) is precisely the hardest to measure, while the easiest-to-measure activities aren't always the most valuable. Measuring marketing well means navigating that tension, not pretending it away.
'Half the money I spend on advertising is wasted; I don't know which half' still captures marketing measurement's core problem. Engineers assume the fix is better tracking — then discover the most valuable marketing (brand, demand creation, word-of-mouth) is the hardest to measure. Measuring well means navigating that tension, not pretending it away.
How do you know if your product is actually working? Not "did we ship the feature" but "did it make the difference we hoped?" Answering that requires metrics — and product management lives in a productive tension here: data is essential for knowing whether you're succeeding, yet the most metric-obsessed teams often build worse products by optimizing the measurable at the expense of the meaningful. Using data well means measuring what matters, letting it inform judgment, and resisting the traps that catch data-driven teams.
How do you know if your product is actually working? Answering that requires metrics — and PM lives in a productive tension: data is essential, yet the most metric-obsessed teams often build worse products by optimizing the measurable at the expense of the meaningful.
All posts on this site are written by Pratik Dhanave, an Agentic AI Architect with 7+ years building production distributed systems, multi-agent AI platforms, and cloud-native infrastructure. About the author → Each article includes working code, architecture diagrams, and references to the specific frameworks and standards discussed. Browse all posts or explore related topics using the tag cloud above.