A framework supplies a thinking structure; specific metrics still need product-level customization

What it is

Frameworks such as HEART supply a structure for asking and deriving, not a pasteable metric library. Task success in payments may be “the funds arrived and the user confirmed no error”; in notes it may be “an item was opened again and writing continued.” Dropping “completion rate” or “NPS” into every category treats the structure as a checklist. Customization means: keep the structure, rewrite the counting rule for this product’s objects, tasks, and cost of failure.

Why it happens

A framework that wants to travel across products can stay at categories and layers, not at fields. Once an explainer uses “weekly active days” as the Engagement example, the example mutates from illustration into default implementation, because it is collectable, plottable, and benchmarkable. Default implementation ignores object differences: “active” may be harmful in clinical scheduling and may be the value itself in an authoring tool. Customization starts at the signal: what phenomenon is visible on this product when the goal is met, then pick a count for that phenomenon. The structure offers a completeness check—was happiness asked, did it pass through a signal—not an industry average. Taking someone else’s metric as yours is taking their phenomenon as yours, and phenomena do not travel with the framework.

Studying it

Collect HEART tables filled “from the tutorial,” and count how many metric definitions could be used unchanged on another product; the higher that share, the more customization has failed. Compare signal sentences for the same category across products; near-identical signals were probably reverse-engineered from metrics. A migration test also works: attach product A’s metric definition to product B’s data and see whether it still separates B’s successful and unsuccessful users; if it cannot, the metric is A’s customization, not a generic part of the framework.

Where it stops holding

Refusing to borrow any common metric raises invention cost; customization can pick from a candidate set rather than invent counts from zero. Mandated fields (identity completion, disclosure checks) are not generic HEART parts; they are statutory counts that may sit under task success, still with their own signal written down. Benchmarking needs shared definitions, which is a different use, and must not force the product’s internal success standard to coincide with the benchmark definition. Over-customization, with every group holding mutually unintelligible definitions, destroys cross-team alignment; the structure layer should stay shared, the field layer is what customizes.

Applying it

• Metric definitions in each HEART category must name the product’s object and task; ban bare “completion rate” and “activity.”
• Write this product’s signal sentence first, then pick or rewrite from common metrics; the order must not reverse.
• Before importing another product’s metric definition, test whether it separates this product’s successful and unsuccessful users; if it cannot, do not use it.
• Share one framework header, let each product fill different metric cells, and in review challenge only whether the cell matches the signal.

Related

• Same group: Q6.07.1 HEART maps happiness, engagement, adoption, retention, and task success onto goals and signals · Q6.07.2 Frameworks name dimensions differently, but all require goals before metrics · Q6.07.3 Applying every framework dimension without product stage dilutes measurement focus
• Adjacent: Q6.02 Goals–Signals–Metrics · Q6.11 Benchmarks and competitive comparison
• Search terms: framework as thinking structure · metric customization · HEART