A team receives a familiar request: “Add more payment methods so bookings improve.” The request may point to a real problem, but it jumps from a symptom to a solution. Diagnose product context by mapping the **value exchange**. Who is trying to complete which job? What counts as success for that person? What does the service provide, and what does the organization spend or risk to provide it? If the product connects two sides of a market, map both; improving one side can harm the other. Locate friction in the whole journey rather than in one screen. A departure before payment might be caused by an unsuitable appointment or a fee revealed too late.
Consider a fictional independent appointment platform. In one month it records 10,000 visits to search, 4,000 appointment selections, 2,000 entries to payment, and 1,600 completed bookings. These are event counts, not yet unique people. Selection-to-payment transition is 2,000/4,000, or 50%; payment-to-completion is 1,600/2,000, or 80%. Optimizing payment because 400 attempts leave there might overlook the 2,000 attempts lost earlier. Yet the larger number alone does not determine priority. Some people may select appointments to explore options without intending to book. We need to understand the task and behavior before valuing that drop.
Example
Define the **unit of analysis** first: sessions, people, or booking attempts? One person can try five times. If the counts represent sessions, do not call 400 departures 400 people. Check the start and end event definitions, period, locale, device, and instrumentation failures. Then write a simple task chain: a person wants a suitable appointment, finds availability, understands price and terms, trusts that the booking will hold, and pays if necessary. Each proposed solution should target a link in this chain. A new payment method can help only a person who reaches payment, intends to book, and cannot use the current methods.
Add the organization's side. Suppose each completed booking yields 12 currency units after variable transaction charges, while a late cancellation creates support and operations work. Do not label the 12 as company profit; fixed staffing and marketing costs have not been deducted. A new payment method might lift completion while raising fraud exposure, cost, or settlement failures. Evaluate user and operational consequences together. A public service without direct revenue would use a service outcome, such as successful task completion, with cost and quality guardrails instead of pretending that every product is a shop. A value model clarifies the decision; it does not prescribe one business model.
In the worked case, four of five interviewees say they hesitated when cancellation terms appeared later than expected; one lacked a usable payment method. Support has 70 tickets about cancellation policy and 12 about payment. These signals are not representative of all visitors. People who contact support or accept an interview may differ from silent visitors. Still, “late information” is worth investigating before building a new payment integration. Form a focused question: if accurate cancellation terms appear when an appointment is selected, does movement to payment improve without increasing cancellations or complaints? Design checks comprehension, operations confirms that the terms match actual policy, and analytics verifies event definitions. A clearer but inaccurate statement would be a worse product outcome.
The diagnosis deliverable is a brief record of segment and context, user job, friction point with a metric definition, competing hypotheses, and the next evidence needed. Our initial segment is new mobile visitors who select an appointment and then stop. Hypothesis one is that late cancellation terms create hesitation. Hypothesis two is that available times do not suit them even though they clicked to inspect them. The first can be tested by moving an accurate explanation earlier and watching transition plus cancellation complaints. The second calls for asking about desired times and comparing actual availability. If most people leave after discovering a time-zone difference, displaying the zone or managing availability takes precedence over copy or payment changes. Mapping the job and value exchange prevents a polished solution to the wrong problem.
When segmenting the data, avoid redefining the problem whenever a dramatic subgroup appears. Start with a split justified by a distinct job or known context: new versus returning visitors, mobile versus desktop, or a country where time-zone display differs. If you search dozens of splits, pick the largest difference after seeing it, and call it a discovery, you have selected evidence to fit an outcome. Record why the segment was chosen, its size, and whether the pattern persists in another period. A lower mobile transition might result from page latency rather than wording; inspect load times and errors before attributing the gap to customer preferences.
Also separate a user's problem from the organization's target. The organization may want more bookings, but “the user does not buy enough” says nothing useful about the obstacle. A testable formulation is: “After selecting a time, the user does not know whether cancellation would cost them, so they stop before payment.” If clearer terms lift completion while also increasing late cancellations, report both effects. The team may need different terms or availability for some appointment types. Product value should remain useful for both user and organization, not merely improve one page metric.
Exercise
A team file product records 5,000 visits to an invite page, 1,500 clicks on “send invite,” and 900 accepted invitations. Sales suggests making the button more prominent. Support reports 80 tickets about messages that never arrive. Name two possible friction points and a first check.
Check your answer Visit-to-send is 30% and send-to-accept is 60%, provided the counts use the same cohort and period; verify that assumption. Some users may avoid sending because they do not understand a colleague's access rights. Others may send but the recipient never receives or trusts the message. Inspect delivery and bounce outcomes by domain before changing button color, then compare acceptance by delivery status. Tickets justify investigating delivery, but do not prove that every unaccepted invite failed to arrive. Do not test a button color until the problem location is understood.
