Product Strategy, Vision and Innovation Questions

Direct answer. Do not decide on the 2% figure. Users are not revenue, strategy or risk. I would measure what those users are worth and what the 10% costs, then choose among four options: fix (cut the maintenance cost, for example by rewriting it), freeze (security fixes only, no new work), migrate (move users to a replacement) or sunset (retire with a planned end date). Sunset only if value at stake is clearly below carrying cost and a path exists for the people affected.

Step 1: put both sides in the same units (illustrative numbers). Suppose maintenance work totals 20 engineer-years a year (the 10% is measured against maintenance effort, not total engineering time, so state that base explicitly), so 10% of it is 2 engineer-years. At an assumed $200k fully loaded cost each (salary plus benefits, equipment and overhead), that is $400k a year, plus the opportunity cost (the value of what those two would build instead). Value side: if the 2% of users hold $800k of a $10M annual contract value (the yearly value of customer contracts), that is 8% of revenue, and the $400k carrying cost is half of that $800k, so the feature may be strategic to big accounts. If they hold $100k (1% of $10M), carrying cost is 400 / 100 = 4 times the revenue, and sunset is easy to justify. Rule of thumb: sunset when revenue at stake is well under carrying cost and no key account depends on it; otherwise try fix or freeze first. At $800k, halving the cost to $200k by a rewrite would cut it to a quarter of the revenue. Also check: are these users expansion accounts (ones that buy more over time), referenceable logos (customers willing to be named and speak to prospects), or a churn trigger (do they leave the whole product if it goes)?

Step 2: look for options before the kill decision. Can the maintenance cost be cut (rewrite onto a modern component, retire an old dependency)? Can it be frozen (security fixes only)? Is there a replacement the users can adopt?

Who to consult. Customer success and sales (account value, contracts promising the feature), support (ticket load), engineering (what the 10% really consists of, security risk), legal (contract commitments) and finance.

Handling dependent customers. Announce early with a firm date (there is no standard length: set it by the contract terms and the migration effort, never shorter than the time to the next renewal for customers whose contract promises the feature, and longer when migration is heavy), offer a migration path or partner alternative, assist top accounts one-on-one, and honor contractual commitments. Track churn on the affected group.

Pitfall. Deprecating quietly invites the loudest 2% to become your worst references.

Position: I would not frame this as monetization against debt. I would pick the debt that blocks monetization and fund it as part of the monetization plan. Technical debt means shortcuts in the codebase that make every later change slower or riskier. OKRs (Objectives and Key Results) are the company's goals and how they are measured.

Step 1: Fit to the goals. Translate "faster monetization" into specific measurable levers, such as conversion from free to paid (the share of free users who start paying), average revenue per account (total revenue divided by paying accounts), and churn (the share of customers who cancel in a period). Then ask which of our current constraints actually limit those. If, for instance, plan changes require a code release, then experimenting with pricing is slow, and that debt is on the revenue path.

Step 2: Split the capacity (capacity means engineer time available; illustrative, 10 engineers)

Shares sum to 100% and engineers to 10.

Step 3: Sequence. Front-load the revenue-blocking debt in the first quarter so that monetization experiments move faster in quarters two and three. Review the split at each quarter against whether revenue levers moved. The table is the year-average: in the first quarter the debt bucket would run above 30% and fall as that work lands, with the freed engineers moving to monetization.

Step 4: Getting stakeholders to back it

• Executives and finance: show the debt work as a dated dependency of the revenue goal ("pricing tests take six weeks today because plans are hard-coded; after this work, setup takes days"). The six weeks is illustrative: say 1 week to change the code, 2 weeks waiting for a release slot, 1 week to migrate existing subscribers, and 2 weeks to collect results, 1 + 2 + 1 + 2 = 6. Making plans configuration removes the first three steps and leaves the 2 weeks of results, so a pricing test takes about 2 weeks plus a few days of setup. In practice I would use our measured numbers, not these.
• Engineers: protected, visible time for debt so it is not constantly traded away.
• Sales and growth: a short list of what is not being done in year one.

What would change my call: if revenue misses at the half-year mark I would shift capacity toward the lever with the strongest early signal, and if outages rise I would increase the debt share. I would agree these triggers with the executives up front so changing the split is a planned decision, not a fight.

Principle: the new CEO changes the question from "how fast can this grow" to "what return and cost can this earn". I would re-open the initiative myself, before leadership does.

Terms: Initiative is the funded product effort. Critical capabilities are the skills and systems that are hard to rebuild if the team is cut. A pivot is a change of direction to a different customer or use for what you built. Contribution is revenue less the direct cost of delivering it. Payback time is the money still to be spent divided by yearly contribution. Sunk cost is money already spent that cannot be recovered. Optionality is keeping the ability to restart something later.

1. Re-evaluate against the new goal. Rewrite the case in profit terms: cost to date, cost to finish, expected contribution, time to payback, and what is already built. Ignore sunk cost: if $4.0M is already spent, that is gone under every option; judge only future cost against future return.

2. Offer options, not a defence. Illustrative: the initiative costs $6.0M per year with 30 people, and the new goal is payback inside 18 months.

• Reduced scope: keep the highest-return part at 60% of cost = $3.6M and 18 people. Expected contribution $3.0M per year, payback 3.6 / 3.0 = 1.2 years, about 14 months.
• Maintenance mode: 40% = $2.4M and 12 people, keeping the core and learning. Expected extra contribution $0.8M per year, payback 3.0 years (36 months).
• Pivot: reuse the work to serve a profitable existing customer segment: $1.5M, expected $1.0M per year, payback 18 months.
• Stop: with a plan for the work already built.
  Read each cost as the spend over the next 12 months to reach a product that then runs on its own, and each contribution as the yearly profit it then earns after its own running costs. If instead the cost recurred every year while contribution stayed below it (3.0 against 3.6, or 0.8 against 2.4), there would be no payback at all and every option except stopping would lose money each year, so confirm which reading the real numbers support before presenting.

Mind the clock. On the reading above, each payback starts when the 12-month spend ends, so counted from today it is 12 months plus the figure: reduced scope about 26 months (12 + 14.4), pivot 30 months, maintenance 48 months. None meets an 18-month target counted from today. Counted from launch, reduced scope (14.4 months) qualifies, the pivot (18.0) sits exactly at the limit, and maintenance (36) does not. Ask leadership which clock the new goal uses before presenting. If it is from today, phase the spend so contribution starts earlier, or recommend stopping.

On the launch clock I recommend reduced scope: it has the shortest payback of the options (1.2 years against 1.5 for the pivot and 3.0 for maintenance) while keeping the capability. State what leadership gives up with each (reduced scope gives up the most ambitious features; maintenance gives up growth; pivot gives up the original customer).

3. Re-negotiate resources. Ask for a smaller, protected budget (money fenced off from further cuts for a set period) with milestone checks (dated checkpoints where funding continues only if targets are met), and offer savings in return (reduce vendor cost, pause acquisition spend).

4. Keep critical capabilities alive. Name the 2-3 skills or systems that would be expensive to rebuild (for example a data pipeline or a platform expert), and keep those people on the smaller option or move them to adjacent work. That also preserves optionality to restart growth later.

5. Morale and credibility. Tell the team honestly and early what changed and what stays; show the new priorities in one page. With leadership, bring numbers, own the earlier assumptions, and focus on what helps the new goals.

Flip: if the initiative cannot show payback inside the new time frame, recommend stopping rather than shrinking it to a half-funded state.

Example story. The structure to reuse is situation, insight, credibility check, persuasion, action, result, lesson. Swap in your own specifics.

Situation: I was the PM for a B2B analytics dashboard. Our strategy was to move upmarket (sell to larger companies than we had before), and the roadmap was weighted toward security and administration features, such as single sign-on (one company login for all tools) and audit logs (records of who did what) those buyers ask for.

The insight: about four months in, win-loss interviews (calls with buyers who chose or rejected us) and sales-cycle data (the median time from first meeting to signature, taken from the CRM for the enterprise deals we closed or lost that year) showed enterprise deals taking a median of roughly seven months from first meeting to signature, with most of that time spent stalled in security review, while mid-sized teams signed up themselves (self-serve, with no sales call), shared dashboards internally, and expanded without a sales call.

Evaluating credibility: I did not act on one data source.

• I read 24 win-loss interviews (a small sample, so I treated it as direction, not proof).
• I checked usage across several hundred accounts to see whether the self-serve pattern was broad or driven by a few.
• I asked whether the interviews were biased, for example only from customers who answered the survey.
• I looked for evidence against the idea, and found the enterprise pipeline was real but slow.

Convincing stakeholders: I wrote a one-page memo with three options and the numbers behind each. Illustratively: (A) stay the course: about 7 months per enterprise deal, so new roadmap revenue lands in 2 to 3 quarters at the earliest; (B) pivot to mid-market: self-serve revenue starts within a quarter but needs the 10-person team moved to onboarding work; (C) run both for two quarters, a 5 and 5 split, which halves the speed of each. I met the VP of Sales and the CTO separately before the group meeting. Then I proposed a six-week test: repositioning the website and onboarding for mid-market teams to see if the trend held.

Re-prioritizing the roadmap: I moved audit-log and advanced single sign-on work out of the next two quarters, pulled forward self-serve onboarding and sharing, and told the enterprise-facing team what we were stopping and why.

Result: trial-to-paid conversion (the share of free trials that become paying accounts) rose from about 6% to about 9% over the following two quarters (a 3 point gain, or 50% relative). Illustratively, that was about 1,500 trials in each period, so roughly 90 conversions became roughly 135; at that volume the gap is well beyond chance (z of about 3.1). At only 300 trials per period the same percentages (18 versus 27) would be indistinguishable from noise (z of about 1.4), so I checked the volumes before claiming anything. Enterprise work resumed later with a clearer scope. On attribution: conversion could have moved for other reasons, so I checked that pricing, traffic sources and the trial length had not changed in those two quarters, and compared the repositioned mid-market sign-ups with the earlier cohort. I treated it as strong evidence, not proof, because I had no randomised control.

What I learned and would change: I should have set a trigger earlier, such as "if cycle time exceeds X, we revisit", so the strategy change was a planned review instead of a surprise. I would also bring finance in sooner.

Direct answer. In the first quarter I would watch for leading indicators (early signals that predict later results) that the problem or the buyer is wrong, not just slow numbers, and treat a pivot (a major change of direction on customer, problem or solution) as a last step after smaller corrections fail. Then I would bring people along with evidence, a clear "what stays, what changes," and a staged commitment.

Signals the vision is out of step (first quarter).

• Demand: prospects agree it is interesting but will not commit to pilots or pay; sales cycles (time from first call to signature) lengthen as buyers ask who owns the budget. Illustrative: you expected 5 signed pilots from 20 qualified conversations (25%) and got 1 (5%).
• Engagement: early users try it once and do not return (illustrative: you hoped 40% of 200 trial users, 80 people, would come back in week two, and 10%, 20 people, did); the use cases that appear are not the ones the vision describes.
• Customer language: interviews reveal a different problem than the one the vision names, or users already solve it well enough.
• Market: a competitor or platform change removes the gap.
  Caution: one quarter is a short sample, so a handful of calls is a hypothesis, not proof. Look for the same pattern across independent sources (interviews, usage, sales outcomes) before acting.

Before pivoting, test cheaper options: change the target segment, the positioning (which customers you aim at and the one reason to choose you), or the packaging (how features are bundled and priced). A pivot is warranted when several of these fail and a stronger signal points elsewhere.

Bringing people along.

• Stakeholders: present the evidence, the options considered (including staying the course), a recommendation, what it costs and what it frees. Agree decision criteria (the results that would make you continue, adjust or stop) first.
• Customers: talk to the existing ones before announcing; keep commitments or provide a transition.
• Engineering team: explain why in terms of the evidence, say which work carries over, name what stops, and protect against whiplash (the team lurching between directions) by committing to a time-boxed test of the new direction with defined success measures.

Sample message to the team (outline). "What stays: the team, the data platform and the integrations. What changes: our first customer moves from large retailers to small ones. Why: only 1 of 20 qualified conversations turned into a signed pilot (we expected 5), and the problem they described was different from ours. The ask: an 8-week test; if 5 of 20 conversations sign pilots, we continue; if not, we reconvene with new options."

Is this a pivot or a correction, and how much do the numbers prove? Moving the first customer from large to small retailers while keeping the problem and the platform is the cheapest correction in the list above (a segment change), so the message announces a time-boxed test of that correction; it becomes a full pivot only if this test also fails and the evidence points to a different problem. On the numbers: if the true pilot-signing rate were 25%, getting 1 or fewer signed pilots from 20 conversations would happen about 2.4% of the time, so the first-quarter result is real evidence against the original plan, though from one segment. The continue rule is noisier: if small retailers truly sign at 25%, 5 or more of 20 appears only about 59% of the time, and at a true 10% about 4% of the time. So 5 of 20 or more is a reasonable bar to continue, 2 to 4 is a reason to extend the test by a few weeks, and a miss on 20 conversations is not conclusive on its own.

Pitfall. Pivoting on a charismatic anecdote, or refusing to pivot because the vision is personally invested.