A product manager sits across from you and describes a business idea related to monitoring. They ask you to walk through how you'd take it from ideation to commercialization. This is the interview.
The first thing to understand is what they're actually testing. It is not the quality of your idea. The PM already has the idea. They want to see your process — how you think through an unfamiliar problem in a structured way. Can you break ambiguity into concrete steps? Do you ask the right questions? Do you make reasonable trade-offs?
The ideal answer is not a pitch deck. It is a conversation. You are thinking out loud, showing your work, and making the interviewer feel like they'd want to build something with you.
2. The Industry
Before you walk into the room, you need just enough context about the monitoring industry to have a credible conversation. Not deep expertise. Just the shape of the landscape.
Monitoring means watching systems to detect problems. Observability means understanding why systems have problems. The industry has shifted from the first to the second over the past decade, driven by cloud-native architectures that are too dynamic and distributed for simple threshold-based alerts.
The core observability market is roughly $3–5B today, but the major vendors — Datadog ($3.4B revenue), Dynatrace ($1.7B), Elastic ($1.5B), New Relic (~$1B), Grafana Labs ($400M+ ARR) — collectively earn over $12B by spanning APM, logs, security analytics, and infrastructure monitoring. The broader market is $25–60B depending on where you draw the boundary. Growth runs 15–20% annually, with cloud-native players growing faster. Open-source tools like Prometheus and OpenTelemetry have reshaped how telemetry is collected.
The buyers are engineering teams — SREs, platform engineers, developers — and the budgets come from infrastructure or engineering leadership.
You do not need to memorize every number. You need to know that this is a large, crowded, growing space where differentiation matters — and that new categories keep emerging at the edges.
To make the rest of this guide concrete, we will follow four hypothetical ideas through every step. Each one represents a different emerging category in the monitoring space. Use the tabs below each section to see how the same thinking process applies to very different products.
The PM describes the idea. Your instinct will be to react immediately — to start solving, to say what you'd build. Resist that instinct. The single most important thing you can do in the first thirty seconds is listen.
When they finish, repeat the idea back in your own words. This does two things: it confirms you understood correctly, and it gives you time to think. Then ask clarifying questions. Three are usually enough to start:
"Who is the primary user you have in mind?"
"What's the core problem this solves for them?"
"Why do you think now is the right time for this?"
These questions signal that you think about products from the user's perspective, not from the technology outward. That matters more than any framework you'll use later.
The PM says: "We should build observability for LLM-powered applications — traces, costs, quality metrics."
You ask:
"Who's the primary user — ML engineers or app developers?"
"What's the core pain — cost surprises, latency, or hallucinations?"
"Are target customers already in production, or still prototyping?"
These questions cut to the heart of the opportunity. An ML engineer fine-tuning models needs very different tooling than an app developer calling the OpenAI API. Production teams have urgent pain; prototyping teams have curiosity.
The PM says: "We should build a product that automatically tracks DORA metrics for engineering organizations."
You ask:
"Who's the buyer — eng managers or VP/Director-level?"
"What's driving demand — internal improvement or leadership pressure?"
"What source control and CI/CD tools are most common in our target?"
DORA metrics (Deployment Frequency, Lead Time, Change Failure Rate, MTTR) are well-defined, but the buyer and the motivation vary enormously. A team lead who wants to improve is a different user than a VP who needs a dashboard for the board.
The PM says: "We should help engineering teams track and reduce the carbon emissions of their cloud infrastructure."
You ask:
"Who owns this problem — platform engineering, finance, or sustainability?"
"Is demand driven by regulation or voluntary ESG commitments?"
"Are target customers mostly single-cloud or multi-cloud?"
Carbon monitoring sits at the intersection of engineering and compliance. The answer to "who owns it" determines whether you're building a developer tool or an enterprise reporting product — two very different businesses.
The PM says: "We should build specialized observability for message queues and event streaming infrastructure."
You ask:
"Which systems — Kafka, RabbitMQ, SQS, or all of them?"
"Who's the user — the platform team managing brokers, or app devs consuming messages?"
"What's breaking today — consumer lag, message loss, or debugging during incidents?"
The queue ecosystem is fragmented. A Kafka-first product is a very different business than a multi-system abstraction layer. And the persona question matters enormously: platform teams want cluster health; app developers want to know why their messages are stuck.
4. The Persona
Every monitoring product serves a specific person. Before you can evaluate an idea, you need to know who that person is. This is the persona.
In the monitoring industry, the common personas are:
SRE
Keeps services reliable. Cares about uptime, incident response, SLOs. On-call rotation shapes their life.
Platform Eng.
Builds internal tools and infrastructure. Cares about standardization, developer experience, reducing toil.
Developer
Writes application code. Wants to debug fast and ship features. Observability is a means to an end, not a goal.
Eng. Manager
Owns budget and headcount. Cares about cost, team velocity, and whether tools are actually being used.
The persona determines everything downstream — the pain points you target, the channels you use to reach them, the language on your landing page, the pricing model. Get this wrong and nothing else matters.
Primary: The AI application developer. They call LLM APIs (OpenAI, Anthropic, Bedrock) to build features — chatbots, search, summarization. They ship to production and are responsible for cost, latency, and quality, but have almost no visibility into what happens inside their LLM pipeline.
Secondary: AI platform teams who manage model-serving infrastructure across multiple application teams. They care about standardization and cost governance.
Primary: The engineering manager. They manage 1–3 teams, run sprint planning and retros, and are increasingly asked to quantify delivery performance. They want data to back up their instincts and advocate for their teams.
Secondary: VP/Director of Engineering who needs an org-wide view to identify bottlenecks across teams and justify headcount or process changes to leadership.
Primary: The platform engineer with a sustainability mandate. They already manage Kubernetes, cloud costs, and infrastructure. Carbon monitoring is a new responsibility being pushed to them by leadership or regulation.
Secondary: The sustainability/ESG lead who needs data for compliance reports but lacks the technical depth to collect it from infrastructure systems.
Primary: The platform engineer or SRE managing Kafka clusters. They own broker health, partition rebalancing, and consumer group management. When a queue backs up at 2am, they get paged.
Secondary: Application developers who publish to or consume from queues. They care about whether their messages are being processed and how fast — but they do not want to learn Kafka internals to debug a stuck consumer.
5. The Pain
A product only matters if it solves a pain that already exists. The sharper the pain, the easier the sale. So once you know the persona, ask: how badly does this problem hurt them today?
Pain has levels. At the bottom, it's a mild inconvenience — something people grumble about but tolerate. At the top, it's costing real money, waking people up at night, or blocking critical work. Products that address tolerable inconveniences struggle to get adopted. Products that stop the bleeding get pulled in by customers.
Mild "It takes a few extra clicks to correlate logs and traces."
Medium "We spend 2 hours per incident digging through dashboards."
Severe "We can't meet our SLOs and we're losing customer trust."
In your answer, name the pain level explicitly. If the idea addresses a mild pain, acknowledge it and explain how you'd validate whether it's actually severe enough to build for. This shows maturity — not every idea is worth building.
Severity: High. A single LLM call can cost $0.10 or $10.00 depending on the prompt, model, and token count. Teams ship an AI feature and their cloud bill triples — and they cannot tell which queries are expensive or why. Latency swings from 200ms to 30 seconds. Hallucinations reach production users and nobody knows the rate.
"We shipped an AI feature and our API costs tripled overnight.
We have no idea which prompts are causing it."
This is severe, active pain tied directly to money. Teams will pull in a solution.
Severity: Medium. Most engineering leaders know they should measure delivery performance but tolerate not having the data. The pain spikes during reorgs, performance reviews, or when a VP asks "how fast do we ship?" and nobody has an answer. It is chronic, not acute.
"Every quarter my VP asks for deployment frequency and
I spend two days pulling data from three tools to give
a rough estimate that nobody really trusts."
Medium pain means slower adoption. You need to validate whether the pain is severe enough to drive a purchase, or just a nice-to-have.
Severity: Medium, trending toward severe. Today it is a compliance checkbox — annoying but manageable with rough estimates. But regulation is tightening. The EU Corporate Sustainability Reporting Directive (CSRD) requires auditable Scope 3 emissions data. Companies that cannot attribute cloud carbon to specific services will fail audits.
"We report an estimate to our sustainability team.
Nobody trusts the number, but nobody has been
asked to verify it — yet."
Regulation is the forcing function. Pain that is medium today becomes severe on a known deadline.
Severity: High. When a Kafka consumer falls behind, messages pile up by the millions. Downstream services break, orders get delayed, events get dropped. The existing monitoring — broker JMX metrics in a Grafana dashboard — shows that something is wrong but not why. Is it a slow consumer? A hot partition? A poison message blocking progress? Teams spend hours correlating broker metrics with application logs to find the root cause.
"Consumer lag spiked to 2 million messages at 3am.
It took us 4 hours to figure out one bad message
was blocking a single partition."
This is acute, incident-driven pain. It wakes people up, and the debugging process is painful every time.
Before you propose building something, you need to answer a basic question: how do people solve this problem today? That is the landscape. Your job in the interview is to show that you understand what already exists, where it falls short, and why there is room for something new.
Start by listing what your persona actually does right now. This usually falls into three buckets:
Competing products
Tools that directly solve the same problem for the same persona. These are the obvious names the interviewer will expect you to know.
Partial solutions
Products that solve a related problem and might expand into yours. Datadog started with infrastructure metrics and moved into APM, logs, security, and incident management. These are dangerous because they already have the customer relationship.
Manual workarounds
This is what most people actually do. Spreadsheets, Slack threads, scripts, tribal knowledge, or simply ignoring the problem. The most common "competitor" is not a product — it is inertia. If you do not understand the workaround, you will not understand what you are replacing.
Once you have this picture, look for the gap. What are existing tools bad at? Where do users complain? What does the manual workaround fail to do? That gap is the opportunity — and it is what you will build your wedge around in the next step.
Datadog LLM Monitoring, New Relic AI Monitoring — bolted onto existing APM. They treat LLM calls as generic HTTP spans with no cost or token context.
Workaround
Print statements in the codebase, custom OpenTelemetry instrumentation, a shared spreadsheet where someone manually logs the monthly API bill.
The gap: Competing tools are tightly coupled to specific frameworks (LangSmith requires LangChain). Partial solutions lack LLM-specific context (token costs, prompt content, quality signals). The workaround gives you a monthly total but cannot tell you which user request cost $8 or which LLM call in the chain was responsible. No existing tool combines cost attribution, quality signals, and trace context in a single view.
Competing
Sleuth, LinearB, Swarmia, Jellyfish, Faros AI — developer productivity and DORA tracking platforms.
Partial
GitHub Insights, GitLab Analytics, Pluralsight Flow, Backstage plugins — they show some delivery data but do not calculate DORA metrics or benchmark against the research.
Workaround
An engineering manager spends a day each quarter pulling data from GitHub, CI, and the incident tracker into a spreadsheet. The numbers are rough and nobody fully trusts them.
The gap: Competing tools require extensive configuration — mapping deployments to services, tagging incidents, defining what counts as a "change." Most teams try them, get frustrated by setup time, and abandon. The workaround is slow and imprecise. The gap is zero-config accuracy: trustworthy metrics without a week of setup.
Kubecost, CloudHealth, Vantage — cloud cost tools that correlate with carbon but do not measure it. They could add carbon as a dimension tomorrow.
Workaround
The sustainability team uses the cloud provider's carbon dashboard (AWS Customer Carbon Footprint Tool, GCP Carbon Sense). It is delayed by three months, aggregated at the region level, and cannot attribute emissions to any specific service or team.
The gap: Competing tools require manual setup and produce estimates with wide error bars. The cloud provider workarounds are too coarse and too delayed for audit-ready reporting. Nobody does real-time, workload-level attribution that integrates with the existing observability stack.
Competing
Confluent Control Center (Kafka-specific, tied to Confluent Platform), Conduktor, AKHQ — queue management and monitoring tools.
Partial
Datadog Kafka integration, Grafana + JMX exporters, CloudWatch for SQS — basic throughput and consumer lag metrics without message-level context.
Workaround
Custom Grafana dashboards built on JMX metrics, combined with manually tailing consumer logs during incidents. It works until a 3am page, when correlating across tools takes hours.
The gap: Competing tools are vendor-locked (Confluent only works with Confluent Platform). Partial solutions show broker-level metrics but cannot trace an individual message through the system. Nobody gives you end-to-end message tracing — producer to broker to consumer — with latency at each hop.
7. The Wedge
You cannot launch a product that does everything. You need a wedge — the smallest possible product that is dramatically better than the status quo for one specific use case.
The wedge is how you get your first users. It's narrow enough that you can build it well, and sharp enough that people switch from their current tool (or non-tool) because the difference is obvious. Once you have those first users, you expand.
Datadog's wedge: infrastructure metrics with a beautiful UI
(when the alternative was command-line Nagios)
Honeycomb's wedge: high-cardinality event exploration
(when everyone else pre-aggregated data)
Grafana's wedge: open-source dashboards for Prometheus
(when the alternative was PromQL in a terminal)
In your answer, define the wedge clearly. Say what's in scope and what's explicitly out. A good wedge makes the interviewer nod — it's so focused that it's obviously right for that one use case.
The wedge: Cost tracing for LLM chains. A single user request — like "summarize this document" — can trigger multiple LLM calls: a retrieval step, a reranking call, the main completion, maybe a follow-up. Each call is billed by tokens (input + output). The wedge traces every call in the chain with its model, token count, dollar cost, and latency, then rolls it up so you see the total cost of that user request and where the money went.
In scope: OpenAI + Anthropic SDK auto-instrumentation,
cost + latency breakdown, trace viewer
Out of scope: quality/eval scoring, fine-tuning analytics,
custom model hosting, prompt management
The wedge: Zero-config DORA metrics from GitHub + CI. Connect your GitHub org and CI tool. Within five minutes, see all four DORA metrics — deployment frequency, lead time, change failure rate, MTTR — benchmarked against the DORA report's Elite/High/Medium/Low categories. No manual tagging required.
In scope: GitHub + GitHub Actions + CircleCI integration,
auto-detection of deploys and failures,
DORA benchmark comparison
Out of scope: Jira/Linear integration, custom workflow
definitions, sprint velocity, code quality
The wedge: Real-time carbon attribution per Kubernetes workload. A lightweight agent reads resource usage per pod, maps it to the cloud region's grid carbon intensity, and produces a CO2-per-service estimate updated hourly. Integrates as a Grafana datasource or OTLP exporter.
In scope: Kubernetes, AWS/GCP/Azure region grid data,
namespace-level CO2 attribution, hourly updates
Out of scope: Scope 1 & 2 emissions, supply chain carbon,
hardware embodied carbon, optimization recs
The wedge: End-to-end message tracing for Kafka. Instrument producers and consumers with one SDK. Every message gets a trace: publish time, broker arrival, partition assignment, consumer pickup, processing duration. When consumer lag spikes, you see exactly which messages are stuck and why.
In scope: Kafka producer/consumer auto-instrumentation,
per-message trace with latency at each hop,
consumer lag with partition-level drill-down,
dead letter queue tracking
Out of scope: RabbitMQ, SQS, Pub/Sub, broker management,
schema registry, stream processing (Flink/Spark)
8. The Market
The interviewer wants to know: is this opportunity big enough to matter? You need a quick, honest market size. Not a number from a Gartner report. A number you can defend.
The simplest approach is bottom-up. Start with the persona, estimate how many of them exist, and multiply by what they'd pay. Market sizing uses three layers:
TAM
Total Addressable Market. Everyone who could theoretically use a product like this. The whole pie.
SAM
Serviceable Addressable Market. The slice you can actually reach with your product, pricing, and distribution. Your realistic ceiling.
SOM
Serviceable Obtainable Market. What you can realistically win in year 1–2 given your team, budget, and starting position. This is the number that matters most.
Persona: SREs at mid-to-large companies
Count: ~50,000 companies with 100+ engineers globally
Seats: average 5 SREs per company = 250,000 SREs
Price: $50/seat/month = $150M ARR addressable
This is your SAM (Serviceable Addressable Market).
Your SOM (obtainable in year 1-2) might be 1-2% of that.
Don't over-engineer this. The point is to show that you think about market size with discipline, not that you have the exact right number. Round numbers are fine. Honesty about assumptions is better than precision.
Persona: AI application developers in production
Count: ~30,000 companies actively using LLM APIs
Seats: average 3 AI devs per company = 90,000
Price: usage-based, ~$100/seat equiv/month
SAM: ~$108M ARR
SOM year 1: 1-2% = $1-2M ARR
But the real lever is usage-based pricing — heavy users trace millions of LLM calls. Top-down, the AI infrastructure market is $10B+ and growing 40%+ annually. Observability is a fast-growing slice of that.
Persona: Engineering managers at 50+ dev orgs
Count: ~80,000 companies with 50+ engineers
Seats: $30/contributor/month, avg 60 contributors
Price: ~$1,800/month per org
SAM: ~$1.7B ARR
SOM year 1: 0.5% = ~$8.5M ARR
Large SAM, but medium pain means slower conversion. The question to answer for the interviewer: is the TAM growing because more orgs want DORA metrics, or because they're being required to measure them? The forcing function matters.
Persona: Platform eng + sustainability at cloud-heavy orgs
Count: ~15,000 companies with >$1M cloud spend
AND sustainability reporting obligations
Price: ~$2,000/month avg contract value
SAM: ~$360M ARR
SOM year 1: 0.5% = ~$1.8M ARR
Smaller addressable base today, but regulation is the tailwind. EU CSRD compliance deadlines create a forcing function that grows the market on a predictable schedule. Every year, more companies fall into scope.
Persona: Platform engineers / SREs managing Kafka
Count: ~40,000 companies running Kafka or similar
Teams: average 3 platform engineers on queues = 120,000
Price: $60/seat/month
SAM: ~$86M ARR
SOM year 1: 1-2% = $1-2M ARR
The seat-based number understates the opportunity. Usage-based pricing on messages traced is the bigger lever — companies processing billions of messages per day have massive observability needs that scale with volume.
You have a persona, a pain, a wedge, and a market size. The temptation is to start building. Don't. First, validate — find the cheapest way to test whether your riskiest assumption is true.
Every product idea rests on assumptions. The riskiest one is usually about demand: do enough people have this pain, and would they pay to solve it? You can test this without writing a line of code.
Design partners
Find 5-10 companies that match your persona. Interview them. Do they have this pain? How do they deal with it today? Would they use a solution like this?
Landing page
Describe the product and put up a signup form. Drive traffic with a blog post or a targeted ad. Measure signups.
Concierge MVP
Solve the problem manually for a few customers. If they keep coming back and asking for more, the demand is real.
In your answer, name the riskiest assumption explicitly and describe one validation method. This shows the interviewer that you don't fall in love with ideas — you test them.
Riskiest assumption: Teams running LLMs in production cannot see what each user request costs in tokens and dollars — and would pay to fix it.
Validation: Interview 10 teams running LLM features. Ask: "Do you know how much a single user request costs end-to-end? Can you trace a slow response to a specific LLM call in the chain?" If 7+ say no and express frustration, the demand is real.
Cheapest test: Open-source a Python SDK that prints cost-per-call to stdout. If developers adopt it without a product behind it, the pain is confirmed.
Riskiest assumption: Engineering managers will trust automated DORA metrics without manual configuration or tagging.
Validation: Build a read-only GitHub App that analyzes 90 days of history for a single repo. Show the output to 10 eng managers. Ask: "Are these numbers accurate? Would you show this to your VP?"
Cheapest test: A free web tool — "Paste your GitHub org URL, get your DORA score in 5 minutes." Measure how many people use it and share it.
Riskiest assumption: Sustainability leads will act on workload-level carbon data, rather than just needing a single aggregate number for compliance.
Validation: Interview 10 sustainability leads and platform engineers. Ask: "If you could see CO2 per service per hour, what would you do with that data?" If they describe specific optimization actions, the granularity matters. If they just need a number for a report, the wedge is wrong.
Cheapest test: Manually build a static carbon report for one company's Kubernetes cluster. Show them per-namespace attribution. Watch their reaction.
Riskiest assumption: Teams cannot trace individual messages through their Kafka infrastructure today — and this gap is causing real incident pain, not just inconvenience.
Validation: Interview 10 teams running Kafka at scale (>1M messages/day). Ask: "When consumer lag spikes, how long does it take to find the root cause? Can you trace a specific message from producer to consumer?" If most describe a multi-hour, multi-tool debugging process, the pain is real.
Cheapest test: Open-source a Kafka consumer lag CLI that shows partition-level detail with consumer group breakdown. If it gets GitHub stars and organic adoption, teams need better queue observability.
10. The MVP
Validation passed. Now you build the minimum viable product — the smallest thing that delivers on the wedge. Not a prototype. Not a demo. A real product that a real user can rely on.
The hardest part of defining an MVP is deciding what to leave out. A useful exercise: list every feature you can imagine, then cut it in half. Then cut it in half again. What remains is probably still too much, but you're closer.
The MVP must be good enough that your wedge use case works beautifully. It's okay to be missing entire categories of functionality. It is not okay to be bad at the one thing you promised to be good at.
In scope:
Python SDK, auto-instruments OpenAI + Anthropic clients
Trace viewer: flame graph of LLM call chains
Dashboard: total cost, p50/p99 latency, error rate
Cost per user request over time (broken down by LLM call)
7-day retention
Out of scope:
Quality/eval scoring, prompt versioning, JS SDK,
custom model support, alerting, SSO
Success metric:
5 design partners sending >1,000 traces/day after 30 days
In scope:
GitHub App (read-only, installs in 2 minutes)
All four DORA metrics, auto-detected from git + CI
Weekly trend charts
Team-level breakdown
DORA benchmark comparison (Elite/High/Medium/Low)
Out of scope:
GitLab/Bitbucket, Jira integration, custom deploy
detection rules, alerting, API access, SSO
Success metric:
10 orgs installed, eng manager views dashboard
weekly after 30 days
In scope:
Kubernetes DaemonSet, collects CPU/memory per pod
Maps to cloud region grid carbon intensity
(electricityMap / WattTime public data)
Dashboard: CO2 by namespace, by hour, 30-day trend
CSV export for sustainability reporting
Out of scope:
Multi-cloud, non-K8s workloads, Scope 1 & 2,
embodied carbon, automated optimization, alerting
Success metric:
3 companies running the agent in production,
sustainability lead pulls monthly report after 60 days
In scope:
Kafka Java + Python SDK (producer + consumer instrumentation)
Per-message trace: publish → broker → consume with latency
Consumer lag dashboard with partition-level drill-down
Dead letter queue tracking and alerting
7-day retention
Out of scope:
RabbitMQ, SQS, Pub/Sub, broker management,
schema registry, stream processing, SSO
Success metric:
5 companies tracing >100K messages/day after 30 days
You have a product. Now it needs to reach the right people. This is your go-to-market strategy, and in the monitoring industry, it usually follows one of two patterns.
Product-Led
Users find the product, try it for free, and adopt it bottom-up. Self-serve signup, generous free tier, quick time-to-value. This is how Grafana and Prometheus grew — developers chose them before anyone signed a contract.
Sales-Led
An outbound sales team targets engineering leadership. Demos, POCs, procurement cycles. This is how Dynatrace and Splunk sell — large contracts, long cycles, high deal sizes.
Most modern observability companies use a hybrid: product-led adoption to get in the door, sales-assisted expansion to grow the account. The free tier converts developers. The sales team converts their managers.
In your answer, pick a GTM motion that matches your persona and wedge. If you're targeting individual developers, product-led is right. If you're targeting platform teams at large enterprises, you'll need sales. Explain why.
Motion: Product-led. AI developers are early adopters who try open-source tools, read blog posts, and share what works on Twitter/X and Discord.
Channel 1: Open-source the SDK. Zero-friction instrumentation.
Channel 2: Content — "We traced our RAG pipeline and cut
LLM costs 60%" gets shared in every AI Discord.
Channel 3: Framework integrations — LangChain, LlamaIndex,
Haystack plugins.
Free tier converts individual developers. They prove value internally. Their manager approves the paid tier.
Motion: Hybrid. Product-led for small teams (install the GitHub App, see your metrics). Sales-assisted for org-wide rollout when a VP wants it across 20 teams.
Channel 1: Free tool — "Get your DORA score in 5 minutes."
Channel 2: Conference talks at DevOpsDays, QCon, LeadDev
targeting eng managers who feel the pain.
Channel 3: Partnerships with consulting firms who do
engineering effectiveness assessments.
The free tier acquires eng managers. Sales converts the VP who wants the org-wide view.
Motion: Sales-led. The buyer (VP Platform or Sustainability Lead) has budget, a compliance deadline, and needs a vendor they can point auditors to. This is not a bottom-up developer tool.
Channel 1: Direct outreach to companies with public
sustainability commitments and cloud-heavy infra.
Channel 2: Partnerships with cloud providers' sustainability
programs (AWS, GCP, Azure partner networks).
Channel 3: Industry events — KubeCon sustainability track,
GreenOps community, ESG conferences.
Compliance deadlines create urgency. The sales cycle is long (3–6 months) but the contracts are large and sticky.
Motion: Hybrid. Product-led for individual platform engineers (open-source SDK, free tier). Sales-assisted for large orgs running Kafka at scale who want org-wide queue observability.
Channel 1: Open-source the SDK. Kafka community is active
on GitHub and Confluent Community forums.
Channel 2: Content — "How we traced a poison message
across 12 partitions" resonates in DevOps Slack.
Channel 3: Kafka Summit, KubeCon, partnership with
Confluent marketplace listing.
The open-source SDK gets individual platform engineers. Sales gets the VP Infrastructure who wants queue observability across all clusters.
12. Pricing
How monitoring products make money is not obvious from the outside. The industry uses several models, and each one sends a different signal about what the product values.
Usage-based
Pay for what you ingest or query. GB of logs, millions of spans, custom metric time series. Datadog and New Relic use this. It scales with the customer but makes bills unpredictable.
Seat-based
Pay per user. Simple and predictable. But it creates friction — teams limit who gets access, which limits adoption and value.
Tier-based
Free, Pro, Enterprise. Features unlock at each tier. Grafana Cloud uses this. Good for product-led growth because the free tier gets people in.
Pricing signals value. If you charge by data volume, you're saying the product is about data. If you charge by seat, you're saying it's about collaboration. If you charge by tier, you're saying advanced capabilities are the premium.
In your answer, pick a model and explain the trade-off. There's no right answer — but there should be a reason.
Model: Usage-based on LLM spans ingested. $2 per 1,000 spans.
Free: 10,000 spans/month (a side project)
Pro: pay-as-you-go, volume discounts at scale
Enterprise: committed spend + SSO + support
Why: LLM costs already scale with usage, so observability costs should too. A startup tracing 50K calls/month pays ~$100. An enterprise tracing 10M calls/month pays ~$20K. This feels fair relative to their LLM spend and creates natural expansion as adoption grows.
Model: Seat-based per contributor tracked. $15/contributor/month.
Free: up to 10 contributors
Pro: $15/contributor/month
Enterprise: custom pricing + SSO + API access
Why: DORA metrics scale with team size, not data volume. An org with 200 engineers pays ~$3K/month — easily justified if it eliminates one "how fast do we ship?" fire drill per quarter. Seat-based also aligns incentives: you want the org to add more teams, not worry about data volume.
Model: Tier-based with an open-source core.
Open source: basic estimation, single cluster, community
Pro: $1,500/month — real-time attribution,
multi-cluster, team breakdown
Enterprise: $5,000+/month — audit-ready reports,
multi-cloud, API, dedicated support
Why: The open-source core builds credibility and community in a space where trust matters (sustainability claims are scrutinized). The paid tiers unlock the features compliance teams need. Regulation creates the upgrade trigger — when the audit deadline hits, they need the Enterprise tier.
Model: Usage-based on messages traced. $1 per million messages.
Free: 5M messages/month (a dev environment)
Pro: pay-as-you-go, volume discounts at scale
Enterprise: committed spend + SSO + SLA + support
Why: Message volume directly correlates with infrastructure complexity and the value of observability. A startup processing 10M messages/month pays $10. An enterprise processing 10B messages/month pays $10K. The price scales naturally with the customer's pain level.
13. Success
The interviewer will want to know: how do you know this is working? You need success metrics — specific, measurable signals that the product is on the right track.
Good metrics come in pairs: a leading indicator that tells you if you're heading in the right direction, and a lagging indicator that confirms you arrived.
Activation
Did the user get value? For a tracing product: did they send their first trace within 30 minutes of signup? Leading indicator of retention.
Retention
Do they keep coming back? Weekly active users who query traces at least once. The core health metric for any product.
Expansion
Do accounts grow over time? More seats, more data, upgraded tiers. This is how monitoring products become large revenue streams.
NPS / CSAT
Do users recommend it? A qualitative signal that complements the quantitative ones. Especially important in developer tools, where word-of-mouth drives adoption.
End your answer here. Name two or three metrics, explain what each one tells you, and describe what "good" looks like in the first six months. This closes the loop — you started with a vague idea and ended with a measurable plan.
Activation
First LLM trace received within 15 minutes of signup. If instrumentation takes longer, the SDK is too hard.
Retention
User queries the trace viewer at least once per week. Shows it's part of their workflow, not a one-time curiosity.
Expansion
Account grows from 1 instrumented service to 3+ within 60 days. Cost data is being shared in team Slack channels.
GitHub App installed and first DORA metrics visible within 1 day. If it takes longer, zero-config is not working.
Retention
Engineering manager views dashboard at least once per week. Shows the metrics are influencing decisions, not collecting dust.
Expansion
Org grows from 1 team tracked to 5+ teams within 90 days. VP asks for org-wide rollout.
Six-month target:
50 orgs active
30% weekly retention among eng managers
$80K ARR
Activation
Agent deployed, first carbon estimate visible within 1 hour. Kubernetes agents must be drop-in — if it requires a platform team sprint, adoption stalls.
Retention
Sustainability lead pulls a report at least monthly. Aligns with the natural reporting cadence.
Expansion
From 1 cluster to all production clusters within 6 months. Data cited in an actual ESG report or board presentation.
Six-month target:
15 companies running in production
3 using data in published sustainability reports
$200K ARR
Activation
First message trace received within 20 minutes of SDK install. If instrumentation requires broker config changes, adoption stalls.
Retention
Team queries the trace view during at least one incident per month. Shows it is part of the incident response workflow, not a setup-and-forget tool.
Expansion
Account grows from 1 Kafka cluster to all production clusters within 90 days. Tool added to the incident response runbook.
Six-month target:
30 companies tracing messages
35% monthly active during incidents
$120K ARR