Customizing Productboard entities

Role:Lead product designer

Company:Productboard

Duration:4 months

Type:New feature

Customizing Productboard entities hero

Intro

(Project overview)

Productboard's entity model (Product, Component, Feature, Initiative, Release, Objective, Key result) was hard-coded. Customers couldn't rename it, describe it, or change the statuses attached to it.

(Goal)

Remove a top enterprise blocker flagged by 50+ accounts by giving admins the controls to configure entity names, descriptions, and statuses, so that teams stop fighting the platform's vocabulary and stop tracking status in tools outside it.

(My role)

I designed a new admin surface - Item names and statuses, that lets admins rename entities, add custom descriptions, and configure each entity's status set, all in one place. I owned the design end-to-end.

Problem statement

Product Managers and Product Ops can't make Productboard speak their team's language or fit their workflows. Status values for Objectives, Initiatives, Key Results, and Releasesare locked to a generic three-state lifecycle, so customers either rebuild status with custom fields, move tracking out of Productboard, or accept a representation that is plainly wrong. Default entity names don't reflect every customer's delivery process either - forcing teams to learn Productboard's vocabulary instead of customizing the tool to serve their specific needs.

Customers were either using clunky custom fields, tracking status in external tools, or accepting a representation that was wrong.

Status customization existed only for Features, and it lived as one section in Settings → General - buried in completely unrelated context between SSO/SCIM, fiscal year preferences and workspace deletion.

Status customization buried in Settings → General

Challenges

(Limited time & resources)

Frontend was scoped at ~2 weeks. No room to ship everything at once - forced explicit scope cuts.

(Scalability)

I knew that more customization options would eventually land on this surface (icons, access permissions, levels per entity). The solution had to absorb unknown future without redesign.

(No pattern)

There was no pattern in the product for an entity-customization surface. I had to introduce a new pattern, flexible enough to be reused in other product domains.

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

design process✦

Discovery

I started with the feedback. Productboard is powered by user feedback coming from support conversations, account executives, customer success, user researches and internal users - you name it.

Productboard's entity hierarchy is opinionated. Product + Component + Feature + Subfeature, and alongside it Initiative, Release group, Release, Objective, Key result. This hierarchy gives the platform a strong shape. But we also learned that Productboard-suggested default names and status values are not sufficient for its customers.

A customer using Scrum doesn't have Features, but User Stories. Another customer in a regulated industry wouldn't say that something is In Progress, but rather In Validation or In Compliance Review. Learning Productboard terminology was mentioned as a pain.

Extensive customer feedback across 50+ organizations, including Enterprise customers like LeanIX, Autodesk, Avaya, Adevinta, and Enablon, requesting statuses like Discovery, Blocked, Unfunded, Planning, Testing.

Most requested customizable entities - Initiatives 43%, Releases 33%, Objectives 24%

Definition

I had three things to make possible - rename entity, describe it, customize its statuses. This should work for 9 entity types. I broke down the problem into 4 focus areas:

Definition focus area 1

Definition focus area 2

Definition focus area 3

Definition focus area 4

Development

I went back and forth between three patterns.

Accordion - one collapsible section per entity, with rename, description, and statuses inline inside each section.

(Yes, but:)

Comparison breaks. Admins setting up a workspace need to see all entities at once - to spot vocabulary inconsistencies or to copy a status pattern from one entity to another. The accordion forces an expand-collapse-expand repetition to do that.

Too many clicks. Every customization decision starts with a click to expand the right section.

Wrong semantic. Accordions read as "browse and pick one." Entity customization is closer to a register of equally-weighted data pieces.

Doesn't scale. The next column (icons, terminology variants, per-role rules) makes each accordion section taller and every new addition competes for vertical space inside one entity.

New page per entity- Settings → Item management → Product opens a full page dedicated to that entity's customization.

(Yes, but:)

Same comparison problem, with added navigation cost. Comparing two entities is now a back-button round-trip.

Real-estate paradox. A full page for one entity is mostly empty - the customization isn't dense enough to justify 1280px of canvas on its own.

IA is too deep. Settings → Item management → Product → (and then status edit on top of that) is three hops for one settings job.

Loses the audit view. The single most useful thing this page can give an admin is a single-screen view of "what's customized vs. default."

Data pages - statuses as a global catalog. Move statuses out of Settings and into the Data section, alongside Tags, Topics, Default fields. One flat list of every status in the workspace; each status has a side panel where the admin toggles which entity types it applies to.

(Yes, but:)

Removes lifecycle. Status order has a meaning: Discovery → Validation → In delivery → Done is a sequence. A flat catalog has no order, so lifecycle disappears. Statuses become a random list of values rather than a flow attached to an entity.

Inverts the mental model. Admins think "my Initiative goes through these statuses, in this order." The data-pages model says "this status applies to these entity types."

Color and mapping lose context. Two entities can reasonably both have a Discovery status with different colors and different work-progress mappings. A global catalog forces them to share one.

Delivery

After a round of internal usability testings, I landed on the option that worked equally well for each of the aforementioned use-cases - a consolidated table with one row per entity type.

Final design - consolidated table for entity customization

(What's new?)

Rename the entity + add a description. Click the cell, type, click out / Enter to save. A subtle hover affordance on the cell - the cell border gets a faint outline to signal editability without adding pencil icons to every row. The same pattern for description.

Why I insisted on adding a description? Description is already surfaced inside the Global Create modal. It helps users to understand which entity model is used and how to correctly classify work items.

Customize statuses on entity levels. Status customization sidebar from any status pill in the table. Inside: a status list with the capability to drag to reorder, value renaming on click, the capability to add a new status, and work-progress mapping (copy revamped). I designed for it as temporary: the sidebar layout cleanly accommodates the column today, and removes cleanly tomorrow when the mapping moves to its proper home (lifecycle canvas - already on the roadmap).

All customizations applied across entity types

Conclusion

Item customization shipped in December 2025. Four months post-launch, adoption metrics looked good:

(Adoption)

15.8% of eligible (Pro+) spaces had customized at least one status - ~59% of the 25% target. 10,059 status customization events fired in the first 4 months.

(Breadth of use)

Adoption spans every entity type, not just Features - showing the feature is being used across different planning workflows.

(Opportunity)

The 87.6% who haven't customized yet is the next opportunity. Not a churn signal - the feature is for organizations that need to bend the platform to their workflow, and not every org needs to. But there's a known segment of Pro+ accounts that asked for this and haven't adopted it. In-app nudges and onboarding prompts are the obvious next move.

10K

customization events

1 of 8

spaces engaged

1 of 12

top releases of 2025

You made it here!