Intro

During the past year 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.

1. 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.

Product Definition is a paid service that Labrys can provide to its clients and whilst most will tell you that they understand the importance of it, many opt not to pay for it, instead hoping to maximize their budget on direct development. In my experience, this does not save costs in the long run and only leads to more expensive mistakes during development.

2. Building 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).

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.

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, such as our partners at RMIT Blockchain Innovation Hub.

Here are some good resources for further reading on tokenomics:

Optimizing Token Distribution

Optimal Token Vest Schedule

3. Building a bigger-than-needed platform

While it is important to have a product roadmap, some clients 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 the 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.

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.

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.