The feature status values used by team Productboard

For product managers who have long tracked feature ideas in project planning tools like Jira, Trello, or Asana, adopting a dedicated product management system provides a whole new level of visibility around the phases that ideas progress through before delivery.

In productboard, you can track these phases with custom feature status values, which you configure in project settings.

And when you use these statuses as groupings on the Features board or Roadmap, they take on the significance of Kanban-like phases.

The default status values your project came with make few assumptions around how your team operates and it’s expected you’ll want to customize them. But if you’re looking for more guidance, you’re in the right place. Our team has spent the past several years experimenting with and refining the status values we use in our own productboard project. Here are the custom status values we (currently ?) use at productboard.

* Minor adjustments made to some status names for clarity

New idea – This is the default status value for all new “features.” Many times these feature ideas are defined broadly as opportunities or user needs and refined later (once the need is better understood) by updating their name/description. Often, new idea features are filtered off the Features board altogether, e.g. when product managers are focusing on planning or monitoring features in delivery.

Discovery – This is a subset of the new ideas that have been prioritized for additional research. In this phase, our discovery team (designers/product managers) reaches out to users who’ve requested these features to understand their underlying need. We might solicit additional input on our customer Slack community or email out a related survey to customers. As this process progresses, designers begin crafting solution ideas and validating these with many of the same users. The end result is a validated problem and solution.

One of the most important milestones in our prioritization process is the decision around which features to graduate from the new idea phase to discovery. Discovery requires a lot of time and resources to conduct effectively and we want to apply our teams’ limited bandwidth only to those features likely to be most valuable for our users, and best support our product strategy.

Backlog – While it’s always possible ideas that don’t prove valuable enough in discovery (or are otherwise infeasible) could be thrown back into the pond (New idea or Archived), this rarely happens. Typically “discovered” ideas move on to the backlog where they wait to be groomed, which can be carried out much more effectively now that we have a clear understanding of what problem we’re solving and the best way to solve it.

Planned – To move on to planned, an idea must be estimated, groomed (broken down into smaller chunks), and assigned to a delivery team. Ideally, developers are brought into the process early—even sometimes playing a direct role in discovery—but are always involved in final estimates and the breakdown of feature ideas into dev tasks.

Depending on your team’s processes, it may be either the Backlog or Planned phase where features are pushed from productboard into an integrated delivery planning tool like Jira, Trello, Pivotal Tracker, or GitHub Issues. 

Delivery – This is for features currently being developed. At times our team has used additional statuses to track which features are blocked, which are in QA, or which are awaiting PM review before being released to production. But in many cases, teams will track this information in an integrated delivery planning solution, which can be surfaced in the associated task columns within productboard. While all of this takes place, the feature’s overarching status remains delivery in productboard.

Beta – These features have been moved to a hidden labs flag. It means our team can enable them on select customer projects through an admin console UI. These are often significant features, for which it’s useful to have yet another opportunity to validate the solution before setting them live to all of our customers.

A prominent feature we currently have in beta is multiple Portals within the same productboard project. This has been a popular request ever since the Portal was launched and we’ve had plenty of opportunities to analyze these requests and conduct more research, but this beta provides us one last chance to verify we delivered the right features in the right way and fix any issues uncovered before releasing to our entire customer base.

Labs – At productboard, we have a feature called Labs which admins can use to enable new and experimental functionality in their projects. These may be features that have already graduated from beta and are almost ready for primetime, or they may be more opportunistic/innovative/experimental features (e.g., that emerged from internal hack sessions and skipped the discovery stage, like the Prioritization matrix). Regardless, this is the last chance to collect feedback before releasing these features to all customers.

Announcement – Features that are ready to be included in a public-facing announcement/release notes. Smaller features may skip this phase and be moved straight to Done. Larger features entering this phase may require additional coordination with marketing, which may be tracked using the task columns. At productboard, product marketing relies on a saved view filtered to status = announcement to ensure every new feature goes through the launch checklist.

Done – Released features that have gone through the product launch checklist.

Continuous prioritization

The best part of being able to track ideas as they flow through these phases is it allows us to break the big decisions like “what should we build next” into bite-sized decisions, like “which features should we move from New idea into Discovery”?

It means that in many cases we can filter statuses like New idea off our boards, freeing us to focus on the more serious candidates.

It means we can use high-level criteria like objectives for deciding which ideas to move into discovery and more granular criteria (like drivers representing Kano model–styled satisfier and delighter, or custom fields like confidence) for deciding which features to advance into the backlog.

For each of these configurations, the perfect set of columns, feature groupings, and filters can be captured as a saved view so we can return to it at any time.

And finally, with custom statuses we’re able to share a high-level Kanban-style roadmap with our extended product team so everyone understands which features are in each phase of the product management lifecycle.

Now that you can get a high-level structure in place for progressing features through discovery and delivery toward launch, how will that impact your ability to deliver the right features and build them in the right way? Reach out and tell us which statuses your team has used to best effect! For more information on next steps, see customizing feature status values.

Not using productboard yet? Start your free trial here!