Pitfalls to avoid in product partnerships: Juraj Pal of OpenPhone

Juraj shares some actionable advice on how to do product partnerships

I interviewed Juraj Pal, who leads Partnerships at OpenPhone, and was previously Head of Partnerships and Product at Slido. Juraj was there at Slido from 0 to $10M in ARR and has the unique vantage point of being Partnerships leader who also led Product. Here are my favorite takeaways from our conversation:

Avoid shiny-logo syndrome: Having Google as a partner is great but do your customers even want it? Turning on an integration doesn’t mean customers will roll in. Start with real customer demand or skip it entirely.

Don’t ignore culture fit: After every call with a potential partner, ask if working together felt easy or like a battle. Walk away from teams that don’t click; unwinding a bad match later is painful.

Ask the tough, awkward questions of your partner: What are they focused on this year, what are their KPIs, if there is no alignment, say no. Otherwise you’ll end up with weekly calls which go nowhere because they were never strongly interested in the first place.

Don’t skip user research: Talk to customers who asked for the integration, learn the exact workflow they need.

Add value to the partner early on: Send the partner a warm lead, let them speak at your event, share early-access feedback - anything that helps them before a contract is even on the table. Give first, then negotiate.

Become the steward of your partners inside the company: Internally for every big initiative and launch you need to represent your partners - articulate how they can add value to the business and muster support and resources for their enablement.

---

Full transcript

Adi: So maybe I'll start with some context setting: how do you define the different kinds of partnerships, and in your time at Slido and OpenPhone, which ones have you been working on?

Juraj: Yeah, yeah. So it's a good question to start because it does definitely look very different from company to company. Even if we just zoom in on Slido and OpenPhone and compare those two, they are different.

At Slido, the biggest pillar for us when it comes to partnerships was product partnerships and integrations. The way I think about it is very much informed by the product that you're building. For a product like Slido, we would not be able to grow or succeed without really deep integrations in two groups of software: one being video-conferencing--your Zoom, Google Meet, et cetera--and then presentation software--PowerPoint, Google Slides. It’s driven by the nature of the product that Slido is; unless you can use it with those two types of tools, without it, it’s really pointless. So that's why we invested really heavily. That was reflected in my role as well, which was very close to product. At some point, I led the product team as well in this partnership-and-product role.

Very hard to copy-paste to a company like OpenPhone, where, when I joined a year ago, their definition of partners and partnerships was very much on the affiliate and referral side, which is a very different motion from what I had seen at Slido. It was a healthy beginning of an ecosystem play, but very early days when you look at product partnerships and even integrations. So it's very different in that sense.

And yes, the role changes as the company grows and as you enter different stages, but with OpenPhone we are slowly moving toward it. We've known for a long time that we need to get better at integrations and really fill that gap between the product and making sure you can use our product together with the rest of your tech stack. But it's a different focus and lens compared to a product like Slido.

Adi: So when you say product partnership, is it the same as an integration?

Juraj: I think you can. Like, there are so many beliefs there. It's true: not every integration is a partnership--I agree with that--and there's absolutely a space when you're building SaaS products for integrations that are purely there from the technical perspective and there's not much go-to-market around it. But the part that I'm excited about is where you really combine. It all ultimately starts with a use-case--whether it's a purely technical integration or not--but you have the use-case there, something the customer wants to achieve, and it's a real problem. Then you add an integration between presumably two pieces of software, but there's the go-to-market wrapper around it as well. That could be going to market together with the partner you built the integration with--co-marketing to mutual customers, or even generally to each customer base--and applying that ecosystem-marketing lens: their customers could be our customers. That's the part I'm excited about. I'm very bullish on the type of partnerships I'd bet my money on. Even when I look at OpenPhone, where we need to go as we continue to grow, that part of the ecosystem play to me is the most important, I would say.

Adi: Got it. That makes sense. Currently, if you look at how you spend your time at OpenPhone, what percentage goes on product/integration-focused versus affiliate or referral?

Juraj: It's very interesting because, up until three weeks ago, I was a team of one, so my time looked very different--each day, each week--very scrappy, lots of building and setting up the foundation. The affiliate program, because it was set up before I joined and I inherited it and the team has done a great job with it, we're able to put more on autopilot. Affiliate programs are fairly easy to operate because they're not super high-touch; they're not super one-on-one, and you can really scale how you onboard and recruit partners, so that's what we wanted to keep.

But we wanted to invest in something that's a big focus area for us this year: scaling our agency-partner programs. Those are consultants, agencies, or businesses who have a one-on-one relationship with their clients and often implement OpenPhone for them or integrate it with their CRM. That relationship is very different--much more hands-on; you're onboarding the partner, working through enablement. So that has been taking quite a bit of my time, and that was the first hire I made--just three weeks ago--and this person is going to focus on that swim lane.

Product partnerships were probably the majority of the time in terms of setting the foundation and making sure we have all the ingredients to go after a roadmap of integrations and product partnerships. A big part of that was launching our public API last fall, which also allows other partners to build on top of OpenPhone and not just ask us to.

That probably doesn't answer your question in a super clear way, but as a team of one I was all over the place. Now we're starting to specialize: the new partner-manager hire will spend more time on the agency-partner program, and I'll continue to focus on product as well as building the foundations for that partnerships play at OpenPhone.

Adi: What you're saying is that you got the referral/affiliate motion handed to you, and more recently you've been working on the agency as well as the product partnerships. Where your strength lies--and perhaps where you see the biggest potential--is product, and you've hired someone to help on the agency side. So let me dive deeper on product partnerships. If you had to break down a product-partnerships role into “jobs to be done,” what would they be?

Juraj: Great question. The framing I like: when you purchase new software, you compare that choice to every other choice you've made in purchasing software. Say you're looking to buy OpenPhone or another phone system; you'll think, “I bought my CRM a couple of years ago—it's HubSpot, for example—and I bought this tool for that.” You'll assess OpenPhone against: does OpenPhone work with my CRM, because I've already made that choice. It's too late; you presumably don't want to change the CRM and your tech stack just to fit a tool around it.

That's a big shift in software-buying behavior--not recent, but more pronounced. Partnerships come in right there. So, job one: deeply understand the customer's tech stack and journey, and the use-case. For us, phone/communications plus CRM is obvious. You expect your communications stack to integrate into your CRM. Without the real use-case, no matter how cool an integration sounds, unless the real job-to-be-done is there, it's going to be hard to get off the ground. Yeah, that's what I’d posit.

Adi: So the first step when deciding which product partnerships to pursue is pulling data on current customers, seeing what other CRMs or tech stack they’re using, doing that data-driven view of the largest commonality— which products to target. Fair? Or have I missed anything?

Juraj: Yeah, you're right. Understanding the customer’s stack and journey is the starting point; that gives you a good map of what other tools our ideal customer relies on, and then: is there a use-case for an integration? It varies between teams—I work with different CS and sales teams—but one thing I always tell them, going back to how customers make buying decisions, is we need to be very early in those conversations. Whether it’s the discovery call or the initial meeting, ask what other tools this customer is using. If that’s an afterthought, we’re already missing out. It’s a strong value prop to tell a customer: “Yep, we work with your stack. We won’t give you a headache or add a silo.”

Once you understand the lay of the land and the use-cases, you start engaging partners individually: what are their priorities? Staying with the CRM use-case—are they building calling/texting features natively, or building a partner ecosystem? From there it becomes more tactical, but I always look at mutual customers and what the overlap looks like: if we launch tomorrow, who’s there that will care? Again, two logos together may sound cool, but do people care? Does it make customers more successful?

Adi: In that strategy question—deciding which partnerships to go ahead with this year and next—how do you think about small attach-rates with a big company versus larger attach-rates with smaller companies, but doing more of them?

Juraj: You mean specifically with integrations?

Adi: With integrations and product partnerships—one really large company where a small percentage become customers versus smaller niche CRMs with a tighter product use-case.

Juraj: Yeah. I like to treat each integration or product partnership as a standalone product or feature. That helps a lot cross-functionally; there’s no reason a strategically important integration should be siloed from the rest of your product roadmap—your integrations become the product as well. For us it’s 100 percent true: HubSpot is our most-used integration, higher attach-rate. We invest more there—huge ecosystem, great for co-marketing and co-selling. But then, something new to me when I joined…
Because the customers that we serve are SMBs, there are just so many niche, small CRMs—there’s a CRM for cleaning businesses, there’s a CRM for roofing businesses, I had no idea that that is the world I’m going into. That creates a good discussion for your point: where do we invest, where do we go? I’m sure my thinking on this may evolve, but right now I’m kind of thinking about the long tail of these integrations and how do we support these with tools like Zapier or Make or other solutions that actually give the power to the hands of our customer. Also, to our team—our customer-success-management team and our solutions engineer—this is where they actually step in oftentimes and help our customers design more custom integrations, if you will. Yes, we won’t be able to prioritize building a very niche CRM integration and putting our own product and engineering resources, because we have so many table-stake CRMs to build, at least right now. But I wanted to make sure that—you can almost think of it as a pyramid of product partnerships and integrations—at the bottom of it, we have a layer that supports and gives the tooling to our internal teams, but also our customers, to build and create the long tail of those integrations.

Adi: Gotcha. So suppose you kind of decided internally—strategized, used data, used qualitative interviews—to say that, okay, for the next year or two or three, these are the integrations or product partnerships we want to focus on. What happens next in terms of, like, what is the set of work that you need to do to make that partnership successful? And even just, what is the timeline for this to go live and actually start working?

Juraj: Yeah. I would say there are kind of two different streams that start and happen at that stage. One is the business-development—you could call it; it’s really kind of the partnership side. The other one is user research, and I’m really bullish on that. Again, it goes to the point of: I want to treat those integrations as products, as if you are building a product, because you in fact are. So I go—and this is probably my product background coming forward—but I like to then essentially kick off a user-research stream around a specific integration. So if you’re building an integration with OpenPhone and Pipedrive, for example, I want to get a list of all our customers who requested an integration in the past, or managed accounts who have already given us feedback or asked for that integration. I want to get, like, a good amount of them on a call.

And I don’t know how I’d scale this in the future—I mean, you scale it with a team, obviously—but at this stage, because we’re such a small team of two, I like to be on those calls myself. I don’t like to think of user research in this context as something that you can outsource. We actually have an amazing Director of User Research, and we often partner with him, but it’s just so much more valuable to actually sit on those calls, whether you’re organizing them or not. So that’ll be kind of the immediate step.

And I would say that oftentimes I would actually prioritize this before engaging the actual partnerships team at the company. Maybe we do them simultaneously at the same time, because it’s even better if the partner is committed to the research phase with you. But I would hate to go through negotiations and sign an agreement with a potential partner, then do a round of user research and realize that, really, our customers don’t need an integration, or it’s more of a nice-to-have. And then what are we doing it for?

This was an interesting contrast. When I worked at Cisco—when I was working on their Webex developer platform—it was a very different approach over there, where there’s just a natural push toward quantity of integrations on the platform over quality. It was an interesting culture shock for me, coming from Slido—which was, again, a startup, very product-centric, customer-obsessed culture—into a Fortune 100 company, Cisco; and I’m trying to convince them, “Maybe let’s get on a call with a couple of customers before we invest in building an integration,” and that just wasn’t in the DNA of the company. So it was interesting to observe.

Adi: Awesome. And so basically you’re saying, just try and understand very deeply how that integration—as a product—is going to be used, so that when you kick-start this partnership it’s clear on both sides what the end state is going to look like and how customers are going to benefit.

Juraj: Exactly, yeah. It also helps you then scope out the actual integration: What should we include in version one versus what is for later? What do we really need to go to market with? Yeah—things like that.

Adi: And you said this was one stream; what’s the other stream, and what are the steps to do there?

Juraj: Yeah, so the other stream—you can call it business development, you can call it purely the partnership work—is working with the BD or partnership contact at the other company. So there’s discovery in that sense as well, and you do get through a lot of that user discovery, but it kind of anchors mostly around the use-case and the mutual customer: Are we both serving— is there overlap with our ICP? Are we as two companies culturally aligned? That’s a really important aspect. If I’m going to a bigger company and I’m saying we want to build an integration, does that fit into what their goals are for the next six months? Does that fit into their strategy? So there’s a lot of that discovery work. And of course it then progresses into talking about the commercial aspect of the partnership—often contract negotiations and the more admin/ops things.

Adi: And what, according to you, are typical timelines, and what variables influence those timelines?

Juraj: Oh, it really varies. I remember at Slido one of our key partners was Google. From a product perspective we were building an integration with Google Slides, and that partnership took—I want to say—probably two years, maybe a year-and-a-half to two, from the initial meeting to actually launching the product. Because in that case Slido is a small fish—bootstrapped startup that Google really doesn’t know about—and then you have Google, the big fish, and you’re playing that dynamic of understanding. With them it came back to aligning with their goals and making sure that they, as an organization, want to invest in this area as well—and how can we help them as a partner as opposed to them building this and owning this?

So you can have strategic partnerships like that which take a long time. You can also have the opposite—in a matter of months. We recently launched an integration with Jobber, one of the leading field-service-management software that our home-service business customers use, and that integration partnership—like, it’s actually been in the works for a while, but from actual commitment on both sides, through build, through launch—it’s been a couple of months.

Adi: Gotcha—interesting. When you talked about working with a really large, giant company like Google—or a much larger-scale company—do you have advice on what to keep in mind? I feel like that could go wrong in many ways, and it could also be a hit success. If you were to think of what to do and what not to do, what would you say?

Juraj: Yeah—my advice there is to actually align. The questions are kind of hard and awkward to ask in these conversations, especially if you’re the smaller company and you’re asking this to the Googles or Microsofts of the world, but you really want to ask them: What is your team focused on? Very tactically, what are your goals, what are your OKRs for the next quarter or the next half-year? You want to understand what they’re thinking day-to-day and what they’re building toward. Yes, it’s an awkward question for the first meeting, so you’re building that relationship toward it, but it does pay off because you ultimately need that understanding to get anything across the line. If you realize early on that you’re complete opposites—in this case Google’s focused on something completely else and they’re not going to invest in the area where you fit—you’re just going to be constantly … every two weeks you’ll log into a call; it’s a nice catch-up but nothing’s going to happen because you’re at the mercy of them as the big fish.

And, cliché as it is, if the priorities are aligned and you can bring in that real use-case—the real customer—the bigger the customer, the better. That helps a lot. If a company truly says no and doesn’t want to listen to you when you’re bringing them real customers and their quotes, feedback, them asking for an integration or for something you want to work on, and the company just ignores that, then they’re telling me they’re not focused on the customer and making them successful. So again, it’s going to be hard to work with them.

Adi: Have you had that experience—where you really wanted to work with a company, there were interesting words at first, but their actions were completely different and you ended up losing time?

Juraj: Yeah, it’s happened many times. At Slido most of our partnerships in this space were with big companies. Those two pillars I talked about—presentation software: Microsoft PowerPoint, Google Slides; video-conference: Zoom, Google, Microsoft Teams—so you’re constantly interacting with big players, and timelines vary.

An interesting example: we had a swim lane in our strategy to invest in presentation software, but we weren’t set on PowerPoint versus Google Slides. We knew our customers—big majority—cared about PowerPoint (as much as I hate to say it, everyone’s still using PowerPoint). But the relationship with Microsoft, and their platform readiness, just wasn’t there; the platform didn’t have the access we’d need as a developer to build on top of—it wasn’t built with that context. So we shifted priority and worked on Google Slides first: the wrapper was there, goals aligned, and their developer platform and experience were better. You can go back and forth and shift.

Even in non-product-partnerships, brand partnerships take a long time. Ultimately it’s a lot about relationship-building. In Slido’s early days there were pure marketing or brand partnerships that took a long time because you’re investing in relationship and trust as opposed to building something or marketing something tangible.

Adi: Makes sense. So of the three “jobs to be done” buckets we discussed, on the first one—deciding where to go—what common mistakes do people make?

Juraj: This may sound obvious, but you still see it: shiny-logo syndrome, where the partnership on paper just sounds good. The logo—you want Google or your favorite company on your website, on your blog post announcing an integration—but is the use-case really there? Do your customers care? That’s a big one. Yes, partnerships also elevate brand; putting your logo next to a strong company does a lot. But make sure the investment level aligns with what problem you’re solving. That’s the one I see most often.

Adi: Moving to user research—typical pitfalls? Any advice on getting that part right?

Juraj: Probably not doing the user research. We may be preaching to the choir—people from startup backgrounds, customer-obsessed lens—but not every company has that. Sometimes you have to educate or push them. That goes hand-in-hand with shiny-logo syndrome—maybe you want to convince yourself otherwise: “I’m not seeing the data, but imagine if we launched; it’ll take off!” Just like with product, turning on an integration icon doesn’t mean customers will roll in. That’s a big misalignment.

Adi: Hmm interesting. How about business development and commercials—common pitfalls?

Juraj: Not paying enough attention to the soft pieces. You can almost stack-rank partners when you’re prioritizing: talk to ten partners and decide which to build first. It helps to rank across dimensions, and I always include culture alignment. Do you actually like spending time on a call with this person or partner? Or is it constant battle and friction? Could your two companies exist together if you really partner closely? That’s a big one. I’ve ignored red flags and invested in a partnership anyway—didn’t work out, and then you have to make hard calls, maybe sunset the partnership or go the other way.

I'll say that's it. Also, just being transparent with the partner—especially if you're the smaller company in that discussion and you're working with a larger partner. Transparency is key, you know: not truth-hunting, what are the data, what are the things, but also transparency plus also wanting to add value to the partner.
There's—even before you actually launch an integration—so much value that you can give to a partner in the early stages of a conversation like that, and that actually makes a huge, huge difference. So it's not a transactional thing only, where you're meeting to review data, you're meeting to negotiate a contract, then you sign a contract. Even in that span of time you can have so much value to the partner by maybe going the extra mile and sharing a referral to them—sharing that, you know, your customer was asking about their company and send a lead to them. There are many ways you can do that, but it kind of boils down to just the attitude of giving first and then asking, which is a big, big one for me in partnerships because there are just so many conversations you can be having, but ultimately those who stand out are the ones where it's less of a transaction and more of genuine help.

Adi: I love that. And apart from sharing leads or referrals, have you come up with any other interesting ways of adding value to the company or even to the other person on the team?

Juraj: One thing that we've done at Slido in that context was that we would actually invite a potential partner like that—we would invite them to an event that we would be hosting or to a customer meetup; we would invite them as a speaker. It depends who the partner is and whether this actually appeals to them, but it worked as a really good strategy for us, where you are giving them space to share their knowledge. It's really good for a thought-leadership exercise from that point of view, but you're also showing that you care—you care about giving them this spotlight and introducing them to your customer base, you're kind of opening the doors of your company to them. And there’s no reason you need to wait to do something like that as a post-launch co-marketing strategy; those are best done even before you start negotiating contracts or talking about business because they ultimately build trust.

Adi: I love that. Awesome. I’d like to maybe switch gears and zoom out: if you look at partnerships as a function in the whole company, what other functions do you work very closely with?

Juraj: Yeah, pretty much everyone. It's truly a cliché, but partnerships is a very multifaceted function; it's a very cross-functional team by nature. I don't even—when you're writing certain job descriptions or giving feedback—cross-functional collaboration tends to be the buzzword you highlight, or something you get praise on. With partnerships it's really table stakes; there's no other way, essentially. If we don't exist across the organization, there's no point in having a partnerships team.
And yes, this is true for many teams, but I truly believe that if you want to see impact from partnerships, then partnerships need to be embedded across the whole customer journey. So again, recurring impact—meaning you want to be there across the journey. That means—goes back to your original question about the day-to-day—it does vary, because sometimes you're spending a lot of time with marketing, then you're spending time with engineering and product, and then you're spending time diving into lifecycle, then you're spending time with your CSMs, but it really does vary. That's why I'm very bullish on where partnerships sit in the organization; that can have a major influence on these things. I think that's point one if you want to start investing in a partnerships function: go at it with this lens.

Adi: Right. Given that it's so cross-functional, building those relationships internally becomes super important. If we take marketing as an example, how do you, as a partnerships lead, build relationships with the marketing team internally? How do you get them to invest time with you? They could potentially be investing in current pipeline generation—short-term—versus working with you. What advice do you have on how you build that relationship and work hand-in-hand with marketing?

Juraj: Yeah, in partnerships I think there are two sides to your job. One is obviously the external one, but the other—equally full-time—job is the internal marketing, the internal ambassador, the internal voice of the partners that you become toward the rest of your company. It's not always easy, because the understanding of what partnerships are and what the team does will vary across the organization.
At OpenPhone I'm very lucky the whole org is very bought-in and open to this ecosystem-led growth and partnerships, but you're still doing a lot of work around nuances that make sense in your head as the partnerships leader, but not everyone will be at the same level. With marketing—an interesting exercise recently when we were launching our AI agent Sona—if you zoom in, it was really about making sure that through any activity, any marketing tactic for the launch, we're considering the partner. It's nothing wrong; the marketing team will not naturally think of partners as the first thing in terms of audience or someone who can help multiply that launch activity.
For us it was about starting with: can we give early access to our partners to this feature? Can we get feedback from them? We know partners have their own audiences, communities, networks—potential and existing customers. How do we equip partners to market for us? That's the ecosystem play: we don't need to own all the channels; we let the ecosystem do its job. That's mostly enablement. Exercises like that open the eyes of marketing—or other teams—on how we can leverage this ecosystem, this army of enthusiastic partners who care about the company’s success, and help them at the same time.

Adi: And similarly with product or engineering: you started off owning only partnerships at Slido and then got a chance to lead product and look at the company through a new lens. What were some interesting things you learned from that product lens that you now apply to partnerships?

Juraj: Most cross-functional relationships are about empathy. With product it's very felt—understanding the role of a PM, having actually been in a product role. You develop and work on your own product sense. I'm not saying every partnerships leader must have product sense, but for product partnerships, yes. I look at product sense as a skill everyone in a SaaS business needs to some extent. That empathy is something I developed in that role. It comes with rituals I apply in partnerships that may be non-traditional—talking about user research, writing up the spec for a partnership—this product lens. In larger businesses those functions are often separate: a product manager assigned to that area and a partner manager assigned, working together. I believe in a strong product sense plus a generalist partnership person who can dive deeper into the actual product, because ultimately we're not selling contracts; we're building products customers use.

Adi: That makes a lot of sense—the empathy of understanding the PM role, their time stress, how they think about user research, specs, documentation culture—great stuff you can bring into partnerships or any org part.

Switching topics: advice for partnerships leads entering investor or board-level meetings. Any learnings? Expectations you didn’t have? Insights on working with the board?

Juraj: Good question. My background—I’m not a channel-sales partnerships leader; that’s not what I enjoy. If you put me in a very salesy partnership role, the advantage is it’s tightly connected to revenue. The risk in other motions is it becomes flaky: “We believe revenue will come at some point.” It will, and I believe in that. Especially with product partnerships and integrations, I’d advise against over-focusing on revenue. You’re not building an integration purely for short-term revenue gains; you’re building it to improve the whole life-cycle—close new customers, retain existing ones. Revenue follows.

But one thing you can always do—especially with the board or leadership—is connect it to overall revenue goals. At OpenPhone I sit in the revenue org, close to our CEO. Before I joined, the team invested a lot of time to set up reporting and metrics that tie all the way to partners-sourced revenue. Most activities we invest in, we can see the impact on partners-sourced revenue. Ultimately I look at the contribution of partnerships to overall revenue: what percentage of new ARR are partnerships bringing? That’s a really important metric for board conversations. You may not look at it every day, but understand benchmarks for your stage and walk backward from there.

That’s probably the single recommendation: tie to the revenue number, no matter how focused you are day-to-day. Both things can be true—I’m not over-focused on pure revenue daily, but for a board meeting I focus on showing that impact.

Adi:
Awesome. When hiring for your team, how do you evaluate candidates? What skills do you look for and how do you assess them?

Juraj:
At OpenPhone—Series B, ~140 people—we’re a startup. I’m a big fan of small partnerships teams that are well-interconnected. So, in the first role I hired I prioritized a builder persona. Builder goes hand-in-hand with a generalist partnership person who can fold into marketing, product, or whichever life-cycle part we’re working on. Early hires: that’s more important than specific experience, because much work is experimenting with channels and approaches.
We debated whether the first hire should go deep into partner marketing or partner ops; different beliefs around that. I think partner marketing might be next, but builder and generalist were key for me here.

Adi:
Love that. This has been super helpful—thank you for answering all my questions patiently. This was fun. Thank you—I really appreciate your time.

Juraj:
Of course. Thanks, Adi—chat soon.