Customer and User Obsession Questions

Direct answer

I would treat the threat as information about an unmet problem, not an order. I would lead the negotiation as one accountable owner with my executive sponsor (a senior leader on our side who owns the relationship) and the customer's sponsor (the senior person on their side who backs the purchase) present, find the problem beneath the requested feature, offer alternatives that solve it without damaging the product, avoid dated feature promises tied to the threat, and write the final decision in a decision record.

Before the meeting: size the stakes

• Share of annual recurring revenue (ARR, the yearly subscription revenue) and the renewal date.
• What the contract says, so nothing is promised that legal has not seen.
• Engineering's estimate of build cost and of the ongoing cost of keeping the variant working.
• Which other customers asked for something similar.
• The customer's real alternative: another vendor, building it themselves, or living without it.
• Whether the person making the threat signs the renewal.

In the meeting: ask about the problem

"Walk me through the last time this blocked you." "What happens to your team if it does not exist by renewal?" "Who else is affected?"

Alternatives, cheapest for the product first

Options 1 to 3 are the usual first moves, 4 is the usual route when the need is real, and 5 and 6 are last resorts.

1. Existing capability used differently, or configuration.
2. Integration through the public API, by the customer or our solutions team.
3. A generalized version: a smaller capability that solves the underlying need for many customers, built on our normal release rhythm (cadence).
4. A design partnership: the customer co-designs and tests that general version, in return for early access.
5. Paid custom work, isolated, with explicit support terms and an end date (a sunset date, when the arrangement stops).
6. Decline, with a clear reason.

What I would say to the customer

"I want you renewing, and I want your approval problem solved. I cannot commit to building that exact approval chain by a date, because it would stay in the product and slow every later change we make for all customers. What I can commit to is this: a manual second-approver checklist from next week, a design review of configurable approval rules with your compliance team by the end of next month, and a review date at the start of next quarter."

If they push for the feature and date in the contract, I take it to legal and my sponsor and offer the commitment to the problem and the review date instead.

Roadmap commitment under a churn threat

If a commitment is the price of staying, I make it a commitment to a problem and a review date, not a feature and a ship date. Engineering owns dates. That protects roadmap discipline, the engineering cadence, and the contract risk together, because a promised date that slips is worse than an honest "design review by June".

Worked example (illustrative)

A customer worth $900k of $18M ARR (5%) renews in five months and demands a hard-coded approval chain for their organization. Engineering estimates one quarter of the year (about 13 weeks) of two engineers to build it, so about 26 engineer-weeks, plus keeping that variant (a customer-specific version of the product that must keep working alongside the main one) working through every later change to approvals. Discovery shows the real problem: their compliance team needs two named approvers on purchases above a limit.

Illustrative cost comparison at $4,000 per engineer-week: the custom chain is 26 weeks = $104,000, plus about 6 weeks a year of upkeep = $24,000 a year, indefinitely. The general rules might cost 36 weeks = $144,000, but upkeep is part of normal product work and the rules also serve other customers who ask. Against that, the revenue at risk is $900k times the chance they really leave: even at 25% that is $225k. So money alone does not rule out the custom build. What tips it is that the variant's upkeep never ends and every later customer will ask for their own.

Proposal: configurable approval rules, built for everyone on the next planned cycle, with the customer as design partner. Interim workaround: a manual second-approver checklist. A decision record is a short written note of what was decided, why, and when to revisit it. Excerpt:

Decision:  Build configurable approval rules (general), not a custom approval chain.
Context:   Customer needs two approvers above a spend limit; renewal in 5 months.
Options:   Custom chain (rejected: permanent variant), config rules (chosen), decline.
Our commitment: Design review with their team by end of next month (owner: PM).
Their commitment: Two people available for design feedback and testing.
Review date: Start of next quarter. Reopen if design review shows the rules cannot express their policy.

Trade-offs and pitfalls

• A renewal at risk is real, but so is the compounding cost of a one-off variant that every later customer will ask for.
• Do not assume the threat is a bluff, and do not accept it as a deadline without checking who is making it.
• Do not let sales agree to the feature in a side channel. One owner, one record.
• If they leave anyway, record that as a known cost of the decision and learn from it.

Direct answer

I would not present it as user experience against revenue. I would frame it as a bet about long-term value, state the harm as a testable hypothesis with guardrails, and look first for a version that captures the revenue without the harm. If there is no such version, I would propose an experiment with a holdout group (users who do not get the change) so the business decides on evidence.

Elaboration

1. Restate the business goal and agree what success means, for example revenue per new user over 90 days, not first-week revenue.
2. State the customer harm as a hypothesis: "if we show the upgrade prompt before a user has had a first success, fewer reach that success and 60-day retention falls".
3. Use counterfactual lifetime value. Lifetime value (LTV) is the total revenue a customer is expected to bring over their time with you. Counterfactual means comparing against what would have happened without the change, not against zero.
4. Set guardrail metrics: measures that must not get worse while you chase the target, such as week-4 activation (the share of new users who have completed their first meaningful task within four weeks of signing up), downgrades and support tickets. Each needs a threshold agreed in advance (a guardrail threshold), for example "stop the test if week-4 activation in the test group falls more than 2 points below the holdout".
5. Offer options that respect the goal: same prompt later in the journey, a softer prompt, or a smaller test.
6. One-page narrative for executives: the goal, the proposal, the risk in one sentence with its number, the experiment design, and the decision wanted by a date.

Worked example (illustrative numbers; a simple model that ignores discounting, which is the idea that money received later is worth less than money today)

Baseline: 10,000 trial users a month, 4.0% convert (400 payers), $20 per month, monthly churn 3%. Monthly churn is the share of payers who cancel each month. If 3% cancel each month, the average payer stays about 1 / 0.03 = 33.3 months (if 1 in 10 left each month, the typical stay would be 10 months). At $20 a month, LTV is about $667 per payer.

The proposed change lifts conversion by 20% (4.8%, 480 payers). My hypothesis is that it raises monthly churn to 4%, giving a lifetime of 25 months and an LTV of $500.

The change looks like a 20% win in month one and is about 10% worse over the lifetime. To break even at 4% churn, conversion must exceed 266,700 / 500 / 10,000, about 5.3%. The churn rise is my hypothesis, not a fact, and churn takes months to show. So the test uses leading indicators (early measures that move before the final outcome, such as week-4 activation) for an early read, and keeps a long-running holdout for churn. Illustrative design: each month 1,000 of the 10,000 trial users (10%) stay on the current flow and 9,000 get the change. Users are assigned to the two groups at random at sign-up, because random assignment balances the groups on known and unknown differences (traffic source, company size, intent), which is what lets the holdout stand in for what would have happened without the change. After four weeks compare week-4 activation between the two groups, and track each group's payer churn monthly. Activation is the early warning; 60-day retention is the later confirmation. A caution on the guardrail: with only 1,000 users in the holdout and 9,000 in the change group, a week-4 activation gap has a 95% margin of about 3.3 points (1.96 x square root of (0.25/1,000 + 0.25/9,000), taking activation near 50%), so a 2-point stop line is inside the noise (z of about 1.2) and a single month cannot trigger it reliably. Either pool two or three monthly cohorts before applying the 2-point rule, enlarge the holdout, or set the stop line at 4 points or more for a one-month read.

The holdout is the counterfactual, the comparison against what would have happened without the change. If the holdout's 60-day retention is 80% and the change group's is 74% (illustrative), the 6-point gap is the change's effect. Comparing 74% with last quarter's number instead would mix in seasonality and other launches.

Other versions of the same tension

• A UX issue that drives churn vs a monetization change: fixing the churn driver is itself a revenue decision. Size it with the same LTV arithmetic and compare it with the monetization idea.
• Short-term satisfaction vs long-term integrity: a design that tricks users into paying may satisfy the quarter and erode trust. Name it as a trust risk and offer an honest alternative with a clear value moment.

Trade-offs and pitfalls

• A loud "this will hurt users" without a number loses to a concrete revenue forecast.
• Do not hide behind the experiment to avoid taking a position. Say what you expect and why.
• Guardrails need thresholds agreed in advance, otherwise any result can be explained away.

Direct answer

I would build a closed loop with five stages: capture every issue in one place with consistent tags, triage it against published criteria, give each decision an owner and a time commitment, connect decided items to the roadmap, and tell the customer what happened. The loop fails most often at the last two stages, so I would design those first.

The loop

1. Intake and tagging. Support and customer success record each issue in one shared system with required fields: product area, customer segment, severity (blocked, degraded, annoyed), the customer's own words, and the account. Free-text complaints with no tags cannot be counted.
2. Triage criteria. A short weekly review (product, support lead, an engineering representative) scores items by how many distinct customers are affected, how severe the impact is, how strategic the segment is, and whether a workaround exists. Publish the criteria so the field knows why something was not picked.
3. Owners and SLAs. An SLA here is a service-level agreement: a stated time within which something gets a response. Every triaged item gets a named owner and a decision deadline, for example triage within a week and a decision within a month (illustrative). An item with no owner is how backlogs become black holes.
4. Reaching the roadmap. Group related items into problems, not feature requests. Problems with enough weight become roadmap candidates with the evidence attached; small fixes go to a standing bug-fix capacity (a slice of each sprint, for example 10 to 15% of engineering time, reserved for small fixes) so they do not wait for a planning cycle.
5. Closing the loop with customers. When an item is decided, support tells the customer: shipped, planned, or declined with a reason. A "no" with an explanation keeps trust; silence loses it.

Worked example

Support logs three tickets, from three different accounts, saying "can't find the invoice download". Tagged as billing area, small-team segment, severity degraded, they cluster with two more raised through customer success from two other accounts, so five tickets from five distinct accounts (counted by account, not by ticket volume). At triage they are grouped as one problem affecting five accounts with a workaround; the owner is a product manager with a decision due within the month. It ships as a small fix. Support then emails the five accounts, and the ticket closes only when the customer is told.

Model-improvement angle

When the product contains a machine-learning model, tag tickets where the model was wrong. Reviewed and with personal data removed, these become test cases (fixed examples the model must get right before each release) and training or evaluation examples (labelled examples used to teach the model or to measure how often it is right), so a ticket leads to a measurable model fix as well as a reply.

Pitfalls and measures

Measure the share of tagged items decided within the commitment and the share of decided items communicated back. Beware tagging fatigue (keep fields few), counting volume instead of distinct customers, and a loop that only handles complaints from the biggest accounts.

Direct answer

Tell a story where evidence about customers (not a loud opinion) made you move or delay something on the roadmap (the team's ordered plan of what to build and roughly when), and where you won people over by showing the evidence, the options and the cost of each, instead of announcing a verdict. Always name what you gave up by changing the plan.

Story shape

• Situation: the planned item, who wanted it, and the commitment attached.
• What changed your mind: at least two kinds of evidence that agree (triangulation means checking a claim against independent sources). Typical mix: customer calls, product usage data, support ticket themes.
• Bringing others along:
  1. Share the raw evidence early, including what does not fit your conclusion.
  2. Present two or three options with cost of delay (what waiting costs us) and cost of being wrong.
  3. Talk to the engineering lead and the sales or customer-facing lead (the person who owns the relationship with those customers) one-on-one before the group meeting.
  4. Agree a checkpoint: "If the new item does not move X by date Y, we revisit."
• Result and reflection.

Worked example (illustrative skeleton)

A technical product manager has "scheduled data exports" planned for next quarter because several large customers asked for it. Eleven discovery calls (customer conversations to learn about their problem and what they do today, not to sell) show the real job: customers copy numbers into a finance spreadsheet every Monday to reconcile figures. Usage data shows a "download CSV" button pressed by the same accounts on almost the same weekday pattern, and tickets repeat "numbers differ from our finance report".

The conclusion: exports automate a workaround; the root problem is the figures not matching finance's definitions. The PM proposes delaying exports by one quarter and building a reconciliation view first. For the engineering lead, the argument is smaller scope. In the one-on-one: "I want to defer scheduled exports by a quarter. A reconciliation view removes the cause instead of automating the workaround, and I think it is a smaller build. Here are the 11 call notes and the Monday CSV pattern. What am I missing?" For the account team, a promise to tell the three requesting customers directly, with a date: "I will call each of them by Friday, explain what we heard, give a date for the first reconciliation view, and offer a manual weekly export until then."

Before the group meeting the PM also lays out the options with cost of delay and cost of being wrong, and shows the evidence that does not fit. Option A: build scheduled exports as planned. Cost of delay: none to the three requesting customers. Cost of being wrong: the Monday spreadsheet work and the mismatched numbers remain, and exports may be built for a workaround. Option B: reconciliation view first (recommended). Cost of delay: exports slip one quarter and the three requesters wait. Cost of being wrong: if the real need turns out to be scheduling, a quarter is lost, which the manual weekly export partly covers. Option C: a small slice of both. Cost of delay: both arrive later and the team splits focus. Cost of being wrong: a half-built version of each. The evidence that does not fit: two of the eleven customers only wanted to email a file to a colleague, which exports would serve, so the PM states that openly instead of leaving it out.

The checkpoint metric (the number you agree to watch to judge the decision) is reconciliation-related support tickets and weekly CSV downloads from those accounts, reviewed six weeks after the first reconciliation view ships (the date promised to the three requesting customers), not six weeks from today. Illustrative numbers: tickets at 40 a month should fall to 24 or fewer (a 40% drop), and CSV downloads at 120 a week should fall to 60 or fewer. If neither moves, we revisit and build exports.

Trade-offs and pitfalls

• Do not overreact to one account or one call. A change of plan needs convergent evidence.
• Delay has a price: promised customers, engineering morale, planning credibility. Name it and plan the communication.
• Avoid "I told them they were wrong". The goal is a shared view of the evidence.
• Data analyst or engineer angle: you can be the person who brings the evidence (the pattern in the usage logs), not only the PM who decides.

Direct answer

I would not decide on the size of the segment alone. I would compare expected value per unit of effort (the benefit I expect from each option, divided by what it costs to build) for each direction, check that the numbers rest on evidence, and weigh the strategic risks. For typical assumptions, I lean toward a thin version of the premium feature first, validated with a few high-value users, because their need is stronger and a small accuracy gain may not change their behaviour. I would reverse that if the premium group's pain turns out to be unvalidated or if accuracy problems are driving churn across all users.

Decision frame

1. Define the groups. "High-value" must mean something concrete such as revenue or strategic importance. A small effect on 90% is not automatically bigger than a large effect on 10%.
2. Estimate benefit per group: how many people, how much their behaviour (retention, meaning the share of users who stay; upgrade; usage) changes, and what each is worth.
3. Estimate cost and risk: engineering effort, time to ship, data needed for personalization, privacy, and the chance each effect is smaller than hoped.
4. Strategic factors: dependence on a concentrated group (losing a few of them hurts a lot), what competitors are offering them, and whether accuracy is a baseline that everyone expects.
5. Test cheaply before building fully. A prototype or hand-run pilot for the 10% group, and a check whether an accuracy gain actually moves retention for the 90%.

Worked example (illustrative numbers, not real data)

Assume 1,000,000 users: 900,000 standard users worth $10 a year each, and 100,000 high-value users worth $60 a year each.

On these assumptions the premium feature is worth about 6.7 times more per year ($300,000 divided by $45,000). The decision then depends on cost and on whether the assumed effects are real. To compare per unit of effort, assume the accuracy work takes 2 person-months and the premium feature 10 (five times as much). Accuracy: $45,000 / 2 = $22,500 per person-month. Premium: $300,000 / 10 = $30,000 per person-month. The gap narrows from 6.7 times to about 1.3 times (30,000 / 22,500), so the choice now hinges on how far you trust the 5-point assumption. And if the 5-point effect is only 1 point, premium gives $60,000 a year, which looks close to the accuracy option's $45,000 in total value but is not close per unit of effort: $60,000 / 10 = $6,000 per person-month against $22,500 for accuracy, about 3.75 times worse. Total value alone would hide that.

Recommendation

Run a small premium pilot with a handful of high-value customers, measure the retention or usage effect it produces, and keep a modest accuracy workstream going so the 90% do not drift down. Commit the larger investment once the pilot shows the effect.

Pitfalls

Do not treat every user as equal, and do not treat revenue as the whole story. Do not rely on assumed effects without a pilot. Watch for building something only a few love at the cost of the quality everyone depends on.