Overview
Before I became a product manager, I served many roles focused on building cross team processes and communication to prioritize financial and human resources.
Implementation of such a process never looks exactly the same. There’s an important balance between strongly written, corporate leaning systems and more nimble, startup-style development. As someone who built their career in the startup space, I lean naturally into the nimble system design. That said, as the product, team, and user-base grows, there is an increasing need for stronger written documentation and asynchronous systems to develop.
Product Goals
As a product leader, my goal centers around shipping the right tech as efficiently as possible. Adding bullet points here to give an idea for how I like to think about the needs of remote, web3 product teams to communicate and ship properly. These are in loose priority.
- Understand the Problem
- Sufficient User Research
- Build User Feedback Loop
- Ensure Entire Team Understands the Problem
- Don’t Lose Money
- Create Strong Auditing + Product Shipment Systems
- Critical in Web3/smart contract development
- Ship Effectively
- Build Cross Team Communications
- Consistent Process (with team input and buy-in)
- Updated Reference Documentation
- Agreed Upon “Definition of Done”
- Create Parallel Development (across dev and design)
- Reduces blocking
With these goals as a reference we can look into the details of a scrum process and documentation templates I’ve implemented with teams in the past.
Scrum Process
While I enjoy nimble, startup style product development, I find building a cohesive team and mature product in a remote setting requires templatized documentation to create consistent expectations and reference points for product and design requirements, user context, delivery timeline, QA checks, etc.
In general, these documents and associated checklists should be integrated into sprint tickets to be referred to by both independent contributors and managers. I also find the development of such a process and documentation to hinge on feedback from everyone in the organization (the process is only valuable if everyone buys into it).
The Importance of the Backlog
The classic sprint cycle involves building a backlog of tasks to sort into two week sprint cycles. Tasks include a large range of priorities including internal documentation, design work, tech spike, feature requests, etc. As the backlog develops I like to prioritize with leadership to ensure everyone is on the same page with the bulk of work ahead of us both in the coming sprint as well as into the coming months. I’ve found solid backlog organization as one of the strongest ways to bring together a team to anticipate productivity on a weekly, biweekly, monthly, yearly timeframe. Essentially, a mature backlog should could be used as a roadmap to provide anyone on the team a high level view for the current and upcoming goals of product development.
Documentation
Each team I work with builds some form of the following documents to incorporate into the asynchronous development system.
Product Requirements Document (PRD)
The most important living document in the backlog. PRDs provide a robust space to document the problem and solution that needs to be developed and incorporated into the product itself. The template for a PRD might be large or small depending on the scope and importance of the feature. For smaller features, certain sections may be left blank. In general, this document provides the source of truth for what should be built and where that feature lives in the product pipeline.
Research Documents
Research documents include user anecdotes/surveys/data, design verification, and technical spikes that might be done prior to making the decision to implement a product feature. The user research might involve user anecdotes and surveys, or market analysis to verify and contextualize the problem the feature aims to solve.
In the research phase of development I like to focus on ensuring the product problem is real, and that the UX will solve the problem in the most efficient way prior to spending energy researching technical specs.
User Flow and UX/UI Design
More involved features and products should include some type of user flow diagram and, ideally, a low fidelity UI design to gather more detailed feedback from users as well as clarify the feature requirements and expectations across both engineering and design teams. Mocks and diagrams should include all state and information changes for the application features in question.
Once the mocks have been approved by leadership (and ideally received user feedback) the design lead can focus on creating high fidelity UI to be implemented in the final stage of development.
Implementation and Testing
Once the high fidelity UI design is approved by leadership (and ideally the tech spike is complete), the product/feature should move to final implementation. Web3 features should be shipped to 1. staging on a testnet to run through QA tests, and then to 2. mainnet staging for the same testing, prior to 3. pushing live to production.
Summary
The page above takes you through a high level example of how I like to structure product process. Team buy-in is critical for any process to work, and the documentation and communications involved will be determined by the way each team I work with prefers. The basic documents and structures described above provide a relatively robust overview for the steps and documentation required to ship a product to production in a remote, web3 environment.