Product partnership: options with costs
What it is
Product partnership is the working relationship between an engineering lead and a product manager, and it has one defining behaviour: in discovery, you supply options with costs, not verdicts.
VERDICT "That'll take six weeks."
"That's not possible."
"We'd need to rewrite the pricing service first."
OPTIONS WITH COSTS
"A is two weeks and covers the top three merchant
types. B is six weeks, covers everything, and makes
the multi-currency work in Q3 nearly free because
it lands the rate-lookup abstraction. I'd pick B if
multi-currency is still on the roadmap, A if it
isn't. Which is it?"
The second answer contains the same engineering judgment, and it hands the decision to the person whose decision it is while making your reasoning inspectable.
The other half of the job: own the non-functional requirements, because PMs almost never write latency, availability or cost targets, and if you do not, nobody will.
What this is confused with: being accommodating. A partner who says yes to everything is not a partner, they are a queue. Options with costs is a form of pushback, and a much more effective one than refusal, because it makes the cost visible rather than making you the obstacle.
Also confused: protecting the team. A lead who protects the team by being obstructive wins the individual battle and loses the partnership, and the PM starts routing around them, at which point the team is protected from nothing.
The problem it solves
The verdict-based relationship degrades in a predictable sequence.
Week 1 PM: "can we ship X by the 14th?"
Lead: "no, that's six weeks of work."
Week 3 PM asks a different engineer, who says "probably doable."
Week 5 PM commits to a customer without asking.
Week 7 Lead escalates about process. PM's manager hears it as a
complaint about their PM.
Week 9 the lead is invited to fewer discovery conversations,
because they are "the person who says no", and now
hears about commitments after they are made.
Nobody behaved unreasonably at any single step. The first
answer contained no information the PM could use, so they went
looking for information elsewhere.
"No, six weeks" is a true statement that is useless, because it does not tell the PM what a shorter version would look like, what the six weeks buys, or what would have to be true for the date to work. Every one of those is something the lead knows and the PM does not.
And the non-functional gap:
A feature spec, as written:
"Merchants can see a live view of their orders."
Not written, and nobody will write it unless the lead does:
- how live is live? 1 second? 30 seconds? 5 minutes?
- what happens when the merchant has 200,000 orders?
- what is the availability target, and what does degraded look
like?
- what is the cost ceiling? A 1-second refresh for 40,000
merchants is a materially different system from a 30-second
one.
These get decided anyway: by whoever writes the code, implicitly,
under deadline pressure, and discovered in production.
Mechanics
Constructing an options set
Three options is the useful number, and they should differ in kind rather than in size.
Bad options (all the same option at different sizes):
A: 4 weeks B: 6 weeks C: 8 weeks
Good options (different shapes, different costs, different
consequences):
A NARROW: the top 3 merchant types only. 2 weeks. Covers 71%
of order volume. Leaves the long tail on the old flow, which
we would keep running.
Risk: two flows to maintain until the tail is migrated.
B FULL: all merchant types. 6 weeks. Also lands the
rate-lookup abstraction, which makes the Q3 multi-currency
work roughly 3 weeks cheaper.
Risk: the 14th is not achievable.
C MANUAL-ASSIST: A, plus a support tool so the ops team can
handle the tail by hand. 3 weeks. Covers 100% of merchants
from the merchant's point of view.
Risk: ~4 hours a week of ops time until we do B.
Cost: ~$X/month of ops capacity, which is a real number
someone should decide to spend.
My recommendation: C if the 14th is a hard external commitment,
B if it is a preference, because B's Q3 saving exceeds C's
difference within a quarter.
Four properties make an options set useful:
1. EACH OPTION IS ACTUALLY SHIPPABLE. An option that requires a
later phase to be valuable is not an option, it is a
milestone.
2. THE COST IS IN THE PM'S UNITS where possible: coverage,
merchants, volume, revenue exposure, ops hours. Weeks alone
is an engineering unit.
3. THE CONSEQUENCE IS NAMED, including the ones you would rather
not mention. "Two flows to maintain" is the cost of A, and
omitting it makes A win a decision it should not.
4. YOU RECOMMEND ONE, with the condition attached. A set of
options with no recommendation is abdication wearing the
costume of neutrality.
The recommendation with a condition is the highest-value sentence: "I'd pick B if multi-currency is still on the roadmap, A if it isn't" tells the PM exactly what fact decides it, and that fact is usually one they have and you do not.
Owning the non-functional requirements
Write them into the spec yourself, as numbers, before the work
starts:
LATENCY p50 and p99, at the user-visible boundary
FRESHNESS how stale may the data be
AVAILABILITY the target, and what degraded mode looks like
SCALE the largest realistic case, not the median
COST a ceiling, in currency per month or per unit
RETENTION how long is the data kept, which is also a
compliance question
ACCESS who may see it, which is where most rework comes
from
For each, ask the PM ONE question that produces the number:
"How stale can this be before a merchant would call support?"
-> gets you a freshness target from someone who knows the
customer, which is far better than you guessing.
"What is the biggest merchant we need this to work for?"
-> gets you the scale case. The answer is often startling and
always cheaper to hear now.
Translating each into product language is what makes it survive prioritisation:
Engineering framing Product framing
------------------------------------------------------------
"we need to add caching" "this cuts checkout p99 by 300ms,
and our own data says every 100ms
there has historically moved
conversion by X"
"the pipeline needs "right now a merchant sees yesterday's
rework" numbers until 10am, which is the
second-most-common support ticket"
"we should fix the "a bad deploy currently takes 25
deploy process" minutes to roll back, so a
checkout-breaking bug costs us
roughly $Y of orders"
The pattern: state the user-visible or money consequence, and use the company's own historical numbers rather than industry claims. "Amazon found 100ms costs 1 percent of sales" is a citation about Amazon; "our last three latency regressions each moved conversion by this much" is an argument about you.
Knowing the product
A lead who cannot name the product's north star metric looks
disconnected, and reasonably so.
Know, and be able to say without looking:
- the north star metric and its current value
- the two or three inputs that move it
- which of your systems touches which input
- the current quarter's product goal, in the PM's words
- the top 3 sources of support tickets
The last one is the most under-used. Support tickets are a
free, continuously updated list of what your systems do badly,
expressed in customer language, and almost no engineering lead
reads them.
Pushing back well
NEVER: "that's not possible"
(it is; you mean it is expensive, and saying the wrong
word costs you credibility when something genuinely is
impossible)
INSTEAD, three shapes depending on what is wrong:
TOO MUCH FOR THE TIME
"Here is what fits in that window, and here is what it leaves
out. If the cut is unacceptable, the date moves. Which do you
want to change?"
-> the scope/date/quality triangle, offered as a choice rather
than asserted as a law.
WRONG PROBLEM
"Before we build this, the thing merchants actually complain
about is X, and I think this solves Y. Can we check?"
-> only credible if you read the support tickets, which is why
that habit matters.
MISSING A CONSTRAINT
"This works until a merchant has more than about 50,000
orders, and 40 of them do. We can build it as specified and
it will break for our biggest customers, or we can spend two
extra weeks. Your call, and I'd spend the two weeks."
-> the non-functional requirement, surfaced as a decision.
Always offer at least two acceptable outcomes. A pushback with one acceptable outcome is a refusal, and refusals are what get leads routed around.
The process conversation, separated
When a PM commits to a date without asking, there are two problems, and solving only the immediate one guarantees a repeat.
THE DATE: solved with options and costs, immediately, in front of
whoever needs it. Do not litigate the process here.
THE PROCESS: a separate, calm, private conversation, framed as
helping them rather than correcting them.
"I want to make sure you can commit to dates confidently. For
that you need me in the room before the number goes out.
What would make that easy for you?"
Framing it as making them more credible works far better than
"don't do that again", which produces defensiveness and no
change.
IF IT REPEATS: escalate with data, not grievance. The specific
commitments, what they cost in engineer-weeks, and a proposed
working agreement. And bring your own manager as a peer
conversation with theirs, not as a complaint.
A worked example: a lead who was being routed around
A payments team. The lead had a reputation, stated in their own performance feedback, as "protective of the team" and "sometimes a blocker." Discovery conversations were happening without them.
What was actually happening, from four months of examples:
Ask 1: "Can we support instalment plans by end of quarter?"
Answer given: "Not without rewriting the settlement service."
What the PM did: nothing for three weeks, then scoped a
narrower version with a different engineer.
Ask 2: "Can merchants see live order status?"
Answer given: "Sure, that's easy."
What happened: built with a 5-second poll, no scale
requirement written down, and it fell over for the four
largest merchants in week two.
Ask 3: "Can we ship the refunds change by the 14th?"
Answer given: "That's six weeks of work."
What the PM did: committed to the 14th anyway, having heard
from someone else that a partial version was possible.
Three different failure modes: a verdict with no options, a yes with no non-functional requirements, and a refusal that was routed around.
The change, applied over one quarter:
Ask 1, re-answered in the new form:
"Three options.
A. Instalments for the two card processors that already support
it natively. 3 weeks. Covers about 62% of instalment-eligible
volume based on last quarter. The other processors show
'not available', which is a product decision you should
make rather than me.
B. Full coverage, which needs the settlement service to handle
multi-leg transactions. 9 weeks. It also removes the
reconciliation workaround that costs finance about 6 hours
a month, so finance would get that back.
C. A, plus a manual settlement process for the remaining
processors, run by ops. 4 weeks. Covers 100% from the
merchant's view, costs ops roughly 5 hours a week, and I
would want a hard expiry on it, because manual settlement
processes never get removed on their own.
I'd pick A if the goal is learning whether merchants want
instalments at all, and B if we already know they do and this
is about coverage. Which is it?"
The PM's answer took 30 seconds: it was a learning goal. They
shipped A.
The 30-second answer is the point. The original verdict cost three weeks of stalled discovery and produced a worse plan; the options set resolved it in one conversation because it asked the PM a question only they could answer.
Ask 2, re-answered with non-functional requirements written first:
The lead wrote five lines into the spec before estimating:
Freshness: how stale can order status be before a merchant
calls support? -> PM's answer: "under a minute
is fine, they're not
watching it continuously"
Scale: largest merchant? -> 212,000 open orders
Availability: what does
degraded look like? -> "showing a slightly stale
number is fine; showing an
error is not"
Cost ceiling? -> nobody had thought about it;
agreed at $2,000/month
Access: who can see it? -> merchant's own orders only,
plus support with an audit
log
The 5-second poll implied by "live" would have been:
40,000 merchants x 12 polls/min = 480,000 req/min
A 45-second refresh with server-push for changes:
~2,000 req/min plus a change stream.
Same product outcome. Roughly two orders of magnitude of
infrastructure difference, decided by one question to the PM
about what "live" meant.
"How stale can this be before a merchant calls support" is a question the PM can answer in five seconds and the engineer cannot answer at all, which is the general shape of a good non-functional question.
Ask 3, and the process conversation:
The date conversation, in the room, immediately:
"By the 14th we can ship refunds for single-item orders, which
is 78% of refund requests. Multi-item and partial refunds
would follow in three weeks. Alternatively everything by the
5th of next month. If the 14th is a customer commitment
that's already made, tell me and we'll do the first one."
It was a customer commitment already made. They shipped the
78% version, and the customer was satisfied because their
volume was single-item.
The process conversation, two days later, privately:
"That worked out, and I want to make it easier next time. If
I'm in the room before a date goes to a customer, I can tell
you what fits, which is usually more than you'd assume. What
would make it easy to loop me in?"
The PM's honest answer: "I didn't because I expected you to say
no, and I needed to give them something."
That sentence is the actual finding, and it is a diagnosis of
the lead's behaviour rather than the PM's.
"I expected you to say no" is the whole page in five words, and it was only available because the conversation was framed as help rather than correction.
Measured over the following two quarters:
before after
lead present in discovery
conversations ~40% ~95%
commitments made without
engineering input 4/quarter 0
NFRs written before estimate 0 of 11 11 of 13
rework attributable to a
missed NFR 3 features 0
features shipped as a narrower
option than originally asked 0 5
Five features shipped as a narrower option is the number that mattered to the PM, because each one arrived earlier than the full version would have, and in three cases the full version turned out not to be needed.
The reputation change, and the honest part:
The next round of feedback described the lead as "the person who
finds the version we can actually ship."
The lead's own read, recorded: nothing about their engineering
judgment changed. The same constraints were true before. What
changed was that the judgment arrived in a form the PM could
act on, and that they asked the PM questions instead of
answering questions the PM had not asked.
Production evidence
Marty Cagan's product-discovery writing (Inspired, and the Silicon Valley Product Group materials) argues explicitly for engineers participating in discovery rather than receiving specs, with the stated reason that engineers are the largest source of ideas about what is newly possible, and that the cost of an approach is information only they have.
The "options with costs" pattern is the practical form of the same argument, and it appears in engineering-leadership writing as the alternative to feasibility verdicts, on the grounds that a verdict transmits a conclusion while withholding the inputs.
Service level objectives as a product artifact is the position taken in Google's SRE materials: availability and latency targets are product decisions with cost consequences, and the SRE practice of negotiating them with product owners exists because leaving them implicit means they are set by accident.
The scope-date-quality triangle and the practice of cutting scope rather than quality is standard delivery guidance, and the specific form that works with a product partner is offering the choice rather than asserting the constraint.
Support-ticket analysis as a product input is standard in customer-experience practice and unusual in engineering leadership, which is what makes it a differentiator: the tickets are a continuously updated, customer-worded list of what your systems do badly.
Amazon's widely cited latency-to-revenue findings and Google's comparable published results are the reason latency-to-conversion translation is credible as a category, and the stronger version of the argument uses your own historical numbers rather than theirs.
The debate
Is "options with costs" just avoiding a decision? No, and the distinguishing feature is the recommendation with a condition attached. A set of options with no recommendation is abdication; a set with "I'd pick B if multi-currency is still on the roadmap" is engineering judgment plus the explicit statement of which fact decides it, and that fact usually belongs to the PM.
Should engineers write non-functional requirements, or should PMs? In principle PMs; in practice nobody does unless the lead does. The productive version is that the lead writes the question and the PM supplies the number: "how stale can this be before a merchant calls support" is answerable by the PM in seconds and not answerable by the engineer at all.
Is it the lead's job to know the north star metric? Yes, and a lead who cannot name it will be treated as a service function, reasonably. The counter-argument, that engineers should be shielded from business context to focus, has it backwards: without it, every prioritisation argument the lead makes is in engineering units, which lose.
Should you ever say no? Yes, for things that are genuinely unsafe, illegal or impossible, and sparingly enough that it retains meaning. Saying "not possible" when you mean "expensive" spends the word, and then the one time something truly is impossible you have no way to say so.
Is protecting the team from the PM part of the job? Protecting focus is; being the obstacle is not. A lead who blocks is routed around, and a team whose lead is routed around is not protected, it is uninformed. The version that works is absorbing the negotiation rather than the refusal.
Does the process conversation actually work? When it is separated from the immediate decision and framed as making the other person more credible, usually. When it is held in the same conversation as the date, it reads as blame and produces defensiveness, which is why the separation is the mechanism rather than the wording.
Follow-up Q&A
"What does 'options with costs' look like concretely?"
Three options that differ in kind rather than in size, each independently shippable, each with its cost expressed in the PM's units and its consequence named including the inconvenient ones, plus your recommendation with the condition that decides it. "A covers the top three merchant types in two weeks and 71 percent of volume, but leaves two flows to maintain. B is six weeks, covers everything, and makes the Q3 multi-currency work three weeks cheaper. C is A plus an ops tool, three weeks, 100 percent coverage from the merchant's view at about four hours a week of ops time. I'd pick B if multi-currency is still on the roadmap, A if it isn't." The last sentence tells the PM exactly which fact decides it, and that fact is usually theirs.
"Why is 'that'll take six weeks' a bad answer?"
Because it is true and contains nothing the PM can act on. It does not say what a shorter version would look like, what the six weeks buys, or what would have to change for the date to work, and all three are things the lead knows and the PM does not. The observable consequence is that the PM goes looking for that information elsewhere, gets a less-informed answer from someone else, and the lead stops being invited to discovery. In one case a PM said plainly: "I didn't loop you in because I expected you to say no, and I needed to give them something."
"Who owns the non-functional requirements?"
Nominally the PM, actually nobody unless the lead writes them, and they get decided anyway by whoever writes the code under deadline pressure. The workable division is that the lead writes the question and the PM supplies the number: how stale can this be before a merchant calls support, what is the biggest merchant this must work for, what does degraded look like, what is the cost ceiling, who may see it. In one case asking what "live" meant produced "under a minute is fine," which was the difference between 480,000 requests a minute and about 2,000.
"How do you translate platform work into product language?"
State the user-visible or money consequence, using your own historical numbers rather than industry claims. Not "we need caching" but "this cuts checkout p99 by 300 milliseconds, and our own data says every 100 milliseconds there has moved conversion by X." Not "the deploy process needs work" but "a checkout-breaking bug currently takes 25 minutes to roll back, which costs roughly this much in orders." The company's own numbers are an argument about you; a citation about Amazon is an argument about Amazon.
"How do you push back without becoming the person who says no?"
Always offer at least two acceptable outcomes, because a pushback with one is a refusal. Depending on what is wrong: for too much in the time, "here is what fits and here is what it leaves out; if the cut is unacceptable the date moves, which do you want to change." For the wrong problem, "the thing merchants actually complain about is X and this solves Y, can we check," which is only credible if you read the support tickets. For a missing constraint, "this breaks above 50,000 orders and 40 merchants are above that; we can ship as specified and break for our biggest customers, or spend two extra weeks, and I'd spend them."
"A PM commits to a date without asking you. What do you do?"
Separate the two problems, because solving only the immediate one guarantees a repeat. The date gets options and costs, immediately, in front of whoever needs it, with no process litigation. The process gets a separate private conversation days later, framed as making them more credible rather than correcting them: "if I'm in the room before a date goes out, I can tell you what fits, which is usually more than you'd assume; what would make it easy to loop me in?" If it repeats after that, escalate with data rather than grievance: the specific commitments, what they cost in engineer-weeks, and a proposed working agreement, brought as a peer conversation between managers rather than a complaint.
Common misconceptions
"Giving options is indecisive." Options without a recommendation are. Options with a recommendation and the condition that decides it are engineering judgment made inspectable.
"Saying no protects the team." It gets you routed around, after which the team is not protected, it is uninformed about commitments already made.
"The PM owns the requirements." They own the functional ones. Latency, freshness, scale, availability and cost get decided by whoever writes the code unless the lead writes them down first.
"'Not possible' is a strong position." It is usually the wrong word for "expensive," and using it that way spends the credibility you need for the rare case that is genuinely impossible.
"Business context distracts engineers." Without it every prioritisation argument you make is in engineering units, and engineering units lose.
"Fix the process in the moment." Litigating the process during the date conversation reads as blame. Separating them by a couple of days is the mechanism, not the wording.
Interview delivery note
Say this verbatim: "My job in discovery is to supply options with costs, not verdicts. 'Six weeks' is true and useless; three shippable options with the cost in the PM's units, the consequences named, and a recommendation with the condition attached, lets them decide with my judgment included rather than going to find a less-informed answer elsewhere." It names the behaviour and the failure it prevents.
The senior-versus-staff separator is owning the non-functional requirements by asking the PM the question rather than guessing the number. A senior engineer estimates the feature as specified. A staff engineer writes freshness, scale, availability, cost and access into the spec before estimating, and asks one question per line that only the PM can answer, such as "how stale can this be before a merchant calls support." In one case that single question was the difference between 480,000 requests a minute and 2,000, for the same product outcome.
The second signal is separating the date from the process. Handling the immediate commitment with options in the room, then holding the process conversation privately days later framed as making the PM more credible, is what produced the honest answer "I didn't loop you in because I expected you to say no." That sentence is a diagnosis of the lead, and you only get it if the conversation is not framed as a correction.
Further reading
- Marty Cagan, Inspired, and the Silicon Valley Product Group materials on engineers in discovery.
- Google's SRE Book on service level objectives as negotiated product decisions with cost consequences.
- Your own product's support-ticket taxonomy, which is the cheapest continuously updated list of what your systems do badly.
- The a PM promises a date and a director wants a date you cannot commit to pages, which are the scenario forms of this page.