Product and Engineering Collaboration Questions

Direct answer

I delayed a customer-facing feature by three weeks so we could finish a security-driven upgrade before its deadline. I won the room by laying out the dates and the cost of each ordering, talking to each stakeholder before the group meeting, and agreeing in advance how we would judge the outcome. The story uses illustrative numbers; use your own real figures when you tell it.

Situation

The vendor of our core database version would stop shipping security fixes in 8 weeks. The upgrade was estimated at 3 weeks. The roadmap held a 6-week feature (saved reports) that Sales had mentioned to a customer with a target date.

Worked example: the dates under each ordering

Feature-first misses the deadline (6 + 3 = 9 is more than 8), so it was not a real option. Doing both in parallel with a split team would have slowed both.

How I brought stakeholders along

1. One-to-one conversations first. I spoke to the PM, the Sales lead who had mentioned the date, the security lead and my director separately, so no one met the trade-off for the first time in a group.
2. A one-page note: what happens if we do nothing (no security fixes after week 8, and customer security questionnaires ask about supported versions), what each ordering costs, and my recommendation.
3. Speaking each person's concern. For Sales: I will help you give the customer a new date and a reason. For the PM: the feature keeps its scope and gets a firm new date. For security: the deadline is protected with margin.
4. Agreeing the success measures in advance: the upgrade finishes before week 8, no customer-facing incident from it, and the feature ships at the new date.

Result

The upgrade finished in week 3, 5 weeks before the deadline. The feature shipped in week 9, 3 weeks later than first planned, at its original scope. The customer accepted the revised date after Sales gave them the reason. The migration caused no customer-facing incident. We also agreed to a standing maintenance allowance in planning, so the next end-of-support date would not arrive as a surprise.

What I would do differently

I would have raised the end-of-support date at quarterly planning, when it was months away, and kept a dated list of dependencies approaching end of support, so this was a scheduled item rather than a trade-off. I would also have told the customer the new date earlier, rather than after the group meeting.

Trade-offs and pitfalls

• "Technical work is important" is not an argument; dates and consequences are.
• Delaying a feature without a new committed date just converts a delay into mistrust.

Direct answer

I would not say yes or no at the first conversation. I would turn "I suspect it will break capacity" into a number: how much extra load, when, against what limit. Then I would recommend a staged launch with explicit gates, so product still gets the feature early while the system is protected. The recommendation is the output of the arithmetic, plus a plan for what to do if the arithmetic is wrong.

What I ask product

• Expected adoption: how many users, how fast, on which days? Is there a marketing event that causes a spike?
• Per-user behaviour: how many requests does an active user make through this feature?
• Deadline logic: is the date fixed by a contract or event, or preferred?
• Flexibility: can the feature launch to a segment first, or with reduced functionality?

What I ask telemetry

• Current peak requests per second (RPS), and growth trend.
• Utilisation at peak: CPU, memory, connection pools (the fixed number of reusable database connections the service can hold open), database load.
• Latency at the 95th percentile (P95: 95% of requests are faster than this) and error rate as load rises.
• The tested saturation point from a load test: the load where latency or errors degrade. If there is no load test, that is the first task.
• Lead time to add capacity (minutes for autoscaling, where the platform adds servers automatically when load rises; weeks for database changes or quota requests).

Assess and decide

Set the rule: peak load stays at or below 70% of tested saturation (the load level where latency or errors start to degrade in a load test). The 70% is a rule of thumb, not a law. The margin covers forecast error, traffic spikes above the daily peak, losing a server during peak, and the fact that systems slow down sharply as they approach their limit because requests start queueing. A team with a slower scale-up or a less certain forecast would pick a lower share; a team that can add capacity in minutes could run higher.

Worked example (illustrative)

Tested saturation is 7,500 RPS, so the ceiling is 7,500 x 0.7 = 5,250 RPS. Today's peak is 4,000 and organic growth will take it to 4,400 by launch. Product forecasts the feature adds 1,200 RPS at full adoption.

At full rollout we would need a saturation point of 5,600 / 0.7 = 8,000 RPS, about 6.7% above the tested 7,500. So the recommendation: launch to 10%, then 25%, then 50% behind a flag, holding each stage long enough to see a full peak day; in parallel, add the capacity (or remove the hot spot found in the load test: a single table, queue or server that takes far more traffic than the rest and hits its limit first) before the 100% step. Time to market is barely affected: users get the feature at stage 1, and the final step waits for roughly one capacity change.

Pitfalls

• Treating a forecast as fact. The gates exist because forecasts are wrong; watch live utilisation at each step.
• Averages hide peaks and the first bottleneck may not be the one you load-tested.
• What would change my call: a load test showing the saturation point is far lower than assumed, or a hard launch date with no capacity lead time, which turns it into a conversation about descoping the feature.

Direct answer

I treat the date as fixed and the scope as the variable, and I negotiate with the engineering manager from the outcome, not from the feature list. I ask: "What is the smallest slice that lets a real user get the value we promised on launch day?" Then I agree three things with the manager: that slice, the safety nets that make it safe to ship, and a written ledger of everything cut, with owners and dates, so the cut work does not quietly disappear.

Finding the smallest slice that still delivers the value

1. Write the value as one sentence a customer would say ("I get told when my order ships"). Anything not needed for that sentence is a candidate to move after launch.
2. Ask the engineering manager to split every item into "must be true on day one" and "can follow". Engineers often see cheap partial versions that a spec hides (an unsubscribe link instead of a full preferences page).
3. Re-estimate the slice, not the whole feature, as a range, and plan to about 80% of capacity so a surprise does not break the date.
4. If a stakeholder wants the ideal feature (three sprints of work) in one sprint, do not stretch the estimate. Lay out two or three delivery plans side by side (full in three sprints, slice in one sprint plus follow-ups, a smaller slice with a manual fallback) and let product and leadership choose with the costs visible.

Safety nets I insist on

• A feature flag (a switch that turns the feature on or off without a new deploy) so exposure can be ramped (widened in steps, for example 5% of users, then 25%, then everyone) and reversed.
• A kill switch (a flag that turns the feature off in seconds) and a rehearsed rollback (return to the previous version of the product), tested before launch, not on launch day.
• An alert on the one or two numbers that would show harm (error rate, failed sends), with a named person watching them.
• A manual fallback for the cut part (support can send the notice by hand) so a missing feature is an inconvenience, not an incident.

Tracking the catch-up work after launch

Every cut item goes into a ledger (a simple list, one row per cut item) as a real ticket with an owner, a target sprint and the reason it was cut. Two example rows:

Even a deferred item has a named owner: the person who must decide whether it happens, not necessarily the person who would build it. I put the launch review on the calendar before launch (two weeks after) and hold part of the next sprint for it. Items nobody asks for after two sprints are removed deliberately, which keeps the ledger honest.

Worked example (illustrative numbers)

A two-person team has 4 engineer-weeks per two-week sprint. The ideal "order shipping notifications" feature is 12 engineer-weeks (three sprints):

3.2 is 80% of the 4.0 available, so one sprint holds the slice with buffer. The same basis applies to the ideal feature: "three sprints" is 12.0 / 4.0 at full capacity, but at the 80% planning rule (3.2 per sprint) the full 12.0 needs 12.0 / 3.2 = 3.75, so four sprints. The gap between the ideal plan and the one-sprint slice is therefore wider than "three sprints versus one" suggests, and the stakeholder comparison should use the same 80% basis on both sides. Of the 8.8 that follows, only the 1.3 engineer-weeks for finishing email (0.5) and hardening (0.8) is non-negotiable and goes into sprint two. The ledger's preferences page (1.5) also targets sprint two, so sprint two holds 1.3 + 1.5 = 2.8 engineer-weeks, which fits under 80% of 4.0 (3.2) with 0.4 to spare. SMS, push and the dashboard are scheduled only if launch data shows demand.

Trade-offs and pitfalls

• Cutting safety nets to keep features is the usual wrong turn: a failed launch costs more than a smaller one.
• "We will fix it after launch" with no owner or date is how cut work becomes permanent.
• If the slice cannot deliver the value even at its smallest, say so early and bring the date itself into the conversation. That is what would change my call.

Direct answer

I would not negotiate the 30% until the number means something. First I establish what the metric is and what it measures today, then I agree what success means (the exact definition, the date, and what counts as a win), and only then I check whether 30% is realistic and, if it is not, trade it for intermediate deliverables the PM can show leadership.

Structured approach

1. Pin the metric definition (day 1). Ask: relative or absolute? "30% better" on an 18% rate means 23.4% (relative) or 48% (30 percentage points). These differ by a factor of two, so the first conversation settles it in writing. Also fix the numerator (the count of successes), the denominator (the count of everyone eligible), the population and the time window.
2. Establish the baseline (week 1). Pull at least 4 to 6 weeks of history, not one number. Record the average and the week-to-week spread, because the spread is the noise any improvement has to rise above. If the data does not exist, say so and instrument it (add tracking so the events are recorded); the first deliverable becomes "we can measure this".
3. Agree what success means. Target value, deadline, how it will be read (same query, same dashboard, same owner), and a guardrail metric (a second measure that must not get worse while you improve the first, for example support tickets or latency).
4. Test the target against the work. Ask engineering which levers move the metric (a lever is a specific change that could raise it, such as a shorter setup form or a reminder email) and what each plausibly delivers. Treat these as ranges, not promises. Compare the sum of the plausible levers to the gap.
5. Negotiate intermediate deliverables if the target is unrealistic. Offer dated checkpoints: baseline published, first lever shipped and measured, a revised forecast. Leadership gets visible progress and an honest range; the team avoids a hidden miss.

Worked example (illustrative numbers)

Metric: share of new signups who finish setup in week 1. Six weeks of data (activated / signups): 700/4000, 760/4100, 690/3900, 740/4000, 810/4200, 720/3900. Weekly rates range from 17.5% to 19.3%. Pooled: 4,420 / 24,100 = 18.3%.

• Relative 30% target: 18.3% x 1.3 = 23.8%.
• Absolute 30 points: 48.3%, which is not a credible target for a setup funnel.
• The weekly spread is about 1.8 points (the weekly rates have a standard deviation of about 0.65 points), so a lift of one point in a single week cannot be distinguished from noise. Averaging three weeks cuts that noise to roughly 0.4 points, which is why the later reforecast quotes a three-week lift. Checkpoints should compare several weeks, not one.

Proposed plan: week 2 publish the baseline and agreed definition; end of month ship the highest-impact lever and read three weeks of results; reforecast. If the levers engineering names add up to roughly 2 to 3 points, I say plainly that 23.8% is a stretch for the quarter and propose a lower committed target with 23.8% as the stretch goal.

Written definition excerpt: "Setup completion rate = accounts that complete all 4 setup steps within 7 days of signup, divided by all accounts created that week (excluding internal test accounts). Source: the weekly activation query, read each Monday for the cohort created two Mondays earlier, because a signup from the last day of a week needs a further 7 days to complete setup, so the most recent cohort is always still immature and is never compared with the baseline. Guardrail: setup support tickets per 100 signups must not rise. Target: 23.8% (relative 30%) by 30 June, owner: PM."

Reforecast message to the PM after the first lever: "Baseline is 18.3%. The reminder email lifted week 1 completion to 20.1% over three weeks, about 1.8 points. Remaining levers add an estimated 2 to 3 points. Forecast for 30 June: 22 to 23%. 23.8% needs a further lever; here are two options and their costs."

Trade-offs and pitfalls

• Anchoring on the 30% before the baseline exists makes every later number a negotiation about face.
• Do not quietly redefine the metric to make the target reachable; changes to the definition are agreed with the PM and recorded.
• Pushing back with "that is impossible" loses the room. Bring the baseline, the noise band and the lever estimates instead.
• What would change my call: a lever with strong prior evidence (a past experiment on the same funnel) would justify keeping the full target.

Direct answer

In the meeting I would not say "no". I would say what I can do by Friday, name the specific harm of the rushed version, and offer a safer path to the same outcome. Then I would write the agreed trade-off down before leaving the room, so the decision and the accepted risk have names on them.

In the meeting

1. Ask what the 48 hours protects (a customer promise, a demo). Understand the goal before arguing about the date.
2. State the risk concretely, in the PM's language: "If we ship this migration unreviewed, it can overwrite customer addresses, and we cannot restore them." A migration is a script that changes existing stored data in bulk. Another line I would say: "I can have Thursday's version ready that only shows what it would change and writes nothing. That gives you something to show on Friday, and the real run follows after review." The words "hard to undo" are the heart of it: a mistake that can be reversed is a cheap risk; one that cannot is expensive.
3. Separate the reversible part from the irreversible part.

What I offer instead

• Option A: in 48 hours, ship the reversible part (for example, read-only or dry-run output: the feature runs and reports what it would change, but writes nothing), behind a feature flag (a switch that turns the feature off without a new deploy).
• Option B: the full feature in about 5 working days with a review and a rollback plan (the exact steps to return to the previous state if it goes wrong).
• Option C: the full feature in 48 hours only if the PM's manager accepts the named risk in writing, with a tested backup of the data first.

I recommend A, then B. If the PM chooses C, I record it and do what I can to reduce harm, not refuse.

Recording the trade-offs

Post a short decision record in the team channel or ticket the same day:

Decision: Ship dry-run address cleanup Thursday behind a flag; real write after review (target 5 working days out).
Context: Sales wants it for Friday's customer call. The write step cannot be undone without a backup.
Options considered: A) dry-run now, write later  B) full in 5 working days  C) full in 48h, no review
Chosen by: PM (what and when), tech lead (risk statement)
Risk accepted: Customer sees a preview, not the cleaned data, on Friday.
Revisit: review at the 5-day mark, owner: tech lead

Trade-offs and pitfalls

• A bare refusal teaches product to stop asking engineers early.
• Do not bury the irreversible risk in jargon; the PM cannot weigh what they cannot picture.
• If the PM overrules me, I still write the record. It protects the relationship as much as the team: everyone later sees the same facts.