Product Manager Interview: Should Existing SaaS Customers Pay More?

Prompt and applicable context

An interviewer gives you a SaaS product with paying customers: the new-customer price must increase, while existing customers still renew at the old contract price. Decide whether to migrate them, how to handle grandfathering, how to communicate, and how to tell a pricing problem from a packaging problem. This is a product-strategy case for PM, growth, and subscription roles.

What the interviewer is testing

The interviewer wants you to split “a higher price” into value capture, customer fairness, contract constraints, and execution risk. A strong answer does not jump to “raise everyone” or “never raise”; it separates new-customer price validation from installed-base migration, segments by value, renewal cycle, and contract, and defines revenue, renewal, downgrade, support, and complaint metrics. It also recognizes that a migration needs billing-system support, not only a new pricing page.

Questions to clarify first

• Does the new price reflect new value, cost changes, or a revenue gap? Each reason changes the argument and the communication.
• Are existing customers monthly, annual, or on long contracts? The renewal point controls timing and notice obligations.
• Is value measured by seats, usage, or a fixed plan? A wrong value metric can make a price increase amplify a packaging problem.
• Which customers have high value but high switching cost? Should we segment by size, usage intensity, region, or contract terms?
• Can the billing system preserve legacy prices, set an effective date, prorate changes, and handle failed payments?

A 30-second answer

“I would not start with a full-base increase. First I would confirm that the increase maps to a defensible value, then validate the new price with new customers. I would segment existing customers by contract, renewal cycle, and value. My default is advance notice and migration at renewal, with a finite grandfathered window whose end date is explicit; high-risk accounts get a downgrade or human conversation. I would track net revenue retention, renewal, expansion and downgrade, price objections, and support cost. If valuable customers resist the pricing axis, I would fix packaging or the value metric first. Finally, I would test price replacement, billing dates, proration, and rollback in the billing system.”

Step-by-step deep answer

1. Diagnose the reason. If the product now delivers value customers will pay for, an increase can capture that value. If the driver is cost pressure, compare cost reduction, usage limits, and repricing. A weak reason turns a pricing change into a trust problem.
2. Separate new and existing customers. A new price changes a prospect’s purchase choice, so measure trial-to-paid conversion, sales objections, and cycle length. Existing customers already built budgets and workflows around the old price; new-customer conversion does not predict their churn.
3. Segment the migration. Monthly customers can see the new price at the next renewal; annual customers need notice before renewal. Evaluate high-usage, critical-workflow, and high-support-cost accounts separately rather than ranking only by revenue.
4. Make the transition finite. Grandfathering can respect early expectations, but it needs an end date, scope, and trigger. Permanent legacy pricing creates a durable two-tier base and makes sales, finance, and the next migration harder.
5. Offer governed choices. For a price-sensitive customer whose value still fits, offer a lower feature tier, fewer seats, or an annual commitment instead of an open-ended discount. Record an expiry and approver so sales cannot create an ungoverned third price system.
6. Treat communication as product flow. State the old price, new price, effective date, value change, options, and contact path. Explain first to the most affected accounts, then cover the long tail with in-product notice and billing email, allowing confirmation before the invoice.
7. Define metrics and guardrails. Primary metrics are net revenue retention and revenue per account. Guardrails include renewal, cancellation, downgrade, complaints, refunds, sales cycle, and support tickets. Compare customer cohorts before and after migration so natural expiry is not misclassified as price churn.
8. Make billing executable. Stripe’s documentation warns that replacing a subscription price requires specifying the existing subscription item; otherwise two prices can be active. Also test billing periods, proration, invoice preview, and failed-payment states. The product plan needs a canary, audit trail, and rollback, not just a public price-page edit.

High-quality sample answer

“I would choose a staged migration rather than immediately increasing every existing customer. First I would validate that the new price reflects value and observe conversion and sales objections among new customers. Then I would segment by contract, renewal cycle, usage intensity, and customer value. Monthly customers migrate at renewal; annual customers receive notice in advance; critical accounts can receive a one-time, finite grandfathered window with an explicit end date in the contract and system. For price-sensitive customers I would offer a downgrade or a better value metric before a permanent discount. I would track net revenue retention, renewal, downgrade, cancellation, complaints, and support cost. Before launch I would test subscription-item replacement, proration, invoice preview, failed payments, and rollback so the product decision cannot create duplicate charges.”

Common mistakes

• Symptom → “New customers accept it, so raise everyone.” Why it fails → The two groups have different budget commitments and switching costs. Fix → Validate new-customer pricing separately from installed-base migration.
• Symptom → “Permanent grandfathering is the most respectful option.” Why it fails → It creates a lasting two-tier base and operational complexity. Fix → Set a finite window with a date, scope, and renewal trigger.
• Symptom → “Give every objector a discount.” Why it fails → No expiry or approval creates an ungoverned third price. Fix → Use downgrade, metric changes, or time-limited offers.
• Symptom → “The launch is done when the pricing page changes.” Why it fails → Existing subscription items, effective dates, proration, and failed payments can still be wrong. Fix → Include billing state, invoice preview, audit, and rollback in acceptance.

Follow-up questions and responses

What if high-value customers reject the increase while new-customer conversion is strong?

First determine whether the objection is the price level or the value axis. Interview those customers about seats, usage, integrations, and compliance value. If the value is real, offer an annual commitment or finite transition; do not hide a packaging mismatch behind a permanent special price.

If renewal falls but revenue rises, is it a success?

Not from total revenue alone. Calculate net revenue retention, gross margin, support cost, and the long-term value of churned accounts by cohort. Set acceptable cancellation and complaint guardrails before expanding the migration.

An annual customer prepaid the old price. When does the change start?

Usually at the next renewal with the notice required by the contract. A mid-cycle change needs an explicit proration and refund decision. Product, legal, and finance must agree, and tests must cover invoice preview and failed payment.

How do you stop sales from promising permanent legacy pricing?

Model an exception as a contract term with an approver, amount, plan, and end date; prohibit free-text promises. Generate expiry reminders before renewal and include exceptions in the migration report shared by sales, finance, and product.