User needs in web3

Often times we build stuff for the sake of building them. Or because we really like the technology. Or maybe because we strongly believe in a future where our product will solve a problem. There is a lot to build as well - we see new shiny toys coming up almost every quarter. And that is fantastic - by building stuff we learn, we grow and generally gain XP as professionals.

But caught up in all the building we often forget something critical - we are building for real people.

TTT - The Tech Trap

Many of us have fallen into the tech trap. I know I have. I still remember the excitement when the tech lead and I were in a room sketching out how our referral smart contract would work. We were so proud of its technical elegance and versatility. We spent days perfecting it, only to launch it and discover that... no one used it. Not a single person.

We often follow a predictable path: start with a cool concept, get hyped, figure out the stack, add the bells and the whistles, then add more bells and more whistles. The result of this process could be satisfying but often not as practical or usable.

This is something that continues to happen across various verticals.
In one of his tweets 0xMert_ says

This is what the tech trap is. The bells and whistles won’t solve problems or bring users unless there is a need for them. The technical jargon and the complex interface often have nothing to do with addressing real user needs.

Below is one example (my favorite) but I’m sure you can think of others.

And that’s not just in DeFi. There are multiple examples across different verticals which leads to tweets like this one.

Inside-Out vs. Outside-In

An interesting way to think about product development is inside-out vs outside-in:

• Inside-out: Start with a technology stack or a concept and build out a product.

• Outside-in: Start with a user need or a problem and build out a solution.

Too often in web3, we build inside-out. We assume users want what we want, or that they're excited about the same technical aspects that excite us. We focus on delivering products and building out features.

No matter how highly technical or innovative our product is we still need to:

• understand how (and if) our product meets the needs of our users

• identify what to build based on those needs

• focus on delivering solutions and the user benefit

By thinking about this approach in terms of bets, the play is clear. Understanding the needs first and then building based on that is a better bet compared to “retrofitting” assumed needs after we build the product.

Requests vs. Needs

It’s vital to differentiate needs and requests in this context. Trusting your users to tell what to build is a common pitfall (especially in a B2B context) which I have been a victim of.

An interesting example I saw recently was from @Nerd3Lab. They built a dev playground for the Superchain but the thing that caught my attention was that they had pre-funded accounts.

The need here is testing. And for testing you need testnet tokens. So the request becomes - gib testnet eth. Faucets and giving away testnet tokens at conferences is fulfilling the request. Pre-funding an account is meeting the need.

Figuring out the Needs

Data, data, data. Despite all the anonymity in web3, I still find that simply talking to folks is the best way to understand their needs. When I ask someone to jump on a discord call or do a google meet to share thoughts or do an interview, most times they say yes.

Hanging out in your own (or your competitor's) discord gives you tons of insights. CT too. I’ve also found that adding a “tell us how to improve” or “share feedback” button on key screens is another simple way to gather some data.

Finally, try launching a tiered reward campaign with different feedback options. As Drew Tozer suggests, meeting users where they are makes it much easier for them to provide valuable input.

Conclusion

Web3 doesn’t lack talent or technical ability. On the contrary, there is an abundance of it. Building cool stuff is awesome and most of us love to do it. That’s how we become better at it. And while doing that, it would be great if we can keep in mind that we are building for real people. As user needs are often different from the cool features we want to build.

So next time you are building this cool feature, remember to think of the user.

For more content like this, subscribe to product3—a community where web3 product builders share authentic experiences, exchange ideas, and tackle challenges collectively.