How to Succeed as a Product Manager in Web3 - A Complete Guide

Are you building an NFT Marketplace, a DE-FI Portal or perhaps even a Metaverse?

This article is here to guide you through the most valuable lessons I’ve learned in my first 3 months of leading a product team in Web3. I’m writing this now, because the lessons are hot and fresh in my mind - and 3 months is enough time to cover the majority of them.

This is everything I wish I knew before starting my first job as a product manager in Web3.

I’ve spent 3 months now taking a project from conceptualisation to pre-launch.

All things considered, 3 months is not a long time, however in Web3 3 months can feel like an eternity.

In the last 3 months I’ve seen the market change dramatically.

  • NFT Hype reaching all time highs.
  • A market crash from the implosion of Terra/Luna.
  • Hundreds of new projects launching, many competing to be the first to provide their respective utility.

To give you some context, our project spans across 5 areas: NFT’s, DEFI, DAO structures, ERC-20, and the Metaverse space. It’s an incredibly ambitious project and I’ve gleamed experience about the challenges that are unique to each area.

Major Lessons Learned

Lesson 1: Web3 is all about digital ownership.

It’s also about the utility of that ownership. NFT’s are a gateway to unlocking creator portals, filled with creator content. Event ticketing and gaming will bring NFT’s into the mainstream audience. Metamask is leading the charge for wallet provision and usability. Ethereum, Polygon and Solana are the biggest chains for NFT’s. Binance is hot on their heels.

Lesson 2: Web3 is NOT a complete replacement for Web2 (yet).

We still need fast read and write access to massive data stores. We still need lightning fast caching servers and CDN’s. We still need user accounts and user settings for our applications. Blockchains cannot support huge data storage for data intensive applications. IPFS is helping to solve this.

Lesson 3: As a product manager, you need to understand blockchain technology.

  • Major differences between blockchains
  • Network demand, gas and block time
  • Market liquidity and bridge accessibility
  • Blockchain centralisation and decentralisation.
  • The power of brand and reputation in blockchain.
  • The impact a severe security event can have on trust.

Lesson 4: As a product manager, you need to make tough decisions about initial blockchain support, knowing that things can change completely in 6-12 months time.

  • Ideally you support one chain as your primary, and identify the best secondary chain to support after that.
  • Supporting multiple different chains can completely change your business structure, strategy, and application logic. So think hard on this one.
  • Blockchain support is the earliest dependency that everything else flows from.
  • Ethereum is the gold standard for Dapps, however Polygon and Solana are close contenders.
  • Everything could change again with Ethereum 2.0 and sharding.
  • This can make or break your business.

Lesson 5: For development, you need agile.

  • You need daily standups.
  • You need to test assumptions quickly.
  • Someone needs to manage your scrum board.
  • If you are the founder, you might find yourself doing this. It’s better to hire someone.

Lesson 6: For UI and UX design you can use kanban.

  • UI and UX design needs to happen early on during conceptualisation.
  • You can split this into its own board in Jira.
  • Do user flow diagrams and wireframes first.
  • One big mistake is to go straight for high fidelity designs. It’s too slow and things change a lot as you learn.
  • As a product manager you need to work closely with the UI/UX engineer.
  • The UI/UX engineer also needs to have a strong understanding of Web3 technology.
  • This can be a tough role to fill with a strong candidate.

Lesson 7: For contract development and deployment, you can use kanban.

  • Contract development and deployment should happen early on.
  • In Web3, a lot of the frontend (and backend) logic depends on contracts being live.
  • You can split this into its own Jira board.
    • You still need to identify any dependencies on the main Dev board though, and some stories will have overlapping scope with contract deployment and testing. So there will be duplicate tasks in some cases.
  • Contracts go through a different testing process to frontend and backend testing.
  • Contracts typically also need to be audited by an auditing agency. Especially staking and De-Fi contracts.

Lesson 8: Authentication works differently now.

  • There are 3 options.
  • The first is the Web2 way.
    • Login with Email and Password.
    • Login with OAuth2.0 (Google, Facebook, Twitter etc)
  • The second is Web2.5.
    • Passwordless - still linked to email.
    • Login with Magic Link
  • The third is pure Web3.
    • Passwordless
    • Login with Metamask
    • Login with WalletConnect
    • Account UID’s are the wallet address.
  • As always, there are strong pros and cons to each, but the main considerations are: How important is full anonymity to your customers? How important is having their email address?
    • If you use Web2 methods, you need email addresses so that you can process forgotten passwords.

Lesson 9: Each Testnet is Unique, with different node distribution, different block times etc.

  • This can affect your application logic when you move to Mainnet.
  • Ethereum has Ropsten (now deprecated) , Rinkeby (now deprecated), Goerli, and Sepolia.
  • Polygon has Mumbai
  • Solana has Devnet, Testnet and Mainnet Beta.
  • Block time, network demand and gas prices can vary significantly between each. Be careful of how this may affect your app logic with regards to testing VS production.

Lesson 10: You need a good team chat and asynchronous workflow (I recommend Slack).

  • We tried Discord because it is also used for community chat, but the notifications get too blended, and it’s tough to manage direct messaging because you need to add everyone as a friend first.
  • You should build a Team Directory
    • Names, roles, and time commitments
    • Timezones, and overlapping online hours
    • Public wallet addresses for each team member

How to Prioritise Work and Succeed as a Product Manager in Web3
Just follow these 29 simple steps (lol) and rocket ship your project to the moon. (Or even Mars, even).

Step 1: Start with business strategy and vision.

  • If you’re the founder, you know this. If you’re not, you need to speak to the founder.

Step 2: Identify the epics - usually an epic will have 4-5 BIG user stories.

  • E.g. EPIC: Buying and Selling NFT’s on a Marketplace.

Step 3: Ongoing: Start researching the market.

  • What is out there?
  • Who are the big players?
  • What technical decisions have they made and why?

Step 4: Identify the BIG user stories.

  • e.g. I want to VIEW all recent NFT Listings on the marketplace so that I can search and buy NFT’s.
  • e.g. I want to CREATE a listing for an NFT that I own so that I can sell the asset.

Step 5: Create the SMALL user stories - a big user story can have 10+ smaller user stories.

  • E.g. As an NFT Collector viewing the marketplace, I want to sort the listings I can see on the marketplace by price so I can see the cheapest listings first.
  • E.g. As an NFT Collector viewing the marketplace, I want to easily see which blockchain the NFT is on so that I can buy things using my primary Metamask wallet.

Step 6: Organise the small stories underneath the big stories, underneath the epics.

Step 7: Groom them, and identify the priority level based on business value.

Step 8: Speak to the engineers about them to gain an understanding of technical difficulty.

  • This may come later if you don’t have engineers yet.

Step 9: Groom them again, and identify the priority based on business value AND cost of implementation.

Step 10: Re-prioritise and split stories into now VS future. Make sure the founders are aware of your logic behind these decisions.

Step 11: Prioritise the epics.

  • Now that you have a bunch of epics, big user stories, and small user stories, prioritise the epics.
  • Which big developments need to happen first?
  • Are there dependencies between epics? You should have a clear idea of this now.

Step 12: Create a roadmap.

  • It doesn’t need to have hard dates on it, just an order of priority based on the Epics. Whatever you do, don’t say a date yet. DO NOT GIVE A DATE. It’s a lose-lose scenario. :P
  • You still don’t know your sprint velocity, so estimating how long things take is still too difficult.

Step 13: Start setting up your backend.

  • Ideally this is part of the conversation from day 1.
  • Before deploying frontend code, you will need some basic things on the backend setup. This can be started before you know all your logic and UI/UX. E.g. Databases, Redis, etc.
  • Knowing your epics helps a lot with this, for example if you have a Chat feature you will need a certain thing. If you are storing large amounts of images or audio files, you will need a certain thing.

Step 14: Start making decisions about your frontend stack.

  • Ideally this is part of the conversation from day 1.
  • If SEO is important, look at using Next.js.
  • This will affect hiring and team building.
  • If you already have an engineering team, they will influence this decision heavily.

Step 15: Build your engineering team.

  • If you haven’t already started this, now you can make more accurate hiring decisions.

Step 16: Design user flow diagrams.

  • Your app logic will beg for questioning when you go through this process.
  • User flow diagrams are extremely quick to build
  • A lot of teams skip the step.
  • Use Figma Jams.
  • You will need to iterate on the logic a few times to get it right.
  • It will change.
  • Groom user stories as you go.
  • Show the engineers as you go. Get their input.

Step 17: Design wireframes.

  • Go fast.
  • Get all the basic functionality in there first.
  • Start with Navigation and overall layout.
  • Start with Authentication (as always).
  • Groom user stories as you go.
  • Show the engineers as you go. Get their input.

Step 18: Finish your first High Fidelity designs.

  • Start with Navigation and Authentication (as always).

Giant Leap 19: Start sprinting.

  • Start with authentication (as always).
  • Setup your CICD pipeline as you go.
  • Have conversations about code review
  • Have conversations about team responsibilities.
  • Start identifying individual strengths and weaknesses, and allow the team to self organise who does what.
  • Junior engineers can be helpful with branch management and merging in Github.

Step 20: Get 6 weeks ahead with user stories.

  • Circle back and iterate as you build

Step 21: Get 4 weeks ahead with User Flow Diagrams.

  • Circle back and iterate as you build.

Step 22: Get 4 weeks ahead with wireframes.

  • Circle back and iterate as you build.

Step 23: Get 2 weeks ahead with backend data structures.

  • Circle back and iterate as you build.
  • Frontend can build UI using dummy data to start, but they will need to circle back and refactor when the API endpoints become available.
  • Backend entities are constantly evolving as you continue wireframing and grooming user stories.
  • There is a soft dependency on backend being done first. Frontend can build UI without it, but eventually it needs to be hooked up correctly.

Step 24: Get 2 weeks ahead with high fidelity designs.

  • Circle back and iterate as you build.
  • These are the final versions to hand over to the engineers.
  • Engineers can work from wireframes and user flow diagrams, but ideally you don’t want things to change too much at this point.

Step 25: Get 2 weeks ahead with your Jira backlog.

  • Learn from me here: do not walk into a sprint planning meeting without well groomed user stories, and AT LEAST wireframes ready to build.
  • The backlog does not need to have hundreds of arbitrary future tasks on it. Ideally it’s only filled wiith well groomed, high probability stories, and ordered from top to bottom based on priority.
  • Engineers that know what is coming up can passively fill their mind with questions about implementation details, and this can be a powerful way to solve problems before they are screaming at you directly.

Step 26: Plan out your sprints using as much design asset as possible.

  • It’s so much easier for engineers to have a conversation based on how a wireframe looks rather than simply discussing a user story.
  • This doesn’t mean design is a replacement for discussing using stories. Those conversations should have already happened before they even made it into the wireframes.
  • At this point the conversation is more about the technical implementation rather than the business value of the story.

Step 27: Manage your sprints effectively.

  • Focus on powerful planning to begin with. Some scrum masters will say the sprint retrospective is the most important meeting, but in my experience if you shoot yourself in the foot with a poor planning session you set yourself up to fail and then you get to talk about that in the retrospective, bowing your head in shame as the product manager who is responsible for all this.
  • Have daily standups. Your team is not a team unless you have a daily. Trust me on this. When things are running smoothly these standups can be as short as 10 minutes. When work is hitting the fan you will know it because your standups suddenly became 45+ minutes.

Step 28: Play catchup and learn to juggle your time effectively.

  • You are working hard to get as far ahead into the future as possible while still managing the day to day activities of your team, and solving problems as they spring up.

Step 29: Good luck.

  • The job of a product manager in web3 is not easy.

So those are the major lessons specific to being a product manager in Web3. Now I want to write about some of the more general aspects to the job, industry, and things to be aware of.

Most projects are startups.

No surprise here. Unless you are working as a product manager at a well established company like Coinbase or Opensea, you are probably working in an early stage startup project. This means as a product manager, you will be very focused on the business strategy, product conceptualisation, team building and managing the early stages of agile deployment.

Fundraising works different.

A few years ago, most of the Web3 space was using the ERC20 token standard and ICO/ITO method to fundraising. While this is still a common method, now NFT’s have joined the space offering communities a powerful and fun way to buy a stake in a project. The current trend now is moving more towards and NFT-first approach, and the ERC20 token as the secondary. The reason for this is that NFT collections are a powerful dual purpose collectible, and are an easy way to created gated content and gated access to app features.

Twitter, Discord and Telegram.

Everything is happening in these spaces. Instagram is also a powerful emerging player specifically for the NFT space, as it’s a great platform to showcase the assets in a collection. As for general industry alpha - it’s Twitter. For community specific Alpha - it’s Discord Announcements and secondary to that, it’s Telegram chats. Chat and comms are all over the place in Web3, and managing this can be tough!

Remote teams are abundant.

The reason for this is that a lot of the money is in the west, and a lot of the talent is in the East, and Europe. Our team is a fully remote team, with engineers in Eastern Europe, Turkey, and Sri Lanka. I personally live in Bali, which offers me an overlap of 4-6 hours with most of my team, however I constantly find myself working long hours to service this overlap.

Solidity engineers are in high demand.

As a talented and experienced solidity engineer, you can pick and choose your projects. This makes it difficult to lock people down into core members of the team, and often means you need to have multiple different solidity engineers working on specific things. E.g. You might have one person who works on NFT’s and another who specialises in ERC20. Turkey is a good place to look for solidity engineers. Finding an engineer with 2+ years of experience is a unicorn.

Contract auditing isn’t perfect.

A good auditor is a strong engineer... it goes without saying. But as a top 2% solidity engineer, you can work on whatever project you like, and so choosing to work as an auditor is potentially not the most interesting, OR highest paying role. And so, auditing companies are filled with junior to mid level engineers, and the result is that bugs fall through the cracks. This means you need to test your own contracts properly. Get two different engineers to poke holes in each others work. Build unit tests. Do your first round of auditing yourself, and triple check things - ESPECIALLY for De-Fi contracts. I was talking to the CEO of a successful Metaverse project who told me about the failures of the auditing company they used, and how catastrophic it would have been had they not found that bug before deploying the contract into production.

Constantly learn more about the tech.

This goes without saying for a product manager in web3. My job title is actually “Technical Product Manager” and I don’t know how you could do this without having some measuring of understanding about the underlying technology. Additionally to that though is that your entire team will need to do this. Everyone in this space is learning how to build things better. From UI/UX to frontend and backend.

Web2 backend VS Web3 backend.

I started making this semantic differentiation early on because technically speaking, they are both backend components. Your web2 backend is your AWS cluster consisting of databases, elastic search, caching servers, and deployment environments among everything else. Your web3 backend is your blockchain contract logic, running on Ethereum, Solana, Polygon, or whichever blockchain you have chosen. Both backends are different in terms of development, testing and deployment, and both have overlapping dependencies. Web3 is a technically challenging space! And it is most probably going to be a learning curve for your web2 backend or fullstack engineers.

Unity VS Unreal Engine.

Unreal Engine 5 (UE5) is massively hyped. This visual aspect to things you can build in it are incredible. In terms of Metaverse development, it can be easy to think that Unreal is the clear winner - as it’s the closest thing to Ready Player One lifelike realism. But it’s not without its challenges. Firstly, web3 integration. A metaverse needs to understand blockchain data. It needs logic built in to create NFT dependent gaming experiences. The libraries for this are primarily community driven developments. The team at Unreal has their hands full building the engine and showcasing to AAA game developers and cinematographers the potential of what can be done in a visual sense. Additionally, Unreal developers use C++ and cost more. Additionally++, building in Unreal engine requires a beastly computer to render scenes and game builds quickly without breaking workflows. So all things considered, Unreal Engine is the tool to use to showcase your vision, but ultimately may not be the engine you use to build, run and deploy your Metaverse.

Unity has unparalleled platform support. While it may not be able to compete with Unreal on the visual side, its new HDR pipeline (High Definition Render Pipeline) offers significantly improved ray tracing and scene lighting. Unity apps can be deployed to Android, iOS, Web, Playstation, Xbox, Nintendo, Apple TV, and basically anywhere that can run code (jks). It also has the best support for VR, AR and MR (Mixed reality) development, and the largest community of emergent blockchain supporting libraries and plugins. Unity games are built using C#, which is a more common and simple language to learn (I learned it in 2 weeks), and the Unity game engine does not require beastly GPU power to render out your prototypes and initial game logic. This translates to a higher pool of potential engineers, and 3D artists, who can be productive on lower end computers, and be found and hired from cheaper parts of the world. If your team is 100% based in the US, you might have a tough time with the timezones, but considering most teams are fully remote, this integrates nicely to team building. Our chief Metaverse developer is based out of the Philippines.

Metaverses are like Bitcoin.

It’s all a big experiment. Nobody knows where it will go. VR headsets are amazing but they also suck. Wearing a full VR headset for more than 60 minutes gives you a headache and makes you feel dizzy (speaking from experience). AR isn’t here yet. AR also doesn’t offer the level of immersion we are considering, and has an entirely different utility at a high level. Web browsers offer a clunky controller experience. Mobile phone screens are too small. Definitely go for Apple TV (jks :P). The way this translates to your metaverse design and business model is important. You need to choose one platform and go all-in. If you are building for VR you need to build for VR. If you are building for Web, you need to build for Web. Later down the road you can add another deployment target. VR experiences are typically 1st person, and web experiences tend to be 3rd person. Mobile is a whole other ball game that changes your entire controller system and UI. Also on the blockchain side, you are probably looking at either Solana or Polygon for gaming.

Land sales might not be it.

If you are building a Metaverse, you are probably considering a land sale. But if you consider the impact this has on community digital ownership, gaming experiences, and delivering the value you promised to your backers, you may want to reconsider. A land sale is a hard, high level cap of game world real-estate. Take a game like World of Warcraft. It has consistently offered players new experiences by creating new worlds, new exciting and interesting landscapes, new cities, new raids and dungeons etc. If you have a hard cap on land real-estate, you may be doing a disservice to your early backers. They expect their investment to have long-term value in your metaverse, and if you as a designer plan to expand the world at a later point down the road, you better make sure you are considering ways to keep the value of that land high or your community may not be happy and your project might tank. Consider the success of Roblox. Consider the success of Minecraft. Consider how exactly land will be valuable. Is it because of marketing and advertising opportunities? Is it because of blockchain reward logic?


I accept all major tokens, coins, and pictures of bored looking apes. 😁

0x6BaC2dbfA72b1f65B7CC2C09e96315025aA1d303

Subscribe to Jack Cotton-Brown
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.