Product-Led Blockchain Development

Hello everyone, my name is Gregory Rocco as mentioned and 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-Led Blockchain Development, so it's kind of covering the whole lineage of going from product-led growth for startups to product-led protocol development, which was originally coined by Dan Romero a couple of years ago when thinking about Forecaster, and then finally product-led blockchain development, which is this new era of everyone seemingly wanting their own block space for some strange reason, but we'll figure it out eventually. But the subtitle here is Why You're Wrong and the Market is Right deals specifically with making sure that whenever you think about 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 interested in what you're doing, but at the same time, you have to serve a market.

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 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 companies and protocols that have done it. Maybe ENS is the closest to product market fit when it comes to identity. But user-controlled credentials generally were quite tough.

Going back into the core basics of product development, one of the kind of core pillars there is product-led 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 in 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 of building these emerging protocols and blockchains, 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.

Kind of fast forward a little bit later and you have the situations where developers do developer-y 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 Forecaster put out a post called Product-Led Protocol Development, and it specifically dealt with 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 tenets of product-led protocol development. The first is that users use apps and clients, they don't use protocols. So let's use Farcaster for the sake of the example. Users are using Warpcast. They're kind of making posts.

They're interacting with the application. On the back end, it's Farcaster, the protocol, that's kind of informing all of these interactions. The second thing is that a developer worth their salt will make sure that they're 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 said 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 roll-ups. 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-led 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 see that. All right, let me get this box to you. Ready? And go. Hello, thank you.

I'm curious to have your opinion about the fact, don't you think the space is even designed to not incentivize competition between different roll-ups? Because they're all looking to attract liquidity, attract users, and just grow individually. And so this doesn't go in pair with taking care of every user, because they compete for users, they compete for liquidity, and there is a lack of interoperability, really. So what are your thoughts on this? So in the case of very app-specific case, you're then competing with others.

We don't need all those roll-ups. No, we don't. It's unnecessary. I think I'm in agreement with you. 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.

I might not be understanding the question correctly. Well, I think the space is designed in a way like everyone wants to top their own roll-up, get users, get liquidity, but at the end, we're not building something that actually can be useful for people. And it's also sometimes just serving the ecosystem. But to an extent, so if there is a dominant use case that's an app-specific roll-up, then good for them. I hope it amasses the most amount of liquidity in that own way and dominates that space if it's providing a good enough of experience.

Like, I want to allow the ability for anyone to create that app-specific roll-up, but at the same time, I want someone to win. And that's okay because it means users getting the value. And if that app-specific roll-up 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. OK, thank you. Is there another question?

Because otherwise I was another one here. Yes, there are others. So you essentially mentioned that developers should focus on building a product that the market wants. What makes it, and we see that most companies actually 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 in the space for a number of years, everyone, there's a number of years, everyone, there's a lot of cases where people aren't working deeply enough or pinpoint enough on a very specific issue. Namely that, good example, let's use a hypothetical of social protocols, or someone building a chain for 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. There are 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 developing and designing.