FYI, I’m the Chief Creative Technologist and co-founder of Forward in San Francisco. I occasionally write about tech, culture and innovation.
I wrote this as a quick reference for your next brainstorming session when blockchain invariably comes up (and trust me, it will).
So do you need it? The blockchain? Short answer, probably not.
Longer answer: it depends. Probably not. But if you really want to put a round peg in its proper round hole, read on.
Because while blockchain is indeed a nascent, disruptive technology, in most cases it’s often a misunderstood, buzzy solution that’s still looking for the right problem to solve.
For many organizations, the idea of a ‘shared ledger’ that could potentially provide cost reductions, remove intermediaries or even power wholly new customer features like physical goods tokenization and trust-less payments is indeed compelling — but if a regular old database will suffice — blockchain isn’t really needed for your idea.
So if you are brainstorming potential blockchain ideas, this is a good starter-pack of rules-of-thumb. Thumbs? Thumb.
(there are more technical decision tree resources here if you need them).
- Your idea needs to have an immutable (non-editable), publicly accessible database of transactions/records at its core. If this isn’t required, then a regular database is perfect for the job.
- Your idea won’t work without with multiple writers to that database (e.g. not just you/your company) and it’s necessary that you don’t really care — or even trust — who those other writers are. They are anonymous strangers; they could be users anywhere in the world, maybe even your competitors, or perhaps other departments in your company.
- Your product/idea depends on having no single “gatekeeper” of each transaction’s verification because all transactions will ultimately be accepted/rejected by peer-to-peer validators. Once it’s validated, it’s on the blockchain forever, and can’t be removed or edited (“immutable” in blockchain speak). Otherwise, what you want is a centralized database where you control who has access, what gets written, update records, etc.
- Your idea relies on transactional interdependencies (party A transaction depends on B that interacts with C) all of which are “chained” together in order they were validated.
If you can envision requirements where all four of these facets are important to your idea, and this makes your idea more useful/compelling/secure than using traditional data storage — then maybe it’s a good candidate for blockchain. Maybe.
If not — perhaps it’s really just a buzzy solution in search of a different problem to solve. Then it’s back to the whiteboard.