unconfirmed.blog
Open in
urlscan Pro
76.76.21.21
Public Scan
URL:
https://unconfirmed.blog/iterate
Submission: On March 16 via api from US — Scanned from DE
Submission: On March 16 via api from US — Scanned from DE
Form analysis 1 forms found in the DOM
<form class="space-y-6">
<div class="mb-6">
<div class="flex flex-col sm:flex-row shadow-sm rounded-md mt-9 space-y-3 sm:space-y-0">
<div class="relative flex items-stretch flex-grow focus-within:z-10">
<div class="absolute inset-y-0 left-0 flex items-center pl-3 pointer-events-none"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="currentColor" aria-hidden="true" data-slot="icon" class="w-5 h-5 text-gray-400">
<path d="M1.5 8.67v8.58a3 3 0 0 0 3 3h15a3 3 0 0 0 3-3V8.67l-8.928 5.493a3 3 0 0 1-3.144 0L1.5 8.67Z"></path>
<path d="M22.5 6.908V6.75a3 3 0 0 0-3-3h-15a3 3 0 0 0-3 3v.158l9.714 5.978a1.5 1.5 0 0 0 1.572 0L22.5 6.908Z"></path>
</svg></div><input type="email" name="email" id="email"
class="sm:rounded-l rounded-md sm:rounded-r-none sm:rounded-t-none text-sm sm:text-base block w-full pl-10 border-gray-300 focus:ring-primary-500 focus:border-primary-500 disabled:text-gray-400 focus:border-transparent"
placeholder="Type your email..." value="">
</div><button type="button"
class="sm:rounded-r rounded-md sm:rounded-l-none sm:rounded-t-none inline-flex justify-center px-4 py-2 text-sm font-medium text-white bg-blue-600 border border-transparent shadow-sm hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-blue-500 sm:col-start-2 sm:text-sm disabled:opacity-50 disabled:cursor-not-allowed"
style="background-color: rgb(158, 59, 246);">Subscribe<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="currentColor" aria-hidden="true" data-slot="icon" class="w-5 h-5 ml-2 text-white-400">
<path fill-rule="evenodd" d="M12.97 3.97a.75.75 0 0 1 1.06 0l7.5 7.5a.75.75 0 0 1 0 1.06l-7.5 7.5a.75.75 0 1 1-1.06-1.06l6.22-6.22H3a.75.75 0 0 1 0-1.5h16.19l-6.22-6.22a.75.75 0 0 1 0-1.06Z" clip-rule="evenodd"></path>
</svg></button>
</div>
</div>
</form>Text Content
UNCONFIRMED
Subscribe
BUT FIRST, ITERATE
OR HOW TO NOT SHOOT YOURSELF IN THE FOOT
*
BRECK.ETH
January 23, 2024
Share
Collect
*
1 collector
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.
Loading...
Collect this post to permanently own it.
Collect
Subscribe to Unconfirmed and never miss a post.
Subscribe
ARWEAVE TX MEoSsPRzh9AVbHjABXgv4C4-3W8uNX0hDpbdVNwM0uQ
Add your comment
brxckinridge
Commented 1 month ago on Farcaster
I wrote this a couple of weeks ago, but it feels right to share here given I
think that @dwr.eth and @v have done a great job embodying some of the lessons
I've learned along the way and tried to distill in this post
https://unconfirmed.blog/iterate
3 0 0
polluterofminds
Commented 2 months ago on Farcaster
So many great nuggets from this article (h/t @colin for sharing), but figured
this was a good quote to share with the devs. “Use technology that’s available
today, not what’s promised in the future.” https://unconfirmed.blog/iterate
1 0 0
colin
Commented 2 months ago on Farcaster
Really enjoyed this post by @brxckinridge. It encapsulates a lot of the
foundational thinking we have at Paragraph: https://unconfirmed.blog/iterate
27 2 5
manuelmaccou.eth
Commented 2 months ago on Farcaster
After just the first few paragraphs, I’m already in agreement and it’s what I’ve
been saying for a while. The crypto community discards decades of best practices
(that actually work) for the sake of defiance against “Web2”. How to build a
great product/business shouldn’t be ignored out of spite.
3 0 0
morereese
Commented 2 months ago on Farcaster
This is an awesome no-nonsense take based on real, hard-earned experience. I
especially enjoyed the framing, “everything before that is just practice”
2 0 0
cojo.eth
Commented 2 months ago on Farcaster
+1 for our approach with @ponder
2 0 0
sanchitram.eth
Commented 2 months ago on Farcaster
What would you say is something you learned after iterative releases, about what
your PMF / differentiators would be?
1 0 0
polluterofminds
Commented 2 months ago on Farcaster
“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.” 💯
1 0 0
WHAT'S YOUR EMAIL?
Subscribe to never miss a post.
Subscribe
No thanks
RSS
Create your own publication
© 2024 Unconfirmed