During the past year (my 1st year working in the industry), I’ve had to look at, consult for, put together a commercial proposal and/or been involved in the Product Definition of around 100 web3 projects and would like to share the most common mistakes that teams make when it comes to building a web3 platform. 

Disclaimers:

• The content of this post is my personal opinion and not necessarily that of my employer. 

• The examples below are related to projects building their first web3 platform and not of web3 native established projects.

Lack of Product Definition

Most, if not all, projects are successfully delivered when there’s a well defined scope, requirements and product definition in general. Some clients would want a quote produced from a pitch deck, mockup or google doc with a vague description and some bullet points. 

When it comes to web3, or software development in general, the Product Definition phase of the project is perhaps the most critical. By skipping PD, there’s always surprises that end up with scope creep, blown-out budgets and delayed delivery. Spending time on User Journeys, defining (and prioritizing!) requirements, and having a complete set of User Stories (plus other techniques) will set the foundation of the platform. 

Interestingly, it’s often the case that, while going through this phase, disagreements between project team members (usually founders) arise and, needless to say, it’s better to iron out things at the beginning instead of in the middle of the project.

Build the platform around a Token

I’ll start by saying that not every single web3 platform needs a token. And those platforms where a token is required, should spend a great deal of time defining the token economics (aka tokenomics).

Let’s see how bad tokenomics can cripple a project:

• Lack of token utility: in order to justify the existence of a token, some projects force demand with use cases such as “buy my product/service with my $TOKEN” and then they get into this scenario:

In this scenario, the users looking to procure the platform’s product or service only need to obtain the token just so they can spend it (often right away) without needing to hold it, which means the token demand is temporary at best.

Another inefficient token use case is “Staking”. The original purpose of staking was to secure POS networks, validate blocks and be rewarded for doing so. These days, a lot of platforms have “staking programs” with the sole objective of reducing circulation, guaranteeing team and early investors the possibility of selling their tokens with less sell pressure. Good read on the topic here.

• Unfair Token Distribution: some teams issue a token (before having a platform) with distributions not only skewed in favor of the team and early investors but also badly designed Vest Schedules which typically generate the below price action:

While this might be good for early investors and founders, now you have a community pissed off and that will probably not only give the project bad marketing on social media but also not use the platform at all. We recommend our clients to spend time defining their token economics with specialized teams.

Good resources in terms of Optimizing Token Distribution here, and Optimal Token Vest Schedule here.

To wrap this one up:

→  If the platform needs a token, founders must make sure the tokenomics are designed correctly;

→ If the platform does not need a token (at least from the get-go), it’s always better to first find product-market fit, and launch the token at a later stage. This way, the team has the opportunity to reward early adopters with airdrops, which by the way is a great way to market the project and grow the community organically.

Build a bigger-than-needed platform

While it is important to have a product roadmap, some teams are tempted to include way too many features on their initial product release. Web3 is a highly experimental industry which moves at a neck-breaking speed and by wanting to build platforms with all the bells and whistles founders could end up burning a lot of money for a platform that might not end up finding product-market fit.

The best approach is to build either a Proof-of-Concept or a Minimum Viable Product in an Agile fashion and release it to market to see what the reception is. Most platforms will require several iterations and some of them will end up pivoting to different use cases down the track. 

Let’s define these concepts so everyone is on the same page:

POC: aims to demonstrate the feasibility or potential value of your idea or approach to validate it before committing significant resources to its development. 

• Ultra low cost entry to validate product concept

• Usually best for early-stage and self-funded teams

• Tool to secure venture funding or demonstrate product value to stakeholders

MVP: a cost-effective way to validate market demand and gather feedback on your product or service, it's a great way to showcase your value proposition to target customers and improve chances of success.

• Suitable for teams with seed funding, ready to launch their first live product

• Low cost strategy for quickly bringing a product to market

• Establish a foundation for future iterations

Only then teams should focus on a fully fledged Production platform that is released at scale.

Conclusion

If you are part of a team building a web3 platform, put some consideration into these topics in order to maximize the chances of success of your product. Questions and feedback are always welcomed, feel free to reach out.