XMTP Product Flow - v0.1
This document outlines an initial sketch of a product development process for XMTP. Expect it to evolve quickly as we discover what works best for us and as our team expands.
Credit for ideas and inspiration: The Remote Flow.
Changelog December 8, 2021
- Introduction of key Product Flow concepts: boards, stories, epics, stages, and sizing.
Just as our product starts from a place of simplicity, so does our initial product development process. To that end, every product team at XMTP will use the Product Flow Kanban Template to track product execution through the full lifecycle from concept to deployment. This template draws from Agile and async-first best practices developed at Remote to maximize velocity by keeping the next steps for product team members clear and actionable.
Teams may modify this approach to adapt to their situation, but should first surface these changes for discussion in case it makes sense to apply them universally to the Product Flow template.
Active Product Flow Boards > At the time of writing, XMTP is one product team, with one active board:
Stories
User stories are the atomic unit of product development at XMTP. Stories ensure that we keep the user centered as we break down larger product initiatives into units of work. In classic Agile, a user story is written with the template "as a [who] I want to [what] so that [why]". In practice, our user stories can be more loosely written, since product teams should already be in clear alignment on who the user is and what problems we are solving for them.
Just like any other unit of work in Height, Stories exist there as Tasks. Any Engineering or Design work that directly supports a Story should be linked to it as a Subtask, so that a viewer of that Story can easily understand what work is required to be done in order to complete it.
Since Height allows Tasks and Subtasks to be on multiple lists, Engineering or Design tasks can be tracked separately by those teams as top-level items using their own boards.
On kanban boards, Height visualizes tasks as cards that can be dragged between columns. In our Product Flow template, Stories usually move left-to-right through columns representing sequential stages of product development. Stories are stack-ranked in a column such that the highest priority stories are listed first.
Epics
The Product Flow template allows closely-related Stories to be organized into groups known as Epics. Currently, only Stories can change position on the board, so Epics simply provide non-interactive visual separation within a kanban column.
To add a Story to an Epic, that Epic first needs to be created as a Task. Epics can then be linked from the Task detail view of a Story. All stories that are grouped into an Epic are automatically listed on that Epic's Task detail view.
Stages
Because the goals of Product Flow are simplicity and velocity, we bias towards movement between product development stages even over completeness. This preference for action has a few implications:
- Anyone on the team is free to move a Story between product stages at any time. Don't wait for someone else to do it.
- Stages are labels, not requirements; as such, Stories can skip product stages.
- Expect Stories to be moved prematurely and sent back to an earlier stage by someone else. This is a positive signal of trust on the team and that we are correctly biasing towards action.
Currently, the available stages for Stories are:
Triage: Stories that will soon be moved to another stage by the Product Manager. The Triage column may be used by anyone on the product team when there is a need to quickly capture new Stories in a rough state -- for example, during a meeting.
- In the early days of Product Flow at XMTP, Triage will be done synchronously to create alignment and shared understanding of the criteria for each stage.
Backlog: Stories that require prioritization, or require further product definition before tasks for Design or Engineering can be identified.
Define: Stories that are actively being shaped into clear, actionable product requirements.
Design: Stories that are actively receiving UX or UI definition from Design.
Technical Refinement: Stories that are being broken down into component tasks by Engineering.
Ready: Stories that are ready for Engineering to begin implementing.
Blocked: Stories that Engineering cannot finish implementing without dependencies first being completed.
- A Story that needs further technical refinement, design work, or product definition before work can continue is not considered Blocked and should be moved back to the corresponding stage.
In Development: Stories that are being actively worked on by Engineering.
Review: Stories that have had all Engineering subtasks completed and are being reviewed for production readiness.
Done: Stories that have been deployed. A Story that is not deployed is not Done!
Not Doing: Stories that have been removed from scope or otherwise reconsidered.
Sizing
Noting the size of a Story allows us to communicate approximately how long the related work will take to complete and to adjust resource allocation and prioritization as appropriate. Furthermore, sizing can be used to provide a sense of product velocity.
Ideally a story's level of effort will be estimated by Engineering by the time it reaches the development stage.
While XMTP is still in the prototyping and exploration stage, sizing is encouraged but not required.
The Product Flow template currently allows T-shirt size labels (S, M, L, XL) to be assigned to Stories. As our codebase matures and our ability to accurately estimate level of effort improves, we will probably adopt Points as our unit of sizing. Points deliver the advantages of:
- Quantitative capacity planning and resource allocation
- Providing a currency for prioritization exercises such as the Pandora system
- Enabling a metric for product velocity that can be monitored over time
Feedback
It is fairly unlikely that the best practices for building consumer products that inspired the first version of this document will all translate equally well to building a protocol. For that reason and many others, Product Flow at XMTP should be considered a living system that depends on fast feedback from everyone at the company. Adjustments we make based on our experiences with this system will be recorded in the changelog at the top of this document -- serving as a reminder that feedback is always welcome from all sources.