 So my name is Alim Kamisa. I work at Element Finance. I'm a product manager. Element Finance is a protocol, a DeFi protocol for fixed and variable yields and I'm really excited to be here today to talk to you about product development in DeFi and let's get started. So first off, I kind of wanted a level set on what does a product manager do and you know, there's lots of different definitions. And oftentimes people will think they do one thing or another. Oftentimes a PM does a lot of things. It's everything. So the core area of responsibility is shaping the product, shipping the product, measuring product success. And these are things I'm going to kind of loosely talk about throughout the presentation. But synchronizing the team is really important. The product person will interface with the rest of the team, kind of align on timelines, hash out kind of product requirements and ensure everyone is on the same page and kind of working in the same direction. So I want to talk about building the product roadmap and how I want to kind of place a little bit of emphasis on R&D and how that's really important to kind of creating new product opportunities. So DeFi research teams really need to focus, sorry, DeFi teams really need to focus on research and development in order to succeed in the space. They got to commit to experimentation. It's not just about rehashing existing solutions and it's important to take an additive approach where you're building new DeFi primitives and contributing those primitives to the open source DeFi ecosystem. And at the same time you're leveraging DeFi Lego pieces and this again fits within the whole, you know, idea or ethos of composability within the DeFi space. So having a pipeline of research projects is really important. It could really guide the evolution of the product or DAP you're working on within the DeFi space and it could potentially lead to entirely new products. And so with that, you know, the the pipeline of research projects can really form the basis of the R&D roadmap and the R&D roadmap is a critical input, a very important input into the product roadmap. Mind you, it's not the only input into the product roadmap. There's lots of other things, but it is really important. I want to talk about how do we structure the product roadmap or lay it out because oftentimes we think about it from a timing perspective by month, by quarter. I think the now next later approach works really really well, especially in the fast-paced environment of DeFi or for teams that are working on new product development you know, V1 of a protocol where there's a lot of uncertainty and things are changing really fast. So everything you're working on in flight is kind of in the now bucket, everything that's coming up is a next and anything that is low priority kind of gets shifted into the later bucket. This kind of gives DeFi teams the ability to not be kind of handcuffed to specific timelines when you're developing a V1 and kind of, you know, develop it right and not necessarily take the shortcuts. And it just gives them the ability to have more flexibility in terms of how they're developing and timelines overall. So this is actually one of my favorite sections of their presentation, and I want to get into you know, how do we find a process, a product development process that works for for your team? I have to say that I'm going to caveat this with there are lots of nuances across different teams, team size, culture. If you're working on a DeFi protocol versus a DAPT that's being built on top of a protocol, all of these things kind of play into the specific custom product process that you should develop for your team. So this is something that's worked really well for Element Finance and with that we are still evolving the process as we should be to suit our needs as we kind of evolve as a team. So stage zero is kind of the concept vision stage and this is where our smart contract leads and our founders, both of our founders are previous ETH2 researchers and come from a very intensive research background. So they'll usually kind of come up with a new feature or something new, whether it's a new product concept altogether. And then the smart contract team leads will usually try to crystallize that with our founders. And then in stage one, the formative stage will have our smart contract teams, our front-end teams, product and design kind of working together to really hash out and understand the core functionality. And then in stage two, the smart contract team usually takes a little bit of a step back and they take on a little bit more of a consultative role and our front-end design teams and our product teams will kind of do the scoping and prototyping. So hashing out the UIUX, the requirements and of course also kind of creating the project plan for what's to come. And then in stage three, we get into our development sprints. Many of you, if you work on product teams today, sprints can be typically two weeks, but it could be a week, it could be a month, it really depends on the team. And this is where we get into the execution cycle. Important to note that we're actually running two sprints in parallel. So the smart contract team is developing all of the solidity code, their unit testing, they're doing their Fuzz testing, formal verification and audits. And then the front-end team is, excuse me, the front-end team is working with product and design to kind of execute the development of the UI and the UX. And of course we're doing a lot of internal and external stakeholder feedback throughout that entire process to ensure we're validating assumptions. So when we get into the sprint cycle, one thing that's really, really difficult for product teams to do, this is something I found personally very difficult to do, is agile estimation. So estimating the work effort that goes into your tasks. And that's really important to velocity. And velocity is really important to understand, like how is the team performing? Are they able to deliver on time? Are they able to complete all of the tasks in the sprint on time? Poor task estimation often leads to suboptimal velocity and timeline slipping. So I got to give a shout out to my front-end team. I don't know if I have any of them here today, but shout out to them. Because we came up with this really interesting framework for estimation that I think works really well. So we kind of look at time, rough estimate of the time to complete that user story or if it's broken down into the development tasks, we look at collaboration cost. And I think this might be something you might be new to many of you. The level of collaboration with other teams, for example, if my design team needs to provide new components, if there's a lot of, you know, if the product requirements are really intensive and require a ton of time and require lots of working sessions, all of those things are going to take away development time, and that needs to be factored in. So that's part of the collaboration cost. The confidence is really a score for the confidence on the time estimate, which also includes complexity and the collaboration cost. And the key takeaway here is you want to avoid your timelines from blowing up by having too many high collab and too many low confidence scoring tasks in the same sprint. That's going to allow the development team to have enough time to be able to execute the tasks without getting bogged down on a lot of working sessions and too many meetings and stuff like that. I don't know if I have enough time for simulation modeling, so I'm going to skip this, but this is a topic that's very near and dear to my heart. So if you have questions, we can address them a little bit later. But I'll just quickly touch on tools like Catcat, Gauntlet, Token Spice, all of these things I do encourage everyone to kind of take a look at and explore on their own. Product Market Fit and KPIs, really important. This is something my team has been spending a lot of time on lately. And what's the common metric across DeFi right now, right? It's TVL, total value locked, right? It's a good metric. Is it a great metric? I don't think so. It's a good metric when it's taken in concert with other metrics. Alone, I don't think it's sufficient to give you a good idea of Product Market Fit. So TVL is not really sticky. Traders often look for the best yields across DeFi, so the loyalty is fickle. And that can cause a lot of volatility in the TVL. TVL is also subject to a lot of market cyclicality, bull, bear. And it's just not a good long-term metric to measure long-term sustainability, health, and success of a protocol. So again, it's not a bad metric, but it should be taken alongside other key metrics, which I'll touch on very quickly. Ecosystem engagement metrics are crucial. Understanding community engagement and frequency, developer activity, are there other developers building on top of your protocol? Integrations, are there other protocols integrating with your protocol? Those are really strong indicators of Product Market Fit. And the number of unique token holders. So if the token distribution is really high and you have a very decentralized token economy, you might have more participation in governance, and you just have more participation in the protocol, that's also a really good sign as well. Product engagement metrics, like daily active users or daily active addresses, turn and retention metrics, user actions, like in a DeFi protocol, you often have users depositing, trading, redeeming, and other types of metrics are really important. I'm going to skip over this for time, because I'm down to a minute and a half, but how do we measure some of these metrics? It's really important. So first of all, you may not know this or maybe you do, but a lot of DeFi projects out there, like Maker, Aave, Uniswap, DYDX, are collecting user data. Mind you, most of them have the privacy flag turned on, which is something you can do in Google Analytics and other tools like Mixpanel. But they are collecting user data. It's anonymized data. It's really important for informing product decisions, app and protocol evolution, and optimizing marketing efforts as well. What's really important is that you've integrated consent management. This fits within the ethos of Web 3, where users have full control over their data. If they want to opt out of anonymous data collection, you need to give them that opportunity to do that. Then open source tooling is better than closed source, of course. The tech stack that I've outlined here is a typical product marketing analytics tech stack that we could use that includes all open source tools. I'm happy to chat about that a little bit more later, because I know I'm just down to a couple seconds. But yeah, feel free to follow me on Twitter, elements underscore phi on Twitter as well. I'll have a blog post coming out, which will be very comprehensive and cover all of this in much, much more detail. So stay tuned for that as well. Happy to take any questions if we have any time.