IN PARTNERSHIP WITH

Who doesn’t like free stuff?

It’s Cybersecurity Awareness Month, and the team at Mastermind started it with a bang—dropping its newest Lead Auditor course centered around the buzzy ISO 42001 standard and AI governance.

This is actually the second installment in the Mastermind Lead Auditor courses, and—against all odds—they continue to offer these programs, including the final exam, totally free.

Who is Mastermind? This is the same certification body that issued the world’s first accredited ISO 42001 certificate back in July 2024 and has continued to blitz the market, having followed up with certifying the likes of Google, Microsoft, Grammarly, Dataminr, Thoropass, Anecdotes, Swimlane, and Sierra—to name a few. They certainly know a thing or two about this ISO standard.

INTRODUCING: GRC COLLECTOR CARDS

Everyone in GRC knows you need to "partner with Product" and "collaborate with Engineering."

Nobody tells you how.

What does a Product Manager actually care about? When do they have capacity for security work? Why can't they "just tell Engineering to prioritise this"? How do you frame GRC so they say yes instead of pushing back?

GRC Collector Cards solves this.

Think of them as technical specifications for the humans you work with. Each card breaks down a key stakeholder: what drives them, when to engage them, how to speak their language, and what triggers resistance.

Over the next 12 weeks, you'll collect the complete set:

• Card 001: Product Manager ⭐ EPIC

• Card 002: Security Engineer

• Card 003: Infrastructure Engineer

• Card 004: CISO

• Card 005: SRE

• Card 006: Account Manager

• Plus more...

This isn't theory. Every card includes real examples from working at a public company, actual conflicts that happen, and practical solutions that work.

By the end, you'll have a complete field guide for building relationships across your entire organisation.

Let's start with the most requested card: The Product Manager.

Gotta audit 'em all. 🎴

Table of Contents

• 🪪 Core Identity

• 💭 What They Actually Care About

• ⚡ How GRC Intersects Their World

• 📅 Key Milestones in Their Calendar

• 🤝 Critical Meetings They Run

• 🌐 Their Key Stakeholders

• 💬 How to Start the Conversation

• 💬 How to Start the Conversation

• 🚩 Red Flags (When They'll Resist GRC)

• 🧠 Their Mindset & Philosophy

• 🗣️ The Language They Speak

• 🎴 Key Takeaways

🪪 Core Identity

Role: Product Manager (PM)
Department: Product
Reports To: VP Product / Head of Product / CPO
Key Metric: Product adoption, feature velocity, customer satisfaction, revenue impact

💭 What They Actually Care About

• Understanding what customers truly need - Not feature requests, but underlying problems. Customers often focus on UI fixes when strategic needs matter more.

• Shipping features that drive business outcomes - Revenue, engagement, retention. Output matters less than results.

• Balancing competing stakeholder demands - Engineering wants time. Sales wants features. Design wants perfection. PM orchestrates.

• Managing without authority - Responsible for outcomes but can't command anyone. Engineers report to Engineering Managers. (See our Human API newsletter)

• Making decisions under uncertainty - Perfect data rarely exists. Balance analysis with intuition.

• Building trust with Engineering - This relationship makes or breaks execution.

⚡ How GRC Intersects Their World

GRC enters a Product Manager's world when security, compliance, or risk requirements affect what gets built, when it ships, or how it performs. For most PMs, GRC feels like an external constraint rather than an enabling partner.

When GRC Becomes Their Problem

Scenario 1: Audit needs vs launch deadlines
Needed compliance data extraction three weeks before a major feature launch. PM's response: "I can't help. You need to figure it out." Trying to work around him through engineers backfired - they deferred to PM authority. Built a custom workflow instead.
Lesson: When PMs are in launch mode, they have zero flexibility. Don't depend on PM capacity during critical windows.

Scenario 2: Security blocker surfacing too late
Major feature ready for launch. Security review two weeks before GA found critical vulnerabilities. PM wasn't looped into security during development. Faced impossible choice: delay (break commitments) or ship with compensating controls. Escalated to CEO.
Lesson: Security reviews mid-flight create no-win scenarios. Embed security in planning, not at launch.

Scenario 3: Documentation lag in fast-moving features
Enterprise buyer asks detailed security questions about new AI feature. Documentation doesn't exist yet - shipped last week, docs lag by weeks. Loop in PM to answer questions, disrupting their current work. Happens repeatedly.
Lesson: Fast product cycles need documentation workflows that keep pace with shipping velocity.

Common Conflicts

• Mid-sprint security requirements appearing without warning - PMs plan sprints weeks in advance with Engineering. When GRC shows up mid-sprint saying "we need this security control now," it derails commitments to stakeholders, damages PM credibility with Engineering, and creates the perception that compliance blocks velocity. The PM then has to explain to Sales why their promised feature is delayed.

• GRC underestimating technical complexity - "Just change these two lines of code" often means re-architecting entire systems, database migrations, API changes, and testing across environments. PMs understand that what sounds simple to non-engineers frequently involves coordination with multiple teams. When GRC minimises complexity, it erodes trust and makes future collaboration harder. (Related: See our Strong Workflow, Dumb AI newsletter on understanding implementation reality)

• Misunderstanding PM authority - PMs are responsible for roadmap outcomes but have zero direct authority over Engineering. Engineers report to Engineering Managers. When GRC treats PMs as if they can simply "tell engineering to do this," it reveals a fundamental misunderstanding of how product teams work. PMs must influence through business cases and collaboration.

• Compliance requirements arriving after roadmaps are locked - PMs participate in quarterly planning cycles where priorities get locked for the next 3-6 months. When GRC asks for work outside this cycle, there's literally no capacity unless something else gets cut. The best time to influence the roadmap was last quarter's planning, not mid-execution.

• Framing security as pure cost, not business enabler - When GRC says "we need to implement this control," PMs hear "spend engineering time on something that doesn't move metrics." When GRC says "this control unblocks enterprise sales worth $2M in pipeline," PMs suddenly have a business case they can defend to stakeholders.

📅 Key Milestones in Their Calendar

• Q1 (January-March): Annual planning complete, roadmaps locked for the year. OKR setting happens. Early execution on Q1 deliverables. Post-holiday momentum building.

  • GRC insight: Too late to influence this year's roadmap. If you need something urgently, you'll need to make a case for cutting existing work. Focus energy on Q2 planning.

• Q2 (April-June): Feature delivery sprint. Iteration based on Q1 launches and user feedback. Mid-year planning begins for H2 priorities. PMs are balancing execution with forward planning.

  • GRC insight: This is your window to discuss H2 needs. It's still possible to influence Q3 roadmap if you engage early in the quarter.

• Q3 (July-September): Mid-year course corrections happen. Preparing H2 initiatives. Some companies start next year's planning here. Often quieter due to summer holidays affecting capacity.

  • GRC insight: Last realistic chance to get into Q4 roadmap. More importantly, start conversations about next year's security needs now.

• Q4 (October-December): Year-end feature pushes to hit annual goals. 2026 strategy and roadmap planning in full swing. PMs reflecting on wins and losses whilst planning ahead. High-stress period with competing demands.

  • GRC insight: Roadmaps for next year are getting locked. If you need something in 2026, speak up NOW. Don't ask for Q4 work unless genuinely urgent and you can explain what gets cut.

IN PARTNERSHIP WITH

Screenshots are a spooky business

Can you tell if a screenshot is a trick or a treat that actually meets the requirements? Play now to see how you stack up against your peers.

And when you’re ready to replace screenshots with data, you know who to call.

🤝 Critical Meetings They Run

Weekly: Sprint planning (setting priorities for 2-week sprint), product review with Engineering (checking progress, unblocking), stakeholder syncs (keeping Sales/Marketing/Customer Success aligned), sometimes engineering standups

Monthly: Product review with leadership (demonstrating progress to VP/CPO), roadmap refinement (adjusting plans based on learnings), customer feedback review sessions (synthesising research and support tickets)

Quarterly: OKR reviews (assessing goal achievement and setting next quarter), roadmap planning (setting priorities for next 3-6 months), strategy sessions with C-suite (aligning product direction with business strategy)

GRC insight: Get invited to roadmap planning sessions and OKR reviews. That's where priorities actually get set. Sprint planning is too late because decisions are already made.

🌐 Their Key Stakeholders

Upstream (who influences them): VP Product, CEO, sometimes Board members. These people set strategy and approve major initiatives.

Downstream (who they influence): Engineering teams (who build the product), Design (who creates the experience), Product Marketing (who positions and launches features).

Peers (who they collaborate with): Sales, Marketing, Customer Success, Data/Analytics, Legal, Finance.

Critical note: PMs influence Engineering but engineers report to Engineering Managers, not PMs. This is why saying "just tell engineering to do it" doesn't work. The PM-EM relationship is the real power dynamic to understand.

🏆 What Success Looks Like to Them

Short-term (this quarter)

Ship roadmap on time with high quality. No major incidents. User satisfaction scores remain strong or improve. Stakeholders (Sales, Marketing, Engineering) aligned and happy. Zero surprises that damage credibility with Engineering or leadership.

Medium-term (this year)

Product adoption metrics hit or exceed targets (DAU/MAU, feature usage, engagement). Key features drive measurable revenue or reduce churn. Team velocity improves quarter over quarter. Relationship with Engineering Manager is strong and collaborative, making future planning easier. Recognition from leadership for driving business outcomes.

Long-term (career)

Product becomes company's growth engine and competitive advantage. Promoted to Senior PM, Lead PM, or Director of Product. Known internally for shipping products customers love. Built strong cross-functional relationships that make execution smooth. Developed reputation for good judgment under uncertainty. Maybe transition to VP Product or start own company eventually.

💬 How to Start the Conversation

Opening That Works

"I want to help you ship faster whilst staying compliant. Can we embed security requirements into your planning process so they don't become mid-sprint surprises? I've got 15 minutes to understand your roadmap and identify where GRC can add value instead of creating blockers."

Frame GRC As

• Product enabler preventing future blockers: "Building this authentication logging now means enterprise customers don't block sales in Q3."

• Competitive advantage for enterprise deals: "This SOC 2 control is what unlocks Fortune 500 buyers. Sales says it's worth $2M in pipeline."

• Technical debt prevention: "Implementing this correctly now saves re-architecting it under audit pressure later, which always costs 3x more."

• Trust signal accelerating sales cycles: "Customers who see our security posture close 40% faster according to Sales data."

Avoid Saying

• ❌ "We need to implement controls before you can launch" (creates launch blocker perception)

• ❌ "This is a compliance requirement" (without business context - sounds like bureaucracy)

• ❌ "Security says no" (without offering alternatives or explaining trade-offs)

• ❌ "This is easy, just..." (minimising complexity destroys credibility with PMs who know better)

🚩 Red Flags (When They'll Resist GRC)

Trigger #1: Surprise Requirements

Situation: GRC identifies a security gap during an audit and tells the PM "we need this fixed by end of quarter" without prior discussion. PM has already committed capacity to features that Sales depends on for quota.

How to defuse: Participate in quarterly planning cycles 6-8 weeks before quarters start. Give PMs visibility into upcoming GRC needs so they can factor them into capacity planning. If something is genuinely urgent, explain the risk/impact in business terms ("this vulnerability is actively exploited in the wild") and offer to help reprioritise, which means explaining to Sales why their feature is delayed and getting their buy-in.

Trigger #2: Perceived Blockers Without Alternatives

Situation: PM proposes a feature. GRC says "we can't do it that way for security reasons" but offers no alternative approach. PM feels blocked without recourse and loses trust in GRC as a partner.

How to defuse: Always come with options, never just "no." "We can't do X because of Y risk, but here are three alternative approaches with different trade-offs. Option A is most secure but takes 2 weeks. Option B is faster but has these limitations. Which trade-off makes sense for your timeline?" Make GRC the team that enables smart solutions, not the team that stops progress.

Trigger #3: Misunderstanding PM's Lack of Authority

Situation: GRC asks PM to "make Engineering prioritise this security work." PM explains they can't command Engineering. GRC interprets this as PM not caring about security rather than structural reality.

How to defuse: Understand that PMs influence through business cases, not authority. Help the PM build the case: customer impact, revenue implications, technical debt costs, competitive positioning. Then present it jointly to Engineering Manager, who actually controls engineering capacity. Respect the PM-EM partnership rather than trying to go around it.

🧠 Their Mindset & Philosophy

Core Beliefs

• Lead through influence, not authority - PMs succeed by building trust and making compelling cases, not commanding teams

• Customer obsession drives everything - Understanding real user needs (not feature requests) is the foundation of good product work

• Data informs decisions but doesn't make them - Quantitative analysis is necessary but insufficient. Context, strategy, and judgment matter

• Speed matters, but sustainable speed matters more - Shipping fast builds momentum, but shipping broken features destroys trust

• Clear communication prevents misalignment - Most product failures come from unclear goals, not technical problems

• Balance business, technical, and user needs - Good PMs are translators between these three worlds

Daily Frustrations

• Ambiguous requirements from stakeholders - "Make it better" or "our customers want this" without specifics

• Engineering pushing back without explaining why - "That's too hard" without technical context prevents finding solutions

• Sales making promises PM didn't commit to - Customer says "your salesperson told me this ships next month" when it's not even on roadmap

• Leadership changing strategy mid-quarter - Roadmap built around one direction, then sudden pivot requires re-planning everything

• Compliance appearing as last-minute blocker - Feature ready to ship, then "wait, we need security review" delays launch

• Stakeholders treating PM like project manager - "Just build what I tell you" misses PM's role in discovering the right thing to build

What Motivates Them

• Seeing users love what they built - Positive customer feedback, high adoption rates, users voluntarily sharing the product

• Shipping features that move business metrics - Revenue up, churn down, engagement increasing. Quantifiable impact on company success

• Building strong relationships with Engineering - When Engineering trusts PM's judgment and PM respects Engineering's expertise, magic happens

• Clear autonomy and ownership - Freedom to make decisions within their domain without constant approval cycles

• Recognition for driving outcomes, not output - Being celebrated for business results, not just number of features shipped

🗣️ The Language They Speak

Phrases They Use Daily

• "How does this impact our velocity?" (Will this slow down feature delivery?)

• "What's the user benefit?" (Why should customers care about this?)

• "Can we ship an MVP and iterate?" (Start small, learn, improve vs build everything at once)

• "What's the business impact?" (How does this affect revenue, retention, acquisition?)

• "How does this enable enterprise sales?" (Does this unlock deals with bigger customers?)

• "Let me check with Engineering" (I need to consult the people who actually build this before committing)

Translation Guide (GRC → PM Language)

❌ Instead of: "We need to implement control AC-2.17 for SOC 2 compliance"
✅ Say: "This authentication logging feature is blocking three enterprise deals worth £500K because buyers are asking for it in security questionnaires. Sales says if we ship this in Q2, those deals close by end of quarter."

❌ Instead of: "This is a critical security vulnerability that needs immediate remediation"
✅ Say: "This vulnerability is exploitable in production and could lead to a data breach affecting 10,000 users, which triggers GDPR notification requirements. We've seen similar vulnerabilities exploited at [competitor] last month. Engineering estimates 3 days to fix properly."

❌ Instead of: "Audit found this gap and we need it closed"
✅ Say: "Auditors flagged this because enterprise customers require it for contract renewals. Customer Success says three renewals worth £300K are pending security questionnaire completion. Building this control closes the audit finding and unblocks those renewals."

❌ Instead of: "We need logging for compliance"
✅ Say: "Without proper logging, we can't detect incidents or prove to customers how we responded. This is the #1 question in enterprise security reviews. Building comprehensive logging now prevents us from rushing it later under audit pressure, which always costs 3x more."

❌ Instead of: "Security review needed before launch"
✅ Say: "I need 30 minutes async to review the architecture against common vulnerabilities. I'll provide feedback by Friday so we stay on track for Monday launch. If I find anything blocking, I'll bring solutions, not just problems."

🎴 Key Takeaways

• PMs have responsibility but zero authority over Engineering - influence them through business cases, not commands

• Engage during quarterly planning (6-8 weeks before quarters start), never mid-sprint when capacity is locked

• Frame GRC as product enabler that unblocks enterprise sales, not compliance burden that slows shipping

That’s all for this week’s issue, folks!

If you enjoyed it, you might also enjoy:

• My spicier takes on LinkedIn [/in/ayoubfandi]

• Listening to the GRC Engineer Podcast 

  • Spotify

  • Youtube

  • Apple Podcasts

See you next week!