Do Things That Don’t Decentralize
Thoughts on Paul Graham’s “Do Things That Don’t Scale” — Applied to blockchain applications and products.
TLDR: Don’t decentralize the entire product at once. Build the crucial parts, release and iterate until you’ve build something users want. Then decentralize the rest.
Fresh from Berlin Blockchain Week, DeepWork Studio is excited for what we see as a renaissance of decentralized autonomous organisations (DAOs). They’ve been around in theory for a while, but now we’re beginning to see them in practice. However, as product designers we’re concerned by repeating mistakes from 2017 and 2018. Whereby users needs are placed second to developer’s idealisation of decentralization, we propose a product design approach to develop Minimal Decentralized Products. Using principles from ‘do thing’s that don’t scale’.
At Deep Work Studio we’ve helped teams such as ConsenSys, Hummingbot, Molecule, Ramp, Pillar and Wyre release user-focused products.
What happens when you decentralize everything?
For any product the more features you add to a product, the exponential time it takes to release.
Being entirely decentralized means you need a lot of features to launch a product. There isn’t a lot of room to iterate quickly and loosely. Thus there is a lot of under the covers build-up to the ‘big launch to mainnet’.
However, this leads to increasing gaps between studying and iterating on what works for users and actual launched products. How many times have we seen projects go from hyped launch to big flop? How many are struggling to onboard users or gain liquidity?
What’s the result been?
Dapps are not building things users want — in the worst cases they haven’t even asked what they want. The disconnect is tragic and only going to get worse.
Taking a rather relevant paragraph from the mighty Paul Graham of YC:
“So why do founders think launches matter? … They think what they’re building is so great that everyone who hears about it will immediately sign up. Plus it would be so much less work if you could get users merely by broadcasting your existence, rather than recruiting them one at a time. But even if what you’re building really is great, getting users will always be a gradual process — partly because great things are usually also novel, but mainly because users have other things to think about.”
But, decentralization is important, otherwise we’re building nothing better!
Beltran Berracol suggests that Decentralization is always the end goal — something we should strive towards. It will be a cultural shift and movement — like civil rights — and played out over time. It won’t happen with mythical seismic launches. It will happen one usable step after another.
We need to keep the end goal in mind. Taking it in steps — creating awesome products that shift users towards better solutions.
Only then can we solve problems such as the worlds 26th richest people owning as much wealth as the bottom 50%.
How to build products user want, but love?
Iterate, iterate, iterate.
Or put another developer-centric way,
Launch > Feedback > Iterate > Feedback > Iterate
If you want to decentralise everything for launch — you’ll never build something that users want. Because, you haven’t asked what they want enough.
How can a blockchain protocol or Dapp iterate?
I propose a Modular Approach to Decentralization:
To borrow from Paul again:
Manual — There’s a more extreme variant where you don’t just use your software, but are your software. When you only have a small number of users, you can sometimes get away with doing by hand things that you plan to automate later. This lets you launch faster, and when you do finally automate yourself out of the loop, you’ll know exactly what to build because you’ll have muscle memory from doing it yourself.
Stripe is an excellent example of iteration. Stripe’s banking onboarding looked like automated software. It was in fact the team manually setting up a client with a banking partner. The users had no idea and didn’t care. It felt like it was automatic, but was in reality automated later after they knew how to do it for users. Likewise, just as you can automate parts of a software product you can also decentralize parts of an application or system as you go.
For a decentralization maximalist. The idea of launching something with parts controlled by a centralised party might be a hard pill to swallow. But, what’s the point if FinTech keeps talking to users and building better solutions? Will we ever build an alternative decentralized finance system if we can’t catch up and build solutions users want?
Blockchain has a UX problem and Fintech is winning the war.
It doesn’t matter how we get there. As long as we get there. To reach a decentralised, permissionless, censorship resistant, usable web3 promised land — we need to go into war mode.
“Peacetime CEO knows that proper protocol leads to winning. Wartime CEO violates protocol in order to win.” — Ben Horowitz
It’s a stark choice between launching and iterating until we have a billion decentralized users. In the meanwhile, the incumbents will win with moat-style regulation, centrally controlled blockchains and user acquisition.
How To Design A Modular System To Decentralization
- Talk to users and find out what they care about
- Find the market and business value in your product
- Have a plan on how and when you’re going to decentralize
- Build the MVP — or Minimal Decentralized Product (MDP)
- Gather feedback and iterate
- As you grow your user base, introduce more and more decentralized components
Summary
Don’t decentralize the entire product at once. Build the crucial parts, release and iterate until you’ve build something users want. Then decentralize the rest.
Have an alternative to Minimal Decentralized Products (MDPs) ? — I’m here on Twitter: @charliellington
Need Product Design Strategy? Unsure how to prioritise and find the most valuable parts for decentralization? See our work at DeepWork.Studio. We use Google Ventures Design Sprints to remotely prototype, test and learn from real user feedback — fast.
Thank you to Jim Kosem and Andrej Ktitarev for your inputs and edits!
