Explore

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

Update August 2023: Since writing this article over 1 year ago, my life has changed. Working in startups often requires you to be multi-talented, wearing shoes that span multiple areas of product development.

As a product manager, I found myself working more and more with the design teams, and cultivating a passion for design along the way.

Recently, I’ve decided to create my own one-man design subscription service. If you need design work done for your startup, you can consider my service: Designship.

⁠

This link can't be embedded.⁠

⁠

And now onto the article...

Are you building an NFT Marketplace, a DEFI 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.

The second is Web2.5.

Passwordless - still linked to email.

The third is pure Web3.

Passwordless

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!

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.