Leader Spotlight: Gathering feedback from the field, with Gayathri Somanath

---

Gayathri Somanath is VP of Strategic Initiatives and previously VP of Product for Merchant Services at Signifyd, an end-to-end commerce protection platform. Early in her career, Gayathri transitioned into product management after joining Cisco and later worked for InnoPath Software (acquired by Qualcomm) and Citrix.

In our conversation, Gayathri highlights the importance of customer empathy — not only as a skill for product managers but as a necessary quality that must permeate the entire organization. She talks about how, in a way, everybody is in product, and collaborating across the entire organization often sparks the best ideas. Gayathri also discusses the symbiotic relationship between Signifyd’s product team and teams in the field — customer success, implementations, sales, and more — and how they unite to solve customer pain points.

---

Having a technical background in product

You began your career as a web developer focusing on localization. How did you transition into product?

It feels like almost a lifetime ago, but I graduated with my undergrad degree in computer engineering. It was very natural for my first job to be in development. In that role, I was given the opportunity to talk to customers directly and to support sales with clients. The company didn’t have a product management function, so I would just accompany sales or the client manager when a technical counterpart was needed.

I realized that the intersection of business and technology and being able to meet a need with a product solution excited me a lot more than actual solution building. I moved into my next role as a business analyst which would allow me to continue to be at the intersection of customer needs and product development. That experience then allowed me to transition into product roles. Initially, I worked on internal products at Cisco within their data warehousing BI space, and then I transitioned over to B2B products and companies.

Do you have an example of an experience where that technical background was especially helpful?

As an individual contributor and product manager, earlier in my career, I didn’t necessarily think that a technical foundation was required to be successful. SQL skills and things like that helped, but my technical foundation has served me well in product leadership. In general, whether or not a technical background will help you really depends on the type of product you’re working on.

If you’re a product manager for a product that will be used by developers, yes, it’s going to add value, but if your product is more about providing experiences for an end user, then I think user empathy and being able to clearly articulate user needs and visualize solutions is more important.

As I’ve grown in my career, my technical background has served me more in terms of my ability to be more fungible across a product portfolio. Especially when you work in B2B and SaaS, there are so many different components that have to come together because you’re building the entire end-to-end solution. At Signifyd, we have an extensive product that includes API integrations. For me to be able to guide a team of product managers who own these various components and help connect the dots, it does require a deep understanding of how all our systems work.

How customer compassion guides products

You talked a little bit about empathy earlier, and customer empathy is important in the tech space as well. Can you talk about that in relation to the products at Signifyd?

Customer compassion is one of our core company values. Within my team, I think you need to be able to hear and experience the customer’s pain points firsthand. At Signifyd, I love that we have a very collaborative and almost symbiotic relationship between our teams in the field — customer success, implementations, sales, etc. We get to hear and work with them on the ground with customers and solve our customers’ challenges together.

That constant feedback loop directly from our customers and from the teams on the field is key to our product and design teams understanding customer pain points. We do a lot of user research and testing, that’s at the heart of everything we build. It’s important because you really need to test ideas and concepts directly with the users to develop customer empathy for what they’re going after. It’s also why we have product management design and research in one organization under one leader because that’s how you get those teams to work together and develop customer empathy.

Do you have an example of when customer feedback you were getting caused a pivot or a change in the roadmap?

Last year, we redesigned what we call our agent console, which is our web app at Signifyd. In that relaunch and redesign, we took out a feature and changed a navigation component that we thought wouldn’t be missed. We designed the switchover from the old experience to the new experience so there was an opt-in period and an opt-out period. As we started to analyze the data from who was opting out, it was exactly the feature that we took out that they were missing.

Our design team pivoted quickly to put that back and solve that pain point. But it also showed how testing and data help with developing customer empathy because we didn’t force everybody over to the new experience. We took it slowly and allowed them to opt out and tell us why they were opting out. We didn’t force the opt-in until we knew that we had covered the biggest issues that would make adoption difficult.

Aligning teams through shared KPIs

Working with all of those different teams, what are some strategies that you have for effective cross-functional communication?

I think what really matters is a shared vision and a set of goals or KPIs that everybody, cross-functionally, is aligned on. We talked about how customer empathy should be shared and obviously, our customer-facing teams have that customer empathy. But it’s really important that we drive that same customer empathy within the product organization as well.

Cross-functional communication is obviously very critical to effective collaboration. Especially at Signifyd, we decided to stay globally distributed and primarily remote even after the pandemic. That collaboration is even more important when you’re not all going back into an office. We take that communication and feedback loop very seriously.

Even with these elements though, I think consistency can still be an issue. As organizations grow, it’s easy to develop silos where you have one team working one way and another team working another. We have processes for product reviews where we ensure cross-functional teams are part of that review process. We have implementation managers giving us feedback on how this is going to affect the integration experience and customer success team members giving us feedback on which potential customers to test with and get feedback from.

What about a single source of truth? As you’re rolling out a new feature or even testing with a few customers, do you have a method for ensuring that all stakeholders are looking at the same set of metrics?

At Signifyd, overall we do have a very data-driven culture. From the beginning, we’ve been good about having easy access to data for the entire company. Our reporting and data platform is open to everyone, and it’s a common set of metrics that everybody can look at. I think that makes aligning the organization very easy versus where you have multiple reporting systems sitting in different teams.

When we are defining projects within the product organization, we drive a culture of thinking about your metrics upfront. There’s no easier or better way to get stakeholder buy-in and trust than being able to point to the data that led us here and the outcomes that it’s going to drive. And we continue to measure those outcomes right after we launch.

Focused ideation efforts

Innovation really seems to be key to Signifyd’s culture as well. Could you talk a bit about that and share an example where internal ideas led to a big development?

You often hear people say everyone’s in sales. I also like to think that everybody is in product, to some extent, especially when you work at a tech company.

A recent example of an idea that came internally is our strategic partnership with Adobe within their commerce solutions and what they call Payment Services for Adobe Commerce. This was spearheaded by our partnerships team. It didn’t come from product — they came to us, pitched it, we saw the value, and we collaborated with them to bring it to life.

Do you have any methods for brainstorming ideas, either in product or other teams?

One thing that we do when actively working on an idea is design sprints. I think this is a practice that started at Google, but it’s a key technique that we use to foster cross-functional collaboration into a new product feature improvement. I love that it brings together a really cross-functional team that wouldn’t typically be involved in product development.

It’s not just design and product and engineering. We’ll bring in data science, sales, or post-sales depending on what we’re working on, and get everybody together in a room. It’s a focused ideation effort in terms of what we want to build and how it’s going to look. You test it early and it’s a time box exercise, but you have everyone focused. We get a lot of great feedback that way and we were able to bring everybody into that product development process. We’ve done that for a couple of projects we’ve done at Signifyd.

Given how critical security is in today’s digital landscape, how do you ensure that it’s integrated into the product lifecycle, especially concerning payments?

In payments, it’s such an important aspect because there’s a lot of payment card industry (PCI) compliance that we have to be aware of. Security needs to be thought about upfront as part of the requirements and design process. It can’t be an afterthought because of the nature of the data that we work with.

This isn’t a product issue alone. You need to have great partners in InfoSec, legal, and compliance that have set these policies and standards at the company and collaborate with product and development teams to ensure that they’re followed and continuously audited. On the product development side, I think training is key. Each of our team members deeply understands why security is important. We enforce that it be thought about in the requirements upfront. It really is a team mindset, organization-wide.

The importance of curiosity

How do you see the role of product leaders evolving as we move forward?

In general, being adaptable and flexible are key traits for a product leader because the technology space and consumer expectations are always changing. Nothing is constant but change. During the pandemic, we saw leaders having to quickly adapt and pivot in terms of new strategies.

In terms of the way that the product leadership role will evolve, I think it’s more about product leaders having to stay focused on a few key things:

• Customer centricity — Continuing to have a deep understanding of your customers while their expectations change. There’s going to be new challenges all the time. It’s really important that we invest in understanding that so that we can adapt to shifting trends and be able to then personalize that user experience
• Globalization — Everything’s becoming a lot more global. Markets are becoming more interconnected. When you’re building products, there’s a global audience that you’re serving
• Inclusivity — Diversity is becoming more important. As we become more global and as global boundaries collapse because of technology, I think that’s just something that product leaders are going to have to become more aware of
• Technical competence — We talked earlier about how technical skills may not be so important as a product manager depending on the portfolio that you’re working on, but it does matter as a leader that you stay current with technologies and understand their impact. And with that is how you are going to incorporate that emerging tech or if you need to incorporate it in general

What would you say are the key traits that you look for when you’re hiring someone for your team?

I always say curiosity, number one. Some of the best product managers that I’ve had on my teams are just curious and hungry. I love that. That’s one of our values. But I think more than technical knowledge, or the ability to write great requirements documents, curiosity makes such a great product manager.

The second thing is customer empathy. That deep desire to make customers happy.

And then the third thing I would say is communication and collaboration. You really need to be able to reach out to the organization and make sure that everybody’s bought into that what you’re building has an impact. Product is one of those roles that’s so highly cross-functional, and everyone has an interest in it. And at the company, everyone wants to be a part of it. If you can’t collaborate and communicate cross-functionally and gain that trust, it’s really hard to be successful.