Product and Engineering Collaboration Questions

Direct answer

Build one page for the quarter where every piece of work, whether a feature, a reliability improvement or maintenance, is a row with the same columns and is paid for from the same capacity number. Once all three kinds compete for one budget, the conversation changes from "can we squeeze this in?" to "what moves below the line if we add this?". The line is the capacity line on the page: items above it fit in the quarter's capacity and are committed; items below it do not fit and wait. I would use it as the agenda of a fortnightly planning review.

What the page contains

1. Capacity header: engineers x weeks, minus a reserve for leave, on-call and interruptions.
2. Initiative table, one row per item, with these fields: ID, name, type (feature, reliability, maintenance), product goal supported, owner, effort in engineer-weeks, dependencies, risk, and the cost of not doing it.
3. A capacity line: items above it are committed, items below it are not.
4. A decision log: date, decision, who decided, reason. A sample entry: "Week 3. Moved F2 below the line to fit the partner feature. Decided by: product lead, with engineering lead consulted. Reason: partner contract renewal. Reopen if capacity grows."

Worked example (illustrative)

8 engineers for a 12-week quarter is 96 engineer-weeks. Holding back 20% for leave, on-call and interruptions leaves 76.8 plannable weeks (96 x 0.8).

Capacity line: at 76.8 plannable weeks, all seven rows (75 weeks) sit above the line and are committed; a new row is placed below the line unless something above it moves down.

Totals: features 45, reliability 18, maintenance 12, all 75 weeks (45 + 18 + 12), leaving 1.8 unallocated. That is a split of 60%, 24% and 16%. It is a starting point to negotiate, not a rule.

Using it in conversations

• When a request arrives: "It costs 12 weeks. We have 1.8 spare. Which item moves below the line?" The trade becomes visible and belongs to whoever asks.
• For reliability items, bring evidence in product terms (incidents, customer minutes affected) so they compete with features on impact.
• The same page works when requests come from outside engineering, for example product asking a data team for a report. An intake form feeds new rows into the table: requester, the decision or customer need it supports, deadline and why, who uses it, rough size, and triage checks (is it a duplicate of existing work? is the data available? is there a named owner?). Unqualified requests wait. A filled-in example (illustrative): "Requester: PM B. Need: churn report for the renewal review on 14 March. Users: 6 account managers. Size: 3 engineer-weeks. Triage: no duplicate, data available, owner named. Result: becomes row F4 and competes with the rest."

Cadence, participants and decision rules

Fortnightly 45-minute review with the product lead, engineering manager, SRE or tech lead, and a design representative. Rules: anything over 5 engineer-weeks, or anything that displaces a committed item, is decided in the review; product owns feature order, engineering owns the evidence and minimum bar for reliability and security; unresolved ties go to the director of product and director of engineering, and the outcome is written in the decision log.

Presenting trade-offs to stakeholders

Show two or three scenarios, each with what ships, what slips and the risk, and recommend one. Example: adding a 12-week partner feature means moving F2 below the line (its 15 weeks plus the 1.8 spare cover the 12), and the product lead decides whether that is the right trade.

Pitfalls

A page that only lists features; reliability rows without impact evidence; refilling the reserve with scope because it looks idle.

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

I would lead a blameless post-mortem (a review that asks how the system and the decisions allowed the failure, not who to punish), then convert it into shared accountability for both sides. Engineering is not guilty for "not stopping it" and product is not guilty for "wanting speed"; the real finding is usually that the decision to ship fast was made without a clear, agreed view of the risk. I would rebuild trust with facts and visible follow-through, and change five things in the release process (listed in Step 4), of which two matter most and come first: who signs off when a release gate is skipped, and how much capacity is protected for quality.

Step 1: stabilise and gather facts (days 1 to 14)

• Fix and verify the immediate cause, then reconstruct a timeline from logs, chat and tickets, with times and the information people had at the time.
• Interview both sides separately first, asking "what did you know, and what did you expect?"
• Reconstructed timeline excerpt (illustrative): 14:05 release goes out with the quality check skipped to meet a customer date. 14:20 error rate climbs; an alert fires. 14:35 on-call engineer pages the team lead. 15:10 the change is switched off and service recovers. The outage lasted 50 minutes (14:20 to 15:10), and the 15 minutes between alert and page (14:20 to 14:35) is itself a finding.

Step 2: run the post-mortem (60 minutes)

The rows sum to 60. Facilitation is neutral (a person from outside both teams if possible).

Step 3: assign accountability without blame

Accountability means a named person owns each action, not that someone takes the fall. Three kinds of ownership:

• Decision ownership: who accepted the risk of the rushed push? If nobody explicitly did, that is the finding.
• Action ownership: each action has one owner and a date.
• Outcome ownership: product and engineering share the goal, for example a stated release quality target.

Step 4: change the process

Step 5: the 90-day plan and executive communication

• Days 1 to 14 (14 days): stabilise, post-mortem, publish findings.
• Days 15 to 45 (31 days): put the gates and rollback in place on the most-changed service.
• Days 46 to 90 (45 days): extend to other services and review results.

The three phases total 14 + 31 + 45 = 90 days. Executives get a one-page update every two weeks, opening with something like: "Outage on the 3rd lasted 50 minutes. Cause: a release shipped without its quality check. Done: automatic rollback in place on the billing service. Next: release gates on two more services by day 45." Each update covers: what changed, which measure moved, what is next. Measures: change failure rate (releases that caused an incident divided by all releases), time to restore service (minutes from the start of an outage to normal service, 50 in the excerpt above; the DORA research program, at dora.dev, now calls its version of this measure failed deployment recovery time, counted from a failed deployment, and defines change fail rate as the share of deployments needing immediate intervention such as a rollback or hotfix, so state which definition your dashboard uses), and lead time for changes (from code committed to running in production), so speed is tracked next to quality.

Rebuilding trust

Small kept promises: the action list gets reviewed publicly until it is closed; each side presents the other's constraints at the next planning session; and we agree a shared name for the metrics.

Pitfalls

A post-mortem that ends with "be more careful"; actions without owners; giving up speed entirely; and executives hearing about it from the incident rather than from you.

Direct answer

I would tell a story where I stopped treating it as "product vs engineering" and got both sides to agree on one shared problem, then traded explicitly. In my example, product wanted to ship new onboarding features as often as every day or two to learn from users (a user-experience goal), while engineering wanted a slower weekly release because each deploy was manual and risky (a developer constraint). A deploy is putting new code into the live product; a rollback is undoing a deploy by returning to the previous version; a hotfix is an urgent fix pushed outside the normal schedule. I got both to look at the same release history, proposed a trade that gave each side what it needed most, and we measured the result after six weeks.

The story, step by step

Situation. A team of 8 engineers, a six-week plan, and two camps. Product wanted a faster signup flow with several user tests. Engineering wanted the last two deploys' rollbacks fixed before anything new went out. The sticking point was deployment cadence (how often code goes to production): product wanted near-daily deploys, engineering wanted one a week because every deploy needed a two-hour manual regression check (a person clicking through the product to confirm that old features still work after the change).

What I did, in order:

1. Asked each side what it was protecting, not what it was demanding. Product was protecting learning speed (every week of delay was a week without user feedback). Engineering was protecting stability and its own evenings (rollbacks happened after hours). Writing both down showed that neither goal was unreasonable.
2. Put one shared fact on the table. I pulled the last ten releases: four needed a hotfix or rollback. That made "slow down" and "ship faster" both partly right, and it moved the argument from opinion to data.
3. Proposed a trade with a price tag. Two engineers spend two weeks automating the smoke tests (a short set of quick checks that the most important paths, such as signup and login, still work) and putting new work behind feature flags (switches that let code ship switched off and be turned on later without a new deploy). Product keeps its fast cadence because code can ship dark (deployed to production but switched off for users) every day, instead of waiting for the weekly release train (the fixed weekly slot at which all finished changes go out together). Engineering controls exposure because a flag can be turned off in seconds. Product also agreed to cut the first release to the first step of the new flow.
4. Made the decision visible and owned. In the planning meeting I said to the product lead: "You keep daily shipping. In return the first release is only step one of the flow, and two of our engineers spend two weeks on the test automation." To the engineering lead: "You get a switch to turn anything off in seconds, and the manual check goes away once the automation covers it. Are you comfortable with that?" I then wrote a half-page note with the trade, the cost, and a checkpoint at week three, and both leads signed off in the planning meeting. I owned running the checkpoint.

Worked example: the numbers in this story

These figures are illustrative placeholders; use your own real ones in an interview.

• Capacity: 8 engineers x 6 weeks = 48 engineer-weeks. The automation pair cost 2 engineers x 2 weeks = 4 engineer-weeks, which is 4 / 48, about 8% of the plan.
• Baseline: 4 of the last 10 releases needed a hotfix or rollback (40%).
• Outcome after six weeks: 1 of 10 needed one (10%), and product shipped three flagged experiments instead of waiting for the weekly train. With only ten releases each side, I presented that as an encouraging but statistically weak signal (a Fisher exact test, a standard small-sample significance test, gives p of about 0.30 for 4 of 10 versus 1 of 10, meaning a gap this size could easily be chance) and kept watching it for another quarter rather than calling it proven.

What I would do differently

I would bring the release-history data to the very first conversation instead of the second, and I would agree on a standing reliability share of capacity up front so we did not have to renegotiate it feature by feature.

Trade-offs and pitfalls

• Declaring a winner ("we do reliability first") satisfies one side and costs the relationship. A trade both can explain to their own team lasts longer.
• Vague outcomes ("things got better") sound like a story you invented. Name the measure before you tell it.
• Skipping the cost of the compromise (the 8% of capacity) makes it sound free and invites the follow-up "so what did you give up?"

Direct answer

I timebox the decision to about an hour of two engineers' time, decide on a few written criteria, and usually land on the middle path: a minimal preparatory refactor sized to the feature, then the feature, with the larger cleanup scheduled separately. The question is never "refactor or ship" in the abstract. It is "how much does this specific code change raise the risk or cost of this specific feature, and of the next one?"

How much time to spend assessing

About 60 minutes, with the tech lead and one engineer who knows the code, plus the product manager (PM) for the first ten. If the answer needs more than that, the unknown itself is the finding, and the next step is a short spike (a timeboxed experiment to learn something, not to ship).

Criteria that decide it

1. Is the refactor in the path of the feature? If the feature must change the messy code, prepare it first. If not, defer.
2. Regression risk: is there test coverage on the code we will touch? None means a change can break things silently.
3. Can it be split? The smallest refactor that makes the feature safe, versus the full cleanup.
4. Cost of waiting: does the next feature compound the problem?
5. Reversibility and date: what does product lose if the feature lands one sprint later?

Facilitating the sprint-planning conversation

When product and design push new work and engineering warns about regressions, I bring a one-page decision aid: options, extra days, regression risk, what product gets, and when. The people in the room are the PM, the designer, the tech lead and whoever owns testing. The PM decides what and when; the tech lead states the risk plainly; the sprint commitment is written after the choice.

Worked example (illustrative numbers)

Feature: a discount-code field in checkout, 3 days. It touches a shared tax-calculation function with no tests. A sprint has 10 working days; 6 are free for this work.

I choose C: it leaves 1.5 days of slack, and the remaining refactor (3.5 days) goes onto the next sprint's plan, visible to product.

Pitfalls

• Assessing for two days to decide a one-day question.
• Using "refactor first" as a default: it delays the customer and often grows past its estimate.
• Using "ship now" as a default: the cost shows up later as slower, riskier work. What would flip my call: a hard external date with no safe slice, in which case I ship with a flag and record the refactor as owed.