Visual summary of operating lessons from Jeremy Epling.

Lessons from Jeremy Epling

Jeremy Epling led product at Microsoft, GitHub, and Vanta, focusing on developer workflows and automated security. This profile details his approach to scaling teams by empowering individual contributors and enforcing fast shipping cycles. It also covers his methods for dodging decision-making traps and building software trust as agentic AI enters the enterprise.

Part 1: Product Strategy and The "Build-First" Philosophy

  1. On rapid prototyping: "If I can show it, I can test it. If I can test it, I can learn." — Source: Executive Function Podcast
  2. On shipping quickly: Delivering a minimum viable product fast is often more valuable than debating hypothetical perfect designs in a conference room. — Source: Product Growth Podcast
  3. On user feedback: Prototypes force real reactions. You cannot get authentic user feedback from an abstract specification document. — Source: Executive Function Podcast
  4. On feature prioritization: The best product strategies focus relentlessly on the workflows developers use every day, not just the edge cases. — Source: Microsoft Azure Blog
  5. On iterative development: Shipping GitHub Actions to general availability in nine months required aggressively narrowing scope and maintaining a relentless focus on the core user journey. — Source: First Round Review
  6. On product pain points: Epling frames product quality around staying close to customers: product leaders should be in sales, demoing the product, studying why deals are won or lost, and feeding that signal back into what the team builds. — Reference: First Round Executive Function interview with Epling on customer proximity and product quality
  7. On continuous learning: The faster a team can move from concept to testable software, the faster they can invalidate bad assumptions. — Source: Executive Function Podcast
  8. On building platforms: When designing developer platforms like Azure DevOps, the goal is to reduce friction so teams can focus on their own code, not the tooling. — Source: Clear Measure Podcast
  9. On product simplicity: Great product management is often about saying no to good ideas to protect the simplicity of the core experience. — Source: Product Growth Podcast
  10. On execution over strategy: A perfect strategy is useless without the organizational velocity to execute it and adapt it based on market feedback. — Source: Executive Function Podcast

Part 2: Navigating AI and the Future of Security

  1. On the AI security equation: "AI has completely changed the security equation. It's creating new risks at unprecedented speed, but it's also one of the most powerful tools we have to strengthen defenses." — Source: MSSP Alert
  2. On agentic AI: Deploying AI agents with "computer use" models requires a fundamental rethinking of system access and governance. — Source: DataFramed Podcast
  3. On automating compliance: "We aren't just helping companies with their audit; we're helping them build a foundation of trust that scales as they grow." — Source: SiliconANGLE
  4. On siloed security: "Risk doesn't live in a single tool, and neither does the exposure that matters most... a siloed system can't see the connection." — Source: Business Wire
  5. On human-in-the-loop AI: While AI can automate evidence collection and vendor reviews, human oversight remains necessary to validate complex security contexts. — Source: DataFramed Podcast
  6. On proactive risk management: By embedding AI into security workflows, teams can shift from constantly fighting fires to managing risk proactively. — Source: SiliconANGLE
  7. On the speed of AI adoption: The rapid integration of AI tools by employees means security teams must adopt automated, continuous monitoring to keep pace. — Source: DataFramed Podcast
  8. On trust as a platform: Modern security platforms must do more than check boxes; they must demonstrate real-time trustworthiness to partners and customers. — Source: Vanta Announcements
  9. On defending against AI threats: The best defense against AI-driven attacks is often using AI-driven automation to enforce internal controls continuously. — Source: MSSP Alert

Part 3: Leadership, Decision-Making, and The "Fetch a Rock" Problem

  1. On the "fetch a rock" anti-pattern: "Someone's like, 'Hey, can you go fetch a rock?' And you're like, 'What rock?' So you bring one and they're like, 'Actually, that's not the right one.' That's the worst." — Source: First Round Review
  2. On setting boundaries: "We try to define boundaries around decisions and ask, 'What data do we all agree we need to make this decision?'" — Source: First Round Review
  3. On executive requests: Leaders must be specific about what constitutes a successful outcome, rather than sending teams on open-ended, ambiguous missions. — Source: Executive Function Podcast
  4. On decision frameworks: Pre-agreeing on the metrics and data required for a decision prevents endless debate and subjective overriding later. — Source: Executive Function Podcast
  5. On leadership alignment: A team's velocity plummets when leadership is misaligned on the core problem they are asking the team to solve. — Source: Product Growth Podcast
  6. On modeling leadership: Learning from effective leaders, like Nat Friedman at GitHub, involves observing how they push teams to achieve faster timelines without burning them out. — Source: First Round Review
  7. On clear constraints: Providing a team with strict constraints often unlocks more creativity than giving them a completely blank slate. — Source: Executive Function Podcast
  8. On avoiding busywork: The "fetch a rock" problem doesn't just waste time; it demoralizes teams who feel their effort is being thrown away due to shifting goalposts. — Source: First Round Review
  9. On data-driven decisions: While intuition is valuable, complex product debates should ultimately be settled by mutually agreed-upon data. — Source: Executive Function Podcast
  10. On empowering teams: True empowerment means defining the "what" and the "why" clearly, and leaving the "how" up to the team's expertise. — Source: Product Growth Podcast

Part 4: Scaling Developer Platforms (From Microsoft to GitHub)

  1. On developer workflows: Building tools that developers love requires deeply understanding their daily friction points, from code commit to deployment. — Source: Microsoft Connect();
  2. On the evolution of TFS: Transitioning Team Foundation Server (TFS) to the cloud as Visual Studio Team Services (VSTS) was a massive architectural and cultural shift for Microsoft. — Source: Azure DevOps Blog
  3. On embracing Git: Microsoft's integration of Git into its enterprise tooling marked a turning point in adopting industry-standard developer workflows. — Source: Azure DevOps Blog
  4. On GitHub Actions: Delivering GitHub Actions to general availability quickly required a highly focused team operating with extreme alignment and urgency. — Source: First Round Review
  5. On platform ecosystems: A successful developer platform relies on a thriving ecosystem of third-party integrations and community contributions. — Source: GitHub Blog
  6. On cloud modernization: Moving enterprise customers to cloud-based DevOps platforms requires balancing new features with strict reliability and data security. — Source: Azure DevOps Blog
  7. On standardizing CI/CD: GitHub Actions aimed to make continuous integration and deployment natively accessible right where the code lives. — Source: GitHub Blog
  8. On enterprise tooling: Tools built for large enterprises must still provide an excellent, intuitive user experience for the individual developer. — Source: Microsoft Connect();
  9. On modernizing legacy systems: Upgrading massive legacy developer platforms involves careful migration strategies so users do not experience workflow disruption. — Source: Azure DevOps Blog

Part 5: Managing Shipping Velocity and Performance

  1. On the value of speed: Maintaining a high shipping velocity is a competitive advantage that compounds over time. — Source: Executive Function Podcast
  2. On startup vs. big tech speed: Startups must rely on raw velocity and tight feedback loops, whereas big tech can often afford to rely on massive distribution. — Source: Product Growth Podcast
  3. On artificial timelines: Setting aggressive, seemingly impossible deadlines can force a team to cut unnecessary scope and find innovative shortcuts. — Source: First Round Review
  4. On performance management: Managing performance in a fast-paced environment requires continuous, direct feedback rather than waiting for annual review cycles. — Source: Executive Function Podcast
  5. On minimizing process: Processes should be added only to solve specific friction points, never for their own sake or out of habit. — Source: Executive Function Podcast
  6. On the "Mission Impossible": When tasked with a seemingly impossible goal, the first step is to ruthlessly strip away everything that isn't absolutely necessary to the core objective. — Source: First Round Review
  7. On team momentum: Shipping frequently builds a rhythm of success that keeps engineering and product teams motivated. — Source: Product Growth Podcast
  8. On overcoming perfectionism: Waiting until a feature is completely flawless guarantees it will ship too late; getting it "good enough" for user testing is the priority. — Source: Executive Function Podcast
  9. On unblocking teams: A leader's primary role during a sprint is to rapidly clear away organizational hurdles so the team can maintain their pace. — Source: First Round Review
  10. On evaluating speed: You measure a team's true velocity not just by how much they output, but by how quickly they iterate based on user reactions. — Source: Product Growth Podcast

Part 6: Empowering and Celebrating Individual Contributors (ICs)

  1. On recognizing talent: "I always look for the influencers in my org. A lot of companies don't celebrate ICs enough." — Source: First Round Review
  2. On IC influence: Individual contributors are often the ones driving the most important technical decisions, even if they lack a formal management title. — Source: First Round Review
  3. On executive communication: "They're usually extremely good at what they do. They can communicate it well to executives. And I think that is a skill." — Source: First Round Review
  4. On building trust: Keeping a close relationship with senior ICs provides a leader with an unfiltered view of the reality on the ground. — Source: Executive Function Podcast
  5. On career paths: Organizations must create viable, prestigious career tracks for senior technical talent who do not want to become people managers. — Source: Product Growth Podcast
  6. On hidden leaders: The true leaders of a technical project are often the ICs whose opinions the rest of the team quietly defers to. — Source: First Round Review
  7. On leaning on expertise: When solving a complex architectural problem, a product leader should draw heavily upon the deep domain knowledge of their senior engineers. — Source: Executive Function Podcast
  8. On rewarding impact: Recognition and compensation systems should accurately reflect the massive outsized impact a top-tier IC can have on a product's success. — Source: Product Growth Podcast
  9. On cultivating culture: Celebrating the achievements of ICs publicly helps foster a culture where technical excellence is prioritized over political maneuvering. — Source: First Round Review

Part 7: The "Shift Left" Movement in Development and Operations

  1. On developer responsibility: "We're moving towards a world where security, testing, and even responsibility for production operations are shifting left towards the developer." — Source: Datadog Summit
  2. On integrating security: Security can no longer be an afterthought applied before deployment; it must be embedded directly into the developer's daily workflow. — Source: Vanta Blog
  3. On DevOps culture: The essence of DevOps is breaking down the silos between writing code and maintaining that code in production. — Source: Clear Measure Podcast
  4. On automated testing: Shifting left requires reliable, fast automated testing to catch regressions at the pull request stage, not in staging. — Source: Azure DevOps Blog
  5. On developer experience (DX): If you ask developers to take on security and operations tasks, you must provide tools that make those tasks seamless and intuitive. — Source: Datadog Summit
  6. On early feedback loops: The earlier a developer gets feedback on code quality and security vulnerabilities, the cheaper and faster they are to fix. — Source: Clear Measure Podcast
  7. On empowering developers: Shifting left isn't just about shifting burden; it is about giving developers the autonomy and tools to ship safely on their own. — Source: GitHub Blog
  8. On continuous compliance: By shifting compliance checks earlier into the pipeline, teams can avoid the massive slowdowns associated with traditional audit periods. — Source: Vanta Blog
  9. On toolchain integration: The most successful development pipelines integrate security and operations seamlessly into the source control and CI/CD tools developers already use. — Source: Azure DevOps Blog

Part 8: Transitioning from Big Tech to High-Growth Startups

  1. On adapting to startups: Moving from a massive enterprise like Microsoft to a startup requires unlearning heavy corporate processes and embracing ambiguity. — Source: Executive Function Podcast
  2. On the "bridge" role: Working at GitHub served as an ideal transition phase, blending Microsoft's scale with a more agile, developer-first startup culture. — Source: First Round Review
  3. On resource constraints: In a startup, you cannot rely on massive specialized teams to solve problems; product leaders must be willing to roll up their sleeves. — Source: Product Growth Podcast
  4. On risk tolerance: Startups inherently require a much higher tolerance for risk and a willingness to ship experimental features that a big tech company might veto. — Source: Executive Function Podcast
  5. On customer proximity: At a startup, product leaders have a much more direct, unfiltered line of communication with early customers, which is vital for finding product-market fit. — Source: Product Growth Podcast
  6. On hiring for growth: Recruiting for a startup means finding adaptable builders who thrive in chaos, rather than specialists who need structured environments. — Source: Executive Function Podcast
  7. On organizational agility: The primary advantage a startup has over an incumbent is the speed of its decision-making loop; leaders must fiercely protect that agility. — Source: Product Growth Podcast
  8. On redefining success: Success in big tech might mean a fractional increase in retention for millions of users, whereas startup success often means proving a core hypothesis from scratch. — Source: First Round Review
  9. On bringing big tech lessons: While shedding heavy processes is necessary, startups greatly benefit from the rigorous data hygiene and scalable architectural thinking learned at large enterprises. — Source: Executive Function Podcast