How to Prioritize 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 NFTs 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 NFTs.
- 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 difficulties.
- 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, prioritize 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).
- Set up 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.
- The front 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 the backend being done first. The 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 with 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 minds 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 many design assets 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 the 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 catch up 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.