Product Manager Interview: Should API Version Lifecycle Support Be Paid?

Prompt and Context

Your B2B SaaS has three API versions still in use. Engineering wants to maintain only the latest version for free, while sales promised large customers long-term compatibility. You must decide which versions remain available, how deprecation is communicated, who funds migration tooling, and whether long-term support should be a paid capability.

RFC 8594 defines the Sunset response header for indicating that a resource may become unresponsive in the future. RFC 9745 defines the Deprecation response header for indicating that a resource is deprecated. These provide machine-readable signals, but they do not decide support windows, customer tiers, or migration responsibility.

This case is about API lifecycle product governance and commercial boundaries. It is distinct from implementing an API shutdown or writing a general API adoption strategy.

What Interviewers Evaluate

• Connect compatibility promises to customer value, renewals, and engineering cost.
• Define versions, support levels, deprecation notices, and measurable migration success.
• Separate baseline security obligations from chargeable long-term maintenance.
• Handle sales exceptions, contract promises, ecosystem fairness, and self-service migration.
• Use metrics, pilots, and exit criteria instead of making an unlimited promise.

Clarifying Questions to Ask

1. What are request volume, active customers, revenue, concentration, and failure modes for each old version?
2. Which changes are security fixes, bug fixes, enhancements, or breaking changes?
3. Do contracts already specify support duration, notice period, service levels, or remedies?
4. Can customers switch without changing business logic, and do SDKs, migration reports, and test environments exist?
5. Is the sales promise an exception or a market expectation shared by every enterprise customer?

30-Second Answer Framework

Segment versions by usage, revenue, risk, and migration difficulty, then make security fixes and deprecation notices baseline commitments. Maintain the latest version and a limited window for older versions for free. Charge for support beyond that window only with an explicit version scope, response level, migration tooling, and end date. Pilot with compatibility metrics, migration completion, and support cost before expanding.

Step-by-Step Deep Dive

1. Validate Whether the Problem Merits Monetization

Build a version map with request volume, active customers, revenue, error rate, sensitive-data risk, SDK coverage, and estimated migration hours. Segment customers into self-service, assisted migration, and contractually long-term-compatible groups.

Interview developers, procurement, security, and customer success to learn whether customers value the old version itself or are buying down migration risk, downtime risk, and internal approval cost. If most customers simply lack migration documentation, charging for long-term support penalizes a problem that product improvements could solve.

2. Define Tiered Lifecycle States

Use three states: current, maintenance, and deprecated. The current version receives new features and normal fixes. A maintenance version receives security and high-impact bug fixes only. A deprecated version keeps returning clear migration guidance and machine-readable notices until the announced end date.

Publish release, deprecation, shutdown, support-scope, and replacement dates for every version. Use Deprecation to express deprecated status and Sunset to express an expected unresponsive time. Documentation, console, SDK warnings, and customer contacts must share one timeline.

3. Set the Free and Paid Boundary

The free tier should include security fixes, public migration documentation, changelogs, stable deprecation notices, and a reasonable migration window. Paid long-term support may include a longer maintenance period, dedicated response, migration assessment, batch compatibility tests, and custom connectors. It should not monetize fixing a security defect in the product itself.

Price by version count, support duration, request volume, or service level. Contracts must specify endpoints, fix categories, response times, customer obligations, exception approval, and the final shutdown date so a verbal sales promise does not become unlimited liability.

4. Build Migration Tools and Evidence

Start with diff reports, deprecated-endpoint inventories, request examples, SDK recommendations, a sandbox, and replay tests. Offer codemods or lint rules for statically detectable parameter changes; use review checklists and shadow traffic for semantic changes.

Measure migration completion, failure reasons, rollback count, test coverage, and days from notice to cutover. A customer viewing a migration guide is not migrated; completion requires real requests on the new version and successful critical business outcomes.

5. Govern Sales Exceptions Fairly

Create an exception register containing the customer, promise owner, contract language, version scope, expiry date, cost, and alternative. A short exception needs a price and an exit date; engineering should not maintain an invisible private branch.

Publish the same baseline timeline to every customer. Paid customers may receive extra service capacity and a longer window, but not the privilege of hidden deprecation or bypassing security fixes. When historical contracts conflict, legal and sales should confirm the obligation before product publishes one consistent notice.

6. Measure Cost, Risk, and Outcomes

Costs include compatibility matrices, test environments, on-call work, documentation, SDKs, and security fixes for old dependencies. Risks include vulnerabilities, migration-induced downtime, lock-in perception, and ecosystem fragmentation.

Track old-version request share, notice reach, migration completion and failure, support hours, long-term-support gross margin, critical-fix latency, and renewal impact. Segment by customer so a few large accounts with low traffic do not hide the burden carried by many smaller customers.

7. Roadmap and Exit Criteria

Phase one cleans the version map, contract promises, and notice mechanism, then pilots migration tooling with two customers. Phase two adds console reminders, diff reports, a sandbox, and paid long-term-support contracts. Phase three uses declining traffic, migration success, and margin to decide whether to shut down old versions or automate more.

Exit when security fixes cannot meet the promise, exceptions keep growing, migration failures create material risk, customers will not pay while value declines, or maintenance cost exceeds retained revenue. Freeze new customers on the old version, announce early, and execute the final shutdown plan.

Strong Sample Answer

I would map version usage, revenue, contracts, and migration difficulty first, then make security fixes and deprecation notices baseline commitments for every customer. The current version gets new features; the maintenance version gets security and high-impact fixes; the deprecated version remains available during a public window and uses Deprecation, Sunset, console, and documentation notices consistently.

Long-term support can be paid, but the paid value should be a longer window, dedicated response, migration assessment, and compatibility testing—not fixing a product security defect. I would pilot diff reports, a sandbox, and replay tests with two customers, measure traffic decline, completion, failure, support hours, and renewal impact, then expand paid support or shut down the old version when exit criteria are met.

Common Mistakes

• Shut down old versions for engineering convenience without checking revenue, contracts, or migration risk.
• Put security fixes behind a premium tier and damage the baseline trust boundary.
• Publish only a blog post without machine-readable dates, console reminders, or reach tracking.
• Promise long-term compatibility without endpoint scope, response level, or an end date.
• Treat migration-guide views as migration success instead of validating real new-version requests.
• Maintain a private branch for one large customer and lose an auditable version matrix.
• Omit a freeze on new old-version customers and a final shutdown exit condition.

Follow-up Questions and Answers

Why not maintain every version for free?

A finite baseline window limits ecosystem risk; an unlimited window keeps adding test and security cost. Paid long-term support makes extra time and responsibility explicit while preserving a fair baseline security promise.

What if a customer says the contract promised permanent compatibility?

Preserve the contract evidence and have legal and sales confirm the obligation. Register the exception scope and expiry, provide a migration plan, and do not unilaterally shut down the service while the obligation is unresolved.

Can RFC headers solve deprecation communication?

No. Deprecation and Sunset provide machine-readable signals, but documentation, console, SDK, customer contacts, and support workflows must execute the same timeline.

How do you keep paid support from creating lock-in?

Publish version rules, exportable migration tools, and end dates. Charge for response, assessment, and testing services so customers can complete a basic migration without vendor assistance.

When is a codemod worth building?

When parameter changes are statically detectable, the customer base is large, and failure modes are stable. Semantic or data changes still need a sandbox, replay, and human review; do not promise a fully automatic safe conversion.

Which metric decides when to shut down an old version?

Combine request share, critical-customer coverage, migration completion, failure risk, support cost, and contract obligations. A single traffic threshold misses the impact of a few high-risk customers.