Randolph D’Souza is Director of Product Management at Vercara, a cloud-based security software company. He started his career as a support engineer at Dell Technologies and then transitioned to systems engineering. Randolph then joined Akamai Technologies, where he worked for eight years in solutions engineering and as a sales evangelist, before moving to his current role at Vercara.
In our conversation, Randolph talks about how he works to align different teams together, such as product, OEM engineering, and sales. He also shares best practices for collaborating effectively, such as open communication, setting expectations early, honesty, and hosting frequent check-ins.
For me, this is broken down into two components: a hell of a lot of communication and a ton of trust and planning. When you get two separate parties involved with each other — either wanting to build a go-to-market strategy, a new product, or something in between — you need to set expectations early and often. The product team has to get a lay of the land about the realm of possibility within your own organization, as well as within the OEM engineering team or their organization.
You have different strategies or interests in getting everyone aligned. It’s never a square peg in a square hole. Once you get your team on the same page, you need to settle in on a schedule. You also need to come to terms with your reality. Hope is not a strategy — too many organizations run into that trap too often. That is where you need to be honest with yourself, as a product leader, to make sure that the two are going to match up as closely as possible.
On top of that, within the OEM engineering team, if you set realistic expectations up front, people will be more comfortable about meeting in the middle. It becomes significantly more difficult if you get, say, 3–6 months into a project. Setting that expectation up front is key.
You have to be honest about what each party is delivering. Say you are taking some code from a company that does something really well. It would take you a long time to catch up if you want to do it in-house, especially if they’re doing something very specific. That’s a set of expectations that you need to share with your entire org. Again, you have to map that out and break down a big piece into much smaller pieces.
The same thing goes for if you’re just doing a full-on white label. I’ve done both across multiple companies. That is where overcoming the perception of the deliverables is an art. You have to get ahead of the purpose and communicate that with your business leaders internally so that they really get it.
Then, you need to look at things like scheduling. For example, if your organization is used to delivering functionality on a three-month schedule and they’re used to delivering on a one-month schedule, that makes things easy. You may be able to introduce new products or functionality on an even basis. Challenges come in if you expect to deliver something every month, but the OEM engineering team gets it done on a three- or six-month basis.
When that happens, you need to really think about the market that you are growing into and if that is going to work for the organization. In past lives, we’ve decided to move on from working with an OEM engineering team. It’s not because what they built wasn’t good enough, but because it wasn’t aligning with our go-to-market strategy. I’ve seen so many sides of this experience that now, in my current role, I’m seeing a lot more success by taking learnings from the past.
This is where honesty and being direct are best. You want to get it out of the way up front. I went through this recently with a provider — their goals and stakeholders were not aligned with our executive team. I found myself in a situation of being a middleman. I was negotiating between the two and felt like I was translating.
That’s why, when you go into the first negotiation and you’re feeling each other out, you need to get those chief items out early. Unfortunately, that is where challenges often arise, especially in the engineering world. Say you ink a deal for X amount. You may have revenue commitments on either side, and there may be a pre-negotiated amount to be paid just to cover costs for the OEM engineering team. In that situation, you may have a lot of sunk costs down the road and little to show for it.
You start getting into these situations where you go to market and your sales team says, “Well, this isn’t what we signed up for. These are not the revenue commitments. We’re not going to make that now that we fully understand what we’re selling.”
That is where being very direct is crucial. Maximize that common ground, and that’s where you can set expectations like, “When we come into this scenario, we’re going to do our own thing, but here is where we’re going to focus on the OEM tech.” From there, work with your go-to-market teams to set those expectations and create as clear of swim lanes as possible.
Well, my nature tends to be pretty loquacious. I like to meet very regularly, even if it’s just to check up on progress. For me, this is where it comes down to the individual to feel out who you’re working with, as stakeholders, from the OEM organization. They may be very comfortable meeting with you once a month, and a lot of that comes down to the market that you are delivering for and the market that they’re used to building for.
I think weekly meetings are a good cadence. If you feel strongly about meeting more often or less often than they would, set that expectation early and often. Then comes bringing other stakeholders in. In product, you may be a centralized figure and have your hands in everything. Depending on the relationship, your marketing teams might talk to the OEM’s marketing team, and your sales team might be expected to bring theirs in in certain circumstances.
Personally, I’ve found a lot of success in just listening in. Not everyone has the same amount of time. Everyone’s got their own responsibilities, but shaping that out and getting a common understanding about what is a good match for that relationship is key.
This is another instance that I’m convinced is more of an art than a science. First and foremost, I like to get the lay of the land of what my sales team is capable of. One recommendation I would make is to be brutally honest with yourself about what your go-to-market strategy currently is and what you envision for the future.
This is where I’ll commonly meet with sales leaders and test the waters about their understanding of a particular market. Sometimes, they may know the area very well, but other times, not so much. Gauging what they are capable of is key for me. This is because I came from sales. Before I was in product management, I spent many years as a solutions engineer, and I found that type of background to be very helpful.
Conversely, I’ve also realized that sometimes it’s important to bring sales into the OEM org.
If you’re just working with a straight engineering team, that may not bring much value. However, some sales folks — particularly those who have a strong technical background — will bring a new set of eyes into that process. I’ve seen that once or twice with some of my sales colleagues. It was a great moment where we said, “Wow, you’re right. That’s a great idea. I wouldn’t have thought about it that way.”
I try to be as humble as possible and not assume I’m going to be the authority in a particular area. I feel like I have pretty good instincts when it comes to going to market, but I’m not going to pretend that I know more than everyone else. That’s where it’s most helpful, especially if you are required to work with these other folks, to try to build a great working relationship with them. It makes it better because now you’re involved with that process. You can help them with pitch practice and onboarding new customers.
Say you take an OEM project, such as a new product release. That’s where you take that and you can help them along the process. Don’t go in cold — in some cases, hold their hands through the first sale. It depends on where your market motion is, but that’s how to help build confidence in them, and, in turn, they build confidence in you. I’ve found that to be a requirement for success in these OEM circumstances.
In product management, we have to say no a lot. I like to provide context around how tech organizations are fundamentally orchestrated. People have different goals. In sales, you are on the hook for generating revenue, whereas in product management, it’s about how well you’re delivering. I like to find common ground about the realities of both positions.
It’s definitely easier said than done, but this is where you need a great executive team to build a team that can work around that. Having said that, when you’re going into a new market, I found working with them and putting yourself in your revenue team’s shoes is very helpful. Specifically, run training in the context of your go-to-market team’s strong suits. If they’re very used to talking about a certain market or a certain set of products or services, you need to find ways to be able to gauge your new market in that context.
Further, if you’re in the type of go-to-market that requires sales engineering, spending a lot of time with them goes a long way. They could be your chief liaise to your sales force or your channel team. For me personally, I’ve invested a ton of time with those types of organizations and I found it bearing fruit significantly.
Lastly, it’s important to always have profitability in the back of your mind. If you’re a product owner, you need to be honest with your organization. If you’re leading up your company’s entire portfolio or if you’re just doing a subsection, be honest about what your goals are. Is it all growth? Is it all profitability or somewhere in between? If you have that north star, you have to weigh that into every decision.
Learning management systems are great. I don’t like to hold long, drawn-out training sessions. If I’m working with a combination of say, sales and pre-sales, for example, I like to make the content very consumable. One personal rule of mine is to provide three things that everyone can take away. And I try to do a litmus test there to get feedback from everyone on whether or not I hit the mark.
Another tool that I like, especially if you’re responsible for messaging, is posting in public forums. They’ve helped me articulate my messages. Same thing with going on podcasts. Even though I’m not necessarily talking to my sales team directly, funnily enough, they will take more from the interviews in podcasts than when I speak internally.
Lastly, I like to get my hands dirty with technology. That is where I would like to understand what it’s capable of doing. Tools include demo environments, which I use as a mechanism to ensure that I have comprehension and understand everything fully.
I would say to always understand your revenue goals, and that depends on the deal you’ve inked with the OEM provider. Map out what that’s going to look like. That’s something that’s always running in the back of my mind — what is growth going to look like for the next quarter, year, or five years?
Also, have constant communication amongst your internal stakeholders. How are people doing? Where are people seeing success? Where are people seeing challenges? How do we solve any problems? Is that something that we need to adjust to? Are we trying to get into a market that we really shouldn’t be getting into or where we’re going to have an uphill battle at the very least? That’s something that always weighs in my mind — what is within the realm of possibility? Is this going to be set up for success?
Lastly, I follow this great mantra for success. Essentially, you’ve seen success, but how do you continue it? Is this something that is supposed to be ephemeral in time? Is it only going to last three years or is this something you’re going to have for an extended period? That depends on the business you’re in and the markets you’re going after. I think that’s crucial to keep a pulse on as well. Those are my main pieces of advice.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Deepika Manglani, VP of Product at the LA Times, talks about how she’s bringing the 140-year-old institution into the future.
Burnout often starts with good intentions. How product managers can stop being the bottleneck and lead with focus.
Should PMs iterate or reinvent? Learn when small updates work, when bold change is needed, and how Slack and Adobe chose the right path.
AI accuracy problems are often chunking problems. Learn how chunk size and structure impact cost, retrieval quality, and UX.
Learn more →
