Product Management Framework (Using Trello) For Small Teams / Startups
With only a Trello board, shared docs, and a design handoff tool you can manage your entire product with this product lifecycle management process.
As I am working on Letterflix, StumbleOnMusic, GoSocial (by Hapramp), and a few other products under the XYZ Umbrella, I developed my own PLM process. This process originated from the need for minimum time spent on process, seamless collaboration in a small team, and more free time to work on the product itself and develop new ideas.
Here’s the link to a sample Trello board that I made to share my process: https://trello.com/b/dyWQfPne
This process (broad) is structured to be used majorly by the person who is responsible for keeping track of ideas, features, bugs, and product roadmap (in the core team). This also serves as a one-stop for the knowledge transfer among new employees who’ll work closely with the product team (designers, developers, and managers).
The best way to quickly understand it is by opening the broad in a tab and going through this blog side-by-side. In this blog, I’ll explain each list on the board, the lables, and how to efficiently make use of this PLM process.~
Tools used:
For now, I’ll assume that apart from Trello you are using Google Docs (for attaching additional information to the Trello cards) and Zeplin (for design hand-off).
How to use these lists?
Note: Mostly, new cards start on list number 3 and may move up to list number 6 based on the product requirement, user requirements, goals, and resource availability. Cards on the other lists remain there or get archived or deleted.
1. What is “Your Product”?
Early-stage products often lack clarity on what it is and what it is not. Form the first MVP to a focus group to the first beta, a lot will change. This list is to keep track of the major changes in the offerings, ways of offerings, USPs, and statements that define the product. You may label the ideas with versions (Idea V1, Idea V2, Idea V3, etc). There’s nothing wrong with many versions and also, there’s no reason why you should not change and try to stick with the initial ideas (the products evolve with time, user needs, and market conditions). These versions can also hold your growing product in various horizontal customer bases and use cases (for example, an app for online mobile recharge becomes a digital wallet).
Write a detailed description under each of these cards. And share with your team for comments. This will become crucial for knowledge transfer when new people join your team. You may also attach documents, videos, or landing pages here to add more information.
2. Product Tracking (Only for product head)
This list consists of mid and long-term product goals. The goals that comprise of more than one feature, functionality, fixes, and changes in the product. This will make a lot of sense when the product grows in terms of functionalities and user base.
Cards on this list drive everything on the board. And multiple cards created on the other lists can be traced back to one card on this list. The product lead should use this list to share learnings, insights, and observations that impact the product.
3. Feature Ideas
This list should be kept open for all the team members to write their own ideas. This list can have potential fixes, improvements, suggestions by anyone in the team, and new ideas. Ideas that the team needs clarity/discussion or short catchup on to promote for the design, discuss with the focus group, or drop.
Even when other team members write their ideas, the product person in the team should edit and add a description to those cards.
I’ve made 3 key labels for this list. These labels categorize and prioritize the features and make them easy to understand.
- Essential: The key tasks that the product exists for should be achieved.
- Enabler: The functionality that enables a user to easily get the essential work done.
- Good to have: The functionality that makes the experience pleasing and delightful.
Other labels in this list are:
- Trim: A feature of functionality needs to be removed.
- Icebox: Features or ideas that are no longer valid. But might become viable in the future.
Here, work more on the essentials and enablers. 80/20 Rule applies here as well. 20% of features are used by 80% of the users. “Good to have” features/functions delight only a fraction of the users, but the essentials and enablers delight most of them.
I’ll share more on Prioritizing Product Features in a separate blog. And write about this categorization in detail.
4. Features Selected
Features, implementations, or updates that the team is clear on and the design is ready (or in progress) is moved from list 3 to list 4. This is where the designer (or design team) spends most of their time on them. This list is also roughly the product roadmap.
Use the card details to create a checklist (things that are needed to achieve it), attach links to wireframes/designs, and attach documents with more details on those features if needed.
5. Selected for Development
Things that are ready to be assigned (or, are assigned) for development move to this list. You may tag the responsible team members on the relevant cards and let them put an estimate on the cards if that's needed. Things that do not need any more discussions or clarity and are helping reach the product goals clearly should move to this list.
I’ve made “WIP” (work in progress), one new label for this list (this label is also used on two more lists: bug reports, user suggestions).
6. Implemented
Features that are released and are live on the production app move to this list. A label “Done” is used on this list to mark things that are released to the end-users. This is the last stage for features. The only possible move from here could be for the functionalities or features that are no more needed in the product. In that case, you can label those “Trim” and move to “Dropped” once those are removed from the product.
Improvements to existing features will start as a separate card on the ideas list and move up to this list.
7. Bug Reports
There is always more that one channel from where users report bugs. It could be your bug report form, play store/app store, email, social media, or internal team members. The product person should collect all the reported bugs and put them on this list.
A sample template for cards on this list: [This] is not happening / Expected behavior is [This], but the app is showing [This] / [This] is missing or non-functional in the app.
I’ve also made five labels specific to this list:
- P0-Urgent: Show stopper, affecting the entire userbase, blocking a key activity on the app, affecting the ratings/reviews, hampering the key objectives of the app.
- P1-Serious: Things that you need to do damage control but are not part of the key functionality.
- P2-Fixes: Fixes in the currently implemented features, minor improvements, and UI changes.
- P3-Cosmetic: Good to have updates or features to be picked when the resources are available. Won’t have a major impact on the users.
- Resolved: Resolved and released to production.
8. User Suggestions/Complaints
These are requests, suggestions, and complaints that do not qualify as bugs received from the end-users. Depending upon the product goals, roadmap, resource availability, and it’s compatibility with the product objectives, you need to take action on these cards. You’ll need to create a new card in the list 3 (feature ideas and label them “user request”) and move them up the product lifecycle.
This list can become a gold-mine for ideas and will be the most crucial to set the trajectory of your product moving forward. Inputs form user interviews, user reviews, and feedback from users will contribute to this list.
The labels, essential, enabler, and good-to-have will be used across the board. So you can use those labels here as well to prioritize,
9. Dropped Features
As the product grows, a lot of your experiments fail, and this is the graveyard of ideas that didn’t work well or were removed from the app.
Additional Work:
Sprint Planning
The product person would be spending the most time on this PLM board. And he/she will need to sit with other key members to move things on this board and finalize the “Ready for Development” list. Depending upon the team size and requirements, the team can plan weekly sprints, 15 days long sprints, or monthly sprints. One to two sprints should mostly clear the list number 5 to make room for more.
Release Management
This has to done by the person who is leading the development across all platforms. Maintaining a spreadsheet can be enough to keep track of things that were released in each update to the end-users.
Quality Assurance
In small teams, product person, designers, and developers are all responsible for testing the impacted area. But in the end, this should be the responsibility of the product person to test each new version and maintain the status on the bugs list.
Final Thoughts
Since I’ve only worked on B2C tech products so far, my processes are only aligned to meet the needs of B2C products. But I think with some tweaks this can suit the needs of a variety of products. I also assumed that teams are collaborating on a channel like Slack or working out of the same space to communicate and hold discussions.
The biggest power startups or small product teams have is that they can run ideas through this entire process within a few days or weeks. This process also helps in keeping track of the momentum and if cards do not get implemented and the bugs do not mark resolved, will show that there is a scope of improvement. It is also important for the key team members to timely review the backlog and has a long-term view of product trajectory.
This PLM process works will with new products for me and I will keep improving it as we face roadblocks and get more suggestions from the team members.
I’d be happy to read your ideas on product management and links to the best resources that I can refer to in the comments.
