CHAPTERS
- 0:00 – 2:05
From Microsoft to Vanta: a career “too comfortable” at BigCo
Jeremy opens with a personal career reflection: he wishes he’d left Microsoft earlier. The conversation tees up what he learned at scale and how that shaped his approach as CPO at Vanta.
- •Regret as a signal: comfort can slow growth
- •Big-company systems can keep you “one promotion away”
- •Transitioning from BigCo experience to startup impact mindset
- 2:05 – 2:50
Internet Explorer era: shipping browser innovations amid web standards battles
Jeremy recounts his time on Internet Explorer in the early 2000s when tabs, extensions, and web standards were still emerging. He describes the fast-changing competitive landscape before Chrome dominated.
- •Tab browsing and tab grouping as “new” features then
- •Early thinking on browser extensions
- •Privacy and HTML standards discussions
- •Competitive pressure from Mozilla/Firefox and the evolving web
- 2:50 – 4:17
Old-school Microsoft PM: waterfall specs, distance from customers, narrow scopes
Aakash and Jeremy compare PM life in the late 2000s: heavy documentation and inward-facing decision-making. Jeremy contrasts Microsoft’s smaller PM scopes and low engineer-to-PM ratios with how he structures teams today.
- •20-page spec templates and waterfall delivery
- •Feeling detached from real customers
- •PMs doing extra roles (design/engineering-adjacent)
- •Narrow PM scopes and very small eng pods vs broader ownership today
- 4:17 – 11:23
AI prototyping and the new EPD operating model (PM/design/engineering overlap)
Jeremy explains why PM-to-engineer ratios should rise as AI tools enable faster prototyping and tighter feedback loops. He outlines how overlapping responsibilities can work with team-specific “shapes” and clear accountability for shipped craft.
- •V0/Lovable/Bolt as accelerants; V0 licenses for all PMs
- •“Seeing is believing”: interactive prototypes beat perfect docs
- •Flexible team models; avoid one template for all squads
- •Design accountable for shipped experience, not just Figma output
- •Blending direct manipulation + AI chat; pipeline from prototype → repo (Cursor/GitHub)
- 11:23 – 12:16
Divergent thinking: explore 5 options, then converge—and be honest about AI limits
They discuss why generating multiple variants reduces ego attachment and improves feedback quality. Jeremy also notes current AI tool shortcomings and the importance of judgment and iteration.
- •Generate breadth (5→2→1) to avoid over-identifying with one idea
- •Faster exploration changes the pace of product discovery
- •AI makes mistakes; leaders must sanity-check outputs
- •Tools are improving, but reliability and craft still matter
- 12:16 – 15:30
Outlook at billion-user scale: protocols, threading, spam, storage, and privacy tradeoffs
Jeremy walks through what a Microsoft PM day looked like on Outlook/outlook.com, including early remote collaboration across sites. He highlights product decisions shaped by scale, infrastructure constraints, and privacy considerations.
- •Split teams across Redmond + Silicon Valley; early remote-work patterns
- •Debates on POP vs IMAP and state sync
- •Conversation threading mechanics and ML-assisted content detection
- •Spam filtering as early applied ML
- •Storage constraints pre-“infinite inbox” and ads/privacy debates
- 15:30 – 17:56
How Microsoft built features: PRDs, technical depth, and global readiness constraints
Using email threading as an example, Jeremy describes how features were proposed, specified, architected, and launched. He emphasizes the drag of localization/accessibility requirements and how design’s role has since evolved.
- •Feature ideas often originated within teams, not top-down mandates
- •Massive PRDs + long research cycles; close pairing with eng
- •PM involvement in architecture diagrams and scaling decisions
- •Global launch requirements: i18n, RTL, accessibility
- •Design often treated as visual polish then—very different from today
- 17:56 – 20:59
How PM changed over 16 years—and Satya’s strategic reset at Microsoft
Jeremy summarizes the evolution: broader PM scopes, stronger design influence, more customer and revenue connection. He contrasts Ballmer-era revenue focus with Satya’s clarity, prioritization, and renewed product/developer orientation.
- •Bigger PM span of control and deeper business accountability
- •Design gaining a true UX seat at the table
- •More customer proximity via enterprise deals and onboarding
- •Ballmer: revenue superpower but weaker product vision focus
- •Satya: clear priorities (cloud), modern SaaS mindset, cross-platform push
- 20:59 – 24:48
Leadership lessons from Satya: clarity, experimentation, and successful acquisitions
Jeremy shares what stood out from observing Satya’s leadership style and Microsoft’s strategic plays. He explains how developer ecosystems (VS Code, GitHub) and “social” acquisitions reinforced each other.
- •Create clarity: fewer, sharper priorities and right-sized bets
- •Enable experimentation even when it threatens legacy revenue (VS Code)
- •Acquisitions that fit strategy and culture integration
- •Developer ecosystem flywheel: VS Code/Cursor lineage, GitHub, LinkedIn jobs
- •Enterprise vs startup cloud dynamics (Azure vs AWS)
- 24:48 – 33:23
Climbing the PM ladder: saying no, cutting your own work, and broadening ownership
Jeremy explains how he advanced at Microsoft by creating focus, questioning whether work still mattered, and moving teams/products every ~4 years to keep learning. He emphasizes end-to-end business ownership as the leap to senior leadership.
- •Promotion signal: learning to say no and create clarity
- •Career growth via pruning misaligned work—even your own charter
- •Rotate domains to avoid identity lock-in and stagnation
- •Advance by owning GTM: messaging, onboarding, pricing/packaging, implementation
- •Adapt communication to audience; provide crisp recommendations
- 33:23 – 37:27
Senior leadership “first team” and the trap of staying too long at BigCo
Aakash and Jeremy reinforce that senior leaders’ real team is the cross-functional executive group, not just their function. Jeremy expands on why comfort at large companies can delay growth—while cautioning against leaving too fast to learn consequences.
- •“First team” concept: C-suite alignment as primary job
- •Great products can still lose without GTM and leadership cohesion
- •Comfort as a warning sign; consider switching roles/companies at 3–4 years
- •Don’t job-hop too fast: stay long enough to feel decision outcomes
- •Avoid becoming a ‘mercenary’; build durability and accountability
- 37:27 – 41:47
What PMs should learn from GitHub: developer workflows, technical fluency, and outcome framing
Jeremy outlines the essentials PMs should understand about GitHub and modern software development. He argues technical literacy helps PMs partner with engineers, challenge assumptions, and translate platform work into customer outcomes—especially for AI products.
- •Learn GitHub workflows: PRs, code changes, CI/CD realities
- •Technical fluency as a superpower for prioritization and speed debates
- •Ask “why” to connect engineering work to customer benefit
- •Frame platform work (re-architecture, build times) as customer outcomes
- •AI products require ongoing quality work; beware hype vs real value
- 41:47 – 51:49
VP of Product reality: always-on accountability, GTM pull, and staying close to the product
Jeremy describes VP-level work: incidents, exec visibility, roadmap conversations with big customers, and heavy engagement with sales/SEs. He warns against drifting into pure “translation layer” management and advocates reserving time for IC-level contributions.
- •VP as escalation point: incidents and executive accountability
- •Deep partnership with SEs and sales; roadmap and customer calls
- •Pricing/packaging and billing model changes (e.g., usage-based)
- •Fight calendar overload; block time for real IC work
- •Stay hands-on: use the product, review designs, comment in Figma
- 51:49 – 57:41
Becoming Vanta’s CPO: finding the right growth stage and culture fit
Jeremy shares how he evaluated roles and why Vanta’s stage (post-Series B/C scaling) matched his strengths and life constraints. He details a thorough, trust-building interview process with transparency, IC interactions, and cross-functional exposure.
- •Prefers scaling phase over seed “wilderness”; would rather found than go too early
- •Role discovery via networking, VCs, recruiters, and founder conversations
- •Culture ‘fit’ as crucial as skills—like dating
- •High-trust process: meet ICs, review specs, talk to GTM leaders
- •No surprises onboarding; founder transparency as a signal
- 57:41 – 1:03:46
Vanta’s growth engines: automating compliance into a trust management platform
Jeremy explains Vanta’s original wedge—making SOC 2/ISO audits faster via automation—and how it expanded into broader trust management for both startups and enterprises. He highlights network feedback loops that help security teams connect effort to revenue impact.
- •Wedge: automate painful, costly compliance processes for startups
- •Enterprise value: efficiency for CISOs/security teams
- •Platform pillars: compliance/audit, vendor risk, trust centers, questionnaires
- •Use data from buyer/seller interactions to create a security feedback loop
- •Expand product lines: automation, monitoring, training, risk management
- 1:03:46 – 1:11:10
How Vanta builds: design-forward craft, weekly product deep dives, platform foundations, AI adoption
Jeremy attributes differentiation to customer experience in a category known for poor UX. He describes hands-on operating cadence, platform investments for reusable capabilities, and a pragmatic approach to adopting AI tools with clear security guardrails and internal enablement.
- •Security products often have bad UX; Vanta competes on craft and clarity
- •Weekly demos/Figma walkthroughs (“deep dives”) for fast feedback
- •Broader PM scopes; design empowered and accountable for shipped quality
- •Build a thicker horizontal platform with smaller apps on top
- •AI tooling adoption with guardrails: never put customer data in tools; validate value vs hype
- •Enablement matters: templates + Loom training drove PM adoption of V0
- 1:11:10 – 1:19:37
Evaluating and leveling PMs: the ‘three Bs,’ ambiguity, and advice for brand-new PMs
Jeremy shares how he assesses PMs using a simple archetype model and by how well they handle ambiguity and drive outcomes. He closes with tactical guidance for new PMs: obsess over customer pain, map workflows, quantify ROI, and learn by joining sales calls.
- •Three Bs: Big Brain (strategy), Bulldozer (execution), Bridge Builder (relationships)
- •Progression = ability to solve larger, more ambiguous problems; senior = baseline mastery
- •Staff+ = specialization/superpowers; managers still need outcome ownership
- •New PM playbook: customer interviews, daily workflow mapping, ‘magic wand’ future vision
- •Tie pain to ROI; shadow best AEs via Gong; be able to sell the product
