Embedded engineering: how FDE accelerates PMF in crypto

Transcript

Hi everyone. How's everyone doing? Very excited to be here um speaking in front of you all today. Um especially in France, traveled from New York to get here. Um I want to talk a little bit more about one of the strategies of finding product market fit, especially in a rapidly evolving industry. My name is Jill. I'm the tech lead of the forward deployed engineering team here at privy and in general I just want to talk a little bit about the impact of my role and both at privy but also in the industry anyways what what is a f deploy to engineer um I I want to start with a question um as a show of hands how many of you guys have built a product that the customer said that they wanted but

you didn't end up they didn't end up actually using it either the product team and the engineering teams were out of sync and maybe weren't communicating as or the product team said one thing and the um engineering team said something else. Um I'm going to raise my hand here. Anyone else who built something embarrassingly? Yeah. So this happens quite frequently and in crypto especially this problem is amplified 10x um both through rapidly evolving technology cutting edge research um shift in regulations there's new standards and new tech developments that come out pretty much every few weeks and within a month or two whatever you built yesterday maybe isn't possible or is different than what we built today. Um

so what are what are FDES? What do forward deployed engineers actually do? Um they're engineers who work with customers directly to build their solutions in real time. Um they're not just implementing requirements, they're discovering them through deep technical collaboration, sharing customer and market signals, and of course implementing them alongside the customer themselves. Um so I like to think about this with the 702010 breakdown. Um 70% engineering. So FTEEs are writing production level code. They're architecting systems. They're deploying features. This isn't just pro prototyping or proof of concepts.

They're not building demos for a customer showing the capabilities that Privy has. Instead, they own features fully from end to end either from conception all the way to maintenance. Um, and then in terms of product management, they go out, they understand customer needs, they're prioritizing features, defining requirements, bridging the gap between what does the customer ask for and what does the customer actually need. Um, and lastly, there's a little bit of pre-sales work involved as well. um a lot of technical due diligence, architecture discussions, and feasibility assessments on what's possible and what's not. And it's also important to think about what FTEE isn't. So, it's neither Devril nor support engineering, not nor solutions engineering. Um and Devril evangelizes existing products to adoption. So, a

developer relations um member might say, "Hey, here's how to use our API to get what you need." On the other hand, a forward deployed engineer will say, "Hey, let's actually build the API capabilities that you're looking for. A support engineering team member might fix an existing product that might be broken." Um, they might say, "Hey, here's how to work around this limitation that exists with our product as it stands today." On the other hand, the FTE team goes out and says, "Let's remove this limitation entirely." And solutions engineering is configuring existing products for specific customers. So, hey, we can customize this dashboard based off of your needs, or hey, we can customize this SDK based off what you're looking for. Um, the FD team, instead of saying, hey, we can

customize this for you, it's we'll build out the workflow that you're actually looking for and and the thing that you're trying to do. Um, there's a little bit of historical context with where the role of FTE comes from. Um, Henry, our CEO and founder, he used to work at Palunteer, and I would say Palanteer really walking in the room as we speak. Um, yeah, Palanteer pioneered this. They deploy engineers directly to intelligence agencies and to corporations. Um, and the problem is that complex data problems can't just be solved with off-the-shelf software. And so what they did instead is they had engineers that would really understand both the technology but also the specific domain and they would go out and deploy Palunteer software. And it's more widespread across SAS. Um, a lot of

other companies h have a FTE shape nowadays. You've got RAMP, datab bricks, snowflakes. They've all got small FTE teams that specialize in different product areas. And the key difference between again product engineering and FTE is that FTEEs are going out and they're figuring out what new things to build out. Um there's also academic roots to the FTE role. Um ethnography, which is an anthropology field. Um these are researchers that live within specific communities to understand the culture of those communities directly. So really going out and you you can't understand a culture from the outside and similarly you can't understand a customer's needs from the outside and so embedded directly within their product embedded directly within their team. Um

and a and a modern parallel here is army versus special forces. So the product teams are or the army they're large organized efficient at executing known strategies and they're great at building features where the requirements are are very clear. They might be stationed out of established spaces, so working out of the privy office or working off the privy road map. Um, on the other hand, the FTE teams are small. They're agile. They operate in unknown territory. They're scouting new opportunities and neutralizing any sort of emerging threats that might might exist. Um, and they're embedded in in hostile territories, customers, complex code bases, someone who has a monolithic architecture, something that's from the 2000s, something that's very old. Um and

FTDES are also sometimes working out of customer offices. They go out and we talk to product teams, talk to engineering teams to understand what they need and report back that intelligence to shape broader strategy um in emerging tech. Why is FTE so important? Um I I'm really bullish on FTEE being fundamental position and role at emerging tech companies um especially newer industry and also old ones. In 2025, there's increase in software complexity. Almost every single comp company out there is a software startup.

If you're not using AI or other tooling, you're likely falling behind in whatever industry that you're working in. Um, even my mom, who's a physical therapist, sees and uses AI to write emails and to write documents for for her patients. Um, there's also faster innovation cycles. What's cutting edge today may be table stage tomorrow. There's new standards that are getting created. EIP7702 just came out recently and I'm excited to talk about that a little bit later in the talk. Um, and lastly, customer sophistication. Customers don't just want tools, they want capabilities that evolve with them. Every single company is unique, and companies are looking aren't looking for pre-cut fabric. They're looking for something that is customtailored to them and their needs. Um, yeah. So in in traditional

SAS, the existing model is that a lot of these businesses have very opinionated stances on how to work. There's a best practice on a way to do things and our tool embodies it. So a couple examples of this are linear and asana for for product management tools. Um they figured out the right way to build and they figured out the right way to iterate and they prescribe their workflows. There's epic stories task sprints and a customer's conversation might look like we don't do sprints and linear comes out and suggests you should and here's why. Um and over here the success metric is customers are adopting your methodology. Similarly in business intelligence you've got PowerBI and

Tableau where here's how data analysis should work. Um there's established patterns connectors transformations dashboards, and reports. And there's pre-built templates for a lot of standard business practices. Similar here, s the success metric is customers fit their data model, their data into your model. The foundation layered reality as I like to call it um is that while in traditional SAS customer success is equal to the adoption of their opinions in crypto infrastructure and teams that have an FDE modeled organization customer success is enabling your customers innovation. Um this thing instead of customers adapting to us we

have to adapt to them and what their needs are. Um every use case is genuinely novel. A traditional example is you know there might be a thousandth CRM implementation versus the first ever ever onchain loyalty program. Um so when like when different companies approach us there's no set model that they're going off of. We're effectively building the road map for them. Um you can't Google how how do I handle social token authentication? It's something that you're building out alongside your customer. Um innovation's happening at the application layer. Our customers aren't just using our tools, they're building on top of them. So Blackbird isn't just using Privy, they're using Privy to create restaurant loyalty experiences that never existed before.

Zora isn't just configuring Privy, they're p pioneering creator monetization models. Um, and so yeah, the it comes down to an infrastructure paradox. We need to be stable enough to be built on reliability, security, performance are all priority number one, but we also need to be flexible enough to enable use cases that we've never imagined. Traditional SAS can't afford to be opinionated. Can't afford to be opinated. Infrastructure cannot. So, we're all running along what I call the innovation treadmill. You're not just competing with today's alternatives. You're competing with tomorrow's possibilities.

And so, engineering PMF, instead of just finding it, you are creating product market fit. Um, in a traditional PMF cycle, you go through the build, launch, iterate, and measure. So it assumes that you can find product market fit through experimentation. You're iterating very quickly. You're trying to find different solutions, testing out different hypotheses and different outcomes. And it works when the market moves slowly relative to your development cycle. On the other hand, finding product market fit with a deployed engineering team is a continuous loop. You're build building, measuring, learning, and going back to building. Um PMF isn't a destination here. It's it's a moving target. And again, you're not finding it. you are building it alongside your

customers. I want to talk a little bit about FTEE in action at Privy. Um, generally for any and all features that we build, there's always a champion customer or champion customers that we're building alongside in mind and this always ensures that the product that we're building is used and is useful to the end customer. Um, so one example of this was the global ecosystem wallets which our champion customer was the abstract team and and abstract chain. Um, if you're not familiar with what global wallets are, they allow for an embedded wallet, which is traditionally scoped to a single application, to be used across a variety of applications. So, the Abstrat team wanted any developer that's building on top of their app, to have access to all

of the users that are existing on the Abstract ecosystem. users are able to bring their wallet from one app to another and have all the shared assets and all the shared data and shared history amongst them along with levels of permissions that go in between it. Um when the abstract team had approached us, we had already started playing around with the idea of interoperable wallets. We released our cross app flows a few months prior and had an initial working on what this would look like for select customers. But for Abstract specifically, they had a lot of very specific needs. Um they wanted deeper customization of their own zkinch smart wallet contract. Um they also wanted extreme levels of UI customization. You can see that little nice background along with the presented by cube ink.

And so a lot of this was figuring out how do we architect the systems so that the entire flow is seamless and easy to integrate for the abstract team and what logic is encapsulated within Abstract's SDK versus what logic lives inside of privy's SDK and how do we build this in a way such that not just the abstract team is enabled to build and use our global wallet solution but any team that may want to use the solution that we've built out is able to now also get the same level of customizability and feature set that they're looking for. So we didn't just end up building a bespoke solution for abstract. We built products and features that are housed within Privy for an increased and improved developer and product experience for any future customer that might be interested in building something similar.

Another example of FTE work in action is our EIP72 and gas sponsorship. And unlike the uh previous slide where this was oriented around a single customer, we have so many customers that are interested in 772 and gas sponsorship generally um as an FTE project. What that ends up looking like and what that's currently looking looking like is talking to any customer that's interested in EIP772 andor having gas sponsored generally given how new F or given how new 7702 is the standards are still very very evolving from EIP5792 wallet send calls to having 4337 compatibility the space is changing very quickly and what every single customer

wants ends up being very very different in how they're adopting 7702. So the FTE team first built towards enabling customers. We built out the functionality for signin EIP72 authorizations with the embedded wallet. This means that any customer who wants to use any sort of 772 method is able to do so given their own own solution. And now I'm particularly excited about this work because we're not just building alongside customers in this case but we're building alongside the industry as well. We're pushing forward new like 77 7836 for preparing wallets and calls.

And I would say this is an FTE and its most exciting form. There's a little screenshot down there. Um we reached out to a few teams asking about what different standards look like and how different standards are evolving for some of the new 77.2 capabilities. And you can see that it's a level it's a level that's so deep that it hasn't even been thought of yet. And we're working towards pushing the entire industry forward which by in turn helps push our customers forward as well. Now going from the yeah the transformation is going from a reactive model to a more proactive model. Instead of building and then hoping and iterating from there, you're building based off of assumptions, hoping that the customers adopt what you've built out and hoping that you get adoption,

it's the right thing and then iterating based off of the embedded feedback. The new model model is embed, understand and engineer. Embed with customers from day one, understand what their real world use cases are and engineer solutions in real time. This has given us a really big competitive advantage. Um, we spend weeks working on a product instead of months. Um, every single thing that we've built out is quite accurate. We know exactly what the customer needs and we're building it from day one of any single feature that we built out. We get adoption with customers that we've built towards. And the relationships are a lot better with our customers. Everything, every customer relationship ends up being a partnership instead of a vendor relationship. We're building next to

them. We're helping to enable them. We're pushing their products forward for them to be able to do whatever they're trying to do on top of Privy. And finally, innovation. We're co-creating. These aren't feature requests that customers are sending to us. They really help and shape the future of the product and what we're building and what they're building. So yeah, thank you for coming to my talk on photo deployed engineering. Happy to answer any questions. Yes, thank you. It was very interesting. What do you do uh uh especially when you are early stage and you are you know there is a an argument about the big customers that kind of dragging you through its

own request and then uh locking in a lot of resources. How do you you know balancing between the customer request and your resources and what makes sense in terms of road map? Yeah, that that's a really good question. Um, especially for when you're building towards champion C customers, there's a lot of noise that comes up and as to what they're asking for and what they're building towards. Um, I think it's really important to both not just think about the single champion customer when you're building, but also think about how what you're building affects every other customer that and and what they're looking for. So for abstract, global wallets specifically, like the global wallet ecosystem is something that we built towards not just for abstract, but we've enabled it. So any chain that's looking to build this global wallet

system is able to do so. Yes, with this champion in mind, but also with the extended tail of of functionality and the ability to have this customizability for for everyone else. Um, on top of that, I would say ruthless prioritization is something that's very important. You have to understand what your top level metrics are, what you're building towards, and what you're really trying to get out of the product and and the partnership and communicating that well and directly with the customer on, hey, this is what our relationship looks like. this is what our top level and this is what we're trying to build. We provide the feature set to enable you to do this. But if there are things that go above and beyond with the scope of the privy product looks like that might end up being something that they have in their systems themselves.

Great question. Any other questions? Thank you so much. Appreciate it. [Applause]