#45. Waiting in July 2022
Marketing reflexion 🧐. Support is overloaded 🏋️♀️. Dark Theme 🌚. Send Emails and Slack messages from Fibery 🎙. Hide Fields from Entity View 🙈.
We use Fibery for team collaboration, roadmap planning, storing business requirements, and development (as an alternative to Jira).
We use two different workspaces for two of our products. One of the workspaces is split into 4 different spaces: the first is for the overall planning, the second is for the product team, the third is for testing, and the last one — for DevOps tasks. Our products are not connected to one Product Management space yet, but we are planning to do that in Q3’2022 to make the planning process in the product studio clear and transparent.
And here is the workspace map of one more product:
We tried Notion, but it is a little bit hard to set up: you need to spend a lot of time setting it up for each team or you need to spend a lot of time teaching people to do it on their own. Also, Notion is not so beautiful for me personally. :)
Jira seems familiar for teamwork with sprints, but it becomes too rigid and expensive when you try to customize it for your needs and when you need to use different roadmaps with dependencies for some temporary external teams. You can make all necessary configurations way easier and faster in Fibery.
The last and the most important reason to switch was the fact that at that moment one of our product teams at The Key had already been a Fibery customer for two years and they organized their work pretty cool with Fibery. We were inspired by their example, so we decided to try Fibery for our start-up streams too.
Fibery is easy to set up and customize for any team member. It is also nice that Fibery is based on database principles, which is similar to the analytical mind of the team members. Even our designers use Fibery to plan sprint work and to communicate with analysts and developers — and all this in the tool with easy Figma integration (which is the prime tool for them).
Usually, we make cross-reference links between two databases and have a smooth experience while working on product features. It is also possible to customize fields and make calculations, same as in Airtable. It’s useful for different time calculations and for the prioritization process.
We are a start-up, so we mainly use two prioritization models: MoSCoW and Kano. They help us define what we should do for an MVP, because there are a lot of competitors in our market and you can’t run your product without some basic functionality.
We also have some hypotheses about unique selling proposition, and we prioritize them together with the main features using the impact–effort matrix.
All of these analyses help us prioritize user stories, features, and tasks into the backlog and give the team and stakeholders a clear understanding of current progress and feature plans.
Features are placed on the roadmap that is open for all team members and clearly shows how far we are from the MVP launch. We navigate the roadmap with the team before every weekly sprint planning and check the status of our features.
The description of the features contains user stories, which we are closing one by one. For example, the purchase functionality is divided into those who want to pay in the cryptocurrency of the offer, pay with currency exchange, pay with a bank card, and so on.
I, as a product manager, define how complete each story should be for the MVP launch and decide what to do during the next sprint. During sprint planning, we try to decompose user stories and features into detailed tasks for each team (analytics, design, backend, frontend, and mobile development) and evaluate the scope of things we can do next week.
We check the statuses of tasks on our board during our daily stand-up calls. Most of the team work remotely and daily calls are a good opportunity to talk and understand who has good news and who needs help with any blockers.
At the end of the sprint, we make a demo for the team. It helps us understand our progress and evaluate how precise our sprint planning skills were — so that we can use these conclusions in the upcoming weeks.
Last week we started pre-launch tests for our MVP with a professional tester and we saw the Fibery test template. The template is nice, but we started with a more classic approach and wrote down the test cases with the results in the bug cards. We need some more time to adjust the template for our purposes, but I believe, it is a great template and we plan to use it to improve our testing routine.
As a product and project manager at the same time, I see reports (and the ways to customize them for different purposes) as one of the most useful features for me. Reports help me with:
After the product launch, I would like to make KPI reports and dashboards with our performance for stakeholders and the team because it is cool when you can have all the things in one place instead of a hundred links.
One more feature that I like is a sharing option for public viewing, we use it for our stakeholders and external collaborations. Also, the newly added read-only users feature is very useful for us as it gives an opportunity to co-work with external staff for some tasks.
We miss a good way to automate the sprint closure, same as in Jira (for example, when closing the sprint I want to see the burndown chart, be able to move all unfinished tasks to the next sprint or to the backlog, and so on). It all can be set up in Fibery, but in Jira it worked out of the box.
It is necessary to improve the whiteboard, because it is far away from the Miro functionality. In general, there are basic functions with stickers, but there is no way to tweak the UI, for example, choose the font size, which makes the boards a little bit ugly.
The mobile version can be polished as well — now it is not very convenient to write and edit specifications on the go.
Are you an early-stage startup? Enjoy 12 months of Fibery for free.