Mar 19, 2026 · 1h 12m · in-depth
The product wisdom every CPO should ignore | Jeremy Epling (CPO, Vanta)
0:00 / 0:00
▶ Watch on YouTube →
gold bands on the timeline = statements, start to end. Hover to read, click to jump. CC turns on captions
In this in-depth interview, Vanta Chief Product Officer Jeremy Epling outlines the strategic, operational, and cultural shifts required to excel as a modern CPO, sharing tactical frameworks on unified EPD leadership, founder-mode collaboration, GTM alignment, and engineering velocity.
How this conversation actually went
Every chapter scored 0–10 on four independent dynamics. Hover any point for the reasoning behind the score. Brett holds 14.6% of the talking time here. How this is scored →
Brett as informed peer 3.4 Guest teaching 3.8 Guest disagreement 1.3 Brett pushing back 1.5
speaking balance: gold is Brett, purple is the guest (3 minute bins)
Sharpest disagreement ▶ 39:01 Dismissing NPS as unhelpful for product decisions
Jeremy directly dismisses conventional industry reliance on NPS, bluntly asserting it is not useful compared to workflow CSAT and per-product revenue.
Hardest push from Brett ▶ 48:46 Challenging modern management dogma on 1-on-1sBrett pushes back on standard managerial habits by citing Jensen Huang's elimination of 1-on-1s, probing if Jeremy has original rationale for keeping them.
Biggest teaching moment ▶ 36:50 Dissecting the executive megaphone effectJeremy explains the subtle organizational disruption caused when executives comment casually in Figma, detailing practical tagging protocols to avoid unintentional roadmap derailments.
Brett holds their own ▶ 29:01 Drilling into the organizational trade-offs of combining rolesBrett cuts past superficial alignment benefits to force Jeremy into articulating the exact institutional sacrifices of merging engineering and product leadership.
the scores for every segment, with the reasoning behind each
| Chapter | Topic | Brett as informed peer | Guest teaching | Guest disagreement | Brett pushing back | Why |
|---|---|---|---|---|---|---|
| Transitioning from Big Tech to Startup Scale-Ups | 4 | 3 | 1 | 2 | Brett opens by probing why Jeremy succeeded transitioning from big tech to startups when most failed after 90 days. Jeremy explains his internal career moves at Microsoft and how running GitHub independently prepared him. | |
| Commercial Learnings and Pricing Strategies at GitHub | 3 | 4 | 1 | 1 | Brett asks about moving from pure product to full-stack commercial ownership. Jeremy details learnings around SE partnerships, usage-based pricing on GitHub Actions, and COGS management. | |
| Defining Chief Product Officer Excellence and Scope | 3 | 4 | 2 | 2 | Brett asks how to define CPO excellence at a scale-up. Jeremy advocates for founder mode details over professional management class habits and explains balancing pace with quality. | |
| Stepping from VP to CPO: First-Team Mindset | 3 | 4 | 1 | 1 | Brett asks about the gap between VP and CPO roles. Jeremy highlights viewing the executive team as your primary team and owning end-to-end execution without safety nets. | |
| Integrating Product Strategy into Executive Problem-Solving | 4 | 3 | 1 | 2 | Brett pushes on whether a CPO should wear a generalist or functional hat in exec debates. Jeremy clarifies that bringing customer-grounded EPD insights enables fast cross-functional pivots. | |
| Aligning Inherent Tensions Between Product and Revenue | 4 | 4 | 2 | 2 | Brett challenges Jeremy on product-revenue finger-pointing and whether personal rapport solves structural friction. Jeremy breaks down the compensation and timeframe misalignments between sales and EPD. | |
| Healthy Conflict, Concise Documentation, and Decision-Making | 3 | 4 | 1 | 1 | Jeremy discusses fostering healthy conflict, weekly C-suite issue lists, concise documentation, and avoiding ambiguous 'fetch a rock' assignments. | |
| Executive Team Diversity, Underperformance, and Board Scrutiny | 3 | 3 | 1 | 1 | Brett asks about cognitive diversity on executive teams and handling underperforming peers. Jeremy discusses avoiding pure devil's advocates and resolving peer issues directly before escalating to the CEO. | |
| Pros and Cons of Combining Product and Engineering Leadership | 4 | 4 | 1 | 2 | Brett pushes Jeremy to explicitly define the trade-offs of combining product and engineering under one leader. Jeremy highlights faster trade-off resolution against the risk of engineering feeling subordinated. | |
| Partnering Effectively with Product-Focused Founder CEOs | 3 | 4 | 1 | 1 | Jeremy details collaborating with product-centric founder CEOs like Christina Cacioppo and Nat Friedman, welcoming direct CEO involvement while avoiding rigid hierarchy. | |
| Granular Leadership and Managing the Executive Megaphone | 3 | 4 | 2 | 1 | Jeremy explains the danger of the executive megaphone when dropping into IC files, and how prefixing comments with explicit urgency levels prevents unintended roadmap churn. | |
| Defining CPO Impact Metrics and Multi-Product Expansion | 4 | 4 | 2 | 1 | Brett asks how to measure CPO output. Jeremy rejects NPS and outlines tracking per-product revenue, ICP attach rates, and dedicated multi-product sales specialization. | |
| Core Strategic Artifacts: Meta Docs, Roadmaps, and Deep Dives | 3 | 4 | 1 | 1 | Jeremy outlines the concrete artifacts he authors, including the modular multi-tab Product Plan meta-doc, Figma pipeline visuals, and interactive weekly deep dives. | |
| Weekly Operating Cadence, 1-on-1s, and Open Office Hours | 4 | 4 | 2 | 3 | Brett playfully contrasts Jeremy's belief in 1-on-1s with Jensen Huang's zero 1-on-1 philosophy. Jeremy explains why working 1-on-1s and open office hours are essential to avoid public criticism traps. | |
| Individual Contributor Impact and Shadow Org Charts | 3 | 4 | 1 | 2 | Brett asks how informal authority develops in shadow org charts. Jeremy explains how influential ICs bridge technical experimentation with executive communication. | |
| Formative Career Lessons in Craft, Technical Debt, and Empathy | 3 | 4 | 1 | 1 | Jeremy reflects on formative career moments, including having his 'ass handed to him' for shipping a B-tier product and how deep technical grounding gives him a strong PM BS detector. | |
| Managing Absorption Capacity and Engineering Velocity at Scale | 4 | 4 | 1 | 2 | Jeremy breaks down managing team absorption capacity, differentiating junior engineer code velocity from PM strategic onboarding, and maintaining high release tempo. |
Statements from this episode (26)
Epling: Post-acquisition GitHub ran independently on Google tools and AWS
“That company was run very independently. Like, I literally quit Microsoft. Like, your contract ended. It was like, we used all Google tools. Everything was built on AWS. Everything was Zoom. When Satya sent emails to the company, they didn't go to anybody that…”
Epling: Microsoft product teams are disconnected from go-to-market motion
“Like, I feel like there's a lot of great things about Microsoft, but in my experience there, you kind of feel disconnected from the go-to-market motion. Like, it's, it kind of feels like it's on another planet. It's like you're just trying to build the best pr…”
Epling: Sales engineering feedback loops are vital for technical product development
“When you're doing like a technical sale, like GitHub, you know, the SE team plays a huge part. Like AEs are critically important for setting up the relationship, navigating the org chart, doing all those pieces, but building that tight feedback loop of underst…”
Epling: GitHub Actions was GitHub's first usage-based pricing product
“You know, with GitHub Actions, that was, like, one of the products I built while I was there. You know, we were doing usage-based pricing. It was the first time GitHub had ever done usage-based pricing on anything”
Epling: GitHub racked its own Mac hardware in its own data centers
“We actually racked our own Macs in our own data centers there.”
Epling: Product leaders lose touch when acting as purely professional managers
“The more disconnected you get from those, like when you start to become more of like a professional manager, I'm just guiding the team, giving strategy and things. I think you lose a lot in making sure you're building the right thing for customers. Cause if yo…”
Epling: Great companies do not necessarily require well-crafted product design
“Hey, I care a lot about product quality and building an experience that's like well-crafted and beautiful and usable and customers love it. And you don't necessarily have to do that to build a great company.”
Epling: New CPOs mistakenly isolate in EPD instead of the C-suite
“I think when I got this role as my first chief product officer role, I talked to a bunch of my friends that were founders and I was like, Hey, what's the biggest mistake that I would likely make in this role? And they were like, you just focus on engineering p…”
Epling: CPOs spend more time with customers than executive go-to-market leaders
“A difference in the CPO role when how you think about the product versus some of the other team members is just, you're probably spending a lot more time with customers than some of the other people are like, we have amazing go-to-market leaders at GitHub, but…”
Epling: Companies succeed by embracing conflict and viewing escalations positively
“I do think there's always a bit of, like, built-in tension, you know, in the system that I actually don't think is a bad thing. Like, I'm comfortable with conflict and things and thinks, like, companies are more successful and more comfortable they get with co…”
Epling: 80-page PRDs are outdated compared to prototypes and bullet points
“Can we just get some bullet points and, like, make a decision here versus, you know, it's some eighty-page PRD, which I just feel like is kind of, like, pretty outdated at this point. And at that point, I'd much rather just get, like, a V-zero or Figma make pr…”
Epling: Habitual devil's advocacy is counterproductive on executive teams
“I think when it gets, when it feels like someone's just becoming devil's advocate, that becomes negative from my perspective, because it's just like, I'm just trying to find issues in everything and any plan you can find issues in, you know what I mean? So I t…”
Epling: Boards nitpick minor issues more when a startup performs well
“The board is, like, harsher when we're doing well, because there's, like, no real problem to, like, talk about, you know what I mean? So it'll be, like, pushing on all these, like, little things that, like, kind of matter, but not as much, but, like, If anythi…”
Epling: Unifying product and engineering leadership accelerates cross-functional trade-off decisions
“I think what you gain is a faster decision-making process. So when you want to go through and decide, hey, do we need to do this big technical re-architecture, and that's gonna trade off against some product features, you need to go through and, like, make tho…”
Epling: Deep-tech companies need separate CTOs rather than unified EPD leadership
“If I had a company that required super, super deep technical expertise, I think that would be the case where I would be much more skeptical of having a single Person that has it all. And I would want a separate technology officer versus not.”
Epling: Never give a founder CEO complete product ownership without a PM
“I never give them, like, complete ownership, if, like, in that regard, I would say I always assign a PM with it. And it's a PM that's like exciting cause it's cool to work with like the CEO and the founder on things.”
Epling: Leaders at companies under thousands of employees must stay in details
“I think when you're still in the thousands, though, like, you should still be doing it, and I think that's part of our philosophy. Like, at Vanta, I think we really expect people to be in the details, and that's something that I believe a lot. Like, It's just …”
Epling: Senior leaders must label feedback levels to control executive megaphone
“He actually just puts, like, what level of feedback is in front of everything. Like, this is an idea, this is a suggestion, or, like, I expect you to take action on this. I think that's something I've learned from my team, that the, like, the more I've kind of…”
Epling: NPS is not useful compared to workflow-specific satisfaction surveys
“I'm not a big believer in NPS. I know some people like it. Like, I don't think it's like that useful, but I think Going and doing customer satisfaction surveys for, like, core workflows of, like, hey, did this make your life better? Did it not? What were the g…”
Epling: Specialty sellers unlocked growth for Vanta's new products
“And that was like one of the fixes we did this year where we're like, wow, when we talk to the general sellers, they just don't know how to go into these deep conversations for the new product. They're kind of scared about selling it because this thing's alrea…”
Epling: Craft excellence and communicating with leadership are two separate skills
“I do think that being great at your job and being able to talk about it to like the leadership team are two different skills.”
Non-technical PMs struggle to appreciate engineering pain and technical debt
“There's definitely product managers who I think they're, they don't know enough about the technical side, which can be fine, but like can't really appreciate the pain engineering is going through and like what on call is like because like they've never really …”
Epling: AI enables designers to build front-end experiences without technical depth
“Like now with AI, it's like hopefully going to get like, it's just getting more and more easier for people to do that without all that technical expertise.”
Epling: New Vanta engineers must ship to production in week one
“Our expectations, you're going to write a PR your first week and like ship something to production.”
Epling: Engineering teams should target hitting 90% of dates to avoid sandbagging
“We ask people to write dates and commit to them. We expect us to be able to hitting, like, 90% of the dates, which I think is, like, reasonable. If it drops down to 85, I'm not worried. If it drops down to, like, 80 or 75, I start to get worried. Like, I want …”
Epling: Nat Friedman gave GitHub Actions a strict nine-month GA deadline
“Talked to Nat, and he's like, hey, we've got GitHub Actions, and he was like, you have, like, nine months to get this to GA. And there's like no question of like, could I ask for more time or not? But it's like basically build it and get it to GA in nine month…”