Product and Engineering Collaboration Questions

Direct answer

I give engineers the problem, the evidence and the success measure, not just a task list, and I check understanding by asking them to say it back and to propose alternatives. The sign it is working: engineers challenge the plan with cheaper ways to reach the goal, and can explain what a feature is for without looking at the ticket.

What I actually do

1. A short problem brief instead of a solution ticket: who has the problem, what we saw (evidence), the outcome we want, how we will measure it, constraints, and what we are not doing.
2. Let engineers hear it first-hand: attend customer calls, read support tickets, watch a session recording.
3. Open sprint planning with the goal. (Sprint planning is the meeting where the team picks the work for the next one to two weeks.) Spend the first minutes stating the goal and the number it should move; every ticket links back to the brief.
4. Ask for a play-back at handoff (the moment a piece of work passes from the person who defined it to the engineer who will build it). In the play-back the engineer restates the problem and what they would do differently. This is where estimates become realistic, because they now know which parts matter.
5. Translate the business goal into technical acceptance criteria (the list of conditions the finished work must meet to count as done). Example: goal, "fewer customers abandon checkout after a payment error". Success metric: payment-error abandonment rate on the dashboard. Technical criteria: a repeated payment request cannot charge twice (idempotent: safe to repeat), failure messages are specific to the cause, and the payment step responds within an agreed time at the 95th percentile (the value that 95% of requests are faster than). With illustrative numbers: today 12 of every 100 customers who hit a payment error abandon checkout, the goal is 8 or fewer, and the agreed time is 2 seconds at the 95th percentile. Engineers can estimate and design against that.
6. Carry engineering concerns upward. Scalability, reliability and cost concerns go into the brief as stated constraints with a cost. I raise them in leadership reviews in business terms ("this approach cannot exceed X load without extra spend or rework"), so they are decisions, not complaints.

How I know it is working

• Questions in refinement (the regular meeting where upcoming work is discussed and clarified before it is scheduled) shift from "what do you want?" to "what are we trying to achieve?".
• Engineers propose simpler routes, and some proposals I accept.
• Fewer "that is not what I meant" reworks late in the sprint.
• A spot check: ask two or three engineers in review what the feature is for. A sample that small only shows whether something is badly wrong, so I combine it with the other signs.

Pitfalls

• A long brief nobody reads; keep to one page.
• Explaining the why once at kickoff and never again.
• Treating the why as persuasion: if engineers still disagree, there may be a real flaw to hear.

Direct answer

This is a story from my work, shaped here with illustrative numbers you should replace with your own. I was the engineer who had seen three payment-timeout incidents in six weeks, and I persuaded the PM to hold the full release of a visible feature back by three days, running it as a limited release on the promised date, so that one engineer-week could go to fixing the cause, by bringing evidence rather than opinion, offering a compromise that kept the feature moving, and making the PM look good to their own stakeholders.

Situation

Our checkout depended on a payment callback that sometimes timed out and double-processed orders. The PM wanted a saved-cart reminder feature next, with a date promised to marketing. I was the backend engineer closest to the incidents.

Task

Get the stability fix scheduled before the feature without becoming "the person who says no", and keep the relationship with the PM intact.

Action

1. Evidence, not alarm. I summarised three incidents of roughly 40 minutes each: 3 x 40 = 120 minutes of degraded checkout in six weeks. For context I used the service-level objective (SLO, our reliability target): a 99.9% monthly target allows 0.1% of the month to fail, which is 30 x 24 x 60 x 0.001 = 43.2 minutes in 30 days, and the incidents were well beyond that (120 minutes is about 2.8 times a one-month allowance, but the incidents spanned six weeks, so the fair comparison is the six-week allowance: 42 x 24 x 60 x 0.001 = 60.5 minutes, and 120 minutes is about 2 times that). This counts minutes of degraded checkout, a time-based view; a request-based budget would count only the failed requests, which is fewer, so I presented the figure as a pointer to the size of the problem, not a precise budget burn. I also counted engineer time on the incidents: 3 incidents x 3 engineers x 2 hours = 18 engineer-hours.
2. Compromise, not ultimatum. I proposed one week on the fix (idempotency: making a repeated callback safe, so that when a timeout makes the payment provider resend the callback, the order is processed once instead of twice, which is how double-processing happened) and then the feature released behind a feature flag (a switch to turn it off) to 5% of users first, expanding after a canary window (a fixed observation period) of two days.
3. Handled pushback. The PM feared missing the marketing date. I asked which part of the date was truly fixed; we agreed the PM would tell marketing "limited release on the date, full release three days later". They kept ownership of that message, and I supplied a chart for it.
4. Kept the relationship. I shared a dashboard so the PM could see the numbers themselves.

Result

The fix shipped in the week; the feature went out limited on the date. In the six weeks after, we had no payment-timeout incident. I was careful about that claim: three incidents in six weeks is a rate of 0.5 per week, so six weeks should average 0.5 x 6 = 3 incidents. If incidents arrive at random at that rate, the chance of a stretch with none is e^-3 (the standard formula for zero events when 3 are expected), about 5%. It is good evidence, not proof, so I kept the alert running and reported it that way. We also tracked incident engineer-hours for the next quarter as the return on the fix. Before: 18 engineer-hours in six weeks is 3 per week, or about 39 over a 13-week quarter. After (illustrative): 4 hours over the quarter, so about 35 hours saved against roughly 40 hours (one engineer's week) spent on the fix. That is 5 hours short of break-even on engineer time within one quarter (35 saved against 40 spent), before counting avoided double charges and customer complaints.

What I would do differently

Bring the data before the PM had promised the date to marketing, not after.

Applying the same argument to security, refactoring, infrastructure and analytics work

For security fixes, refactors or infrastructure work that delay a visible release, the argument is the same: show the cost of not doing it in the PM's terms (incidents, customer-facing risk, engineer-hours), offer a smaller or flagged release alongside, and agree how to measure the return afterwards (incident hours before and after, as above). For a technical analytics or data-pipeline item competing with a visible feature, the same pattern applies: name the decision it unblocks and the cost of wrong numbers (I have no separate story for it here, so treat this as the approach, not a second result). Example (illustrative): an unpatched library with a known security flaw becomes "one week to patch, against a customer-data exposure that would trigger breach notifications and a compliance review", paired with an option to patch first and ship the feature behind a flag.

Trade-offs and pitfalls

Do not claim precise outcomes you cannot back up. Do not frame it as engineering versus product: the strongest version shows you gave the PM something to take upstairs.

Direct answer

Do both, in sequence, and say so out loud. Contain the problem today with a small, reversible stopgap, then spend one or two days finding the real cause before committing three to four weeks to a refactor. A hotfix is a quick, narrow patch shipped outside the normal release cycle: it answers "stop the bleeding". A refactor restructures code without changing what it does: it answers "stop it recurring". They are not rivals. The decision is what each buys, what each costs, and in what order.

Deciding what is now and what is later

Test every candidate action with four questions:

1. Does it shrink customer harm today (missing conversion rows lead to wrong decisions on dashboards)?
2. Is it small and reversible (hours of work, easy to switch off)?
3. Does it hide the failure? A retry that silently succeeds can mask a growing problem, so every stopgap ships with an alert.
4. Does the refactor depend on knowing the cause? If nobody has reproduced the failure, a refactor is a bet, not a fix.

Today: add a stopgap, meaning a temporary measure that reduces harm without fixing the cause. It has four parts: an automatic retry that is idempotent (running it twice gives the same result, with no duplicate rows), an automated backfill (re-loading the days a failed run missed), an alert when a day's conversion count is missing or far below its usual range, and a visible "data as of" note on the dashboards.

Next one to two days: a time-boxed root-cause hunt. Pull the logs of the recent failures and look for the common trigger. Typical suspects: an upstream schema change (the source team renamed or retyped a column and the load breaks), late-arriving data (yesterday's events land after the nightly job has already run), a memory limit (the job crashes when a day's data is larger than usual), or a rate limit (a source API refuses calls after a quota). Time-boxed means the hunt has a fixed deadline, here two days; if no cause is found by then, we decide with what we have instead of searching indefinitely.

Then decide. If the cause is narrow, the refactor may shrink to a much smaller fix. If it is structural (the design cannot tolerate late data), commit to the refactor and slice it so the riskiest stage ships first, with value landing in weeks one and two instead of week four. For example, if the cause is late-arriving data: week 1 makes the load step re-process the previous three days each night, which removes the most common failure; week 2 adds a check that rejects a day with too few rows; weeks 3 and 4 restructure the rest. After week 1 most of the benefit is already in production.

Worked example (illustrative numbers)

Suppose the pipeline failed on 6 of the last 30 nights, which is 20%. A refactor of three to four weeks covers 21 to 28 nights, so with no stopgap you would expect roughly 4 to 6 more failing nights (21 x 0.2 = 4.2 and 28 x 0.2 = 5.6), each one a hole in the dashboards until someone notices. With retry, backfill and an alert, each failure becomes a visible gap of hours rather than a silent missing day. Product gets its hotfix today in the safe form. Engineering gets its refactor after a two-day diagnosis, with a start date.

Keeping product and customers informed

• Product: a short written note today covering what we know, what we do not know, what we are doing, the time of the next update, and one plain sentence on the trade ("the stopgap shortens the gaps, it does not remove failures"). Then updates at the promised times, even if the update is "no change". Give the refactor milestones: the diagnosis decision date first, then weekly.
• Customers or dashboard users: a banner on affected dashboards ("conversion data for 14 March is delayed, expected corrected by 10:00"), corrected figures after backfill, and a note when the permanent fix lands.
• Support and customer success: a two-sentence script so they say the same thing customers see on the banner.

Trade-offs and pitfalls

• Stopgaps become permanent. Put "remove the stopgap" into the refactor's definition of done.
• Never promise "this will not happen again" from a hotfix.
• A refactor pitched as all-or-nothing loses the argument. Slice it and show early value.
• What would change my call: if failures produce wrong numbers (not just missing ones), pause downstream use of the data first. If diagnosis finds a one-line cause, skip the refactor and say so.

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 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?"