Product Manager Interview: Should a SaaS Expose a Field-Level API Deprecation Manifest?

Prompt and scope

Your SaaS has many B2B API customers. The team wants to adopt the June 2026 IETF Internet-Draft “A Deprecation Manifest for Field-Level Lifecycle Signalling in HTTP APIs” and expose application/deprecations+json to describe deprecation dates, sunset dates, and replacements for individual request or response members. Decide whether to make this a product capability and explain scope, customer value, compatibility, rollout, and success metrics. The draft is still work in progress, not a final RFC.

What the interviewer is testing

• Translating a protocol capability into a customer problem, migration workflow, and business value.
• Distinguishing resource-level response headers (RFC 9745, RFC 8594) from a field-level manifest.
• Controlling commitments, compatibility, and governance while a standard is unfinished.
• Choosing observable metrics for adoption, migration completion, and false positives.

Questions to clarify before answering

1. Do customers mainly use SDKs, OpenAPI generators, or direct JSON parsing?
2. Do you already have deprecation notices, version policy, and contact-notification mechanisms?
3. Are deprecated members response fields only, or also request fields, nested arrays, and polymorphic shapes?
4. Is the goal to aid human migration or let CI/CD and SDKs automatically block risk?
5. Which customers, regions, or compliance cases require the old member to remain available, and for how long?

30-second answer framework

Start with the problem: customers struggle to discover member-level changes, while resource-level Deprecation/Sunset headers cannot identify each member. My recommendation is a limited, optional field-level lifecycle signal pilot, without presenting the draft as a stable standard. Start with response members, a manifest, documentation links, and replacement fields; keep OpenAPI, announcements, and resource-level headers. Use discovery rate, migration time, false-positive rate, and rollback rate to decide whether to expand.

Step-by-step deep dive

1. Define the customer pain and boundary

A deprecated member often remains in responses for a period. Customers need to know which member is affected, when deprecation starts, when removal is expected, and what replaces it. The manifest addresses discovery and orchestration; it does not change current behavior and cannot replace version policy, contract tests, or human communication.

2. Explain the relationship to existing capabilities

Resource-level headers remain the default channel. A field-level manifest can be discovered with Link:

Link: </.well-known/deprecations>; rel="deprecation"; type="application/deprecations+json"

Example manifest:

{
  "deprecations": [
    {
      "target": "response",
      "selector": "$.customer.legacy_name",
      "selectorType": "jsonpath",
      "deprecation": "2026-09-01",
      "sunset": "2027-03-01",
      "replacement": "$.customer.display_name",
      "info": "https://docs.example.com/migrations/customer-name"
    }
  ]
}

Product design should separate format, discovery, and business governance. If the draft changes, customers still have stable documentation and OpenAPI descriptions.

3. Choose a minimum viable product

Start with JSON response members, one API version, and explicit dates. Do not promise every JSONPath dialect, request-body variant, GraphQL shape, binary protocol, or automatic client rewriting. Keep the manifest read-only and cacheable, with a source-document link and a human confirmation path.

4. Design rollout and migration

After a change is registered, the platform generates the manifest and validates date ordering. Documentation, SDK changelogs, and customer notifications ship together. Start with internal APIs and design partners, then expand to self-serve customers. Keep version history and a rollback switch for false positives or date changes.

5. Set governance, risk controls, and metrics

Governance should require a member owner, a minimum notice period, an available replacement, and exception approval before sunset. Track manifest discovery rate, affected-call identification, median notice-to-migration time, calls still using deprecated members, false-positive rate, support tickets, and rollbacks. If customers do not parse manifests, invest in SDK, CLI, or CI checks instead of adding formats.

6. Make a staged decision

If the pilot materially reduces migration time with controlled false positives, expand to request members and nested structures. If value comes mainly from documentation rather than machine parsing, keep the manifest as an advanced capability and improve OpenAPI, notification, and version policy. Label every external commitment with the draft status and compatibility guarantee.

High-quality sample answer

I would build it, but position it as a field-level lifecycle-signal pilot, not as a finalized standard. Customers can receive resource-level Deprecation and Sunset signals today, yet those do not identify a particular response member. A manifest can give automation the member, dates, replacement, and migration link.

Phase one supports one JSON response model and explicit deprecation and sunset dates. OpenAPI, documentation, and resource-level headers remain compatibility channels. At registration time, the platform validates the member owner, replacement, and minimum notice period. We start with internal APIs and design partners, measuring discovery rate, median migration time, deprecated-member call share, false positives, and rollbacks. Because the format comes from a June 2026 IETF draft, documentation must say it can change, and the feature needs a disable or downgrade switch.

If the pilot shows earlier discovery and lower support cost, expand to request members and more complex shapes. If customers rely on documentation rather than parsing, shift investment to SDKs, CI checks, and notification orchestration. Success means fewer surprise breakages and faster migrations, not merely adding a protocol name.

Common mistakes

• Calling an Internet-Draft an approved RFC or promising immediate support everywhere.
• Discussing only JSON syntax without ownership, date policy, notification, and rollback.
• Assuming a response header can locate arbitrary nested members automatically.
• Giving only a yes/no decision without a pilot, metrics, and stop conditions.
• Ignoring ambiguity from request members, array indexes, and polymorphic shapes.

Follow-up questions and responses

What if customers do not parse the manifest?

Keep it as a machine-readable supplement and continue OpenAPI, migration docs, SDK changelogs, webhooks, or email notices. Use discovery rate to measure real use rather than forcing adoption.

How do you handle draft changes?

Isolate the manifest generator from the customer API, record a format version, allow disabling the manifest or falling back to docs and resource-level headers, and label the draft status in compatibility notes.

When would you support request members?

Only after response-member pilots show stable selectors, dates, and migration workflows, and request members have clear validation and rollback semantics. Otherwise a false positive can become a failed write.

How would you prove product value?

Compare pilot and control groups on migration completion time, deprecated-member call share, support tickets, and rollback rate. Also check parser coverage and false positives; documentation page views alone do not prove migration success.