When writing software, it’s easy to assume whatever is shipped will solve problems. After all, that’s the whole idea of code — automate the solution of specific problems. But code doesn’t do this inherently. And when you productize code, it gets even more complicated. All of this applies doubly to code designed around new technologies. It’s incredibly easy to get excited about the technology and build solutions that people don’t actually want or need. Even if they do need the solution, it’s possible people don’t want it. In that case, your code has to solve the problem but also bridge that gap of need and want.
For my company, SimpleID — a developer tools suite for Web 3.0, we fall into that last bucket. We need to solve a problem but we need to do it in a way that enables the ultimate end-users to adopt the solutions built via SimpleID en masse. We’re not alone in this problem. The issue applies to product creators across Web 2.0 and Web 3.0.
Let’s take a look at the market I’m working in: Web 3.0. Web 3.0 is essentially the decentralized web. The web where users control their data, not big tech companies. In the Web 3.0 space there are many solutions offering non-custodial, completely decentralized experiences. They are great, and they are needed. But to those solutions, the question we have to ask is:
Who is the customer?
If you are building a solution that applies to the slim minority of cypherpunks and developers who are willing to go through the complexities of using your solution, that’s great. But if you, like many in the Web 3.0 space, want to attract the wider internet user-base, you have to make your solution attractive to that market.
In other words, you have to bridge the gap.
The problems many of us in the Web 3.0 space are trying to solve are similar:
- Privacy
- Security
- Data Ownership
- Identity Control
The way those problems are solved is what differs. In almost all cases today, the tooling around building applications that satisfy the above needs place an unprecedented burden on users of the modern web. I say modern web here because surely someone somewhere will be able to point out a scenario in the very early days of the World Wide Web where people had extreme cognitive burden in order to use the new technology.
So, again, when building in the Web 3.0 space, ask yourself who are you building for. If you’re building for a future customer who will be willing to shoulder the additional burden of using the protocol or product, do that. That’s necessary. If you’re building for the developers who will eventually find a way to make the underlying protocol and tools convenient, do that. That’s also necessary. But if you’re building for enterprises and consumers today, consider the solution you’re offering.
Does it truly need to be non-custodial? Does it truly need to be trust-less? Is what you’re offering so much better that you can legitimately ask people to do more work AND pay you? Or, is there a way to give people enough decentralization and access to decentralized technologies to satisfy the problems in the bullet-points above?
Whether it’s in the Web 3.0 space or the Web 2.0 space, it’s necessary to always ask yourself who your customers are. Build for them, not for yourself. Your ideals matter, but if you are trying to build for an audience, their ideals matter more.
Your product is only as good as the adoption is sees. Adoption, of course, is relative. But no matter what, you have to see that people are using it. Otherwise, it’s very possible you are not solving the problems your customers need you to solve.
Top comments (0)