Lifecycle Experiments
Distinguishing product friction from price objections
Use trial tasks, failures and customer responses to distinguish product friction from stated price concerns.
Do not label a trial customer’s lack of purchase a price objection without evidence of the task they attempted, the result they reached and what they said about the decision. Product friction and price can coexist.
The useful diagnosis changes the next response.
Examine the path to the decision
A customer who could not complete a core task has not faced the same decision as one who completed it and asked about paid terms. Group trial histories by confirmed observations:
| Evidence | Possible explanation | Question to check |
|---|---|---|
| Repeated failed task attempts | Product or setup friction | What failed, and was a remedy available? |
| No attempt recorded | Unclear start, low priority or missing data | Did the customer know what to do, and is tracking complete? |
| Useful result completed; plan details reviewed | A commercial decision may be underway | Which capability and terms matter to the buyer? |
| Customer says the cost is unsuitable | Price is a stated concern | Is the issue total cost, expected value, timing or approval? |
The table offers hypotheses, not a classification from one event. A pricing-page view does not prove the amount is too high. A failed task does not prove the customer would buy if it worked.
Ask where the record is unclear
Review the product history, support conversation and any direct customer response. Ask what the customer tried to achieve, where they stopped and what would have made the trial useful. If they mention price, ask about the relevant plan requirement or purchasing constraint before proposing a discount.
For a shared account, separate the person using the product from the person authorised to buy. One may report friction while another raises cost. Use a verified account relationship; similar email addresses do not establish that two people belong to the same buying decision.
Check data quality before assigning a cause. An untracked route or delayed integration can hide success. An upgrade click can be exploratory.
Keep cases with insufficient evidence unresolved rather than forcing them into a price or product category.
Respond to the supported explanation
For a specific failed task, offer the relevant fix or support handover. For a customer who reached the intended result but needs to understand a paid capability, explain how the plan relates to the task and state current terms accurately.
If the customer explicitly rejects the cost, consider a suitable arrangement under approved terms. An automatic discount is not a diagnosis.
Recheck the plan, trial status and open issues before a delayed commercial message. Make sure the message is appropriate for the customer and channel.
Review the diagnosis
Count cases with verified friction, stated price concerns, both or unresolved cause. Record the response and whether the customer later completed the task or made a paid decision. A paid outcome after support or a revised offer does not show, by itself, that the response caused it.
