Product manager interview: Should a SaaS offer OpenTelemetry log export?
Prompt and scope
A B2B SaaS receives an enterprise request to export product runtime logs and audit-related events to the customer's OpenTelemetry Collector. Engineering worries about protocol support, redaction, bandwidth, and support cost; sales sees a procurement gate. Decide whether to build it, who to serve first, and how to validate the need.
The OpenTelemetry Logs Data Model defines Timestamp, ObservedTimestamp, Severity, Body, Resource, and Attributes. It provides an interoperable contract but does not solve tenant isolation, compliance, or customer-backend differences. A strong product answer converts the standard into a measurable customer outcome.
What the interviewer evaluates
- Define a customer workflow instead of saying “support a standard.”
- Separate product logs, audit events, metrics, and traces so scope stays bounded.
- Design an MVP with permissions, redaction, retries, and cost limits.
- Propose segmented validation, adoption metrics, retention, and support burden.
- Make trade-offs across revenue, reliability, privacy, and roadmap opportunity cost.
Clarifying questions
- Is the job centralized troubleshooting, compliance retention, cross-product correlation, or security detection?
- Which signals are needed: application logs, audit events, metrics, traces, or only one class?
- Does the customer already run a Collector and backend? What protocol, region, throughput, and retention are required?
- Which fields contain personal data, credentials, or customer content, and who owns redaction and keys?
- Is this a procurement gate for a few strategic customers or a repeatable need across a segment?
30-second answer
I would validate the customer's job before promising “OTel support.” If the job is cross-product troubleshooting, start with structured application logs and explicitly exclude raw audit payloads and highly sensitive content. The MVP offers a controlled endpoint, batching, retries, tenant permissions, field redaction, and quotas for enterprise customers that already run a Collector. Measure activation, time to first useful event, query success, export failures, support tickets, and gross margin. If one customer drives expensive customization, offer a connector or professional service first.
Step-by-step product decision
1. Define outcome and boundary
Rewrite the request as an outcome such as “the customer can correlate error logs by service and time in its own platform,” not “we implement OTel.” The first release promises core application-log fields only. Audit events need separate discovery because integrity, retention, and access controls are stricter. Metrics and traces are different signals and should not be bundled automatically.
2. Validate customers and jobs
Interview security, SRE, platform, and procurement roles about current exports, manual cost, incident frequency, and compliance deadlines. Prioritize customers already operating an OpenTelemetry Collector, using a multi-product observability platform, and willing to share samples. Use design partners to test configuration, field semantics, regions, and throttling rather than treating verbal enthusiasm as revenue proof.
3. Design the smallest viable offer
Provide a tenant-scoped export connection, destination URL or controlled connector, short-lived credentials, batching, exponential backoff, dead-letter counts, and a pause switch. Use the OTel Logs Data Model fields but define a field allowlist, version, and maximum event size. Sensitive fields are off by default; show per-tenant throughput and cost.
4. Security, compliance, and reliability
Apply field redaction and policy checks before export. Do not let a client write another tenant's Resource attributes. Credentials are send-only; the platform must not read the customer's backend. When the destination is unavailable, use bounded retries, tenant quotas, and short local buffering rather than an infinite queue. Record drop reasons and oldest-event age, and make region and residency policy explicit before activation.
5. Metering and pricing
Meter events, bytes, or retention duration with a free base allowance and overage protection. Track activation, time to first useful event, daily active exports, field-mapping failures, p95 delivery latency, retry and drop rates, support tickets, and gross margin. Separate customer-backend cost from the vendor's egress cost; subscription revenue alone is insufficient.
6. Canary and product experience
Offer a read-only configuration preview, sample events, and connection test before continuous export. The first successful event should appear within minutes; errors should identify credentials, region, throttling, or field problems. Let users filter by service, environment, and severity, and provide explicit pause, credential rotation, and connection deletion controls.
7. Experiment, decision, and exit criteria
For design partners, compare manual export, bespoke integration, and the OTel MVP on deployment time and incident-debugging time. Stop expanding if activation is low, field disputes are frequent, support cost is high, or one customer keeps requiring custom work; route the need to a connector marketplace or professional service. Invest in more signals and regions only when several segments reuse the same setup at acceptable margin.
Sample strong answer
I would first determine whether the job is cross-product troubleshooting, compliance retention, or security detection, then limit scope to structured application logs. The MVP targets enterprises with an existing Collector and includes a tenant-scoped endpoint, short-lived credentials, field allowlist, redaction, batching, bounded retries, quotas, and a pause switch. Audit events, metrics, and traces are not automatically included.
Success combines activation, time to first useful event, delivery p95, drop rate, support tickets, and margin. Design partners validate configuration, field semantics, regions, and cost. If one large customer drives bespoke work, use a connector or professional service; expand signals and pricing tiers only after repeated reuse.
Common mistakes
- Build because the standard is popular → no customer outcome or payment evidence → validate jobs, alternatives, and repeat demand.
- Bundle logs, audits, metrics, and traces → scope and compliance risk explode → start with one signal and an allowlist.
- Offer only a URL field → credentials, region, retry, and tenant boundaries remain undefined → design the connection lifecycle and controls.
- Count activations only → trials may never become useful → track first useful event, sustained activity, troubleshooting time, and support cost.
- Retry forever when the destination is down → egress and storage costs run away → use quotas, bounded buffers, drop policy, and pause controls.
- Treat one enterprise exception as the product → one customer captures the roadmap → compare reusable configuration with customization hours.
Follow-up questions and responses
Why not export audit logs first?
Audit events usually require stronger integrity, access, retention, and compliance controls. Start with lower-risk application logs and separately validate the audit product and boundaries.
The customer already has a SIEM. Why OTel?
OTel provides unified collection and interoperability; it does not replace a SIEM. The value exists when multiple products can feed one Collector with less bespoke maintenance.
How do you prevent sensitive data export?
Use a field allowlist and default redaction, block high-risk fields by tenant policy, record rule versions and hit counts, and preview sample events before activation.
How do you set a free allowance?
Cover trials and small production usage with an event or byte allowance, warn before overage, then throttle or pause. Calibrate with actual egress, customer value, and support cost rather than competitor price alone.
When do you stop investing?
Stop expansion when repeat demand is weak, sustained usage is low, field disputes and support cost are high, or every customer needs a separate connector. Keep a maintainable integration exit.