Learn what separates exceptional CPOs from average ones. Jeremy Epling shares 20+ years of product leadership insights on execution, strategy, and team build...
What Every Chief Product Officer Should Know: Real Insights from a Vanta CPO
Key Takeaways
- Being detail-oriented is essential: Modern CPOs must immerse themselves in product details, customer interactions, and team dynamics rather than defaulting to pure strategic management
- Founder mode thinking matters: Whether formally "founder mode" or not, successful CPOs operate with deep engagement in product decisions, sales cycles, and customer feedback loops
- Speed and quality aren't mutually exclusive: Leading companies balance rapid feature delivery with maintaining high product standards through careful absorption capacity planning
- Executive alignment drives results: The relationship between CPO and CEO (especially founder-CEOs) determines organizational success more than any single strategic decision
- Full-stack leadership requires learning: Understanding engineering, design, sales, marketing, and financial impacts of product decisions takes intentional effort and diverse experiences
Understanding the Modern Chief Product Officer Role
The role of a Chief Product Officer has fundamentally transformed over the past decade. What once might have been primarily a strategic position—setting vision and delegating execution—has evolved into something far more hands-on and operationally intensive. Jeremy Epling, Chief Product Officer at Vanta, brings over 20 years of product leadership experience, having spent significant time at Microsoft, GitHub, and various scale-up environments. His journey reveals critical insights about what separates exceptional CPOs from those who struggle with the role's complexity.
When Epling transitioned from a 20-year career at Microsoft to leading product at a rapidly scaling company, many observers expected the typical failure pattern: the executive from a massive corporation joins a startup, realizes the context is entirely different, and returns to the familiar structure within 90 days. Epling didn't follow this script. Instead, he discovered something crucial during his time at GitHub after Microsoft's acquisition: the intersection of product excellence, go-to-market execution, and financial impact creates the most rewarding work in technology leadership.
His path from individual contributor roles in Windows and Internet Explorer to leading product development at GitHub to his current position as CPO at Vanta demonstrates how diverse product experiences build the judgment required for executive success. More importantly, his trajectory shows that effective CPOs don't abandon their deep technical understanding or product intuition when they reach the C-suite. Rather, they expand their toolkit to encompass commercial, organizational, and strategic dimensions while maintaining their connection to the details that matter most.
The Detail-Oriented CPO: Why Surface-Level Leadership Fails
One of the most controversial aspects of modern product leadership philosophy involves the concept of "founder mode"—the idea that leaders should remain deeply embedded in operational details rather than transitioning to pure strategic oversight. Epling stands firmly in the "founder mode" camp, though he acknowledges this philosophy isn't universally accepted.
The reasoning is straightforward: when CPOs become disconnected from product details, customer interactions, and implementation realities, they inevitably make decisions that don't align with what's actually happening in the market. This disconnect often leads to what Epling calls the "professional management class" problem, where leaders who haven't used the product in weeks, haven't attended customer calls in months, and aren't deeply familiar with engineering constraints end up steering the company toward confused, unfocused product strategies.
At Microsoft, despite its excellence in many areas, Epling felt this disconnection acutely. Product teams operated in one silo while go-to-market efforts happened "on another planet." The business made money, certainly, but there was a fundamental separation between building great products and understanding how those products created customer value. GitHub, by contrast, showed him what happens when a Chief Product Officer maintains deep involvement across the entire business spectrum.
This manifests in several concrete practices. Epling maintains what he calls "individual contributor time" every morning—typically two to three hours protected from meetings. During this time, he uses the product extensively, logging bugs, evaluating whether features feel right, and assessing whether the company is headed in the right direction. He regularly spends time in customer meetings, both for roadmap conversations and handling escalations. He reviews Figma files and design decisions, leaving comments and feedback that keep him connected to the actual user experience being created.
This approach seems counterintuitive for someone with the title "Chief Product Officer" at a rapidly scaling company. Shouldn't this person be focused entirely on strategy and organizational structure? Epling's experience suggests the opposite: the greatest strategic value a CPO can provide comes from deeply understanding what's actually working, what customers genuinely need, and where engineering is struggling. Without this ground-truth understanding, strategy becomes disconnected theory.
The challenge, however, is clear communication. As a leader's title becomes more senior, even casual comments can be misinterpreted as directives. Epling has learned to be explicit about the nature of feedback he provides. When leaving comments in design files, he clarifies whether he's offering ideas, suggestions, or expected changes. When providing strategic input, he often repeats himself multiple times, sometimes even using capital letters to ensure people understand he's brainstorming rather than mandating a roadmap change.
Building Excellence: The Intersection of Speed and Quality
The scale-up phase presents a unique challenge for product leaders: how do you maintain velocity and quality while your engineering team is growing at an extraordinary rate? At Vanta, Epling's team has hired 50 engineers per quarter for over a year, with plans to continue this trajectory. This creates an environment where roughly 20% of the organization has less than three months tenure.
The conventional wisdom suggests that rapid growth necessitates choosing between speed and quality. Build fast and accept lower quality, or slow down and maintain standards. Epling's approach rejects this false choice. Instead, he introduced a framework called "absorption capacity"—the maximum number of new people a team can onboard and assimilate while maintaining current delivery velocity.
This absorption capacity varies dramatically by organizational area. Teams working with newer, well-architected codebases can absorb new engineers quickly; they can immediately start contributing in isolated areas. Teams maintaining older, more complex systems require more senior people and have much lower absorption capacity. These distinctions matter because hiring without regard to absorption capacity leads to exactly what happened to Epling at GitHub: the company hired aggressively, ramped people up, and then laid many of them off once the business slowed. The human cost aside, the economic waste is staggering—all that time and resources spent on hiring and onboarding disappeared.
The quality discussion itself required a delicate navigation. When Epling joined Vanta, the culture was heavily focused on delivery velocity—"deliver, deliver, deliver" was the mantra. His team was initially uncertain whether emphasizing quality would conflict with this philosophy. After alignment with CEO Christina Lenhardt, Epling introduced metrics that captured both dimensions: features announced per ramped engineer, ramp-up time using developer analytics tools, and quality measures.
The goal is specific: every engineer, even junior ones, should submit a pull request and ship something to production within their first week. This immediate contribution builds momentum and provides learning velocity. Over time, engineers build context and understanding, but that delayed context doesn't mean they shouldn't eventually become expert advisors on product strategy.
The ramp-up philosophy differs notably between disciplines. For engineers, especially junior ones, the goal is slinging code as quickly as possible. For product and design roles, the priority flips: understanding overall strategy, company direction, and broader product context becomes paramount because their decisions have massive blast radius effects across the organization. A confused product decision can confuse 30 engineers downstream.
Epling tracks productivity and delivery metrics at the squad level (roughly 8-10 engineers, one product manager, sometimes a designer) and reviews how time is distributed: what percentage is "keeping the lights on," what goes to architectural work and technical debt, and what constitutes new customer-facing functionality. The goal is roughly 90% on-time delivery of committed dates. If this drops to 80-85%, he becomes concerned about either overly conservative estimates or systemic slowdowns.
The C-Team Dynamic: How Executive Relationships Drive Outcomes
Perhaps the most underappreciated lesson from senior product leadership is how much organizational success depends on the relationships between C-team members, particularly between the CPO and CEO. When asked what advice he received when transitioning to his first CPO role, Epling recalls friends warning him about the most common mistake: focusing exclusively on engineering, product, and design while ignoring the broader C-team dynamics.
This happened despite these being his "happy place"—the areas where he naturally spent the most time and found the most fulfillment. Yet, without connecting these functional areas across the broader business, the CPO's impact remains fundamentally limited. The C-team becomes the primary stakeholder, which means the CPO's first team isn't product managers or engineers—it's the other executives.
This shift in perspective changes everything. When a Chief Revenue Officer raises concerns about declining win rates, the CPO can't simply retreat to product arguments. Instead, this becomes an opportunity for cross-functional problem-solving. Is the issue product features? Pricing and packaging? Sales training and enablement? Competitive positioning? Market changes? Most likely, it's some combination, requiring input from marketing, finance, data, product, and sales working collaboratively.
Epling describes this process with concrete examples. When win rates dip, the CRO might bring this concern to the C-team. Rather than the CPO becoming defensive or the CRO blaming product, the group engages collectively. They examine the data together, consider multiple hypotheses, and work through whether changes are needed in the roadmap, messaging, competitive positioning, or sales strategy. Sometimes they discover that the product is indeed the constraint. Other times, they realize the issue is sales training or market positioning, where product changes aren't the solution.
This collaborative model requires explicit structural support. Epling and his CEO, Christina Lenhardt, meet weekly with the full C-team. Anyone can add agenda items. Discussions are explicit and direct—"I'm worried about declining ACVs" or "I want to reallocate resources to this opportunity; how does this affect your plans?" These meetings serve as the mechanism for building genuine alignment before decisions are implemented.
The prevention of blame culture isn't accomplished through polite, conflict-avoidant management. Rather, it's built through direct communication, shared problem-solving frameworks, and explicit conversations about tension points. The revenue team and product team naturally have different time horizons and incentive structures. Revenue teams operate on monthly or quarterly quotas; product teams think in quarters or years. Revenue teams are inherently reactive to immediate customer needs; product teams must balance reactive customer requests with long-term strategy.
Rather than pretending this tension doesn't exist, Epling and his organization acknowledge it and work with it. The key is ensuring both perspectives are heard and that decisions come from genuine problem-solving rather than internal politics. This requires the CPO and CRO to genuinely respect each other's perspectives and be willing to challenge assumptions collaboratively.
Navigating CEO Relationships: Founder-Mode CEOs and CPO Autonomy
One of the most delicate dynamics in scale-up companies involves the relationship between a CPO and a founder-CEO, especially when the founder built the company on strong product intuition and judgment. These relationships can range from deeply collaborative to adversarial, and the success often depends less on formal structures and more on explicit conversations about how they'll work together.
Epling's approach with Christina Lenhardt exemplifies this. Rather than assuming he should own product strategy exclusively or compete for influence, he spent substantial time understanding what excites Lenhardt, where she wants to stay involved, which decisions bore her, and where his perspective adds the most value. This mind-melding on fundamentals—what makes a great product, what decision-making approaches matter most—prevents the constant left-vs.-right conflict that derails many CPO-CEO relationships.
When Lenhardt became excited about a partnership opportunity and wanted to develop the initial product requirements and vision herself, Epling didn't see this as an encroachment on his territory. Instead, he offered to help—"Do you want to run with this?" When she confirmed she did, he simply told his team to work with Christina and allocated his own time elsewhere. He didn't feel disempowered; he recognized that she needed "spark of joy" in her CEO work and that this project provided it.
This doesn't mean the CPO abdicates responsibility. Epling still assigns a product manager and designer to work alongside Lenhardt, ensuring that her high-level concepts and excitement get translated into practical execution details. This protects her from getting pulled into the detailed minutiae while ensuring the vision remains coherent as it's implemented.
The arrangement reflects a deeper philosophy: in scale-up environments where the company has thousands of employees but still expects hands-on leadership, the CEO can't possibly operate effectively in all functional areas. Lenhardt is excellent at product strategy and excited about customer interactions, but having a CPO handle the day-to-day trade-offs between feature requests, architecture improvements, and technical debt means she can focus on broader company strategy, fundraising, board management, and the relationships that determine company trajectory.
The risk Epling acknowledges is that this arrangement could create a perception that engineering isn't valued—that since engineering reports to the CPO rather than the CEO, it's somehow less important. He works actively to counter this narrative. His engineering leader owns the engineering discipline, hiring, and budget. Epling treats the relationship as peer-based while maintaining his role as manager. They work "in this together," collaborating to build the product and company they envision.
Executive Influence Beyond the Org Chart
Most organizations have an official structure—directors report to VPs, VPs report to the C-suite—but the actual influence flows differ significantly from what the org chart depicts. Some individual contributors without managerial titles wield enormous influence across the organization. Understanding who these people are and how they accumulated influence provides insight into organizational dynamics.
These influential individual contributors typically share several characteristics. First, they're exceptional at their craft—whether that's engineering, design, product, or something else. They've demonstrated such clear excellence that people naturally trust their judgment. Second, they've developed the ability to communicate their thinking to executives in ways that land effectively. This isn't about politics or manipulation; it's about understanding how to make complex ideas accessible and compelling.
Third, they tend to be visionary—staying attuned to industry changes, emerging trends, and future possibilities. When something significant happens in their field, they don't just notice it; they often prototype something, explore the implications, and bring back concrete evidence of why it matters. They "set things up on a platter" for the organization, making it easy for others to get excited about new directions.
Fourth, they're typically well-connected and socially capable of spreading ideas through the organization. They bring up important concepts in meetings, discuss them in all-hands events, and naturally influence how teams think about future direction. Importantly, however, they're not necessarily the stereotype of social butterflies. Many are introverted engineers who simply have a knack for making ideas resonate.
The risk with informal influence is that it can create in-groups and out-groups, where some people feel excluded from important conversations while others seem to have special access to leadership. Epling addresses this intentionally. He ensures that influential contributors aren't invited to every C-team meeting or special initiative, which would create a parallel hierarchy. Instead, he keeps things informal—"If you know something better than me, go work on it directly with the CEO"—without creating a formal tier of special contributors.
The philosophy is that exceptional work and clear thinking should drive influence, not position on the org chart. People at any level can have outsized impact if they demonstrate excellence and can articulate why their ideas matter. Simultaneously, the company actively prevents this from becoming a source of resentment or exclusion by keeping the boundaries implicit and inclusive rather than formal and elite.
The CPO as Full-Stack Leader: Skills That Don't Come Naturally
Rising through product leadership ranks, Epling accumulated advantages that made the CPO role more achievable than it is for many. He coded in high school and built websites for customers, giving him early empathy for engineering. He spent years in various product roles, understanding go-to-market dynamics. He worked at GitHub immediately after the Microsoft acquisition, giving him a unique window into how a high-quality product company operates across all functions.
Yet, despite these advantages, numerous skills required learning and practice. Public speaking and presenting—the kind of polished, rehearsed delivery required for major product announcements—took deliberate effort. Epling remembers being intensely stressed before the GitHub Actions announcement, having rehearsed his demo script 40+ times before it felt natural. Now, with more experience, a rehearsal or two suffices.
Motivating teams at scale, especially in all-hands settings, requires different skills than one-on-one coaching. Performance-related tasks—the ability to "turn it on" when recruiting candidates, shifting into "sell mode" when presenting to customers or board members, delivering bad news with clarity and compassion—these all required learning and repetition. Some people have natural talent for these skills; others have to work significantly harder.
The most valuable learning, however, came from working with exceptional mentors. Nat Friedman, the founder and CEO of GitHub, profoundly influenced how Epling approaches product leadership. When Microsoft acquired GitHub, Epling received a clear nine-month deadline to bring GitHub Actions to general availability. There was no negotiation on the timeline; the goal was simply to build something customers loved and deliver it quickly. Without explicitly coaching on every decision, Friedman's conviction that this was possible—combined with occasional guidance on approach—created the conditions for Epling to exceed what he thought achievable.
This experience taught Epling something he now tries to provide for his own team: the ability to extract excellence from people by believing in their potential, giving them clarity on what matters, and pushing them toward ambitious but achievable goals. The goal isn't to burn people out with unrealistic demands. Rather, it's to create conditions where people walk away from their tenure having done better work than they thought possible, feeling like they achieved something genuinely great.
Decision-Making Frameworks: Data, Disagreement, and Unified Execution
Operating at the C-level requires making consequential decisions with incomplete information, managing disagreement, and ensuring organizational alignment even when not everyone agrees with the final direction. Epling's approach is systematic but not rigid.
When facing a significant decision, his first question is always: "What data do we need to make this decision confidently?" Sometimes that data is hard numbers—customer usage patterns, win-rate trends, revenue impact analysis. Other times it's informed gut feeling based on deep customer exposure and market understanding. The key is establishing agreed-upon information requirements upfront, rather than what Epling calls "the fetch a rock scenario," where someone vaguely asks for analysis and you bring back data they didn't actually want.
He's a strong proponent of documentation and brevity. Rather than extensive written analyses, Epling prefers concise documents with bullet points, visual prototypes, Figma mockups, or simple pictures of customer experiences. His personal motto is "clarity through brevity." This approach accelerates decision-making because people understand the actual question being asked and what information is needed to answer it.
When disagreement arises, Epling values direct communication. If someone raises a concern, his instinct is to address it immediately: "Great, let's talk about it." He abhors the alternative—fragmented one-on-one discussions where some people feel out of the loop or hear secondhand accounts of decisions. This takes discipline, especially when feedback might be harsh or uncomfortable, but the alternative is worse: rumors, resentment, and fractured alignment.
At the same time, he recognizes that constant disagreement is exhausting and unproductive. Having someone play perpetual devil's advocate ensures every plan gets picked apart, but the cost is that no one feels confident moving forward. Instead, his approach is to identify the most impactful questions or concerns. For annual planning, he asks executives to list their top five questions about the plan. The team addresses these critical questions thoroughly. Once answered, they assess whether everyone feels comfortable proceeding.
This allows for genuine challenge without paralysis. There are always more questions and edge cases to examine, but focusing on truly important concerns is key. A certain amount of challenge is necessary to push the company toward better outcomes, but beyond a point, it becomes counterproductive.
Once a decision is made—even if someone disagreed with it—the expectation is unified commitment. Epling has been proven wrong after disagreeing with decisions, and he's also been right when the group went a different direction. Either way, the team presents a unified front and executes as if the decision was a collective one. This "disagree and commit" model is critical because a divided executive team filters down into organizational confusion.
The Product Manager's Core Responsibility: Understanding Revenue Through the Product Lens
As a CPO, Epling's output ultimately boils down to whether customers love the product. This gets measured through win rates, customer satisfaction in specific core workflows, and velocity of new feature development. But beyond exciting individual features, a great product also requires vision—an inspiring, differentiated direction that customers and teams can rally behind.
Beyond win rates and satisfaction, Epling tracks per-product revenue obsessively. Most revenue analysis segments by new logos versus expansion, by geography, by sales rep, and by customer segment. Epling's finance team built a dashboard that segments revenue by product line instead. This reveals whether investments in particular products translate into higher Annual Contract Values, whether they're actually being sold, what attach rates look like across customer segments, and whether products reach their intended personas.
This is more complex than it sounds. Vanta sells multiple products—a core compliance automation platform, a customer trust product, and various add-ons. If a new product isn't selling well, the question isn't automatically "the product is bad." It might be that specialists are needed to sell it (general sellers don't have time to learn new products when existing ones meet their quotas), or the go-to-market motion is wrong, or the product actually does need improvement. This year, Vanta introduced specialty sellers specifically focused on new products, and sales improved significantly. This suggests the product was fine but the sales motion was missing.
Epling maintains a comprehensive "product plan document"—a meta-document outlining every core product, its intended persona, the customer problem it solves, its value proposition, and key differentiators. The document tracks when new features ship and how they enable customer acquisition, whether that's moving upmarket into larger companies or reaching new customer profiles. This raw material aligns the entire EPD team on who they're building for and how they plan to win in the market.
The document also includes timing information that informs marketing and sales. If Vanta expects to win certain customer segments in Q2 next year, the go-to-market teams can plan campaigns accordingly. Sales can forecast improvements in win rates for specific segments. Finance can model revenue impact. However, Epling has learned that while this document is invaluable raw material for product marketing managers and strategic planning, it can overwhelm field sales. When you're shipping over 100 feature updates per quarter, account executives struggle to identify what's actually important amid the noise.
The solution involves effective enablement: distilling the comprehensive product document into what different audiences need. Sales leaders need to understand what new customer profiles the company is pursuing. Executives need to see the long-term revenue potential (using emojis in Figma to denote products with potential for $100M+ in revenue versus smaller add-ons). Marketing needs to understand positioning and messaging angles. The same underlying information gets translated into multiple formats for different audiences.
Team Dynamics: One-on-Ones, Office Hours, and Psychological Safety
Operating at Vanta's scale with dozens of direct and indirect reports requires intentional systems for maintaining relationships and psychological safety. Despite some prominent voices (like Jensen at NVIDIA) running organizations without formal one-on-ones, Epling remains convinced of their value.
Weekly one-on-ones with direct reports aren't about status updates—those happen asynchronously through documentation and direct messages. Instead, one-on-ones are for working through problems together, discussing strategic questions, and building the kind of relationship where people feel psychologically safe bringing real concerns or uncertainties. Even a tight 30 minutes matters significantly.
For broader team members, Epling maintains monthly one-on-ones and "office hours"—an hour and a half weekly where anyone in the company can book 20-minute slots to discuss anything. Sometimes these are from excited new hires wanting to meet leadership. Other times, they're detailed technical discussions with staff engineers. Sometimes people want to discuss an opinionated design decision or get feedback on a proposal.
The value of these interactions goes beyond the immediate content discussed. They demystify who he is and what he does. He tries to be vulnerable with teams, discussing mistakes he's responsible for and lessons learned. This signals that high performers also struggle, learn, and iterate—they're not infallible. When people see leaders at various levels operating this way, hierarchy becomes less intimidating.
However, Epling has learned that people respond differently to feedback and communication styles. Some people are completely comfortable with direct challenge in group settings; others find public feedback triggering and perform worse if they feel criticized in front of peers. Rather than forcing everyone to adapt to his communication style, he adapts to people. Some direct reports get longer one-on-ones specifically because individual settings help them do better work. Is that extra 30 minutes per week per person expensive? In terms of time, yes, but it's completely worth the productivity improvement.
This flexibility reflects a broader principle: companies and teams are complex organisms. When someone (like Jensen) has been running an organization without formal one-on-ones for decades, that system has likely attracted people who thrive in that environment. Trying to transplant that approach into a different organization with different people often fails because people didn't opt into that system—they joined when different norms were in place.
The Value of Diverse Product Experiences
Looking back across 20+ years in product, Epling's varied experiences—building websites in high school, working deep technical roles at Microsoft, experiencing the go-to-market complexity at GitHub, and now scaling product at Vanta—have been invaluable in ways he couldn't have predicted.
His early coding experience meant he never lost empathy for what engineering actually entails. Many product managers without technical backgrounds struggle to assess the validity of engineering constraints. Epling knows what it feels like to be on-call, to maintain legacy systems, to realize mid-project that the architecture decision three months ago is now limiting what's possible. This isn't theoretical knowledge; it's lived experience that gives him credibility and better judgment.
His design exposure, particularly at GitHub under design leader Max Kanat-Alexander, opened his eyes to what truly excellent product experiences require. GitHub maintained an extraordinarily high bar for design and user experience quality. That experience fundamentally shaped how Epling thinks about whether a product is ready to ship. It's not enough that features work; they need to feel right, be usable, and provide a delightful rather than merely functional experience.
This is a choice, not a requirement. You can build successful companies without exceptional product experiences. But for Epling personally, and for the companies he wants to work with, product quality and craft matter enormously. Early in his CPO journey at Vanta, he was explicit about this with the CEO: "I care a lot about product quality and building an experience that's well-crafted, beautiful, and usable. You don't necessarily have to do that to build a great company. But I will chafe against the system if you don't also value it. So, are we aligned on this, or should you hire someone else?"
This clarity prevented the frustration that would have resulted from joined working at a company that didn't share his values around product quality.
Conclusion
The role of Chief Product Officer has evolved from a position focused primarily on vision and strategy into something far more operationally complex and rewarding. Jeremy Epling's 20+ years of experience reveals that exceptional CPOs combine several typically contradictory qualities: they're detail-oriented yet strategic, deeply engaged with customers and teams yet connected across the entire business, decisive yet collaborative, and ambitious yet realistic about what's achievable.
The path from individual contributor through various product leadership roles to CPO requires learning skills that don't come naturally, working with great mentors who push you beyond what you think possible, and maintaining genuine commitment to helping your team do better work than they ever thought they could. The best CPOs extract excellence from organizations not through command-and-control structures, but through clarity, direct communication, psychological safety, and genuine investment in their teams' growth.
If you're navigating product leadership at any level—whether as a junior product manager, senior leader, or someone making the transition to executive roles—the principles explored here offer concrete guidance: stay connected to the details that matter, build genuine relationships across your organization, balance ambition with realism, and remember that your primary job is enabling your team to do their best work. That's not just good management; it's the foundation of building products that customers love and organizations that people want to work for.
Original source: The product wisdom every CPO should ignore | Jeremy Epling (CPO, Vanta)
powered by osmu.app