HEART framework for product managers
Our reviewers evaluate writing services independently. Learn how we stay transparent, our methodology, and tell us about anything we missed.
The HEART framework is a way I organize product experience measurement around happiness, engagement, adoption, retention, and task success. I use it to avoid reducing a complex customer experience to one convenient number. The framework gives me prompts for choosing a goal, signals that indicate progress, and measures that can reveal whether the experience is improving.
I do not treat HEART as a required five-metric dashboard. Some products need all five dimensions; others need only the dimensions that match the decision. A measure is useful when it represents something customers care about and helps the team choose what to investigate or change. A polished dashboard with no decision attached is not a measurement strategy.
Begin with a product goal
I start with a specific customer or product goal, such as helping a new team complete a recurring workflow with confidence. I define the audience, context, and time horizon. “Improve the product” is too broad to guide measurement, while a narrow goal gives the team a meaningful boundary.
Then I write what better would look like from the customer’s perspective. I do not begin with the events already available in analytics. Existing events may be useful, but they can also pull the goal toward whatever is easiest to count. I want the outcome to lead and the instrumentation to follow.
For each goal, I choose a small set of signals and measures. I record the assumptions behind them, including what behavior I believe represents value and what could make the measure misleading. This makes disagreement productive because the team can challenge the interpretation rather than arguing only about a number.
Happiness: understand perception
Happiness captures how people perceive the experience. I may use a focused survey question, feedback after a task, support themes, interviews, or another method appropriate to the context. I distinguish satisfaction with the product from satisfaction with one interaction, a recent outcome, or a support experience.
I ask a question that can support the decision at hand. If I want to understand whether a workflow feels trustworthy, I do not hide that question inside a broad sentiment score. I record who responded, when, where the prompt appeared, and which experience they had. A response from a person who never reached the relevant workflow should not be interpreted as evidence about that workflow.
Engagement: observe meaningful use
Engagement describes the depth, frequency, or duration of meaningful interaction. I define meaningful before measuring activity. Repeated clicks, sessions, or notifications may indicate friction rather than value. For a collaborative workflow, meaningful engagement might involve completing work with the right participants. For a reference product, it may be a successful answer rather than time spent browsing.
I choose an interval that matches the use case. A daily habit and an occasional business process should not be evaluated with the same expectation. I segment engagement by role, use case, customer maturity, and other factors that change the journey. A single average can conceal both a healthy core experience and a failing one.
I also consider intensity and efficiency together. More time can be positive when people are exploring, but negative when they are struggling to finish. When engagement moves, I ask what customer behavior changed and whether the change improved the intended outcome.
Adoption: see whether the experience reaches the audience
Adoption measures whether a defined audience begins using a product, capability, or workflow. I define the eligible population first. If I compare adoption among all accounts when only certain roles can use the feature, the result will be difficult to interpret.
I state the adoption behavior precisely. Creating an account, opening a feature, completing setup, and using a capability to solve a problem are different milestones. I choose the milestone that matters for the goal and describe what happens before and after it. I look for access, awareness, eligibility, trust, and usability barriers rather than assuming low adoption means low customer interest.
Adoption can be an early signal, not a verdict. A new capability may need education or operational support, while an adopted feature can still fail to deliver value. I use the dimension to locate the question in the journey, then investigate the experience around it.
Retention: check continued value
Retention asks whether people continue the meaningful behavior over a suitable period. I define what returning means for the job. Logging in is not automatically retention, and the absence of frequent logins is not automatically churn when the product solves an infrequent problem.
I also avoid celebrating retention that comes from lock-in or unavoidable frustration. Continued use matters when the customer is receiving value and can make an informed choice. Experience measurement should keep that distinction visible.
Task success: test completion and quality
Task success is the most concrete dimension for many product teams. I define the task, eligible users, success condition, and acceptable quality. Success might mean completing a workflow correctly, finding an answer, recovering from an error, or producing an output that can be used downstream.
I measure more than a final click when necessary. Time, errors, retries, abandonment, assistance, accessibility, and confidence can reveal that a nominally completed task was costly. I use usability research and direct observation to understand the path, especially when the event data cannot explain why a task failed.
I am careful not to optimize completion by simplifying away an important safeguard or by counting a partial result as success. The success definition should reflect the real job and its consequences.
Build a goal-signal-metric table
I make the HEART plan visible in a table. For each dimension, I write the goal, signal, metric, segment, data source, owner, and decision it supports. For example, a signal might be “new users feel prepared to complete the workflow,” while a measure could combine a focused confidence response with observed task success. The distinction keeps a metric from pretending to be the entire experience.
I check instrumentation, consent, missing data, identity, and event changes before reading a trend. I establish a baseline when possible, but I do not invent an industry benchmark to make the result look more authoritative. I record limitations and revisit the definitions when the product or audience changes.
Common mistakes
The first mistake is filling every HEART category with a vanity metric. The second is treating the framework as a score that must rise in every dimension. A product change can improve task success while reducing unnecessary engagement, which may be a good outcome.
I also avoid mixing segments, asking broad satisfaction questions without a decision, and assuming correlation proves that one measure caused another. HEART helps me structure evidence; it does not remove the need for judgment or research.
A practical starting exercise
I choose one important customer goal, describe better from the customer’s perspective, and draft one signal for each HEART dimension that is relevant. I test the definitions against real customer journeys, select a manageable measure, and write what decision each result would support. Then I review the plan with the people who understand the data and the people who experience the workflow.
The HEART framework works for me when it turns an abstract experience goal into a balanced learning plan. It keeps perception, behavior, reach, continuation, and completion in conversation without claiming that one number can speak for the customer.
Next step
Build stronger product analytics, discovery, and decision-making skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready product lessons.
