EuPMA - European Product Management Association


EuPMA is part of Open Innovation s.a.s. 

For information or contacts: info@eupma.eu

European

Product

Management

Association

logo v1.2.jpeg

Governance

Privacy Policy 

Product Management Action Card

Identify the Product Capabilities

We drive the future of Product Management in Europe

product capabilities.jpeg

WHY

Up to this point, the analysis has focused mainly on the customer and user:

Customer Insights → Needs → User Journey → Jobs-to-be-Done → User Activities → Desired User Experience

At this stage, the perspective changes.

The key question becomes:

What must the product be able to do to enable the desired user experience and help the user accomplish the Job-to-be-Done?

This is where Product Capabilities become essential.

Moving directly from customer needs or desired experiences to detailed requirements often leads to premature solutions, fragmented specifications and missed alternatives.

Product Capabilities provide an intermediate layer between the user perspective and the product perspective.

They allow the team to define what the product must be capable of doing before deciding exactly how it will do it.

This preserves design freedom, supports innovation and creates a more structured and traceable path toward Product Requirements.

WHAT

A Product Capability describes something the product must be able to do in order to support a user activity, enable a desired experience or satisfy a relevant customer need.

Capabilities are expressed from the product perspective, but they should remain sufficiently independent from a specific technical solution.

For example:

Desired User Experience
The user feels confident that the configuration is correct before starting.

Product Capability
The product must be able to verify whether the configuration is appropriate for the intended use.

A capability does not yet specify exactly how verification is performed.

Possible solutions could include sensors, software algorithms, guided checks, visual feedback or other mechanisms.

Capabilities therefore represent the bridge between:

What the user needs and experiences and what the product must be able to do.

Typical Product Capabilities may include the ability to:

  • detect a condition
  • measure a parameter
  • guide the user
  • prevent an incorrect action
  • adapt to different operating conditions
  • provide feedback
  • communicate information
  • store or retrieve data
  • protect the user or the product
  • automatically perform an activity
  • interact with another product or system

A capability should describe an ability of the product, not a component, feature or implementation.

HOW

  • Start from the desired User Experience
    Review the selected JTBD, the user activity sequence and the desired experience defined for the most relevant activities.
  • Ask what the product must be able to do
    For each important user activity or desired experience, ask:
  • What must the product be capable of doing to make this possible?
  • Express capabilities independently from solutions
    Describe the required ability without prematurely defining technology, architecture or implementation.
  • Prefer:
  • Detect an incorrect configuration before operation.
  • Rather than:
  • Install an optical sensor that detects the position of component X.
  • Connect each capability to its origin
    Whenever possible, maintain traceability between:
  • JTBD → User Activity → Desired Experience → Product Capability
  • This helps explain why each capability exists and prevents unnecessary product complexity.
  • Look for shared capabilities
    Different user activities, JTBD or customer needs may require the same underlying capability.
  • Identifying these common capabilities can reveal opportunities for reuse, modularity and platform development.
  • Check for missing capabilities
    Review the complete user activity sequence and verify whether the product can adequately support every critical moment.
  • Prioritize capabilities
    Distinguish between capabilities that are essential for accomplishing the JTBD and those that primarily improve, differentiate or enrich the experience.
  • Use capabilities as the basis for Product Requirements
    Once the required capabilities are clear, translate them into more precise and verifiable Product Requirements.

The overall logic becomes:

Customer → Need → JTBD → User Activity → Desired User Experience → Product Capability → Product Requirement

The introduction of Product Capabilities marks an important change of focus: from understanding the customer and designing the desired experience to defining what the future product must be able to do.

Need support applying this Action Card? 

Talk to EuPMA.

Read the quick guide. 

pulsante quick guide.jpeg

Download the: “Identify the Product Capabilities" Action Card.