How to Create Deep Partnerships with Technical Teams: Sales Engineering Lessons Learned

How to Create Deep Partnerships with Technical Teams: Sales Engineering Lessons Learned

Speakers: Samantha Pearlstein (Founding Sales Engineer, Escape)

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=pKvBw_03dIc

Overview

In this insightful talk, Samantha Pearlstein, Founding Sales Engineer at Escape, addresses a pervasive challenge in the cybersecurity industry: the often-strained relationship between security teams and the vendors attempting to solve their problems. Pearlstein candidly acknowledges the prevalent "vendor sigh" – the weariness and skepticism security professionals often feel when yet another vendor calls, laden with promises that may or may not materialize. Her mission is to transform these transactional interactions into "deep partnerships" that are not merely beneficial but "magical," enabling security teams to enhance efficiency and secure systems faster.

Pearlstein, drawing upon a decade of experience partnering with security teams across diverse industries, from startups to Fortune 100 companies, distills her expertise into five actionable lessons. These lessons form a practical framework for both vendors and security teams to collaborate more effectively, fostering trust, transparency, and mutual success. The talk is a critical guide for anyone involved in the evaluation, acquisition, or deployment of security technologies, aiming to bridge the gap between product capabilities and genuine customer needs.

The core message resonates with the idea that while vendors aim to sell and security teams aim to secure, the most effective path forward lies in genuine collaboration. By focusing on shared understanding, clear expectations, and consistent engagement, what often begins as a necessary evil can evolve into a powerful catalyst for innovation and strengthened security posture, turning potential detractors into strategic enablers.

Background

▶ Watch: Introduction and the common 'vendor sigh' problem. (0:00)

The landscape of cybersecurity is complex and constantly evolving, leading to an proliferation of security tools and vendors, each promising to solve critical problems. For the security teams on the front lines, this environment often translates into overwhelming pressure. As Pearlstein highlights, these teams are "overwhelmed and they have a lot to do and not enough time to solve those problems." This creates a fertile ground for frustration, as many security professionals have experienced unfulfilled promises or tools that don't quite fit their unique environments, leading to a deep-seated "discomfort" with vendor engagements. The "vendor sigh" isn't just a sign of fatigue; it's a symptom of a broken trust model.

Samantha Pearlstein's role as a Sales Engineer (SE) places her uniquely at this intersection. An SE acts as the technical bridge between a sales team and the prospective customer's technical staff, demonstrating product capabilities, addressing technical questions, and ensuring the proposed solution aligns with the customer's specific technical requirements. Pearlstein's company, Escape, specializes in Dynamic Application Security Testing (DAST) and Application Security Management (ASM) for modern applications, placing her directly in the realm of helping AppSec teams solve their technical challenges. Her background as a security consultant at Accenture, where she led a cybersecurity innovation hub, further underscores her deep understanding of both the technical intricacies of security and the practical realities faced by enterprise security teams. This dual perspective informs her approach to fostering partnerships, recognizing that a purely sales-driven or purely technical approach will ultimately fall short. The problem, as she frames it, is not just about having the right tools, but about forging the right relationships to effectively leverage those tools.

Key Findings

▶ Watch: Overview of the five key lessons for partnerships. (2:30)

Pearlstein's talk outlines five fundamental lessons learned from her extensive experience, which serve as the "key findings" for building successful technical partnerships:

1. Technical Credibility: This is a two-way street, requiring both the vendor and the customer to actively contribute. For the vendor, it means being genuinely curious, asking insightful questions, and deeply understanding their own platform. For the customer, it involves providing comprehensive context, detailed needs, and specific challenges. The goal is a shared technical understanding, not just a vendor presenting a solution. Pearlstein stresses that silence from the customer during a demo is her "greatest fear" because feedback is crucial for tailoring the best technical solution.

1. Radical Transparency: This principle emphasizes uncomfortable honesty. Instead of hiding limitations, bugs, or roadmap uncertainties, both parties should be upfront. Pearlstein advises providing context, explanations, and timelines when discussing issues. She gives examples like "we found this bug, here's what we're doing about it, we'll fix it by this date" rather than ignoring it. This builds trust and ensures that time and resources are not wasted on misaligned expectations, ultimately leading to smoother engagements and happier outcomes.

1. Shared Success Metrics: Deemed the "most important" lesson, this involves defining clear, measurable criteria for success before any product testing or engagement begins. These metrics must be in the customer's own words and serve as the "ground of truth" for the entire partnership. Key questions include: "What problems are you trying to solve?", "How will we measure it?", "Who decides when we’re done?", and "What are the key requirements?" These criteria, once aligned upon and set in stone, should guide all subsequent interactions and be regularly revisited.

1. Consistent Communication: A "quiet PoC is the only one that fails silently." Pearlstein stresses the importance of a clear communication cadence, defined channels (email, Slack, Teams, Discord), and regular updates after milestones and meetings. Crucially, every interaction should conclude with clearly articulated next steps, ensuring both the vendor and customer know their responsibilities and timelines to keep the project on track. Consistency is prioritized over perfection in communication.

1. Celebrating Small Things: While the ultimate goal is a "big win" (like a deal closure), the journey is paved with small victories that build commitment, credibility, and trust. This includes actions like troubleshooting an issue, re-trying a bug, improving documentation based on feedback, or simply providing clear meeting notes. These "little things" create a "ripple effect for advocacy," demonstrating genuine partnership and the vendor's commitment to the customer's best interest.

Technical Deep Dive

▶ Watch: Lesson 1: Technical Credibility is a two-way street. (3:00)

While the talk is not a deep dive into specific security vulnerabilities or tool architectures, it provides a crucial "technical deep dive" into the process of effective technical engagement between vendors and security teams. Pearlstein, as a Sales Engineer at Escape, a vendor specializing in DAST and ASM for modern applications, operates at the intersection of complex technical solutions and customer needs. Her insights are fundamentally about how to navigate this technical terrain collaboratively.

The concept of Technical Credibility is paramount. Pearlstein clarifies that this doesn't mean the sales engineer is a "tech wizard" in the customer's specific environment, but rather an expert in their own product and a skilled interrogator of the customer's context. On the vendor side, technical credibility is built by being "curious and asking the right questions." This involves understanding the customer's existing tools, authentication mechanisms, frameworks, and overall technical environment, even if the SE isn't a developer in that specific stack. The SE's expertise lies in knowing what questions to ask to map their product's capabilities to the customer's unique technical landscape. For example, when Escape offers DAST, which dynamically scans running applications for vulnerabilities, understanding the customer's deployment model, CI/CD pipelines, and application architecture is critical.

Conversely, customers build technical credibility by providing "as much context, details, and needs as possible." This includes specifics about their technical challenges, existing security gaps, and the specific requirements their environment imposes. For instance, if a customer is evaluating Escape's DAST solution, they might share details about their API endpoints, single sign-on (SSO) integrations, or custom authentication flows that the DAST tool needs to navigate. Without this detailed input, the vendor cannot effectively demonstrate how their tool, like a DAST scanner, will integrate and perform within the customer's specific technical ecosystem. The "silent customer" during a demo prevents the vendor from learning these crucial technical nuances and tailoring the solution.

Radical Transparency extends to technical limitations. Pearlstein explicitly states that being honest about "technical challenges and technical limitations" is vital. This means communicating clearly if the product currently lacks a specific integration, has a known bug impacting a particular environment, or if a desired feature is only "on our roadmap" with a specific timeline. For example, if a customer needs DAST coverage for a highly specialized, proprietary protocol, and Escape's tool doesn't support it yet, transparency dictates acknowledging this rather than vaguely promising future capabilities. Providing details, timelines, and context, such as "we found this bug [CVE-XYZ], here's our patch plan, it will be fixed by [date]," builds immense trust.

The Shared Success Metrics section is arguably the most technically-oriented part of the partnership framework. Before "touching a product" – meaning before any technical integration or testing of a solution like DAST or ASM – both parties must agree on what success looks like. These metrics are not generic; they are deeply rooted in the customer's specific technical requirements. Pearlstein's template for success criteria includes tangible items that directly relate to a security product's performance and integration:

• Requirements: These are often technical in nature. "What are all the requirements?" could involve specific API coverage, integration with existing Security Information and Event Management (SIEM) or Security Orchestration, Automation, and Response (SOAR) platforms, support for particular programming languages or frameworks (e.g., Node.js, Python, React), or compatibility with specific authentication methods (e.g., OAuth, SAML, custom tokens). The speaker emphasizes customizing these based on the customer's "tools that they're using, the types of authentication they might have, the frameworks that they're using."
• Validation: How will these technical requirements be proven? Options include "hands-on keyboard testing it out" (actual technical deployment and execution) or "validate it via docs" (reviewing product documentation to confirm feature existence). For a DAST tool, hands-on testing would involve deploying the scanner against a target application, configuring authentication, and verifying vulnerability detection.
• Prioritization: Recognizing that not all technical requirements can be met simultaneously or with equal effort, prioritizing them (high, medium, low) ensures that the most critical technical objectives are achieved first, optimizing the use of both vendor and customer technical resources.

In essence, the "technical deep dive" in this context is about the meticulous, transparent, and collaborative process of aligning a vendor's technical solution with a customer's technical needs, ensuring that the chosen security product genuinely solves the stated problems within the customer's unique environment.

Demo / Proof of Concept

▶ Watch: Lesson 2: Radical Transparency, even about limitations. (5:00)

While the talk doesn't feature a live technical demonstration of Escape's DAST or ASM product, it thoroughly discusses the critical role of a Proof of Concept (PoC) in building deep technical partnerships. Pearlstein highlights how her five lessons, particularly Radical Transparency and Shared Success Metrics, are directly applied during PoCs to ensure successful outcomes.

A PoC is presented as a crucial phase where the theoretical capabilities of a vendor's product are tested against the customer's real-world environment and requirements. Pearlstein's personal "rule" is that "before we touch a product, before we move forward into testing anything out, we agree on what success looks like." This directly ties into the Shared Success Metrics, which act as the "ground of truth" for the entire PoC. These metrics are meticulously drafted in the customer's words, transforming vague expectations into tangible, measurable criteria. For example, a PoC for Escape's DAST solution might have success metrics like: "Discover at least X critical vulnerabilities in Application Y within Z days," "Successfully integrate with our existing CI/CD pipeline," or "Provide actionable remediation guidance for identified issues."

Pearlstein illustrates the application of Radical Transparency with a compelling example from a current PoC she was managing. A customer, who had initially engaged with Escape six to nine months prior, returned ready to move forward. However, a specific need they had discussed earlier was no longer supported in the product's current iteration in the way they expected. Rather than proceeding silently and hoping the customer wouldn't notice, Pearlstein and her account executive held a candid meeting. They openly communicated, "Hey, we promised you this one thing. It's not going to be here today if we choose to move forward." They offered the customer a choice: proceed with the PoC knowing this limitation, or defer until the feature was ready. The customer "really appreciated the honesty," chose to move forward, and even discussed a "design partnership" for the desired feature. This demonstrates how upfront honesty, even when uncomfortable, prevents future headaches and builds a stronger foundation of trust, transforming a potential deal-breaker into an opportunity for deeper collaboration.

The PoC process, guided by Pearlstein's methodology, involves:

1. Early Alignment: All decision-makers involved in the PoC must be present at the initial drafting of the success metrics.
2. Clear Requirements: The technical requirements within the success metrics must be "very tangible, very clear, and not vague in any way." This might include specific integration points, performance benchmarks, or vulnerability detection rates.
3. Validation Approach: Defining how each success item will be validated, whether through "hands-on keyboard testing" (direct technical engagement) or documentation review.
4. Prioritization: Realistically ranking requirements (high, medium, low) ensures that the most critical objectives are met within the PoC's time constraints, guiding the technical efforts.

By meticulously structuring PoCs with these principles, vendors and customers can ensure that the demonstration of a product's capabilities is directly tied to the customer's specific technical problems, fostering a productive and transparent evaluation process that minimizes wasted effort and maximizes the likelihood of a successful partnership.

Defensive Implications

▶ Watch: Practical example of honest communication regarding bugs. (6:30)

This talk, while not discussing specific security vulnerabilities or defensive tools, carries significant implications for how security teams approach their defensive strategies and technology acquisition. Pearlstein's framework empowers defenders to be more effective and strategic in their interactions with security vendors, ultimately leading to a stronger security posture.

Firstly, by understanding the vendor's perspective on partnership, security teams can transform themselves from passive recipients of sales pitches into active, informed collaborators. The "vendor sigh" can be replaced by proactive engagement. Defenders should embrace the principle of Technical Credibility by being forthright about their environment, existing toolchains, specific pain points, and genuine needs. Instead of waiting for a vendor to guess, providing detailed context about their application security (AppSec) challenges, CI/CD pipelines, and development frameworks enables vendors like Escape (with their DAST/ASM solutions) to tailor demonstrations and solutions that are truly relevant. This proactive sharing helps avoid misconfigurations, integration issues, and ultimately, wasted time and resources on tools that don't fit.

Secondly, adopting Radical Transparency is a two-way street. Security teams should be transparent internally about their own limitations, budget constraints, and organizational challenges that might impact a project. Externally, they should openly communicate feedback, concerns, and any discrepancies between vendor promises and observed performance. This honesty fosters a more productive dialogue, allowing vendors to address issues proactively and build trust. For instance, if a PoC for a DAST tool uncovers a flaw in its ability to scan a particular legacy application, communicating this clearly and early allows the vendor to propose workarounds or roadmap updates, rather than letting the issue fester and derail the entire engagement.

Crucially, Shared Success Metrics provide a blueprint for successful security tool adoption. Defenders should insist on defining these metrics in their own terms before committing to any PoC or pilot program. This ensures that the evaluation criteria are directly aligned with their organizational security goals, such as reducing the mean time to detect vulnerabilities, improving developer remediation rates, or achieving compliance objectives. By clearly outlining "what problems are you trying to solve?" and "how will we measure it?", security teams can objectively assess a tool's value and prevent "shelfware" – security products purchased but not effectively used. This structured approach helps security leaders justify investments and demonstrate ROI.

Finally, Consistent Communication and Celebrating Small Things are vital for operationalizing new security tools. Regular check-ins, clear next steps, and open channels prevent projects from stalling. When a vendor's support team goes the extra mile to troubleshoot an integration issue with a DAST tool, or updates documentation based on security team feedback, acknowledging and appreciating these "small wins" encourages continued exceptional service. This collaborative spirit ensures that new security technologies are not just acquired but successfully integrated, optimized, and maintained, thereby strengthening the organization's overall defensive posture against evolving threats. By applying these lessons, security teams can move beyond reactive vendor management to cultivate strategic partnerships that genuinely enhance their ability to secure their digital assets.

Key Takeaways

• Build Technical Credibility Together: Effective partnerships require mutual effort. Vendors must be curious and understand customer environments, while customers must provide detailed context and needs to achieve a shared technical understanding.
• Embrace Radical Transparency: Honesty about limitations, bugs, and roadmaps, even when uncomfortable, builds trust faster and ensures smoother engagements than hiding issues. Provide context and timelines for all communications.
• Define Shared Success Metrics Early and Clearly: Before any product engagement, establish measurable, customer-centric success criteria as the "ground of truth" for the entire partnership. This includes tangible requirements, validation methods, and prioritization.
• Prioritize Consistent Communication: Regular updates, clear communication channels, and explicitly defined next steps are crucial for keeping technical projects on track. Consistency in communication is more valuable than striving for perfect, infrequent updates.
• Value and Celebrate Small Wins: Beyond the big deals, small acts of commitment like troubleshooting issues, improving documentation, or providing clear notes build significant credibility, collaboration, and trust, creating a ripple effect for long-term advocacy.

About the Speaker(s)

Samantha Pearlstein is the Founding Sales Engineer at Escape, a company specializing in Dynamic Application Security Testing (DAST) and Application Security Management (ASM) for modern applications. With a background in computer science and cybersecurity, Samantha brings over a decade of experience partnering with diverse security teams, ranging from startups to Fortune 100 companies globally. Prior to her role at Escape, she served as a security consultant at Accenture, where she was a leading part of their cybersecurity innovation hub. Her unique position as a sales engineer, bridging the gap between sales and technical teams, gives her a distinctive perspective on fostering effective technical partnerships. As noted in the Q&A, the sales engineering role is critical, acting as "the glue between the sales people and the customer" and also a vital source of information for product management, making it an excellent career path for those who are technical, customer-facing, and entrepreneurial.