’s system of record allows you to clearly organize and manage both your product strategy and product planning stages. Here's a short video to help you get started by understanding our data model:

The data model is comprised of the following components:

Workspace > Product > Epics > Features > Sub-features

Alongside these components are the time-bound containers of Sprints and Releases, which define specific timelines for development and deployment.

Your Workspace is the hub for all your product management work in Typically one Workspace will suffice for up to 20 product managers – it’s where you will plan, collaborate, and finally sync with your product development software. Utilize additional Workspaces only when you need to define different team structures or unique terminology and where there is no need for joint Feature prioritization or dependency planning between multiple Workspaces.

Products are high-level entities that help you to organize your work (e.g. Analytics). Later, you can divide your Product into smaller, more manageable Epics, Features, and Sub-Features.

Epics are the main components that appear below your Product layer and allow you to cluster and organize groups of Features. An example of a Epic could be Filter Enhancements. These larger and over-arching Epics eventually get mapped into your preferred development tool as epics.

Features are the building blocks that sit below Epics. They represent a user need or specific set of requirements that you need to build, e.g. Create a new filter button or Enable multi-select of menu items. A well-written Feature provides all stakeholders with the necessary requirements and material to refer to during development. Once a solution is defined for a Feature in terms of development efforts, you can push the Feature into your preferred integrated dev tool as a user story. 

Sub-features are an optional additional layer can be used by those who want to further break down their Features into smaller tasks and to-dos. 

Releases are the deployment date or time period you attach to your Features, typically spanning many weeks and which allow you to manage multi-feature release cycles. These can be named as numbered/descriptive releases, quarters, etc. (e.g., “MVP” or “Release 3.1” or “Q1”).

Sprints are lower level, short, time-boxed containers where the focus is on the delivery of smaller Features or Sub-features. 

To sum up:



Development tool mapping


A collaborative space for planning and management of Products.

A single workspace typically houses multiple Product teams. One workspace will suffice in the vast majority of Product Management use cases.

Not applicable.


High-level entities that help you to organize your work.

In most cases, this represents a Product team or large aspect of your customer-facing proposition.

When integrating with Jira, Products are mapped as labels in Jira by default. When integrating with Azure Devops/TFS/VSTS, Products are mapped into epics.


Allow you to cluster and organize groups of Features.

Contain time, effort and prioritization metadata.

Typically map to epics in Jira or equivalent. In Azure Devops/TFS/VSTS Epics are mapped to Features


Represent a specific user need or a product capability you plan to build.

Contains time, effort and prioritization metadata.

Typically map to user-stories or equivalent.


Can be used for 2 use cases:

1. For larger teams, Sub-Features can be used as user-stories.

2. For small-mid sized teams, Sub-Features can be used to further break down Features into smaller tasks and to-dos.

By default, Sub-Features do not map into dev tools, however, this can be customized if desired.


Time period attached to Epics/Features. Can be defined as per your organization’s terminology (e.g. MVP, Quarters, etc.)

Optional. Typically map to Fix Versions or equivalent.


Shorter work cycles where the focus is on the delivery of smaller Features or Sub-features.

Automatically maps to Sprints in dev tools.

Did this answer your question?