Product managers weigh features against cost and risk every week. Security fits that frame if you describe it as a risk to customers or revenue, with options and costs, instead of as a rule to follow. These are the questions that come up most, with answers an engineering manager can reuse.
Why does security work take so long when the change looks small?
The visible change is often small. The time goes into finding every place the problem exists, testing that nothing broke, and rolling it out safely. A one line fix to how passwords are stored may need a migration plan for every existing account. Ask the engineer for the three parts: find, change, prove. That makes the effort legible. See how to estimate security work in story points.
What do we get if we do it?
Name the outcome in business terms. Fewer ways for a customer's data to be exposed, shorter and calmer responses to customer security questionnaires, fewer emergency weekends. Avoid promising that an attack will never happen. Nobody can promise that, and PMs notice.
Can we ship now and fix it later?
Sometimes, yes. The right answer depends on exposure and on whether the fix gets harder later. If you do ship, write down the risk, the owner and an expiry date. A template is in shipping with a known risk.
How likely is it really?
Be honest that likelihood is a judgment. Give a coarse view such as low, medium or high, with the reasoning. Mention what you know: is the feature public, is the weakness easy to find, is there a known exploit? If you do not know, say so and say how you would find out.
Why can't security just approve things faster?
Often the delay is the late arrival of the question. A review requested before build is quick and cheap. The same review after launch dates have been promised is slow and expensive. Agree a tier rule for when to ask, as in when engineers should ask for a security review.
What does a compliance requirement change?
It adds a date and an evidence need. The requirement may fix what must exist, but not always how. Ask whether there is a lighter way to meet the same control. Do not assume the heaviest interpretation is the only one, and do not assume the lightest will satisfy an auditor either.
How do I weigh this against a feature?
Put both on the same page with the same units: cost in sprint capacity, benefit in revenue or risk avoided, and what slips. If you cannot estimate the benefit of a security item, estimate the cost of the incident it prevents and be explicit that it is a rough guess.
What should an engineering manager bring to the conversation?
- One or two options, not a lecture.
- A cost for each option, even if rough.
- What happens if we do nothing, in plain words.
- A recommendation and a deadline for the decision.
This respects the PM's job and keeps you from sounding like an obstacle.
Quick check
What is the single best way to explain a security risk to a PM?
Describe who is harmed and how in one sentence, then offer two options with costs. Skip jargon and skip fear.
Should I promise that a fix will prevent breaches?
No. Say what the fix removes or limits, and what it does not cover. Overpromising costs you credibility the next time.
Last reviewed: 19 October 2026.
