How to Build Integrations with Platforms Bigger Than You Without Getting Stuck at the Bottom of the Queue

In this episode of Between Product and Partnerships, Biljana Pecelj joins Cristina Flaschen to explain how smaller teams successfully ship integrations with larger platform partners. She makes the case that leveraging usage data and performance metrics is the key to proving your integration's value, giving you the necessary influence to move up a major partner's priority list.

Biljana shares lessons from her experience managing integrations at Hootsuite during major platform shifts, including the rise of Instagram Business APIs and the emergence of new features like Stories that didn’t always come with immediate API support. She also details the process of aligning internal stakeholders to ensure integration features actually ship despite shifting external APIs.

The conversation also covers the operational side of integrations, this includes why observability needs to be built early, how teams detect silent failures before customers do, and how to structure internal alignment when integration work touches engineering, legal, partnerships, and revenue.

Who we sat down with

Biljana Pecelj is a Principal Product Manager at Ledgy with deep experience building integrations inside platform-heavy environments. She has worked extensively on partnership-driven product initiatives where execution speed depends on navigating both technical constraints and external partner relationships.

Biljana brings expertise in:

• Building integrations in environments where APIs and features evolve asynchronously
• Designing for observability and proactive monitoring
• Navigating asymmetric partner relationships
• Aligning roadmap priorities across product, partnerships, legal, and engineering
• Managing tradeoffs between beta opportunities and engineering capacity

Key Topics

• Why integration product work is relationship work

Technical execution matters, but alignment with partners determines whether integrations actually ship and scale.

• Building in ecosystems you don’t control

APIs change. Features launch without endpoints. Roadmaps shift. Successful teams anticipate uncertainty rather than assume stability.

• The importance of observability from day one

Silent failures are common in integrations. Without monitoring, teams often learn about outages from customers instead of systems.

• Roadmap tradeoffs when beta opportunities arise

New partner features can require immediate shifts in engineering priorities. Negotiation and resource reallocation become core product skills.

• M&A and integration complexity

Brand consolidation rarely means backend integration. Teams often inherit layered systems that remain technically independent long after acquisition.

Episode Highlights

01:55 – How integration product management differs from core product work
04:40 – Navigating power imbalances with large platform partners
07:15 – Using data to strengthen partner conversations
10:30 – Building observability when resources are limited
13:45 – Handling silent integration failures
17:50 – Managing beta features and roadmap shifts
21:30 – Aligning cross-functional teams around integration priorities
24:45 – Why relationships accelerate integration execution
28:10 – Lessons learned from building inside platform ecosystems

--

For more insights on partnerships, ecosystems, and integrations, visit www.pandium.com

Transcript

Cristina Flaschen (00:00)
And here we go. Hi, everyone. And thank you for listening to our podcast, Between Product and Partnerships, where we talk about the challenges and what it takes to build integrations, tech partnerships, and SaaS platforms. Today, I am so excited to have Biljana Purcell with us. Nope. We're going to take that again, because I added an R. Today, we're so excited to have Biljana Purcell with us. She is a principal product manager at Ledgy and
I would love to hear more about your background for the audience.

Biljana Pecelj (00:33)
Christina, lovely to see you and really great to be on the pod today. ⁓ Yeah, I'm currently living in Munich. So I've been here for about four years. Originally grew up on the west coast of Canada and I've been doing product across a different set of domains over the last little while. Most recently I'm working at Legge, a Swiss based company that's in the equity management sphere. But I think if I drew a common thread across my career, it would really be that I worked on a lot of integration products, a lot of APIs.

⁓ And overall, ⁓ in some jobs, I've had definitely higher exposure to partnerships and integrations where the entire job was very much in that realm. So excited to talk about this topic today.

Cristina Flaschen (01:13)
Well, you've got tons of experience and we love to see it. Not a lot of folks have spent more than a little bit of time building integrations. I think it's a kind of a, still even a nascent space, even though APIs have been around forever at this point. And since you've done a little bit of regular product work, regular product work and integration work, what would you say makes integration work different than regular sort of product management?

Biljana Pecelj (01:39)
Thinking from the mentals from products stay the same, but the part that gets really interesting is that you have usually a little bit less control and you have to wield things through influence and persuasion a lot more. Because you're typically working with partners where you don't have a good control of their roadmap and you need to work a lot more on collaboration, building those human relationships to ensure that you have alignment. So think that's a key aspect of it.

Another aspect is that it does require an element or I would say a bit of a creative muscle as well. Sometimes you need to work around things that are again out of your sphere of control. An example could be you're working with an API that doesn't have a web hook. So you need to work on developing a polling system to accomplish a goal that you need your product to fulfill. So I think that creative muscle is definitely what drew me into one of my jobs when I worked at Hootsuite around ⁓

integrations because it's kind of like working a little bit with your hand tied behind your back.

Cristina Flaschen (02:39)
Yeah, I'd love to hear a little bit more about your time at HootSuite. That's a name I think a lot of folks will know. So ⁓ I guess when were you there? What was the beginning and the end? What did that look like in terms of the types of projects you worked on?

Biljana Pecelj (02:52)
Yeah, so I started there in 2019 and I guess I was there right up until I moved to Germany, so about four years ago. It was an interesting time. Instagram business was a super hot network. So I would say I definitely had a few great hairs from that integration during the time period. It had lots of interesting aspects because it was this acquisition from Facebook. So you were kind of working with one partner, but really the backend of it was like multiple sort of backends that he would work with.

And it was also the rise of TikTok by the time I was about to leave. So I got to work a little bit on a TikTok integration as well. I worked with a really fabulous partnership team ⁓ and it was probably one of my jobs where I started working with the legal team for the first time, which I really appreciated what it would take to do contracts with really large partners.

Cristina Flaschen (03:40)
Yeah, maybe if that is a thing that I'm familiar with, and I think a lot of companies when they're growing start to be familiar with it's sort of that. And Hootsuite's a big company too, but a lot of times folks are working at companies that are not quite as big as Hootsuite. So there's like this power imbalance when it comes to both. ⁓

like the technology and the requests and things of that nature and obviously like the legal side of things. Like you want to strike that balance of, you know, doing something everyone's comfortable with, but also being kind of the smaller fish in that relationship. ⁓ Maybe if you could share a little bit about what that's like when you are not the...

the company that gets to dictate all the rules, both from the commercial side of the equation, which is the contracting, and then also from the technical side. Like, what advice would you give folks? What does that look like?

Biljana Pecelj (04:29)
Yeah, think in Hootsuite, the model was very interesting because you built basically an entire business around a set of free APIs. And when you're not paying for stuff, you also have less influence from that angle too. So during my time there, ⁓ Twitter was actually the first, and I still refer to them by their old name, because that's kind of how I remember them, I guess. ⁓ They were the first ones to develop actually a paid API. So was a very interesting negotiation where you had a little bit more leverage because at that point,

you were a customer as well, ⁓ not just a partner. ⁓ So it me from a contracting point of view that you have different levers you can pull with different partners, depending on what the contractual relationship looks like. ⁓ Is there a paid component to it or is it free? Are you offering the partner something like really fantastic feedback from big logos to help along in their beta? Cause that definitely incentivizes them a bit more. But I think

In essence, working with a lot of different partners when you're the small sort of fish in the pond is all about acknowledging that asymmetry ⁓ in the relationship right from the get-go and really adapting to it. So it means understanding that every partner has slightly different interests and motivations and learning individually what each of those are and also establishing relationships with all of those along the way.

Cristina Flaschen (05:48)
Yeah, that's such a good point about just being kind of upfront about it. And, you know, being able to articulate what you are able to bring and what you're not able to bring. what, what I've seen happen out in the world is, know, there's two companies, maybe they're around equal size or vice versa. And if the primary KPI for one of them is just lead gen, just like straight new business. And the partner is not in a position to provide that because of their ICP or their size or like whatever it is that can really create that.

imbalance very, very quickly and make folks kind of ⁓ settle to the bottom of the priority list. I guess I'm curious what kind of data you have been able to bring to those partners, whether it's a large company or a small company and how you've been able to get your hands on that data internally. When sometimes I know that it might not be easy for a product manager to get access to some of that. If the infrastructure for that is not built kind of from the very beginning.

Biljana Pecelj (06:48)
I mean, the time when I joined Hootsuite, the team that I worked in was a team really at the forefront of the partnership aspect. ⁓ And it was very small. ⁓ So we had two engineers on the team, which made it very much a reactive team. ⁓ So you would have integrations with a partner where you're maybe lacking observability. So you suspect that certain things on their side of the API integration are causing disconnections with that network, which is introducing frictions into your workflow.

So how do you go about proving that? Well, one aspect is you need to add observability. The other aspect is you maybe need to also influence internally to increase the capacity of your team so you could actually build that observability and instead of being caught on the back foot and having to react to things that you could actually have monitoring set up in the system and really be more proactive and strategic with the conversations you're having. I found with all of the partners that they were really responsive to data where you could actually help their business in some way.

So if you were logging an escalation instead of saying something like, my network disconnected, and we're having like a bunch of outage reports from a client, ⁓ they really appreciate it if you could help them actually with root cause analysis. And that's where really solid observability was extremely helpful. So whether you were having a direct line or portal that you were interacting with to log such issues, being able to state, hey, this is the error code that we got from your system. This is when it started happening.

made them ⁓ much more trusting of you and also kind of helped you bring to the front of the line ⁓ issues that you would have that are outside of escalations because you were also helping them with troubleshooting their own product at times.

Cristina Flaschen (08:30)
Auth issues, man, auth issues are a hell of a drug when folks, auth servers go down and stuff. It's also helpful in my experience to be able to even cite like specific customers. Like, hey, we have, you know, 45 customers that are experiencing outage. Like here are some of the IDs. So, you know, if you can identify that they're like larger accounts versus to your point, just saying like, Hey, your auth is storing an error. Like what's going on?

⁓ depending on who you're working with, like a company of Twitter size, I'm sure that like ticket goes into a queue and like it gets seen when it gets seen. So yeah, the more like concrete examples that you can provide, I think the better off it'll be. The off server stuff is so common for us. I mean, that's what we do like all day every day. And I do think observability is something and like monitoring that folks only think about when something breaks, right? Like you don't.

necessarily think about instrumenting that in the beginning. And then once you start, in my experience, like rolling out that observability across all of your apps, that's when you start to see like how broken things potentially are. It's like, we had no idea that like those things weren't actually working. So I'm always a huge advocate for doing it to your point, like trying to start with a foundation, at least that you can build upon so that you're not then having to like re-architect.

Biljana Pecelj (09:24)
percent.

Cristina Flaschen (09:49)
the entire thing, but it sounds like at Hootsuite you were able to get it done, which that's a big, some of that observability and stuff can be quite a large undertaking depending on how many installations you have and like sort of the overall landscape of the technology that you're using.

Biljana Pecelj (10:06)
Yeah, I think the part of it that was really interesting is we worked with a wonderful engineering team. So was really lucky to have them there. ⁓ They were also a very creative bunch. So you would get different ideas of how we could creatively solve or gather more data. But inherently every API you work with is also very different as well. So one size doesn't fit all when you would build observability for one network, it wouldn't necessarily translate into the same quality of data for another.

So it was always very interesting figuring out what is the common denominator of a foundation that you could reuse versus where do you have those bespoke things that do need to be catering to that one partner a bit more.

Cristina Flaschen (10:45)
Yeah, I mean, even API response codes are supposed to be standard, but not really. Like sometimes they're just not. ⁓ Which is also an interesting challenge when you're thinking about alerting and observability too, right? Because like, if you're trying to capture these in like a log management system, sometimes the codes are just not consistent across accounts. But I think the first, in my opinion, like the first line of support for this is like, just start capturing those things. And then you could start parsing through it. ⁓

Biljana Pecelj (10:48)
But they're not always.

Cristina Flaschen (11:14)
The amount of like silent failures that I've seen for my career with integration stuff is like, makes me feel really sad. Cause I'm like, what if, you know, if this was your core product, like your core Hootsuite product and people like couldn't log in, you would know that immediately. But if an integration, a whole bunch of them are just failing in the background, a lot of times, you know, the customer won't notice necessarily. And you may not notice if you don't have the alerting set up for it. And like at that point.

trying to backfill weeks worth of data. It's just like, it's such a nightmare. So maybe a TLDR from this for everyone is like, think about alerting and monitoring in the beginning. Like don't wait. Because by the time it escalates to like, if it's coming out of your CX team, like it's already bad. Probably if you're getting a lot of reports.

Switching gears, I know you talked a little bit before about &A and working with partners that are going through that. I think that's very timely right now. Anecdotally, I feel like I'm seeing a lot of &A activity out in the world and with our customers, partners, folks getting acquired and partnership teams moving around. I guess, how would you say that that has shown up in your day-to-day work and what are some ways to help maintain continuity for projects when you're dealing with?

&A really on either side, specifically on the partner side.

Biljana Pecelj (12:34)
I mean, it's interesting during my time at Hootsuite, wasn't necessarily an ⁓ &A aspect that took place on the partner side, but there was definitely a lingering side effect of it, I would say. ⁓ So I believe that Instagram was acquired about maybe seven years prior by Facebook. And in terms of it being a single company, at that point, it had rebranded itself to Meta. So it wasn't even like Facebook and Instagram. It was this ⁓ single cohesive unit. ⁓

The part that you definitely did see is that the back end of things lingered behind the branding. Because always with acquisitions, the first thing you do is you have ⁓ the marketing part that gets updated. You maybe rebrand your product. But a lot of the times, the tech is actually much harder to integrate. And this was definitely something that was extremely visible if you were using something like Instagram Business. When you would go to even set up your Instagram Business account as a customer,

you needed to play with two interfaces. So you needed to go into Instagram business itself, then you needed to go into Facebook and you needed to do a series of steps across both of these interfaces to get this sort of one float to work. And this was something that inherently through our research, we found a lot of clients struggle with. So it actually blocked them from integrating into our product, which was step three. So I was very lucky to work with a wonderful designer who built a carousel and that just gave you like a really friendly set of instructions that you could skip through.

around here's this piece that you have to do in Facebook. Here's this other piece that you go to Instagram to do and then you sort of come back to Hootsuite. ⁓ Obviously you need to kind of update that as flows change, but I think investing into ⁓ user guidance and education can really go the distance ⁓ if the tech itself is maybe not as usable or not as integrated as you might assume it might be.

Cristina Flaschen (14:23)
Wonder how that looks now. Dudo, ⁓ I have obviously, I don't have to mess around with that part of Instagram well enough, but is it still like this sort of like leapfrogging back and forth you think?

Biljana Pecelj (14:26)
you

I get the impression from being a user of the system that overall there's a more cohesive suite behind all of it right now. As for the auth setup and the initial account setup, I'm not sure because I haven't done it in a few years, but I'm really hoping for the sake of ⁓ Hootsuite's customers today that that is a much smoother process.

Cristina Flaschen (14:54)
Yeah, yeah. It's funny too, because like, you know, what you're describing is Instagram and Metta, guess, Instagram, Facebook, Metta. But this sort of concept of, you know, the branding of a larger parent company and the systems all being completely separate, really is super pervasive in like,

enterprise tech, you look at like ERPs or like really large companies like Sage that, you know, there's dozens of Sage products. Most of them were acquisitions that are then rebranded under the Sage logo, like Peachtree, think, turned into Sage 50 as an example. ⁓ And so when folks say they want, you know, to integrate to Sage, it's not like saying you're integrating to Salesforce where it's like you have this large product and then, you know, it's all kind of all encompassing. The Sage logo means

you know, a dozen plus completely different pieces of technology. And even amongst, I don't know about Sage specifically, but some other, I won't name the offenders, but some other large like ERPs, they'll rebrand and some of these systems are complimentary. So you would assume that they all talk to each other even internally. And that is also not the case. So get in there and you want to do, you know, the order management system and the e-commerce storefront.

started as two different systems and now 15 years later are still two totally different systems and doing an integration that uses both of them is like this weird three-prong thing. The auth is different and sometimes the folks even at those parent companies don't really know necessarily how it works. So I hear you on that. I'm kind of surprised actually that the meta

I mean, I believe you that Instagram and Metta were like, that it was not easy to do this. Obviously it's just, I would think that they would have it a little more together, but I don't know. I've just, I've also done integrations with companies like that, the docs make it look really nice and clean. And then you get in there and you're like, this is, this is not the same as what your docs are saying. ⁓

Biljana Pecelj (16:49)
My

suspicion is I think that this type of awkwardness when it comes to ⁓ &A and tech comes from most &A is being driven from strictly a commercial and business side. And often the tech side of the business not actually being along for the ride. So I think there's very little due diligence a lot of times around how the tech is gonna integrate and how complimentary it is. ⁓ And then you end up in sort of interesting integration patterns that sometimes linger for decades after.

Cristina Flaschen (17:17)
Yes, and systems that just remain totally separate, although they have the same, the same parent name. Yeah, yeah, yeah. There's definitely some large like ERP type conglomerates that have, are very guilty, I would say that I think they would agree that they are guilty of, ⁓ of doing this. ⁓ So zooming out a little bit, something that comes up a lot when we're talking to folks is the kind of cross-departmental, cross-departmental.

Biljana Pecelj (17:22)
Mm, logo.

Cristina Flaschen (17:45)
nature of integration work generally, right? So you're coming at it from a product perspective. Obviously there's engineering involved, but also for companies that look at this as like a growth lever, which I'm sure Hootsuite did and others that you've worked at, marketing is in on that. The revenue side of the house, generally like sales is in on that. The executive team is in on that. How do you think about cross-departmental alignment generally, which is a big topic, but any like tips and tricks that you have, and then also

cross-departmental alignment when it comes to getting the resources that you want for your P &E team.

Biljana Pecelj (18:24)
Maybe start from the last question. ⁓ So getting the resources for your own team is very interesting. I think in a case where you're branded as an infrastructure team, ⁓ that could be a bit of a double-edged sword. ⁓ Everybody needs stuff from you, but you could be viewed as a cost center to the company. ⁓ And I think a key aspect of stepping into a team like that is to really rebrand what the team does and tie your wins to customer outcomes.

And whether that is directly from things that your team ships or whether it is indirectly through other teams in the company that have dependencies on your team. I think it's a really, really important exercise to go through. ⁓ terms of broader, okay, sorry, I'll stop on this one because I totally lost the second question, the first one you asked.

Cristina Flaschen (19:15)
Yeah, it was just around ⁓ more like general cross-departmental collaboration for integration work, like, you know, thinking about different departments and that kind of thing.

Biljana Pecelj (19:22)
Mm-hmm. Cool.

⁓ what I found very interesting in the Hootsie role, which was entirely an integration role is just exposure to different types of, ⁓ internal stakeholders. ⁓ so of course, ⁓ in your, if you're in any type of platform role, you tend to have internal stakeholders who are often. PMs, designers, engineers on other teams. So I'm very used to that and I've had that in different jobs, but I think the part that Hootsie that was very unique is, ⁓ really working with the legal team when you were speccing out.

your new contracts, maybe there's a new beta that's come around and you really need to be fast to say yes to an NDA in order to get access to that. And that could be like a huge lever for you. So an example of something that was very popular at time when was at Hootsuite was Instagram stories had come out and they became the biggest type of posting that you might want to do as a business, but there wasn't an API for them. So how do you really ⁓

say yes to that beta as quickly as you can. So one aspect was legal. ⁓ Another aspect was really your partnership team who would often need to have really close relationships, often be on the ground where a lot of these companies are headquartered to hear that there's a beta coming, to be able to say yes to it, to express our interest in it. And then often realigning also internal roadmaps for such occasions where, you know, this could be a huge thing.

that really drives a lot of impact for our clients, but it does involve roadmap shifts to things we might've already planned. So how do you accommodate that? So let's say, like every other product role in integration roles, you have a lot of collaborations, but I think it's just taken to a whole other degree.

Cristina Flaschen (21:13)
How do you handle that roadmap conversation? Because I feel like that from a product manager is like the thing is, you you can get everyone at the risk of the company super stoked about whatever this integration is, partnership. like when it comes to the actual engineering roadmap hours, like that's where the rubber meets the road and where the, least where I've seen challenges, challenging conversations take place. So I guess what ⁓ have you seen be successful?

in actually getting that stuff moved around.

Biljana Pecelj (21:45)
I think it's a negotiation. ⁓ So one aspect that I've seen is negotiating around, to use an example, ⁓ you're going to onboard to this beta, but the beta doesn't include webhooks. So you need to have a polling infrastructure. Maybe if one team just really is bogged down would work and doesn't have the capacity to build a polling infrastructure, but they need it. You might find another team. might be like the team I worked in or somewhere else where they'll offer that capacity up.

⁓ So it involves a lot of trade-off conversations, like if you go and say yes to one thing, what comes off. And in general, would say maybe from that aspect that we were quite lucky that a lot of the betas that were coming our way, they were very ⁓ material to the business. I think saying yes to them was relatively easy, but trying to figure out how to work around the trade-offs was definitely where the difficult conversations were had.

Cristina Flaschen (22:41)
It's good that there was at least like ⁓ a strong dotted line to like a company goal. think usually there is, right? Like if there's an integration is bubbling up to the P and E team, like somebody cares about it, but there is this like just internal conflict of like, we have roadmap, we solidified it at the beginning of the year. Like this is what we're going to do. And the integration stuff I find even with best laid roadmaps for integrations and partnerships, there's like stuff that just comes in like to your point, Instagram stories, brand new feature.

and we've got to jump on it. Like we have the opportunity to do that. You're not going to know about that in January or the end of the previous year. Or ⁓ there's always the canonical like sales team needs to close this deal for the end of the quarter. Like we said, we were going to do net suite at the end of the year. Now we need to do it in February type of thing. ⁓ And my beautiful vision for the integration world is that these apps are not

such an unknown to build so that you can kind of slot them in and out, although that's still, you know, there's always, there's always work involved in building any of these things, right? ⁓

Biljana Pecelj (23:46)
you're hitting a very interesting topic of predictability of integration work. And the one part that I'm recalling now is ⁓ we could always predict the calendar of deprecations of APIs. So that part was really lovely. You could usually look six months out and say, okay, these partners are getting rid of this API, we need to have a plan around that. And it wasn't non-negotiable. So that was also very easy to prioritize.

But ⁓ definitely whether they're gonna release a new feature, whether that feature is gonna really take off with your customer base, and then whether that feature is gonna have an API endpoint that gets exposed for it at some point was often an element of surprise. And that's where really having a very strong partnership team was very helpful ⁓ because they developed a bit of a spidey sense of like, I heard there might be a beta coming for this. So you could start doing a little bit of a...

plan, you know, if this was to come our way, this is maybe how our roadmap would shape up versus if that plan for the beta didn't pan out, we would do something different.

Cristina Flaschen (24:47)
It's so funny that we're in a world right now, especially in this moment in time, where it's all about the bots, right? The agents, the bots, the swarms, all the things. No humans, humans don't have to be involved. And so much of technology is about relationships.

Right? Like not even internally, definitely, but then externally, especially like that Spidey sense, as you said, or like you're close with a partner manager and they just be like, Oh, you know, this thing is coming. Like, I'll let you know first, or go to an industry event for your vertical. And you start hearing about things like those are things that are not going to come through. Chat, GPT, like you might be able to catch it.

with an agent or something if there's a press release, but by that point, you've already kind of missed the bus if you're trying to be like a first to market. It's so heavily relationship-based in a way that I don't know of a lot of other kinds of aspects of technology that require that much like sort of human palm to palm handshaking, you know, it really is. And same thing with like the office, like everything about it is like.

calling up your friend at the other company and just being like, yo, like we submitted this ticket, this customer is getting really pissed off. Can you please just go check? And like, it works, you know? And nobody, you know, when you're friends with these folks, they're friendly enough. Everybody is aligned behind the goal of trying to make more money, sell more software, have happier customers. So I think every time that you can bring it back to that, you'll win. But it is interesting that, you know, we're trying to automate like literally everything that goes into every job. But so much of this is done offline.

still in my experience. don't know if you have a similar experience.

Biljana Pecelj (26:25)
agree more. And I think that's an aspect of tech that, first of all, I'm a big AI nerd, and I love it. I love the efficiencies that it's introduced to my life across different aspects of whether learning German, now living in Germany, or being a product manager. I think one part that worries me a little bit is seeing people forget that at the end of the day, people who purchase our products are humans. ⁓ Those of us who ultimately build strategies and build products are humans. We might be helped by technology.

⁓ So I think this essence of a human connection is just something that needs to be, I think the forefront of how we think about software development to this day. ⁓ Technology is going to help us get there faster. There's certain things that we might be able to skip right over and maybe some of our roles are somewhat more blurred than they were before. But I think that the aspect of really interacting one human to another and

talking and helping each other out. I just don't see that going away.

Cristina Flaschen (27:26)
I agree and I'm interested to see in like, I don't know how many years it'll be with how fast some of this stuff is moving now, but in a few years, if we see like a pendulum swing, like we see so often with technology where it's like, well, now we're gonna guarantee that you're talking to a human, like, or now, you know, we're gonna guarantee there's no AI in this or maybe not know, but like, there are those like kind of ups and downs of these types of trends, even in transformational technology. Like I remember just a few years ago, like within the last...

five to 10 years, probably five years, there was like this little flurry of like dumb phones that came out. So it's like not a smartphone. It's like, it just looks like an old cell phone, but like has a touchscreen, but it just texts and makes calls. And this idea, they were for adults. It wasn't for kids. It was like, you don't want to have a smartphone anymore. And it didn't get a ton of traction, but like that is sort of a response in my mind to like, not just being contrarian, but also like people don't want all that stuff anymore.

So it'll be interesting to see where this newest kind of wave takes us when it comes to our interactions with technology. But I agree with you. think remaining human, remembering that people buy software from humans. It's typically humans that are using software. Sometimes it's not, but most of the times it is. And being sure that you can maintain those relationships will always be fruitful, in my opinion.

And we're running up on time here. This has been super fun, but I wanted to ask one final wrap up question.  if If you could look back on your career and go back to your early self going into product management, especially with APIs and integrated products, what one piece of advice would you give yourself?

Biljana Pecelj (29:08)
I would say that you're going to walk into a job where you would expect the job to be all about technology, APIs, API specs, but fundamentally, it's a relationship job. ⁓ So I think from that perspective, you're going to need to work with other people that you're going to need to influence ⁓ and persuade through data relationships. 

In order to move your roadmap ahead and to really ship things that your customers need. And I think ⁓ doing that is going to require understanding the lingo of the other person and the other company that you're partnering with, understanding what their incentives are and what's really driving them and how they're defining success in their own company. And I think from that point of view, you need to really use the relationship building as like your strategic leverage over time.

⁓ And be very proactive, I think, when it comes to communication. ⁓ think proactive communication will help you with escalations so that you reduce the number of them, but it will also help you build trust, which means that from that point of view, it's going to help you accelerate your execution when you have a very good relationship with a partner. So yeah, it's a cross-section of humans aligning with other humans, but technology doing a lot of the work under the hood.

Cristina Flaschen (30:31)
I mean, I think that sums up like software generally. It's like, what it all is if you really think about it. So this has been really fun. I feel like we could talk forever. I definitely could talk to you forever. Thank you so much for joining us. Is there anything you want to plug before we head? You got any hiring or anything? People can find you on LinkedIn, I'm sure.

Biljana Pecelj (30:35)
Yeah.

Yes, I'm on LinkedIn.

Cristina Flaschen (30:55)
Well, thank you again for joining us for our audience. Thank you guys for listening into another episode. If you want more info about integrations, partnerships, APIs, we got workbooks, got guides, we got eBooks, we got everything. We got tons of episodes of this. You can go to pandem.com. Again, really appreciate you spending the time with us today. I hope I see you again out there on the the internets and I hope that you have a great day.