A Playbook for Product Development in DeFi by Alim Khamisa | Devcon Bogotá

foreign [Music] camisa I work at element Finance I'm a product manager element Finance is a protocol a D5 protocol for fixed and variable yields and um I'm really excited to be here today to talk to you about product development and defy 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 um and oftentimes people will think they do one thing or another oftentimes a PM does a lot of things it's everything um 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 uh 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 um 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 D5 research teams really need to focus sorry the D5 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 D5 Primitives and contributing those Primitives to the open source defy ecosystem and at the same time you're leveraging D5 Lego pieces and this again fits within the whole um you know idea or ethos of composability within the D5 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 D5 space and it could potentially lead to entirely new products and so with that um 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 um I think the now next later approach works really really well especially in the fast-paced environment of defy 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 D5 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 the presentation and I want to get into you know how do we find a process a product development process that works for uh 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 D5 protocol versus adapt 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 either previously to researchers and come from a very intensive research background so they'll usually kind of come up with a new feature um 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 in a front-end design teams and our product teams will kind of do the scoping and prototyping so hashing out the UI ux the requirements and of course also kind of creating the project plan for what's to come uh and then in stage three we get into our development Sprints many of you if you work on product teams today uh Sprints can be typically two weeks but it could be a week it could be a month it really depends on the team um and this is where we get into the execution cycle important to note that we're actually running two um two sprints in parallel so the smart contract team is is developing all of this solidity code their unit testing they're doing their fuzz testing a formal verification and Audits and then the front end team is um 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 is is uh agile estimation so 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 sub-optimal 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 it 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 into the development tasks we look at collaboration costs and I think this might be something that might be new to many of you um the level of collaboration with other teams for example if my design team needs to provide new components if there's a lot of uh 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 the development team to 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 um 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 hat cat Gauntlet token spice all of these things I do encourage everyone to to kind of take a look at and explore on their own product Market fit in kpis really important this is something my team has been spending a lot of time on lately um and what's the common metric across D5 right now right it's tvl total value locked right it's 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 good idea of product Market fit so tvl is not really sticky Traders often look for the best yields across D5 so loyalty is fickle and that cause that can cause a lot of volatility in the tvl tvl is also um 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 the token distribution is is really high and you know you have a very decentralized token economy you might have more participation in governance and you just have you know more participation in in the protocol that's also a really good sign as well product engagement metrics like daily active users or daily active addresses churn and retention metrics user actions like in a D5 protocol you often have users depositing trading redeeming and other types of metrics are really important um 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 D5 projects out there like maker Ave 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 right this kind of fits within the ethos of web3 where users have full control over the over their data if they want to opt out of anonymous data collection you need to give them that that opportunity to do that and then you know open source tooling is better I mean than than closed source of course and um the the kind of uh uh the 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 um and I'm happy to chat about that a little bit more uh later because I know I'm just down to a couple a couple seconds um but yeah feel free to follow me on 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 and uh happy to take any questions if we have any time