The security team and the engineering team are usually running two programs with the same deadline and no shared plan. The security team is tracking vulnerabilities, patch windows, and audit findings. The engineering team is tracking features, dependencies, and launch criteria. When those two programs collide at the end, everyone is surprised, which means nobody was managing the intersection.
That intersection is the TPM's job. Not to own security, but to own the integration of security requirements into the engineering timeline before the requirements become blockers.
The specific thing this requires is early and repeated conversations with the security team about what is gating the launch. Not whether there are findings, there are always findings, but which findings are blocking and what the remediation timeline is. Those become fixed points in the engineering schedule, not surprises at the end.
At Intuit, the compliance program included SOC2 audit readiness. The audit timeline was fixed. The engineering work to support it was not. I built a workback from the audit date that showed engineering exactly when their controls work had to be complete. It was not a comfortable conversation. The alternative, engineering finding out six weeks before the audit that they had three months of work left, would have been worse.
Security programs delivered on time are almost always the result of early integration. Security programs that slip are almost always the result of treating security as a parallel track until it isn't.