McPhail Security | Partner-Craft POV | Internal Use Only — Not shared with partner or vendor
[Field: Partner name] | [Field: Vendor name] | [Field: Archetype]
Section 1 — Purpose of This Guide
This guide tells you how to run each session: what to ask, what to listen for, how to handle common dynamics, and what a good output looks like before you leave the room.
It is organized in two parts. The core content covers principles, session structure, and dynamics that apply to every engagement regardless of archetype. The archetype variants at the end replace the core discussion block for the minutes 10–40 section of each session.
Section 2 — Core Facilitation Principles
These apply to every session in every engagement. Return to them if something is not working.
- Your job is to draw out, not to present. The moment you start presenting, you have lost the room
- Silence is productive. After a hard question, let it sit. Count to ten before you speak. The partner will fill it
- The vendor’s enthusiasm is not the agenda. Redirect early and redirect explicitly if the vendor is driving
- If the partner is hedging, name it. Say: “It sounds like there is something here you are not sure is safe to say.” Then wait
- Record outputs in real time, visible to the room. A shared screen or whiteboard builds trust and keeps people honest
- End every session with three things confirmed: what was decided, what is still open, and who owns what next
- One session per week minimum. Longer gaps let momentum die
Section 3 — Standard Session Structure
Apply this template to every session. Adjust timing by session length.
| Time | Activity |
|---|
| 0:00 – 0:10 | Re-orient: where we are in the engagement, what today produces, any pre-work to surface |
| 0:10 – 0:40 | Core facilitated discussion (use archetype-specific block from end of this document) |
| 0:40 – 0:50 | Output capture: what did we actually decide, what remains open, record it visibly |
| 0:50 – 1:00 | Next session setup: who needs to be there, what pre-work is needed, confirm the date |
Preparation: Before every session, re-read the output summary from the previous session. Have the Gap Analysis Tracker open. Know what you are trying to produce before you open the call.
Section 4 — Common Dynamics and How to Handle Them
| Situation | How to Handle It |
|---|
| Vendor dominates the room | Redirect explicitly. Say: “Let us hear how the partner would frame this for their clients.” If it happens again, address it directly with the vendor outside the session |
| Partner is passive | They may not trust the vendor yet. Offer a vendor-absent session for the next round. Name what you are seeing: “You seem cautious. Is there something about this conversation that is not working for you?” |
| Scope creep | Name it early. Say: “That is important but it sits outside what this engagement produces. Let us note it and move on.” Log it in the Gap Analysis Tracker as a deferred item |
| Decision-maker is absent | Stop the session. Reschedule with the right person in the room. A session without decision authority produces outputs that cannot be acted on |
| Cultural deference (Japan context) | Build in written pre-work so opinions surface before the room dynamic flattens them. Ask for written responses before the session and reference them in the room rather than asking for live positions |
| Partner and vendor are misaligned | Do not mediate in the session. Surface the misalignment clearly, log it, and address it separately with each party |
| Engagement is stalling | Name it directly with the partner. Ask: “What would make it easier to keep this moving?” The answer is usually about internal politics, resource constraints, or trust. Address the actual blocker, not the symptom |
Section 5 — Output Capture Standard
Every session produces a one-page summary within 24 hours.
| Field | Guidance |
|---|
| What we covered | A two or three sentence synthesis of the session focus — not a transcript |
| What was agreed | Specific decisions made. If nothing was agreed, say so |
| What is still open | Questions or decisions that need resolution before the next session |
| Gap Analysis updates | Any new gaps identified. Update the tracker immediately after writing this |
| Next session | Date, attendees, focus, and any pre-work assigned |
Timing: Write the session summary the same day. Memory fades faster than you expect. The summary is also your primary input to the engagement retrospective at close.
Archetype Variants
Section 6 — Core Discussion Block by Archetype
Use the version below that matches your engagement. This replaces the minutes 10–40 block in the Standard Session Structure. All other sections of this guide apply regardless of archetype.
These are not scripts. They are prompts for the questions you need answered and signals for what good looks like. Adapt them to the conversation in the room.
A1 — Classic Enterprise Cyber
e.g. Mimic and similar established security vendors
- What does the partner’s client think they are buying, and what are they actually buying? Listen for gaps between vendor positioning and client expectation. This is where deals later break down
- Where does the vendor’s standard demo or pitch fall flat in this partner’s specific client conversations? Not what the vendor thinks the objections are. What the partner actually hears
- What proof points land with this partner’s clients, and what feels imported from another market? APJ clients often respond to different evidence than US or EMEA references. Surface this explicitly
- What does a successful first deployment look like, and who owns it on the client side? A methodology that cannot describe a concrete first win is not ready to go to market
A2 — Industrial / OT / IIoT
e.g. WI-SUN Alliance, Toyota Tsusho context
- Who is the actual buyer in this conversation: IT security, OT engineering, or procurement? If the partner does not know, the methodology has no entry point. This must be resolved before Session 3
- What is the consequence of a security failure in this client’s OT environment, in operational terms — not security terms? Production downtime, supply chain disruption, regulatory penalty. Find the language that moves the OT buyer
- What existing OT relationships does this partner have that the vendor needs to understand and respect? OT vendors and system integrators already in the environment. Stepping on these relationships kills deals
- What does the partner need to be credible in an OT room that they do not currently have? Technical references, OT-specific certifications, architecture documentation. Log gaps immediately
A3 — Emerging / Sensitive AI
e.g. WitnessAI and AI governance vendors
- What is the partner’s honest read on client appetite for AI-related products in their specific market right now? Japan FSI appetite for AI products is highly variable. Do not assume the vendor’s global pipeline reflects local reality
- Where does data residency or sovereignty become a concrete blocker — not a theoretical concern? Get specific. Which data, which systems, which regulators. Vague answers here will produce a methodology that fails in real conversations
- What regulatory conversations is the partner already having that this vendor’s story could plug into? APPI, FSA AI guidance, FISC. If the partner is not already having these conversations, the entry point strategy needs rethinking
- What would need to be true about the vendor’s data handling and governance posture for this story to be safe to tell in a Japanese FSI context? This question often surfaces vendor gaps that need to be resolved before the methodology goes to market
A4 — PKI / PQC / Crypto Lifecycle
e.g. Keyfactor, OmniTrust
- How technically mature is the partner’s client base on certificate management and cryptographic infrastructure today? Clients who have never run a certificate inventory need a different entry point than those who have had a cert-related outage
- Is the PQC conversation being driven by external regulation, internal risk appetite, or is it not happening yet? JFSA and G7 timelines are real but not universally understood. Find out where the client actually sits
- What does the partner need to be able to explain quantum risk to a non-technical executive without losing the room? The executive narrative is often the biggest gap. Log it if the vendor cannot provide one
- Where are the quick wins that build credibility and momentum before the full PQC roadmap conversation? Certificate discovery and visibility are usually the most accessible entry points. Confirm whether the partner can lead that conversation today
e.g. Northern Tech Mender
- What does the partner’s client’s current patching and vulnerability management process actually look like in practice, not on paper? There is almost always a gap between the documented process and the reality. The methodology needs to be built around the reality
- Where does remediation most often break down: detection, prioritization, execution, or verification? Each failure point requires a different solution framing. Do not assume they all have the same problem
- Is the client aware they have a hygiene problem, or does the awareness conversation need to happen before any solution conversation can begin? If awareness is not there, the methodology needs a discovery phase that builds it. This changes the session structure significantly
- What would a managed remediation motion look like for this specific partner’s client base, and is the partner capable of delivering it today? Managed service design requires honest assessment of partner capability, not just vendor product fit
A6 — SOC Modernization / Agentic D&R
e.g. Agentic SOC vendors, autonomous detection and response
- What is the partner’s client currently outsourcing to an MSSP that, with the right capability, they should own internally? Detection engineering, alert triage, threat hunting. Get specific about what is being handed off and why
- What is the partner’s honest assessment of their client’s current MSSP in terms of actual detection and response quality? This is often the conversation the client has never had explicitly. Surface it carefully. The partner needs to feel safe being candid
- Where has the client felt most exposed by slow or inadequate response, and do they connect that to the outsourcing model? The connection between outsourced SOC and poor response quality is not always made by the client. The methodology may need to help them make it
- What does the partner need to be credible in a conversation about agentic detection and autonomous response with a skeptical security buyer? Autonomy in security operations is still a trust problem for many buyers. The partner needs references, architecture clarity, and a clear human-in-the-loop story