Product map

Build and maintain a visual map of your product’s areas, capabilities, relationships, and workflow coverage from the planner.

The product map is a visual view of your product’s areas, capabilities, and relationships. Build it in the planner to give teams a shared structure for exploring requirements, understanding dependencies, and seeing how much of the product is covered by repeatable tests.

Product Map coverage management is available only to eligible Cofactor organizations. If you do not see the coverage controls, ask your Cofactor administrator whether the feature is enabled for your organization.

01When to use the product map

Use the product map when you need to:

Organize a large product into clear areas and capabilities.
Show how capabilities relate across areas or user journeys.
Find parts of the product with limited workflow test coverage.
Plan exploratory work and turn important behaviors into repeatable automation.
Review product structure with both technical and non-technical teammates.

Keep the map focused on the product behavior that matters to users. You do not need to model every implementation detail before you can use it.

02Product map concepts

The product map combines a product structure with coverage information from your flows. Use the structure to navigate the product, then use coverage to decide where to investigate or automate next.

Product areas

A product area is a meaningful part of your product, such as billing, account settings, search, or checkout. Areas provide the top-level organization for the map and help you group related capabilities.

Create and edit areas directly in Product Map. Create areas that match how your team discusses the product. Prefer a small number of stable areas over a long list of narrowly divided screens or technical services. You can reorganize areas as your understanding of the product changes.

Capabilities and relationships

A capability describes something a user or another part of the product can do within an area. Examples include updating a payment method, inviting a team member, or filtering search results.

Create and edit capabilities directly in Product Map, then organize them under the appropriate area. Drag a capability to another group when its ownership or product context changes. Moving a capability updates its organization without requiring you to recreate it.

Relationships connect capabilities and areas so the map reflects how behavior fits together. Use them to represent dependencies, shared journeys, or transitions between parts of the product. A relationship should communicate a useful product connection rather than merely duplicate the hierarchy.

Flow coverage

Flow coverage shows how much of a capability’s behavior is represented by linked flows. Link a flow to the capability it tests so coverage rolls up from capabilities to their areas and the overall product map.

Coverage is a planning signal, not a guarantee that every scenario is tested. A capability can have coverage while still needing checks for important roles, inputs, error states, or cross-area journeys. Open the associated flows and review their results when coverage needs more context.

03Build and edit a product map

Open the product map from the planner. Start with the areas your team uses to describe the product, then add capabilities and relationships as you discover how those areas work together.

Create and organize areas

Open the planner and select the product map editor.
Create a product area and give it a concise, recognizable name.
Edit an area when its name or product scope changes.
Create capabilities within the appropriate area.
Drag capabilities between groups to organize them under the correct area.
Review the map at the whole-product level and remove unnecessary duplication.

Use names that describe user-visible behavior. For example, use Team access instead of a code name for the service that manages invitations. Keep naming consistent across areas so teammates can scan the map quickly.

As the product changes, update the map in the same planning workflow as your requirements and flows. Reorganize an area when its purpose changes, and add a new capability when a meaningful product behavior is not represented.

Link flows and track coverage

Link each relevant flow to the capability whose behavior it verifies. A flow can be associated with the product behavior it covers, making the relationship visible from the product map and allowing Cofactor to calculate rolled-up coverage.

Open a capability in the product map.
Add or select the flows that test that capability.
Review the linked flows and remove links that no longer represent the tested behavior.
Repeat for other capabilities in the area.
Use the capability and area coverage percentages to prioritize missing or lightly tested behavior.

Link flows to the most specific capability they test. If a flow crosses several capabilities, link it wherever it provides meaningful coverage, and avoid linking unrelated flows just to increase a percentage. Review flow results and evidence before treating a covered capability as sufficiently tested.

The product map also reports unmapped flows: flows that are not linked to a capability. Use this count to find test coverage that exists but is not yet connected to the product structure. Map those flows when their behavior is clear, or leave them unmapped until you can identify the right capability.

Edit relationships

Select a capability or area to add, change, or remove a relationship. Connect items when the relationship helps explain a dependency or a user journey, and label or describe the connection clearly when the editor provides that option.

Review relationships from both directions. If a checkout capability depends on account information, for example, make sure the map also helps someone starting from account information discover the checkout connection. Remove links that no longer describe the current product to keep the map readable.

After editing relationships, use the map to follow a representative user journey. This is a quick way to find missing capabilities, disconnected areas, or relationships that imply behavior your product does not support.

Protect human corrections

Treat the product map as a maintained source of product knowledge, not a one-time generated diagram. When you correct an area, capability, or relationship, preserve that correction during later planning and review work.

Use explicit, user-facing names and verify changes before sharing the map. When an automated suggestion or imported information conflicts with your team’s understanding, keep the human-reviewed structure and update the map deliberately rather than accepting an inaccurate relationship.

Record why a non-obvious relationship exists in the surrounding planning context. This gives future editors enough information to distinguish an intentional product dependency from an accidental connection.

04Coverage dashboard and history

Use the coverage dashboard to review product coverage without opening each capability individually. Dashboard cards summarize the current state of coverage, including rolled-up coverage percentages and the number of unmapped flows.

Use the cards to compare coverage across areas, identify gaps, and decide where to focus flow authoring or exploratory testing. Drill into an area or capability to see the flows contributing to its percentage and verify that the linked flows still represent the intended behavior.

Coverage history shows how coverage changes over time. Review the history after adding or linking flows, reorganizing capabilities, or making a significant product change. Use changes in the trend as context for planning; a percentage can change when the map structure or flow links change, not only when test execution changes.

05Best practices

Start with stable product areas before modeling detailed capabilities.
Use one clear name for the same capability everywhere in the map and related flows.
Add relationships that explain dependencies or journeys; avoid decorative connections.
Link flows to the capabilities they actually test, then inspect individual flow results before declaring a capability sufficiently tested.
Review dashboard cards, rolled-up coverage, unmapped-flow counts, and coverage history together when prioritizing work.
Prioritize uncovered or lightly covered capabilities that affect critical user journeys.
Revisit the map after major product changes, flow promotions, or changes to team ownership.
Keep the map understandable at a glance so it supports planning discussions and test review.