Categories, components, tags, and statuses

Sleekplan gives you four ways to organize posts: statuses, categories, components, and tags. They are not competing options. Each answers a different question, and most teams use all four at once. Getting the split right keeps your board readable for the people submitting feedback and powerful for your team behind the scenes.

​

The four at a glance

​

Status: where a post is

A status tracks a post through your workflow and is the one attribute that changes as work moves forward: Under Review, then Planned, then In Progress, then Complete. Each post has exactly one status, users can see it, and the statuses you enable for the roadmap become its columns. Status is the “when / how far along” axis. Keep it as a set of stages that move in one direction. Resist the temptation to bend a status into a kind or an area, that is what categories and components are for.

​

Category: what kind of request it is

A category says what kind of thing a post is: Feature, Bug, Improvement. Every post has exactly one, it shows publicly, and users pick it when they submit, so keep the list short.

​

Component: which part of the product it touches

A component says which part of your product the post is about: Web app, iOS app, API, Billing. A post has at most one, and it is optional, so you can adopt components only once you actually have parts worth separating. Category and component are independent axes, and neither can express the other. A post can be a Bug about your API, or a Feature for Billing. That is the whole point of having both: you no longer have to spend your one user-facing field on the question you care about second. Components are internal by default. You can show them on your public board and let customers pick one when they post.

​

Tags: every other axis, for your team

A tag (shown as a Label on a post) is a flexible marker. Posts can have many, and by default they are internal, there to help your team slice and triage. Whatever the other three axes are not, tags can be. When you want to, you can also make tags public.

​

Why the product area is not a tag

This is the mistake worth avoiding, because it looks reasonable right up until you try to use the data. Tags are disposable by design: optional, unlimited, and applied inconsistently, which is exactly what makes them good at capturing a passing angle. A component has the opposite job. “Which part of the product generates the most demand?” is only answerable if the component is on essentially every post, so the field has to be complete and consistent. Ask a disposable field to carry a complete answer and you get numbers nobody trusts. The same logic rules out spending your category on it. If your categories are Feature and Bug, they cannot also be Web app and API. Before components existed, teams had to pick one of those two axes for the category and push the other onto tags. You no longer have to make that trade.

​

Where each axis belongs

Everything else, priority hints, customer tier, the quarter you plan to look at it, a team name, belongs on tags. Those are angles you will change your mind about, and tags are built to be changed.

​

Setups by team

A few ways real teams split the four. Status is always your workflow, so only the other three change.

​

Rules of thumb

• One question per field. Kind is the category, part of the product is the component, progress is the status. When you catch yourself explaining that a value “sort of means two things”, it belongs on another axis.
• Keep categories and components short. Both are pickers, and both are only useful if applied consistently. Aim for a handful of each. Tags are the one list allowed to grow.
• Statuses are always progress. If an attribute changes as work advances, it is a status. If it describes what a post is, it is a category, a component, or a tag.
• Do not use a tag for something you want to count. Tags are optional and disposable, so tag-based numbers are always a lower bound. Anything you plan to report on wants a field that is on every post.
• You can adopt components later. They are optional, so an existing board keeps working untouched. Add them when you have parts worth separating, then fill them in over time.

​

Related