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.
- The Ethereum Cancun-Deneb upgrade incorporates EIP-4844, or Proto-Danksharding, with the objective of enhancing scalability and mitigating gas fees. This will open the door for more use cases to move on-chain.
- Sharding, a method that segments a blockchain network into smaller entities called 'shards,' constitutes a key aspect of this upgrade.
- EIP-4844 encompasses additional crucial updates beyond its focus on scalability and gas fees, thereby establishing the groundwork for forthcoming upgrades to the Ethereum network.
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.
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).
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, such as our partners at RMIT Blockchain Innovation Hub.
Here are some good resources for further reading on tokenomics:
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;
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.
- 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;
- Usually best for early-stage and self-funded teams;
- Establish a foundation for future iterations;
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.
