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