← Career Prep

Bryan Licas (CPO) Interview Prep

Traction Complete · Hiring Manager Round · 30 min

Interviewer
Bryan Licas · Chief Product Officer · Hiring Manager
What He's Evaluating
Product craft, customer orientation, B2B/RevOps fluency, team fit
From HR Screen
Role is evolving — more customer-facing, revenue-oriented than before
Interview Date
Thu Apr 9, 2026 · 10:00 AM PT
30 Min

Pacing Guide

This is a short call. Be ruthless about airtime — one story per answer, no preamble, no over-explaining. Bryan is a co-founder with deep product instincts; he'll detect filler instantly.

BlockTimeNotes
Tell me about yourself ~3 min Hit 90 seconds on your intro. Leave room for Bryan to react.
Bryan's questions ~15 min Expect 2–3 questions, not 7. One story each, stay specific.
Your questions ~8–10 min You get 3 max. Prioritize: #1 (product ownership), #2 (customer-facing), #5 (biggest opportunity).
Wrap / next steps ~2 min Thank him, express genuine interest, confirm next steps.
Key Rule Short answers > comprehensive answers. If Bryan wants more detail, he'll ask. Don't fill silence with more words.
Positioning

How to Frame Yourself

Your core positioning for Bryan: "I'm an IC product manager who solves messy operational problems by getting close to the data and close to the user. I've done this across field ops, platform infrastructure, and marketplace operations — and I'm bringing that muscle into the Salesforce/RevOps space."

Three Identity Pillars

Every answer you give should reinforce one of these. If a story doesn't connect to at least one, it's the wrong story for this interview.

PillarWhat It MeansEvidence
Operational problem-solver You don't just ship features — you untangle broken systems, fix data architecture, and make cross-functional operations work. This is the RevOps PM job description in different words. Customer data architecture (source-of-truth consolidation), address serviceability fix (identified root cause no one else saw), platform migration (10+ teams coordinated)
Hands-on IC who does the work You write PRDs, build baseline reports manually, scope pilots, debug data issues, and sit in technical conversations with engineers. You're not delegating — you're in the details. Built WoW dashboard yourself, created manual baseline reports for self-scheduling business case, technical feasibility work with ServiceMax + Amazon Lambda, coordinated with GIS team on data architecture
Gets close to users and ships through resistance You talk to real users, you see problems they don't articulate, and you find ways to ship when the org says no. Bryan values this — he came from CS and he's making this role more customer-facing for a reason. LalaMove driver conversations in person/phone, address serviceability fix ("not her job" but did it anyway), self-scheduling Phase 1 shipped around organizational resistance by breaking it into increments

Vocabulary Swap Sheet

Translate your experience into Bryan's world. Practice these substitutions until they feel natural.

Don't SaySay InsteadWhy
Consumer, end user, app Platform, operations team, revenue infrastructure B2B framing. Procurify rejected you for consumer language. Don't repeat.
ISP, telecom, internet company Fiber infrastructure provider, operational B2B environment Ting sounds consumer-y. The internal operations work was enterprise-grade complexity.
I managed / I oversaw / I directed I built / I wrote / I identified / I scoped / I shipped IC language. Bryan is hiring a doer, not a manager. Every verb should be hands-on.
We did / the team did I did [specific thing], working with [team] 30-min interview. He needs to know what you did, not what the team did. Be specific about your contribution.
I think I could learn RevOps I've solved these exact problems — deduplication, data quality, routing, source-of-truth — in a different context Don't position yourself as a learner. Position yourself as someone who already has the skills and is applying them to a new domain.
I was a Senior PM I was doing hands-on product work across [scope] Don't lead with the title. Lead with the work. If the title comes up, it comes up — but don't introduce the comparison yourself.
Thread The single strongest thread to weave through the whole interview: "Your customers are operations people trying to make messy data and broken processes work. I've been that person. I built product for those people. I understand their pain because I've lived it." This is your moat — most PM candidates understand RevOps abstractly. You've done the work from the inside.
Profile

Know Your Interviewer

Bryan's path is Customer Success → Product → CPO. He deeply understands the customer side. Speak his language.

DetailWhat It Means for You
CS → Product career path Bryan came up through Customer Success (Traction Guest → ToD → TC). He values customer empathy and will probe whether you truly understand users vs. just building features. Your LalaMove driver conversations and Ting operational user work resonate here.
~7 years at TC (since founding) He's a co-builder, not a hired exec. He knows every product deeply. Don't bluff on product details — ask smart questions instead. He'll respect genuine curiosity over surface knowledge.
Salesforce Certified Admin Bryan has hands-on Salesforce expertise. Your ServiceMax/Lightning experience is a real bridge — he'll understand exactly what that means. But don't overstate your Salesforce depth; he'll see through it instantly.
Pragmatic Marketing PMC Level 4 Pragmatic Marketing is a structured, market-driven product framework. Bryan thinks in terms of market problems → validation → business cases → roadmap. Frame your stories using this lens: problem identified → validated → shipped → measured.
BCIT BBA grad, Vancouver local Shared local context. Practical, applied education background — not an ivory tower thinker. He likely values pragmatism and execution over theory.
VP Products before CPO (Sep 2023) Promoted to CPO relatively recently. He's likely still defining what the CPO role means and shaping the product org. Your questions about his vision for the team will land well — he's actively thinking about this.
Context

What You Learned from Karen

Use these details to show continuity and that you're already building context.

DetailHow to Use It
Backfill role (was 3 PMs, now 2) Ask Bryan what the departing PM owned. Understand the product surface you'd inherit. Shows you're already thinking about onboarding.
Role is evolving — more customer-facing This is Bryan's vision for the role. Ask him to describe what "customer-facing" means concretely: sales calls? Discovery interviews? QBRs? This is your chance to show enthusiasm for it.
Team: Bryan (CPO), Scott Wilton (Dir Product Design), 2 PMs (Cynthia C., Garren Lau) Small product org — you'd be the 3rd PM. Ask about how PMs divide ownership (by product? by customer segment?) and how closely they work with Scott's design team.
Fully remote, optional Wednesday coworking Confirmed — no need to re-ask. But you can reference it positively: "I appreciate the remote-first setup with the optional in-person touchpoint."
Comp: top of $90K–$120K range Already stated your expectation. Don't revisit unless Bryan brings it up. If he does, hold firm — "As I mentioned to Karen, given my senior-level experience, I'd need to be at the top of the range."
Core

Tell Me About Yourself (~90 sec)

Same frame as HR screen but sharper for a CPO. Lead with product craft and B2B operations, end with why Traction Complete specifically.

I'm a product manager with about five years of experience, most recently at Ting Internet under Tucows. My work was heavily cross-functional and operational — I shipped products that touched engineering, field ops, customer support, and business intelligence, with direct impact on revenue and operational efficiency.

Two things especially relevant here. First, I worked hands-on with ServiceMax, built natively on Salesforce Lightning — so I've operated inside the Salesforce ecosystem, working with the data model, object relationships, and ISV integration patterns. That's structurally the same platform you're building on. Second, a lot of my work was RevOps-adjacent: fixing broken data architecture, building BI dashboards for operational strategy, coordinating cross-functional teams around shared data and processes. The users I built for are very similar to the RevOps practitioners who use Traction Complete.

What draws me here is that this is a product craft role with real customer proximity, building tools for operations people solving messy data and GTM problems — which is the kind of user I understand deeply because I've been that user.
Watch Be precise: say "ServiceMax" not "ServiceNow." ServiceMax = Salesforce Lightning native (your bridge). ServiceNow = completely different platform.
Stories

Story Bank for Bryan's Questions

Mapped to the themes Bryan will likely probe. Have 2–3 ready to go; don't recite all of them.

Customer Discovery & Validation

Ting — Self-Scheduling Initiative
Situation: Manual phone scheduling for fiber installs couldn't scale. Org resisted full self-scheduling because they valued phone calls as a brand differentiator.
What you did: Broke the problem into phases. Shipped Phase 1 (automated SMS) quickly — 35%+ response rates, reduced outbound calls. Led Phase 2 discovery with Design, Research, IS, and Field Ops. Created manual baseline reports to build the business case. Defined 100-customer pilot scope.
Why it's relevant: Shows structured discovery, incremental validation, shipping through resistance, and tying product work to operational/revenue outcomes.

Revenue & Business Impact

Ting — Customer Data Architecture
Situation: Customer data was duplicated or lost across different tool integrations. Multiple teams had their own disconnected sources of truth.
What you did: Worked cross-functionally to identify the fragmentation. Built a central source of truth for customer data that individual teams' tools would draw from. Eliminated duplication and data loss across integrations.
Why it's relevant: This is exactly what RevOps teams do with broken CRMs — the same "organizational archaeology" that Traction Complete's products (Complete Clean, Complete Hierarchies) solve. You've lived this problem from the inside.

Front-Facing / Customer Revenue Work

LalaMove — Driver Acquisition
Situation: Needed to grow the driver side of the platform for LalaMove's marketplace model.
What you did: Worked with Collin on new user acquisition. Spoke directly to drivers in person and over the phone. Drove new user acquisition to grow the supply side of the platform.
Why it's relevant: Direct customer/user interaction driving growth outcomes. Shows comfort being externally-facing and having revenue-tied conversations.
Ting — Address Serviceability Fix
Situation: Ting's website used a radius-based Google Maps hack for address serviceability — no real source data. Customers were getting wrong expectations.
What you did: Identified root cause (no source data). Brought in GIS team. Restructured from radius-based guessing to discrete address lists. Built frontend logic for proper expectation management.
Why it's relevant: Data quality directly impacting customer experience and revenue. Acted without being asked, expanded scope based on what the customer needed. This is the "entrepreneurial" behavior the JD asks for.

Salesforce Ecosystem Experience

Ting — ServiceMax on Salesforce Lightning
Situation: Ting used ServiceMax for field operations management — an ISV product built natively on Salesforce Lightning.
What you did: Collaborated with BAs and field ops managers on process changes and system integration modifications. Worked within the Salesforce Lightning framework, understanding data modeling and object relationships.
Why it's relevant: Structurally identical to what Traction Complete builds. You've seen how ISV products on the Salesforce platform integrate with organizational workflows from the customer side.

AI & Modern PM Workflows

AI-Native Workflow
What you do: Claude Code for agentic software engineering. Building a personal AI assistant with NanoClaw. Co-authored Tucows' Responsible AI Use Policy. Northeastern Agentic AI certificate.
Why it's relevant: You don't just "use AI tools" — you've shaped organizational AI policy and use AI as a core workflow. Complete Discover is their new AI product; this signals you can think about AI-powered product strategy from experience, not theory.
B2B Framing Procurify rejected you for "consumer-focused background." With Bryan, always frame stories in B2B/operations/revenue language. LalaMove = marketplace supply-side operations, not "consumer app." Ting = B2B-adjacent enterprise infrastructure, not "ISP customer support."
Product

Product Depth to Demonstrate

Bryan will expect you to have opinions about the product and market. Don't just recite features — show you understand the problem space.

Know the Product Suite

ProductWhat It Does & Why It Matters
Complete Leads Lead matching & routing. Speed-to-lead is the #1 driver of conversion in B2B. Every minute a lead sits unrouted, close rates drop. This is likely their flagship revenue driver.
Complete Hierarchies Account hierarchy building. Enterprise customers have complex parent/subsidiary structures. Without this, reps from the same company end up competing for the same account. First-of-its-kind for Salesforce.
Complete Clean Deduplication. Dirty data is the #1 complaint of every RevOps team. Duplicates break reporting, routing, and attribution. A "quiet hero" product — not flashy but critical.
Complete Influence Stakeholder mapping. In enterprise B2B, deals involve 6–10 decision makers. Mapping who influences whom is how reps navigate complex sales. Ties into ABM strategies.
Complete Discover AI data enrichment (NEW). Uses Google Sheets to test AI prompts before deploying to Salesforce. Smart approach — meets RevOps users where they already work (spreadsheets) before pushing to the CRM. Lower risk, faster adoption.

Who's Who at a TC Customer Org

The buyer, the user, and the sponsor are different people. Understanding this makes you sound like a B2B PM.

RoleRelationship to TCWhat They Care About
RevOps Manager / Director Primary buyer AND power user. Configures routing rules, dedup settings, hierarchy structures. This is TC's core persona. Data quality, process efficiency, reporting accuracy. They live in Salesforce and feel the pain of bad data daily.
Salesforce Admin Technical gatekeeper. Installs and maintains ISV apps on the Salesforce instance. Will it break anything? Is it native? Easy to configure? TC being Salesforce-native is a huge selling point here — no middleware, no separate data access.
Sales Reps / AEs End users who benefit but don't configure. They see leads routed to them, clean account data, stakeholder maps in Salesforce. "Did I get the right lead fast?" They never log into TC — they just experience the results.
Sales Leadership (VP Sales / CRO) Economic buyer / executive sponsor. Signs the check. Pipeline velocity, rep productivity, forecast accuracy. Doesn't touch TC but cares about the metrics it moves.
Marketing Ops Adjacent stakeholder. Cares about lead flow from marketing → sales. MQL → SQL handoff, attribution, dedup. Duplicate leads break campaign metrics and attribution models.
CS / Account Management Uses hierarchies and stakeholder maps to understand customer relationships and navigate renewals. Complete Hierarchies and Complete Influence are directly relevant — knowing org structure of accounts they manage.
IT / Security Evaluates ISV apps for compliance and data access. Salesforce-native = stays within Salesforce's security model. Big advantage over middleware that needs separate data access.
Key Insight RevOps buys it because the data is a mess. The CRO approves it because they're told it'll improve pipeline velocity. The admin tolerates it because it's native and doesn't break things. The reps never know it exists — they just get better leads faster. Understanding this buyer/user/sponsor split is how you sound like a B2B PM in conversation with Bryan.

Market & Competitive Context

Key competitors: LeanData (lead routing incumbent, larger), Fullcast (RevOps planning), Openprise (data orchestration), Validity (data quality).

TC's moat: Salesforce-native. Not a middleware integration — built on the platform. Customers aren't leaving Salesforce, so platform lock-in works in TC's favor. 1.7M hours of Salesforce consulting DNA from Traction on Demand means they deeply understand the platform's constraints and possibilities.

Market risk to acknowledge (if asked): Salesforce itself could build native GTM automation features. TC's defense is depth — generic Salesforce tooling rarely matches the specificity of a dedicated ISV product.

Honest Product Observations

You don't need to voice all of these — but having genuine opinions about the product makes you sound like a PM, not a candidate. Use these if Bryan asks "what do you think of our product?" or "where do you see opportunities?"

ObservationThe NuanceHow to Use It
Data cleaning is a vitamin, not a painkiller Everyone knows they have dirty data. Nobody wakes up excited to fix it. The buying urgency is low — RevOps teams deprioritize dedup for revenue-generating work. Hard to create urgency without tying it to downstream revenue impact. Don't say this directly. But if Bryan asks about go-to-market challenges, you can frame it as: "How do you create urgency for data quality when the pain is chronic, not acute? I'd imagine the sales motion needs to quantify the downstream revenue cost of bad data."
Individual products feel like features; the suite is the strategy Lead routing alone competes against Salesforce native assignment rules. Dedup alone competes against Validity. But routing + hierarchy + dedup + enrichment as a unified RevOps data layer? That's a consolidation play that's much harder to compete with. Good framing if Bryan asks about product strategy: "It seems like the real value proposition isn't any single product — it's the integrated suite. One vendor that owns the data quality layer for your entire GTM motion."
Speed-to-lead is the strongest revenue story Complete Leads has the clearest ROI math: response under 5 minutes = dramatically higher conversion. Every minute a lead sits unrouted is measurable lost revenue. This is the product that sells itself with a number. If asked which product excites you most, this is a safe pick — it has clear revenue logic and you understand the operational urgency from your own experience with time-sensitive customer workflows at Ting.
Account hierarchies is the most defensible product "First of its kind for Salesforce." Enterprise parent/subsidiary relationships are structurally complex and Salesforce doesn't solve this natively. This product has the deepest moat — hard to replicate, high switching cost once embedded. Good signal to Bryan that you think about defensibility, not just features. "Complete Hierarchies feels like the most structurally defensible product in the suite — once you're the source of truth for account structure, you're deeply embedded."
No qualification/scoring in the suite TC handles what happens after a lead is qualified (routing, matching, enrichment) but not qualification itself (lead scoring, MQL/SQL classification, ICP fit). That's a gap in the GTM workflow — either intentional (leave it to the CRM) or a future opportunity. Strong question for Bryan if the conversation goes to product strategy: "Your products handle the plumbing after a lead is qualified — routing, enrichment, hierarchy. Is qualification intentionally left to Salesforce, or is that something you've considered?"
Complete Discover is the bet that changes the company's ceiling Right now TC is "data plumbing" — essential but invisible infrastructure. If AI enrichment works, it shifts TC toward "data intelligence" — a different market category and price point. The Google Sheets approach is smart: de-risks adoption by meeting users in a familiar tool before touching production Salesforce data. If AI product strategy comes up: "Discover feels like it could reposition the whole company — from data infrastructure to data intelligence. The Sheets-first approach is smart product thinking because it lowers the trust barrier for AI touching production CRM data."
Salesforce-native is a moat and a ceiling Platform lock-in means customers aren't leaving. But TAM is capped at Salesforce shops, and Salesforce itself could build native GTM features. TC's defense: generic Salesforce tooling never matches ISV depth. 1.7M consulting hours means they know platform constraints better than Salesforce's own product team. Don't bring up the risk unprompted. But if Bryan asks about market challenges: "The Salesforce-native bet is clearly right — the question is whether you stay exclusively Salesforce or eventually consider HubSpot/Dynamics as the suite matures."

Why Enterprise Data Is Fundamentally Different

This is context for you, not something to present to Bryan. It sharpens your understanding of TC's problem space so your answers sound native, not learned.

In simpler data environments, you can often solve data quality at input — controlled forms, validation rules, a flat customer model. But enterprise B2B data is structurally different:

The data model is a graph, not a table. One "customer" might be 200+ subsidiaries, dozens of business units, thousands of contacts entered by different reps over different years. The same person can be a lead, a contact, and exist across multiple accounts.

You don't control the input sources. Data arrives from web forms, trade shows, partner referrals, marketing tool imports, manual rep entry, and inherited CRM instances from acquisitions. You can't enforce schema across all of them.

Data decays naturally. People change jobs, companies restructure, subsidiaries get acquired or spun off. A clean record is dirty six months later without intervention.

This is why TC's products exist. You can't prevent the mess — the complexity is inherent to enterprise data. So you build infrastructure that continuously cleans, deduplicates, structures, and routes it. It's not a failure of input design; it's the nature of the problem space.

Your bridge: At Ting, you solved a simpler version of this — fragmented data across systems, teams working from disconnected sources of truth. TC's customers face the same problem at higher structural complexity. Same muscle, higher-dimensional problem.
Careful Do NOT frame this as "coming from B2C, I had to learn why enterprise data is hard." That signals the gap. Instead, if the topic comes up naturally, frame from your experience: "At Ting I dealt with data fragmentation across systems — but the data model was relatively flat. What I find interesting about this space is that enterprise account structures add a whole layer of structural complexity on top of that. You're not just deduplicating records, you're maintaining a living graph of organizational relationships." This sounds like a PM who's thought deeply, not a B2C person catching up.
Tone These observations are for demonstrating product thinking, not critiquing Bryan's company. Frame as curiosity and strategic questions, not "here's what's wrong." In a 30-min call, you'll have room for one, maybe two of these — pick based on where the conversation goes.
Prepare

Likely Questions from Bryan

A CPO interviewing a PM hire will focus on: product thinking, customer empathy, execution, and team dynamics.

Walk me through how you'd approach a new product area you're unfamiliar with.
Testing your discovery process. Use the self-scheduling initiative: you started with manual baseline reports, led cross-functional discovery, and scoped incrementally. Show the system, not just the outcome.
Tell me about a time you worked directly with customers to inform product decisions.
The role is evolving to be more customer-facing. LalaMove driver acquisition for direct user interaction. Self-scheduling for structured discovery with internal stakeholders and pilot design. Address serviceability for acting on customer pain you observed firsthand.
How do you connect product decisions to revenue outcomes?
Core to the role. SMS scheduling reduced outbound call volume (operational cost = revenue). BI dashboards at LalaMove informed revenue strategy. Customer data architecture eliminated revenue leakage from bad data. Frame everything in terms of business outcomes, not features shipped.
How do you work with engineering on scope and tradeoffs?
JD explicitly calls this out. Ting platform migration (coordinated 10+ teams). Self-scheduling technical feasibility work with ServiceMax and Amazon Lambda. Show you're comfortable in technical conversations, not just writing requirements and handing them over.
Tell me about a time you shipped something through organizational resistance.
Two strong stories: (1) Self-scheduling — org valued phone calls, you broke it into phases to prove value incrementally. (2) Address serviceability — "not your job" but you did it anyway because it was the right thing for the customer.
What interests you about the Salesforce ecosystem / RevOps space?
Don't fake deep domain passion if it's not there. Be honest: "I've worked inside the ecosystem via ServiceMax, I understand the platform's constraints and possibilities, and the RevOps problem space maps directly to work I've done with data architecture and cross-functional operations. I'm genuinely interested in going deeper."
How are you using AI in your work today?
Go beyond "I use ChatGPT." Claude Code for engineering, NanoClaw personal assistant, Responsible AI Policy at Tucows, Agentic AI certificate. Connect to how you'd think about AI product features at TC (Complete Discover, AI-enhanced routing builder).
Why Traction Complete? Why this role specifically?
Product-led CEO (rare, meaningful for PM quality of life). Customer proximity. Salesforce ecosystem lock-in = real moat. Small product team where you can have outsized impact. You've been the "operations person solving messy data problems" — you know this user deeply.
Ask Bryan

Your Questions

You have time for 3 questions max. The first 3 are your must-asks; the rest are backup if conversation opens the door.

1. Which product(s) would this PM own, and what does success look like in the first 6 months?
Critical for understanding scope. Five products + a new AI tool. Owning one vs. many changes the role entirely. Also shows you're already thinking about outcomes.
2. Karen mentioned the role is more customer-facing. Which customer roles would I be spending the most time with — RevOps practitioners, Salesforce admins, sales leadership?
Stronger than the generic version. Shows you already understand the persona landscape at a TC customer org (buyer vs. user vs. sponsor) and you're asking where your focus would be. Also reveals whether Bryan wants PMs running discovery with RevOps practitioners, sitting in on strategic sales calls with CROs, or doing QBRs with CS — these are very different jobs. His answer tells you what "customer-facing" actually means here and why he's evolving the role in this direction.
3. Where is the biggest product opportunity right now that you wish you had more capacity for?
The honest version of "what would I work on." Also reveals what Bryan thinks the strategic priorities are — useful context for the demo/case study round.
4. How does the product team divide ownership today — by product, by customer segment, by workflow?
Understand how you'd slot in alongside the other 2 PMs. Also reveals whether the org is product-organized or cross-cutting.
5. You have a product management background — how does that shape how you run the product org?
You flagged the product-led CEO angle with Karen. Now ask Bryan directly. This is a rapport builder and tells you how much autonomy PMs have.
6. How does Complete Discover fit into the broader product strategy? Is AI a horizontal play across all products or a standalone bet?
Shows product strategy thinking. AI as horizontal vs. standalone is a real strategic question for their suite. Bryan will appreciate the depth.
7. What's the relationship between the product team and the sales/CS team on customer feedback? How does customer signal get to PMs?
For a customer-facing PM role, understanding the feedback loop is critical. Also signals you care about process, not just building features.
8. What happened with the PM who left? What would you do differently with this hire?
Direct but important. "What would you do differently" softens the ask while getting at what they're really looking for. Use your judgment on timing — this works better later in the conversation once rapport is built.
Landmines

Things to Watch Out For

B2B / Enterprise Gap

This is your biggest vulnerability. Bryan will be assessing whether you can operate in enterprise B2B without a ramp-up that slows the team. Here's what he's thinking and how to counter it.

His ConcernYour Counterpoint
She hasn't sold to or built for enterprise buyers Ting's internal platform work was enterprise-grade complexity: multi-team dependencies, data architecture decisions that affected the whole org, integration with enterprise tools (ServiceMax, BI). The users were internal operations teams — the same persona as RevOps leaders. The buying context was different, but the problem-solving and stakeholder complexity were not.
She doesn't know B2B sales cycles, procurement, or multi-stakeholder deals Acknowledge directly: "I haven't run a B2B sales-assisted product cycle end to end. But I've worked closely with sales-adjacent teams and understand how product decisions affect revenue outcomes. I'm a fast learner in domain context — at Ting I went from zero to leading cross-functional product work across field ops, IS, and BI within months." Don't bluff. Bryan will respect honesty more than spin.
She doesn't speak RevOps language natively You actually do — just in different words. Deduplication, data quality, routing, source-of-truth architecture, cross-team data fragmentation — these are exactly what TC's products solve. Bridge the vocabulary: "At Ting, I solved the same category of problems your customers face — broken data, duplicated records, teams working from different sources of truth. I called it 'data architecture work,' your customers call it 'RevOps.'"
She'll struggle with customer discovery in a B2B context Your discovery skills transfer directly. LalaMove: direct conversations with marketplace participants to inform product. Ting self-scheduling: structured multi-team discovery, pilot scoping, manual baselines before automation. The method is the same; the customer segment is different. And Bryan values this — he came from CS, he knows customer proximity is a skill, not a domain.
Frame Don't apologize for the gap. Position it as: "I bring strong product fundamentals and operational problem-solving into a domain I'm ready to go deep on. The structural patterns transfer — what I'd be learning is the specific B2B GTM vocabulary and sales motion, which is domain context, not a new skill set."

Senior PM → PM Title: What Bryan Might Be Thinking

Bryan knows you're titled Senior PM. He'll have questions he may or may not ask directly. Be ready for the subtext.

His ConcernYour Counterpoint
Is she going to be a strong IC, or has she drifted into strategy/delegation? This is the big one. He needs someone who writes PRDs, runs discovery sessions, grinds through edge cases with engineering — not someone who "sets direction" and delegates. Emphasize the hands-on: "At Ting I was writing problem statements, building manual baseline reports, scoping pilots with engineering, and debugging data architecture issues myself. I wasn't managing PMs — I was doing the work."
Will she get bored or feel like this is a step down? Flight risk is real in his mind. Be direct: "I'm intentionally choosing a role where I'm close to the product and close to customers. My best work has always been as a hands-on IC, and I'd rather do excellent IC product work than manage a team or sit in strategy meetings. This isn't a compromise — it's what I'm looking for."
Will she try to change how we do things / overstep the role? Small product team (3 PMs + Bryan + Scott). A "Senior PM energy" person could disrupt the dynamic. Signal that you're collaborative, not territorial: "I'm joining an established team with established practices. I want to learn how things work here before forming opinions about how they should work."
Is the comp going to be a problem? You told Karen you expect top of range ($120K). Bryan knows Senior PMs typically earn more. If it comes up: "I've thought about the compensation. The role, the team, and the product space are what matter to me right now. I'm comfortable with the range we discussed."
Read the Room If Bryan asks "what are you looking for in your next role" or "why this level" — these are the flight-risk / IC-strength questions in disguise. Don't wait for the direct version. Weave the "I want to do the work, not manage the work" message into your opening or first story naturally.

Other Landmines

RiskMitigation
ServiceMax vs. ServiceNow slip Practice saying "ServiceMax, built on Salesforce Lightning" as a single phrase. If you catch yourself mid-slip, correct immediately — it's better to self-correct than let it pass.
Consumer-focused framing Never say "consumer," "end user," or "app." Say "platform," "operations," "revenue infrastructure," "B2B." LalaMove = marketplace supply-side operations. Ting = operational infrastructure for a fiber ISP.
Shallow Salesforce knowledge You have real experience (ServiceMax) but not deep Salesforce admin knowledge. Be honest about the depth: "I've worked inside the ecosystem via ServiceMax — I understand the platform architecture and ISV model. I'd need to build deeper Salesforce-specific domain knowledge, and I'm confident I can do that quickly given the structural familiarity."
aiapply application answers Bryan may have read your application. If he references something that sounds unfamiliar, it's probably from the bot answers. Redirect naturally to the real story without calling out that the app was AI-generated.

Interview Process (from Karen)

Key People