[Music]
hello everyone my name is Gregory Roco
as mentioned and um I tried to figure
out what I could do in a short amount of
time for a lightning talk I felt like
you'd have a lot of Highly specific
technical talks so I figured I'd give
product a go when it comes to giving one
of these so the title itself is product
Le blockchain development so it's kind
of covering the whole lineage of going
from product Le growth for startups to
uh product Le protocol development which
was originally coined by Dan Romero a
couple years ago and thinking about
forecaster and then finally product Le
blockchain development which is this new
era of everyone uh seemingly wanting
their own block space for some strange
reason but we'll we'll figure it out
eventually um but the subtitle here is
why you're wrong and the market is Right
deals specifically with making sure that
whenever you think about uh product
development protocol development or even
blockchain development that you are
serving some customer need and not your
own interests to a certain degree you
have to be in what you're doing but at
the same time you have to serve a market
um and a disclaimer to this talk is that
I was a founder and I was wrong plenty
of times I specifically started my
career in uh this space in decentralized
identity which namely is a hard space to
crack when it comes to product
development and probably there are just
very few uh companies and protocols that
have done it maybe ens is the closest to
product Market Market fit when it comes
to Identity um but user Control
credentials generally were quite tough
um going back into the core basics of
product development one of the kind of
core pillars there is product L growth
namely that's whenever you build a
product you specifically have to make
sure that customer needs and customer
experience are at the Forefront
dictating everything that you do and
become the full kind of motion for what
you do so feedback comes in you then
take that feedback as a product
developer and that's what influences
engineering design messaging and
everything in between it shouldn't come
from oh just one more feature and all
these users are going to use it it never
works out that way it's specifically the
case of someone requesting a feature
from what you build you bring something
to Market you get your initial set of
users and you're constantly using that
messaging to inform what you're going to
do and all the decisions you're going to
make when thinking about product
development this was the framework for a
long time when it came to startups it's
what I was indoctrinated with when I
went through Y combinator and then later
in the space since we're all kind of
building these emerging protocols and
blockchains uh the framework had to be
changed a little bit because it was a
bit of like a blue ocean space when it
came to protocol development uh kind of
fast forward a little bit later and you
have the situations where developers do
developer things where the developer
might have an interesting idea and might
have some problems bringing it to Market
specifically because they're just kind
of handing a protocol over to someone
and saying here build on this build all
these great ideas on my protocol it'll
be great but the problem is it's not
taking those first principles into
account and a couple of years ago Dan
Romero from forcaster put out a post
post post called Product Le protocol
development and it's specifically dealt
with the the idea that as a protocol
developer you're building the first apps
and clients that leverage your own
protocol and are then taking the
feedback from those to inform protocol
development namely in his case there are
three core tenants of product lied
protocol development the first is that
users use apps and clients they don't
use protocols so in let's use foraster
for the sake of the example users are
using warp cast they're kind of making
posts they're interacting with the
application and on the back end it's
forast the protocol that's kind of
informing all these interactions the
second thing is that a developer worth
their salt will make sure that they are
concerned with meaningful daily active
users instead of the coolest technology
that they want to use a developer that's
building for an audience specifically
and not experimenting and the third and
final part of it is that Protocols are
valued based on the clients and app
success that build on set protocol so
it's always making sure that apps and
clients are at the center here and then
if you're building a protocol you are
defining the blueprint for how that
protocol should be used by being
informed of what's happening on these
apps and clients that people are
actually using and then finally to round
it out complication requires a bit of
order recently in the space we're
finding protocols wanting to have their
own block space building app specific
rollups and I think just the bottom line
of all this is just making sure that if
you kind of go down this route that you
have to be the block space you want to
see in the world you have to make sure
that when you're building this you are
building the killer app leveraging this
block space that you're not going the
usual route of building this thing and
saying hey everyone we're going to get a
growth marketer to bring a million
developers through the door and then
they're going to build a whole bunch of
stuff on our new protocol and it's going
to be great it's like no you're going to
be building the app that specifically
leverages this for what you designed it
to do and if it doesn't work out well
then you might need to hit the drawing
board again but it's all specifically
going back to this core idea of product
Le growth where you are presenting
something to the market you're
presenting the end users with something
to use they are then informing what
happens with that and everything in
between so kind of returning to First
principles I encourage experimentation
but at the end of the experimentation if
you do wish to bring something to Market
please keep designing and developing
with users in mind and making sure those
users are able to give you feedback to
inform the next stages of what you're
building so
thanks thanks a lot Gregory and now we
have a little bit of time for questions
wow someone's ready I can I can see that
all right let me get this box to you
ready and
go hello thank you don't I'm I'm curious
to have your opinion about the fact like
don't you think like the space is even
design to not incentivize like
competition between different rollups
because they're all looking to attract
liquidity attract user and just grow
like individually and so this doesn't go
in pair with like taking care of re user
because they compete for user they
compete for liquidity and there is like
a lack of interoperability really so
what are your thoughts on this so in the
case of like very app specific case
you're then competing with others like
we don't need all those rollups no we
don't like it's it's it's unnecessary
like I think I'm an agreement with you
we we don't to a certain extent but
making sure that if you were building
something to then build in in those use
cases at the same time um or I might not
be understanding the question correctly
well I think like the the the space is
designed in a way like everyone want to
talk own rollup get users get liquidity
but at the end like we're not building
something that actually can be useful
for people like and it's also sometimes
just Ser serving like the ecosystem but
to an extent so if there is a dominant
use case that's an app specific rollup
then good for that my hope it it masses
the most amount of liquidity in in that
only way and dominates that space if
it's providing a good enough of
experience like I'm I I want to allow
the ability for anyone to create that
app specific rollup but at the same time
I want to very like I want someone to
win and that's okay because it means
user getting the value and if if that
app specific roll turns around and does
something against user wants there's
another app specific roll up kind of
waiting for that or waiting for that
user
base okay thank you is there another
question because otherwise I another one
here yes there are others
so um so you essentially mentioned that
you developers should focus on building
a product that the market wants um what
makes it and we see that most companies
actually have are having a hard time
doing this what do you think makes it so
difficult to apply that very easy
fundamental first principle thinking I
think being the space for a number of
years
um everyone there's there's a lot of
cases where people aren't working uh
deeply enough or pinpoint enough on a
very specific issue um namely that good
good example like let's let's use a
hypothetical of like social protocols or
like a someone building a chain for like
all the social protocols they're
thinking mostly about this is again a
hypothetical but like we're going to
amass all the social protocols they're
going to be using our chain they
different clients and all that without
building the very specific client
themselves and saying we're going to be
offering this experience first as a
first class citizen they're thinking too
much about offer it to everyone before
let's get the experience right and
figure out how to then open it up and I
think that's been a part of the thinking
or an issue with the thinking for a long
time it's ambitious and it's very like a
good thing overall but at the same time
it becomes difficult to provide that
very narrow experience or solve that
very specific problem before thinking
too widely and I think you have to
balance both of that when When
developing and designing