Welcome! On Behind the API, we talk to the people who work to build awesome API products about their journey, learnings, and overall approach.
On today’s session for Behind the API, we are joined by Jake Vacovec. Currently Co-Founder and CEO of Flycode, as well as former VP of Product at Behalf.
To request an invite to Astral for your low-code API Portal and Developer Success Tools, blast off with us here.
For a full transcript, from Grain.io:
All right. Welcome. I'm behind the API. We talked to people who work to build awesome API products about their journey, learnings and overall approach on today's session for behind the API. We're joined with Jake currently co-founder and CTO flat, currently co-founder and CEO of fly code as well as former VP of product at behalf. That's super cool FinTech.
Speaker 2 0:41
Speaker 1 0:42
To start us off, what is fly code and why does it have you excited?
Speaker 2 0:48
Thank you, Kirby. Uh, great to be on, on behind the API here, a fly code is, you know, at its core, we're trying to bridge the gap between technical and non-technical teams. And, uh, you know, really at the end of the day, we're trying to make it easy for non-technical teams like product or UX, who in some ways are technical, but they're not developers, um, easy to engage and change and contribute to the product. So your web or mobile applications without actually coding. Um, and we do this by connecting directly to the code. And the first use case that we have for, for supporting this, this workflow is if editing product copy and, you know, ultimately we believe that there has been a huge wave of external systems that are shifting the way that companies are building their infrastructure. And we want to bring ownership back to the code base, where your tools don't define your infrastructure, your infrastructure is what quantity and the tool should adopt and be flexible to you. And again, you know, first use case is product copy, but, uh, because we're connected to the code, there's a lot of opportunity for us to, to bridge that gap between your developers and your non developers.
Speaker 1 2:07
Yeah. And behind the API, we talk a lot about all the different personas that it takes to launch an awesome API product. And we'll jump into developer delight a little bit and the product managers and designers. But before we do that, let's start a little bit earlier, your API journey, you were always a savvy entrepreneur launching AI API products. Uh, you worked at behalf and, uh, you want to tell us a little bit about what was behalf, where did you start at behalf, and then where did you end up and how did that kind of inform how you even think about interconnected systems and platforms for products?
Speaker 2 2:47
You know, I was very green in the FinTech space, but at the time the FinTech space was, was very green itself. Um, especially on the B2B side, you know, you had some cool companies there, like affirm, you know, they were just starting out and like, what are these guys do that on the B2B side? You know, that area, the only buzz or that was starting to pick up was Omni channel. So, um, I joined a, it was an Israeli FinTech company. I was actually still in college. I went to Middlebury, studied econometrics there. I joined the team as an intern, my, my junior year. And I think I was in third employee in the U S 10th overall. And I actually ended up staying on through my senior year because it was just the most engaging environment that I had. It just like totally shifted my perception of what it meant to, to work, uh, and to learn. And that took the environment. And in the beginning, I was like a generalist. I would do anything and everything from, you know, create marketing emails, to outbound calls, to demos, implementation, you know, you just kind of wear all those different hats and you see what is interesting to you as, as an employee and as a professional. So I think that was one of the most kind of transformative moments for me and being in that young, high paced startup, and then watching it scale to, you know, around over a hundred employees. And it still has a long way to go in. The space is still extremely hot. Um, on the B2B buying out, they later we started in telesales. So we were like giving sales reps, the ability to approve customers live over the phone. And then we started to evolve just like the industry was evolving into kind of a digital online, which was e-comm and then digital offline, which was more like invoicing or more of the telesales types of, of workflows. And towards the end, I was ultimately the VP of product there that I was also like the diplomat between our us and Israel offices. So I was spending a lot of time traveling back and forth to the market basing. And then, you know, they R and D side and my major push towards the end was driving the company towards being flexible enough to go into new distribution channels, because ultimately as a FinTech, you're like in the business of selling money. And so you need to find different channels that you can distribute your product. And, you know, the big ones for me at the, at the time and towards the end was around, you know, payments platforms. How can we kind of cross integrate into those because they're looking for different ways to expand their suite of offerings. Uh, international payments is definitely a big one. And, you know, this really was all API driven. Um, had to be flexible enough. Couldn't always be from 10 driven with an STJ. You had to bring those kinds of payment operations. It's the backend.
Speaker 1 5:44
Now I've had a chance to now meet two former behalf developers and their bad asses. And so, as you were kind of being that diplomat role, what did you learn, um, can of your product management space about designing for developer experience and some of the things that you need to overcome to kind of really get that persona, um, engaged or even excited?
Speaker 2 6:11
Yeah. You know, I think that there's, and this is kind of part of fly code and at its core, and it comes from this experience as well, but there is a gap between the technical understanding of, you know, what you're trying to implement and then like the theoretical or practical, right. You can tell somebody, Hey, you know, there's a transaction, that's going to happen here and you need to use this API endpoint, and then you need to use this other one to get the status, you know, give them that progression. But I must say, you know, fully understand, you know, what is the practical use case, um, that you're trying to solve for you sometimes lose things in between. And that can be from a development standpoint for what you're doing internally, but then even more so when you're facing externally, you need those teams that are implementing your product to really understand, uh, exactly what the flows should be and you know, what the business operations are. And, you know, this is a difficult thing. I think it's also not necessarily going away. You know, this is a as a common challenge that I hear from friends, who've started other, other fintechs that, you know, implementation and integration work is, is challenging. Um, but ultimately I think it comes down to kind of trying to mimic the way that, uh, you know, developers are working really understand how they look at requirement, documentation being created, um, you know, the, the different flows and really trying to be thorough because the more you can equip them and to mimic their existing workflow, uh, the easier it is going to be for them to adopt and implement versus forcing them to change their style and do something new.
Speaker 1 7:57
And you and I have talked in the past about extremely detailed developer guides. What are some of the, what's some of the Jake's secret sauce in making a extremely detailed developer guide?
Speaker 2 8:09
So, because I was in the, uh, kind of strategic partnerships, business development side of building new products that they have when I was Ben fully doing product, uh, I was always pulled back in and I didn't mind, I actually loved doing that business development with one of the co-founders Shai Kleinberg there. And it was a fun experience because you had to kind of do the sale, but you could also upsell them to where you want the product to go and also know your technical constraints. So I found that extremely detailed guides to the point where I was taking screenshots of like Wayfair, for example, as a company we'd integrate with, I was taking screenshots of every single flow that they had putting in a PowerPoint, overlaying our application, tying it to like our putting our end points. They're linking it to postman calls, um, creating dashboards on my side to measure, to see how they were doing calls to our end points and if they were successful. So I found that giving a guide to them as if it was already done with all of the detail requirements, step by step, it took two to three times longer than just saying, Hey, here take the API documentation, but the speed to implementation thereafter and the amount of oversight and extra work to, to monitor dropped significantly. And it's not the most scalable, but it, it definitely saved, you know, myself and the sales team time, because we saw it implementations go a lot faster.
Speaker 1 9:53
It's definitely nice, especially if you're on a partnerships team and you have a few key partners that you really want to go well, and, you know, as a sidebar, whenever you and I talk about different fintechs, that seems like you've worked with everybody. So what team did you learn the most from? And like, why was it so awesome?
Speaker 2 10:13
You know, it's funny the, one of the teams that I work with, which I don't know if we work with, I don't believe we work with anymore, but I really enjoyed working with Veeam. They're a, uh, a payments platform out of, um, San Francisco. And, and I think they have an office in Ontario or Toronto, and they were really creative with how the API is, could work. And to the point where, you know, you can include data in certain API calls that, you know, don't actually have any meaningful impact on the way that it affects our system and the, what it triggers us to do, but that the data that us who included in it can help us in the logs. And so they were very creative in ways that they were sharing, you know, different data that we needed to do our risks checks, um, on the merchant side and the customer side. And then, you know, I thought that a charge after was, uh, very interesting as well because they, they had to create this very flexible system that allowed a bunch of other lenders to plug into it. And, um, I would say from a developer experience, you know, JP Morgan, they have an innovation team there. That's been behind some, uh, pretty awesome fintechs and they have a great developer portal experience, you know, their FinTech offering and Reiki eyes. They could be stronger. Um, but they're, you know, they're getting there, but their developer portal experiences was really, um, you know, fantastic and remind me of, uh, of stripes as well
Speaker 1 11:55
Is thinking about developer experience and even just product experience, fly code as in private beta right now, and, um, side plug for anybody, they should be using fly code and growing fly code. Uh, but what do you feel like you're learning from some of that opportunity for customer intimacy before you guys kind of move over to your public release?
Speaker 2 12:18
Yeah. You know, we're in this kind of private slash open beta, you know, customers can sign up and completely onboard and use the product. And so it's amazing to see that just happening organically, you know, they, we've had around 300 companies that have actually signed up and then 80 that have gone through to actually connect their code base to allow our service to run. And the thing that I think is the most interesting that I've learned is that people are very willing to try your product. And because of that willingness, you really need to guide them to the place that they'll be successful. And so what we found in the beginning was many were connecting, but not connecting what we wanted them to connect. And so they couldn't actually fully experience what we were trying to offer. And so we've shifted that looks like three or four weeks ago, we released a new version and their changes, you know, is dramatic, right. If you can guide them to the path of success, they will go that direction. And it's not always so intuitive. And so you see that from the data watching log rocket, but also then having open conversations about what's creating value for you. And where do you want us to take this with you as a partner, which turns out is extremely vast. It's a big market when you're, you're talking about building developer tools.
Speaker 1 13:48
Yeah. So for thinking about even just overall process, you know, if, um, if another company was launching, like at developer-centric prietary API first product, you know, what do you think that you've learned from this private beta that you would recommend for really trying to nail the UX before trying to go bigger and bigger? I think you had mentioned a piece about trying to lead, uh, you know, customers to get to that, you know, that value point, but what else would you recommend, um, as, uh, to other companies that might be going down the same path?
Speaker 2 14:23
So I think that one of the light bulb moments for us, um, happened after we added log rocket and, um, uh, mixed panel, um, for some events. And it was only a matter of, you know, four to six weeks after our beta was out that we actually implemented. But during that time, there was a lot of activity that was happening where we were. And so we couldn't actually make, uh, you know, some quantitative, but also qualitative decisions on how that experience was being, uh, created, uh, until we actually were able to watch those sessions. So huge value for us. I would say that for others, you know, it is so key to get that information and moving in it. Um, and then, you know, I think the other areas we've invested a lot, even early on in the, in the dad's community where we've had just open conversations saying, Hey, look, we're not, we're not selling you on anything. This is really about, you know, getting your feedback, the usage, you know, um, how can we do it different? And people love to share their opinions. I mean, here we are, right. But like to, to, to share their knowledge and firsthand experience. And if you open up that door to them, most wills will be willing
Speaker 1 15:54
Whenever I'm launching a product. And you're trying to provide a user like, say, for example, a product manager or, um, a copywriter, a tool like flat coat to where they can make changes real time, no code, but then it also needs to be implemented by one of their engineers. And that engineer needs to find it to be so awesome. It's like, if you go to the flight code web site, so three minutes, it's like big in the hero image. Yeah. When you're trying to tell a story where that you're trying to talk to two different personas at the same time, what have you found in your early conversations, or just iterations on your marketing that helps you try to capture those two people in the same room and like, hopefully the joint value that they can both see from really slick tech, three minute integration, but then also like a freedom for no code updates.
Speaker 2 16:47
So, um, I mean, it's a great question. It's also a challenge, right? When you are a platform that sits between developers and then call it UX copywriters or product managers, product owners, I just kind of break it into two worlds. One is, is your product actually easy for developers to use? Is it that friendly or is it dev first? I mean, we had a lot of debates back and forth, no matter early days of are we dev friendly or are we done first? And, you know, we settled on in the beginning being a dev first or a dev friendly platform where the implementation would be very easy for your developers. So there's no development work, no work to spin up, you know, a new environment for us, no work to actually change their code or annotate, you know, shift your infrastructure to we, we do all of that on our side. And we also don't change the way that their existing workflow happens today. So we basically productize their workflow. And, you know, that's a big shift, um, for out in terms of how we're now targeting developers to say, look, you can use and consume this product and then share it with your team, because today you're doing these tasks tomorrow, your other team members don't have you as a dependency. And so we've doubled down on that target, um, because it just makes it faster for us. And this is the biggest shift I think, in the industry where a developer can actually go and try a tool and bring it into their company. Um, sorry, I'm just, can you recall bring it into their company on their own, right. It doesn't need to go through this crazy approval process. They can test it and, and do that in a product manager. Unfortunately, uh, can't always do that, but that doesn't mean you're not going to, you know, still communicate a value props and messaging to them, but the primary focus is definitely developer.
Speaker 1 19:02
And then, you know, so for that, um, just kind of thinking about where you take your inspiration from who are two other API products that you feel like nail dev first, where you can just kind of take that and then kind of run with it really kind of, um, you know, let it be like a good example for you.
Speaker 2 19:24
Yeah. You know, I spent a lot of time reading API docs and B the two that, you know, I think jumped out to me and this is like the classic plug for Stripe, but they really,
Speaker 1 19:41
Speaker 2 19:41
The beginning yeah. Other than Stripe. Right. But they set the standard early on. Um, you know, the others that
Speaker 2 19:51
I really liked and I'd say is, um, there's a company called synapse fi uh, or synapse, and they made their like product offering and their documentation, like almost like one in the same. And I really loved that because it, it paired the kind of the practical, uh, financial product with them, the technical implementation of it, which again, I think is this is a gap in a lot of companies where, you know, you have their slick marketing site and you have product or services, and then you jump into their API docs and it's like, you're looking at a dictionary and you don't necessarily know like the recipes on how to pair and match things together. Um, so I think companies like snaps, uh, they've done an amazing job of pairing the, you know, the business case with, with the technical implementation side.
Speaker 1 20:52
Thanks. And then, um, do you have a background in product and you're working on a dev first startup? So what advice would you have for new product or design team members that are moving over into the space to kind of overcome the imposter syndrome most designing for the developer persona?
Speaker 2 21:15
Well, we don't have the silver bullet yet. Right? We're, we're young, we're growing and we're focused on like community-driven, um, roadmaps. So we want to have our users and, you know, prospective users help us define what we should be building, uh, going forward. And, you know, I think with that, the most important thing there when we've been trying to define and design for the development community is, is one to be transparent, right. To, to show what you have, um, in a where it works. And we try to do that, you know, as clearly as we can with inside the onboarding experience, um, you know, the second is investing in like a dedicated developer page that is almost like the precursor to your documentation of showing, you know, exactly how the experience will work from a technical standpoint. And then you can link it back to your documentation, I think is very helpful to, to communicate. Um, but you know, I don't know if you know, the right answer is different for everybody and for different products and, um, you know, they're developers, no BS. So I think it's like cutting to the chase.
Speaker 1 22:44
And then for my last question, you're obviously on a graded venture right now with Leica and you have an awesome team. Uh, some of the people that you actually worked with behalf are, you know, working with you at flight code. And what do you think you learned about yourself from behalf? That's something that you're applying to this next challenge, cause you had a great career, a lot of personal growth over those seven years, and you want some of the good stuff that you're bringing forward.
Speaker 2 23:13
So I think that for really any entrepreneur and, um, you can even apply it in the corporate space for some innovation teams where you start and kind of the ideas or vision that you have for the future. Uh, you know, things will shift and change and like that's good, there's no straight line. And I think I learned that at behalf where like we used to be called <inaudible> back in the day and we, he had, it was, it was so hard to say it on the phone and I'm like Basma, what, but, you know, so we were <inaudible> back in the day and what we were selling then versus, you know, seven years later it was like a complete makeover. And, you know, maybe that was the vision at the time, but, uh, it was probably bits and pieces. And so the biggest learning I had was being okay with uncertainty and to be open to your customers to share what creates value for you. And so we have a team that is not too stubborn in their ways. You know, we have a team that, uh, is very flat, you know, from brand new employees to, you know, the founding team everyone's voice is heard and, uh, you know, most importantly, um, it's customers first. So, you know, we're investing as much time and energy we can into supporting, you know, the customers we can in sport today. And the ones that we can't, you know, we're very open and honest with them about that. Um, so that we're not overselling them on, on something that, you know, one day could, could actually support them when they're ready. And when we're ready,
Speaker 1 25:00
That's legit. Jake, thank you for the time today, you can find fly code launch coming soon, and we will let you, uh, get to that Peloton so you can get your ride.
Speaker 2 25:12
Yeah, it could use a good sweat.