Leader Spotlight: Gaining context in new industries and verticals, with Boris Logvinsky

---

Boris Logvinsky is VP of Product at Vanta, a trust management platform that automates compliance and streamlines security reviews. He began his career in product management at Demandforce (acquired by Intuit). Boris then transitioned to Twitter, where he became Head of Product for the MoPub platform. Before his current role at Vanta, he led the platform product management team at Flexport, a technology platform for global logistics.

In our conversation, Boris talks about the importance of doing your due diligence to build context and understand customer challenges when you move between industries. He discusses how go-to-market teams enable you to gain this context, as well as how to measure the value exchange occurring between the company and the customer. Boris also shares how Vanta “walks the walk” of its mission by staying continuously secure and compliant.

---

Specializing in the craft of product vs. a particular industry

Throughout your product career, you’ve worked in a variety of verticals. Are there core skills that you found to be transferable from one sector to another, or did you experience a big learning curve when moving into new verticals?

The foundational PM skillset is absolutely transferable across industries. Whether you’re in fintech, consumer, or security, the core PM jobs of understanding your customers and market, setting product strategy, and delivering value for your customers stay true.

However, what changes between industries is, obviously, the context of the space, what customers value, and where PMs need to spike. For example, if you’re working on developer products, you need to understand developer workflows and be technical enough to understand your customers and users.

I’ve spent my career moving between industries because I enjoy the challenge of learning new spaces and I’ve appreciated the opportunity to apply my learnings from one space to the other. When you move between industries, you have to build the context and understand the customer’s challenges. You don’t have that knowledge in your back pocket. When I first started at Vanta, I was coming from the logistics space and had very little context on compliance and security.

Could you talk about your approach to onboarding within the product function? People often talk about the first 90 days. What do you do to accelerate context-building?

My model is to spend 30 days gathering context and the next 30 formulating opinions. Then, by 90 days, you have high enough confidence to go and execute. Early on, it’s common to want to make an immediate impact. When ramping to a new space, I’ve found that starting out with internal teams and industry context (blogs, podcasts, etc.) is the most effective way to learn.

Find other product people or, if it’s a really small organization, the CEO or go-to-market (GTM) people. There are many employees you can learn from who already have context in the space. Show up with a beginner’s mindset and have them explain things to you. Then, get on calls with customers and dig in — you should be listening to customer calls from day 0 and leading them by day 30.

What’s your process for identifying the important stakeholders or the people who might be the keepers of the important knowledge that you need?

Often, it self-reveals itself if you say, “Hey, who do I ask about X?” In smaller organizations, there are usually a couple of people who everyone points to consistently. You just have to ask.

A key factor I’ve found important to understand early on is the difference between who has the historical/industry context and whose help and support you need to move things forward. Oftentimes, they’re not the same people. The person who has context might be an engineer who’s been there from day one, for example, and they might be different from the person you need to engage with then to move the item forward.

Measuring the value exchange to customers

Could you share your philosophy on selecting and evaluating key product metrics and how you go about aligning them with the broader business objectives?

We’re a product-led company from the perspective of how we build products, but we have a sales-led GTM motion. In those environments, it’s often difficult to pick a metric because the product team should be influencing revenue and retention, but you’re only one part of that value delivery chain. You can’t just build a sign-up form, get people to sign up, and control the full funnel. There are humans and processes that factor into that.

So, going back to the metrics question, I like to think about it in a cascade — what are our company goals, how can the product team influence those through the products and features we build, and what are the measurable inputs we can evaluate that we believe will ladder up to achieving our goals?

At Vanta, one of the things that we measure is the customer journey. How quickly and efficiently do customers onboard to Vanta and on what timeframe they achieve their goals; a SOC 2 attestation, for example. Those metrics are deeply tied to the value our customers’ hope to get out of Vanta, and we know the more successful our customers are, the more likely they are to continue to use Vanta.

You mentioned talking to the customer to gather feedback and better understand their pain points. What does that feedback loop look like?

That loop has to happen at a bunch of different levels and there’s no one way to run it. A good option is to think about the mass funnel of information that you get from your customers. At Vanta, our customers can submit feature requests directly through our products. That’s a fire hose of information coming in, and it’s important to sift through that and understand the volume of the feedback.

Further, I like to think about how we engage our GTM teams and enable them to give us context. Seeing the volume from the firehose of feedback is helpful to spot trends, but you don’t always have full context on its importance. You need help from GTM to understand what’s important for which customers, personas, etc.

The most important component of this is to get out of the building. You have to talk to customers yourself to ensure you understand their problems and why they’re asking for certain features. I’ve been in situations where I shipped a feature request and I continued getting similar feedback and requests. It was because I did what the customer asked but didn’t solve the underlying problem.

Avoiding the trap of accommodating niche requests

Do you have an example of a time when you identified and addressed a customer pain point?

When Vanta was started, we built our product for automating the SOC 2 process for small businesses building their compliance program for the first time. There’s nuance for these SMBs, but it’s relatively straightforward. You can give everybody a similar formula and can get them 80 percent of the way there, and the remaining 20 percent needs to be tweaked.

Over time, as we started to sign on larger customers and deal with more sophisticated users, it became obvious that their problem was that our automation was good but not perfect. It didn’t quite meet their configuration needs. Vanta was not as automated for these larger customers as it was for smaller customers. We had to think about that problem and say, “Our approach to this before would’ve been to try and build all those automations for our customers ourselves, but that scale and complexity are too broad.”

We ended up deciding to open the ability for customers to build tests themselves. In retrospect, it made perfect sense to offer that. However, it was a step change in the flexibility of the platform that allowed significantly more sophisticated customers to get more value out of Vanta. It was a successful launch.

Do you go by a rule of thumb to evaluate when to say no to those requests? If so, when do you do that vs. give thoughtful consideration and come up with a solution like this?

This is not Vanta-specific, but, in general, I want to make sure that we’re building products for a specific customer set that is aligned with the overall company strategy. I try to avoid the pitfall of becoming somebody else’s professional services team. Especially as you move up in the enterprise, it’s common to see big organizations asking for bespoke things. They may be a big revenue deal, so it’s easy to fall into the trap of accommodating those requests. You have to be very mindful of that.

Though I want to hear all the input, my default rule of thumb is to evaluate if the impact of solving the problem is aligned with our mission, vision, and strategy for the year. If it’s not aligned, then unless we’re contemplating doing some big mission vision expansion, we probably shouldn’t pursue it. With that said, however, keep your mind open to a business or product opportunity that you hadn’t considered that was surfaced to you. It may represent a step change in your business.

‘Walking the walk’ in compliance and security

From a product perspective, how do regulatory requirements impact the product function in the security and compliance space?

We have to make sure that we’re continuously secure and compliant, and that we’re meeting necessary best practices. As a compliance and security company, we have to walk the walk. If Vanta is operating in, say, the EU, it’s critical that we are GDPR compliant.

What’s unique for Vanta is that regulations have an impact on the product offerings we release to the market. For example, as new regulations and frameworks are announced by countries and regulatory bodies, we need to review them and launch them in Vanta since our customers will need to comply with these frameworks as well. This means we have to be nimble and agile. We have to stay up to speed with the regulatory environment and respond as it changes.

You’re in so many markets and there are many different regulations in each one. How do you stay up to date on that? Do you have subject matter experts by market?

Yes — we have subject matter experts at Vanta. We have a great team of folks who come from varied backgrounds in privacy, security, and compliance, and they help us to understand what’s important and upcoming. We also have a great network of folks who are constantly coming to us in a very active conversation. Most of the time, regulatory bodies move slowly, but when they move relatively fast, as we’ve seen with AI, we have to keep up.

Do you consider it to be part of your responsibility to educate your customers and ensure they’re aware of upcoming changes?

Absolutely. We serve a wide range of customers — from 10-person startups to companies with thousands of employees. Certainly, larger companies have security and compliance teams that think about this day-to-day — it’s their core job. But for startups or SMBs, this is no one’s full-time job. It’s a part-time job for a founder or an engineer. This is why they need the help and turn to us in the first place — they want help getting secure and compliant so they can grow their business.

The future of AI, privacy, and security regulations

Have you experienced having to make trade-offs between security features and user experience?

This came up a lot when I was at Twitter and worked on ads. It was particularly relevant in the context of privacy and data usage. We could collect information on the device, from the user or their email, and stitch it together to serve a highly relevant ad. Or, we could use none of that data and be more privacy-centric but serve up an irrelevant ad. There’s always that back and forth between security, compliance, privacy, and data, what you can and can’t use, and the resulting impact on the user experience.

At the time in that space, there were complex conversations around both following the regulation and maintaining principles as an organization. What are the things we’re willing to do and how far are we willing to mine the data? That was always a tricky challenge.

Finally, as AI technologies evolve, how do you see them being integrated into compliance and security products, and what kind of implications do you think that will have?

We announced several AI features at VantaCon in December. This wave of large-language models (LLMs) has been interesting and a real boon to Vanta and our space. AI represents a really exciting opportunity for us to drive more efficiency and build a much better product.

As an example, when it comes to evaluating someone’s security posture, there are many documents that someone has to go through — vendors’ SOC 2s, security questionnaires, and policy documents, just to name a few. And not everyone has the time for it. With our vendor risk management product, we’ve leveraged AI to parse those documents and enable customers to quickly and efficiently get answers to the questions they care about most and discover risks they need to be mindful of.

More broadly, more AI regulation is certainly coming. Our goal is to help other folks use AI and all of these systems in the right way — one that’s compliant with regulations and best practices. This also represents an opportunity and responsibility to ship and deliver products that aren’t just using AI to help Vanta be better but also help customers make better decisions about how they’re going to use AI in their own systems.