How our product team uses Figma to prioritize features [Free Template]

Challenge: Evergrowing backlog, graveyard of tickets

Here at Bird, we use Linear as our issue tracking tool. How we use it seems pretty standard. We plan out all the issues we will be working on in the next two-week sprint (or "next cycle"). But then naturally, during the cycle, you're going to have user interviews, customer support tickets coming back with different things, or user requests for new features. And some of these are genuinely important things. So you start thinking, "Where do we put them?".

Naturally, the next step would be to add them to a backlog. Then before you know it, the backlog gets full. And then, every cycle, you'll end up spending hours grooming it. Then you run into the tricky situation of "Okay, this feature is not that important right now, but it's quite interesting. Should I keep it in the backlog?". This then turns into "Should I store these somewhere else?". So then, in our case, it usually goes to our Notion doc — which we use for knowledge management. Then that grows too.

Then one day, you essentially have an infinite amount of backlog on Linear, where every time you remove something, something new gets added. Then you have your infinitely growing Notion doc, which never gets groomed, just an ever-growing list. And all of this turns into a graveyard of tickets, features, and ideas.

Solution: Using Figma to prioritize features

How we organize Figma for prioritizing features

To tackle our ever-growing backlog of tickets, we've developed a process for how we prioritize features — using Figma. First, we created this huge Figma doc with multiple columns like security, privacy, collaboration, extension, bug reporting, and technical information features that we want to ensure we've covered. And we can add more columns as we see fit.

The next step that we did was to organize it in terms of near term, midterm, and long term. We also add things that have been done to share successes within the team. We use this Figma doc as a rain check, which houses things we've thought about but are not of priority right now and want to keep still.

Using Figma for sprint planning

In sprint planning, we use Figma to think of prioritization as a relative process. We do the cycle planning every two weeks. This means that every two weeks, we will update our Figma doc. We'll update this giant table with little tags to show what's changed from the previous cycle. This helps the whole team see which issues we decided to prioritize over others, which issues we have started, and which issues are in progress — all high-level things.

Benefits of sprint planning in Figma

We really like using Figma for sprint planning because our Figma doc enables the whole team to see what we're prioritizing and focusing on with one quick look. And by doing so every two weeks, we get snapshots of how the previous cycles really went. So, for example, let's say we've been focusing on bug reporting features for the past three cycles and we haven't touched anything collaboration-related in ages. We can ask ourselves, "Is this okay? Do we want to continue doing this? Or do we want to start dealing with some of these features and knock them off because users have been asking for them?". So for us, it's a way to have a very clear overview — something that we cannot get when using common issue trackers.

How Bird uses Figma vs. Linear for feature prioritization

We still heavily use Linear internally, but more for when we want to get into granular details. For example, we have one ticket created specifically for rich text editing, but within that feature, we will create many sub tickets. And then, we also use Linear for tickets about bugs and other maintenance-related issues. Whereas we use our Figma diagram or doc, which acts as a high-level overview, to make sure that we're making decisions and working on things that will move the needle for us.

We also use our Figma doc for even higher-level things, like our key milestones. In essence, Linear tickets flow down from our Figma doc. So this Figma master file has the overarching features or issues that we need to improve. But in general, they are in sync. Not in a one-to-one way — which it doesn't need to be.

Why does this all matter?

We think that one of the biggest challenges of a startup is that we have to move quickly with limited resources. This means that every single decision really matters.

When Bird just consisted of the three founders, we had to work hard to maintain this sense of constraint. And we still have this as well today. We feel that it's really easy to lose this feeling of constraint as the team grows and has the resources to do more things at once. But for us, we really put importance on maintaining focus.

Conclusion

With this setup, we've already identified key things that we want to achieve by the end of this quarter or year. So long as we make sure we reach those, everything else is sort of like a bonus — no more "Why are we doing this?" questions. Everybody in the team can easily open up our master Figma file at any time and see what's being prioritized in a particular cycle. As long as each department has its focuses mapped out, we can efficiently work on achieving them. Then we can reallocate any excess capacity to make sure we also address other needs.