Productboard User Management Guide

• Model type: role-based
• Description: Productboard uses a fixed set of built-in roles (Admin, Maker, Contributor, Viewer). Permissions are tied to these roles and cannot be customized at a granular per-feature or per-object level outside of what the role defines. Space-level visibility controls allow restricting which Makers can see specific Spaces (product areas), providing some object-level access scoping.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Role-level with Space-based visibility scoping. Admins can restrict Maker access to specific Spaces within the workspace, but cannot create entirely custom permission sets.

1. Log in as an Admin.
2. Navigate to Settings → Members (or go to https://app.productboard.com/settings/members).
3. Click 'Invite members'.
4. Enter the invitee's email address (one or multiple, comma-separated).
5. Select the role to assign: Admin, Maker, Contributor, or Viewer.
6. Optionally assign the user to specific Spaces.
7. Click 'Send invite'. The invitee receives an email invitation to join the workspace.

Required fields: Email address, Role selection

Watch out for:

• Inviting a user as Maker immediately allocates a billable Maker seat once the invite is accepted.
• Pending invitations may still count toward seat limits depending on plan; verify with billing.
• If SSO is enforced, invited users must authenticate via the configured IdP; password-based login is disabled.
• Domain-based auto-join (whitelisting) is not a documented native feature; all invites are explicit.

• Can delete users: No
• Delete/deactivate behavior: Productboard does not offer a hard-delete of user accounts from the admin console. Admins can remove (deactivate) a member from the workspace, which revokes their access. Their historical contributions (features created, notes, comments) remain in the workspace. The user record is retained but the user can no longer log in or access the workspace.

1. Log in as an Admin.
2. Navigate to Settings → Members.
3. Locate the member to remove using search or scrolling.
4. Click the three-dot (⋯) menu or 'Options' next to the member's name.
5. Select 'Remove from workspace' (or 'Deactivate').
6. Confirm the action in the dialog prompt.

Watch out for:

• If the removed user was the sole Admin, another member must be promoted to Admin before removal to avoid losing workspace admin access.
• SCIM-provisioned users deprovisioned via the IdP are automatically deactivated in Productboard; manual removal is not required when SCIM is active.
• Personal API tokens belonging to the removed user are invalidated; any automations using those tokens will break.
• Removing a user does not immediately reduce the invoice if on an annual plan; seat reduction typically applies at renewal or per contract terms.

• Where to check usage: Settings → Members (shows all active members and their roles); Settings → Billing (shows current seat count and plan details).
• How to identify unused seats: No built-in 'last login' or activity report is documented in the admin console. Admins must manually review the Members list and cross-reference with team knowledge, or use IdP activity logs if SCIM/SSO is configured.
• Billing notes: Only Maker seats are billable. Contributor and Viewer seats are unlimited at no extra cost on Pro and Enterprise. Annual plans are invoiced upfront; seat reductions mid-term may not result in immediate credits (verify in contract). Enterprise pricing is custom and typically quoted per volume; significant discounts (reported 72–85%) are available for larger Maker counts.

Every app has a version of this problem, but Productboard's seat model makes it sharper than most. There is no built-in last-login or activity report in the admin console, so identifying unused Maker seats requires manually reviewing the Members list and cross-referencing with IdP logs or team knowledge.

Pending invitations may count toward seat limits before acceptance - this is not clearly documented and should be verified against your contract. On annual plans, removing a Maker mid-term typically does not produce an immediate credit; seat reductions apply at renewal unless your contract specifies otherwise.

Bulk user import via CSV is not a native feature, which adds friction during initial workspace setup or migrations. Teams managing more than a handful of Makers will feel this gap quickly.

The most consistent complaint across community discussions is the Maker seat cost on Pro ($75/maker/mo), which teams describe as high relative to competitors when access needs to scale beyond a small core group.

The absence of custom roles compounds this: there is no way to grant partial permissions - such as editing features without touching integrations - without assigning a full role tier.

SCIM provisioning being locked to Enterprise, with SAML SSO as a hard prerequisite, is a recurring friction point for mid-market teams. Many report wanting automated provisioning without committing to Enterprise-level pricing.

Confusion around whether pending invitations consume billable seats before acceptance is also a noted pain point with no clear in-product answer.

Common complaints:

• Users report that the Maker seat cost ($75/mo on Pro) is high relative to competitors, making it expensive to give full access to larger product teams.
• No built-in last-login or seat utilization reporting makes it difficult to identify and reclaim unused Maker seats without manual auditing.
• The lack of custom roles means teams cannot grant partial permissions (e.g., edit features but not manage integrations) without upgrading the user's full role.
• SCIM provisioning being locked to Enterprise (with SAML SSO as a prerequisite) is a common complaint from mid-market teams who want automated provisioning without the Enterprise price point.
• Some users report confusion about pending invitations and whether they consume a billable seat before acceptance.
• The absence of a CSV bulk-import for users is noted as a friction point during initial workspace setup or migrations.

Manual management is viable for small, stable teams where Maker count is low and role assignments rarely change. Admins can invite users, assign roles, and scope Space access entirely from Settings → Members without additional tooling.

For teams with regular onboarding and offboarding, the lack of activity reporting and bulk import creates compounding overhead. Every app eventually reaches a point where manual seat audits become a liability - for Productboard, that threshold arrives earlier than average given the absence of usage visibility in the admin console.

If your team is on Pro and growing, factor in the operational cost of manual audits against the jump to Enterprise for SCIM. The role model's rigidity (no custom roles, no granular permission scoping) is unlikely to change at lower plan tiers.

Bottom line

Productboard's manual user management is straightforward for small teams but does not scale gracefully. The fixed role model, absence of seat utilization reporting, and SCIM access gated to Enterprise mean that mid-market and growing teams absorb meaningful administrative overhead.

Contributor and Viewer seats are free and safe to assign liberally; Maker seats are the cost center to watch. Without SCIM, offboarding discipline is entirely manual - and the lack of last-login data makes auditing a recurring, time-consuming task.