Product Manager Interview: Should a B2B SaaS Expose an Admin Audit Log?

Prompt and context

Enterprise customers of a B2B SaaS can only open a support ticket when investigating permission or configuration changes. Sales believes an audit log could help renewals; engineering worries about storage, privacy, and misinterpretation. Decide whether to build it, which users to serve first, and the first-release scope and gates.

This is a product decision, not a request to design a log table. Break “we want logs” into investigation, compliance evidence, incident troubleshooting, and internal security tasks.

What the interviewer is testing

A strong answer starts from customer tasks and risk, defines which events matter, who can view them, how long they remain queryable, and how records resist tampering or leakage. Amazon’s product-manager preparation emphasizes customer segmentation, business models, and success metrics; an audit-log product must balance customer value with platform cost.

Questions to clarify first

Ask whether the target account has security administrators, compliance auditors, and ordinary administrators; whether customers investigate permissions, data access, or configuration; whether contracts or industries require retention; whether sources cover API, console, automation, and support impersonation; and who may see personal information or sensitive resource names.

Also separate an in-product event view from a long-term, immutable, exportable audit archive. Google Cloud Audit Logs and AWS CloudTrail distinguish event types, query, and long-term storage; those are different product jobs.

A 30-second answer structure

I would confirm the top three customer tasks, then start with high-value, low-sensitivity management events. Version one would answer who, when, what resource, and what action, with filters, export, and access controls; sensitive data access and long-term retention would need a later gate. I would validate ticket deflection, self-service resolution, query success, correction feedback, and storage cost. If source coverage or permission isolation is weak, I would run an internal beta instead of promising compliance.

Step-by-step analysis

Step 1: Segment by task and customer

Separate “which administrator changed a setting,” “which identity accessed data,” and “what happened during an audit window.” Each task needs different fields, permissions, retention, and export. Start with frequent, verifiable management events that do not expose business content.

Step 2: Define event scope and readability

Every event should answer who, when, what, where, and outcome: actor, time, action, resource scope, and success or denial. Translate internal service names into customer-facing resources and distinguish user actions, automation, and support impersonation. Google Cloud separates Admin Activity, Data Access, System Event, and Policy Denied logs; “all logs” is not a useful product boundary.

Step 3: Design permissions, privacy, and tenant boundaries

Limit access to roles with audit permission and define boundaries across tenants, organizations, and subaccounts. Redact personal data, tokens, request parameters, and content; viewing the log should itself create an audit event. For high-risk Data Access records, start with summaries or export to the customer’s security platform rather than placing sensitive details in an ordinary admin page.

Step 4: Guarantee source, integrity, and query experience

Set source-coverage and ingestion-latency targets, distinguishing “not covered,” “viewer lacks permission,” and “no event exists.” Use append-only or read-only storage and restrict deletion and mutation. Version one needs time, actor, action, resource, and outcome filters; large accounts also need pagination, export, and an API instead of loading every event in a browser.

Step 5: Evaluate value and cost

Connect value to customer tasks: fewer “who changed the permission?” tickets, shorter investigations, higher security-feature adoption, and renewal confidence. Costs include collection, indexing, hot and cold storage, replication, permission support, and support load from misinterpretation. Validate high-frequency queries with a cohort of enterprise customers before funding long-term archives or real-time alerts.

Step 6: Roll out in stages with Go/No-Go gates

Rehearse internally, then expose management-event search and CSV export to 5–10 customers. Go requires source coverage, permission-test success, explainable latency, and matching page and export results. No-Go if key actions are not reliably recorded, cross-tenant access can escape its boundary, or customers may mistake the view for a complete forensic system. Fix the boundary and copy first.

High-quality sample answer

I would define the need as a trustworthy answer to “who did what to which resource and when,” not as a request for a full SIEM. The first users would be security administrators and constrained organization administrators. Version one would cover permission, SSO, API-key, and critical-configuration changes; detailed data access and long-term archives would be later scope.

The first release would record actor, time, action, resource, outcome, and source, with filters, redaction, role-based access, and CSV export. Events would be append-only, and viewing the log would be logged. We would rehearse internally, then beta-test with 5–10 enterprise accounts while measuring related tickets, self-service resolution, query latency, source coverage, and storage cost.

If page and export results differ, key sources are missing, or permission tests show cross-tenant access, I would pause expansion. After the coverage and access gates pass, I would evaluate immutable retention, API access, and real-time alerts. The promise is verifiable investigation capability, not a universal compliance guarantee.

Common mistakes and improvements

• Treating an audit log as every raw log: define customer jobs and event scope.
• Listing only user and timestamp: include resource, action, outcome, source, and permission.
• Promising compliance directly: state coverage, retention, and customer responsibility boundaries.
• Ignoring the sensitivity of viewing logs: log access itself.
• Measuring only page visits: include ticket deflection, query success, latency, and cost.

Follow-up questions and responses

Should every data-access event appear in the first version?

No. Start with high-value management events whose fields and permissions are reliable. Data-access events can require stricter privacy, storage, and export controls, so they need a separate readiness gate.

How do you prevent an administrator from tampering with logs?

Use append-only or immutable storage, restrict deletion and configuration privileges, record access to the log itself, and provide an export path that customers can retain independently. State the integrity guarantee precisely.

What if an event is missing?

Show whether the source was not covered, the viewer lacked permission, or ingestion was delayed. Track source coverage and ingestion lag; never display absence as proof that an action did not happen.

How do you prove the feature is worth the cost?

Compare enterprise cohorts on investigation time, audit-related tickets, self-service resolution, adoption, export volume, and storage cost. Interview security administrators about whether the log changed a real decision, not just whether they opened the page.