Conventional startup wisdom would tell us that ossifying a product idea before iterating based on feedback is obviously a losing strategy. All startups progress from idea to mvp to product and then improve or change drastically based on feedback from users and the market. Even the best product ideas are incomplete and can only be made good after taking into account loads of user feedback. I am a firm believer that it is the act of going to market that unlocks the potential for a product to achieve product market fit. Everything else before that is just practice.

In the crypto community, we hold core values such as decentralization, permissionlessness, and immutability. These are critically important, but I fear that we focus too much on how products should exist in their end state and not how to make great products in the first place. Demanding that all crypto products be built decentralized, permissionless, and immutable from the start makes it more difficult to build useful products. It presumes that we know exactly which products should exist on crypto rails, their exact form factor, and how to bring them to market. This thinking is dangerous and translates to an early stage product culture where we ossify before we iterate. Start with a whitepaper and work toward a product. Nerd snipe the researchers, then build for users. But in practice this is not how good products are built.

It’s a mistake to look at the success of early crypto protocols like Uniswap or Compound and think it’s canon to build products that way. They are outliers. Products don’t gain traction in a straight line. Sometimes the core product is not interesting to users. Sometimes a particular feature leads to a brilliant insight. Sometimes you uncover a series of dead ends and never find anything that sticks because you’re too early or too late. There is only one way to find out.

In the early days of Zora we fell into the trap of ossifying too early and it slowed us down. We spent weeks designing our ideal nft marketplace protocol and then months writing, testing, and auditing the contracts and building all of the middleware on top to support its launch. All in, it took six months to ship V1 on mainnet. Shortly after launch we discovered numerous improvements to be made and started another six month crusade for V2. From the time we started on V1 to the time we completed V2, the market looked vastly different and our ideas had not been well validated. Only later in trying to increase the top of funnel for the Zora Marketplace did we stumble upon the open editions product, where it turns out there was PMF and is now the basis for all Zora products. 

To help teams learn from some of the mistakes I’ve made and still see others make, here are a few simple ideas on how to iterate faster in the early stages of crypto product development.

1. Do more things offchain. The more of your product you decide to put onchain the more costly it will be to build and use your product. For most engineers, the crypto stack is unfamiliar. Building custom smart contracts requires fixed costs in writing, testing, auditing, and deploying new code. But also, putting more logic onchain will simply cost more for your users to use your application. Of course there are many benefits to putting things onchain. So If you must do things onchain, keep it to hardened contracts to minimize scope creep. Examples of applications that have executed well on this approach are Farcaster, Blackbird, and Hivemapper.

2. Use technology that’s available today, not what’s promised in the future. It’s easy to get excited about the latest “endgame” research topic and want to incorporate that into your strategy and product roadmap. But most research is years away from production use. It’s far more strategic to build software that allows your product to adopt a new technology when it’s ready than it is to wait for the technology to arrive. I’ve yet to see “endgame” research translate to product experience benefits to the user. A good example of this in practice is the competitive dynamics between Optimistic and ZK rollups. With the first mover advantage that Optimism and Arbitrum have, it’s been challenging for Polygon Zero, Zksync, and soon Scroll to differentiate. A rollup with faster withdrawal times, just might not be enough to a.) encourage developers to build first party apps and b.) cause users to churn from apps on optimistic rollups. The longer you wait to bring a technology to market, the more differentiation matters!

3. Focus on your onboarding experience. It’s not a hot take to say that user onboarding is still the primary issue for usage of crypto products. That’s not to say if you fix onboarding you will magically get usage for your application. But web2 like onboarding experiences will improve the top of the funnel for your product and allow you to build a healthier user funnel to get more robust feedback. Embedded wallets, L2s, stablecoins, and better onramping solutions will help tremendously here! 

4. Ruthlessly engage with your users. Many crypto teams don’t even know who their users are. I am not sure if anyone knows who is LPing in some of the largest Uniswap Pools. This is one of the double edged swords of building onchain. But it is not a good excuse. Gathering, prioritizing, and incorporating user feedback is required to build great products. Teams that do this best well have products that stand out from their competitors because they’re building explicitly for their users’ needs. 

Views are my own and not investment advice. Please see https://www.haun.co/disclosures.