Customer and User Obsession Questions

Direct answer

No single source tells the truth about customers, so I would use a small set that cover each other's blind spots: conversations to learn why, usage data to learn what and how many, and support and sales channels to catch problems at scale. For a new product with few users I would start with direct interviews, usage analytics and support tickets, and add the rest as volume grows.

Seven sources, what each captures best and what it misses

Combining them (triangulation)

Triangulation means checking whether independent sources point at the same thing. Use quantitative sources (ones that count things: analytics, surveys) to see where and how big, and qualitative ones (ones that capture words and reasons: interviews, tickets, reviews) to learn why. A theme that appears in several independent sources is strong evidence; one that appears in a single channel is a hypothesis. Keep one shared place where every item is tagged by source, segment and product area, and review it on a regular rhythm.

Worked example (illustrative numbers)

Question: why do new accounts stall? Analytics show 40% of new accounts never create a first project. Of the last 100 onboarding support tickets, 25 ask how to import existing data. In three interviews, new users said they could not find the import option. Those three sources are independent and point at import, so it is strong evidence. Sales call notes say the blocker is price. App reviews do not mention onboarding at all. The price claim comes from one channel, and from buyers rather than day-one users, so it stays a hypothesis until I check it by segment. I would fix import first and test price separately.

Context-specific additions

• Mobile: in-app prompts reach active users cheaply; app-store reviews are public and fast but skew to extremes and are tied to app versions, so tag reviews by version and read them for recurring themes, not individual scores. Crash reports and ratings by release show pain users never write about.
• Onboarding window: the first sessions are when people are most willing to explain confusion. Use a short in-product question after setup, activation analytics (measuring how many new users reach their first meaningful result), and early support questions.
• Proof of concept (POC) versus a long-running account: a POC is a trial with a few evaluators and defined success criteria, so you hear buying criteria and a narrow set of voices. A long-running account shows broad usage, accumulated workarounds and renewal signals, but may be dominated by one champion (the single enthusiastic internal sponsor at the customer, whose views may not match the other users).

Pitfall

Collecting everywhere but having no owner, so nothing is acted on.

Direct answer

First agree with leadership on what "niche" means and what evidence would change their mind, before gathering anything. Then test the claim with behaviour data from the whole customer base, because a panel is not a random sample of it. If the pain is niche, say so, mitigate cheaply and set a revisit trigger. If it is not, make the case in leadership's own terms with a small, time-boxed pilot and success criteria agreed in advance.

Step 1: define niche before measuring

Niche by what: share of users, share of revenue, a segment you are trying to grow? Agree the bar up front (for example "affects more than a tenth of active accounts, or a segment we have named as strategic").

Step 2: check whether it is really niche

• Know the panel's bias. A user panel is a standing group of customers recruited to give regular feedback. Panel members are often engaged, self-selected and skewed toward power users (sampling bias: the people you hear from differ from the people you do not). A pain heard repeatedly from the panel tells you it is real, not how common.
• Measure the behavioural signature (the recognisable trace the pain leaves in usage data, called telemetry), for example abandoning a step or using a workaround.
• Survey a random sample of the whole base (for example 400 accounts picked at random from the full customer list, not volunteers) with one precise question, such as "In the last 30 days, did you export data and rework it outside the product to finish a task? Yes or no."
• Triangulate (check the same fact from several independent sources) with support tickets, exit reasons and lost-deal notes.
• Describe reach, frequency, severity, segment value and trend.

Worked example (illustrative numbers)

Nine of 24 panelists raise the same pain. Telemetry shows 1,800 of 12,000 active accounts hit the workaround path every week.

1,800 / 12,000 = 15% of active accounts

That clears the bar agreed in step 1, and it is a count from the base, not from the panel. The panel figure is 9 of 24, or 37.5%, so the panel figure looks about 2.5 times higher (37.5 / 15). Treat that ratio as a direction, not a measurement: 24 panelists is a small sample (a 95% interval around 9 of 24 runs from roughly 21% to 57%), and the two figures count different things (panelists who raised the pain versus accounts that hit the workaround path every week). The pain is real and not niche, but it is a 15% problem, not a 37% one, and leadership should hear the 15%.

Step 3a: if it is niche

Tell leadership, tell the panel honestly, offer a cheap mitigation (a template, documentation), and set a revisit trigger (a pre-agreed condition that reopens the decision) such as the share doubling. Time-boxed means given a fixed end date, for example four weeks, after which you decide.

Step 3b: if it is not niche, make the case

1. One page in leadership's terms: share of accounts, revenue, growth segment, trend, cost of inaction.
2. Two verbatim quotes or a short clip. Invite leaders to watch one session.
3. A pilot with success criteria set before it starts: for example, ship to 180 of the 1,800 affected accounts (a tenth) for four weeks, with the target that weekly workaround use among those 180 falls from all of them to fewer than 60 (illustrative target). Rolled out to everyone, 60 of every 180 is a third of 1,800, or 600 of 12,000 accounts: the base-wide rate would fall from 15% to 5%.
4. Build consensus early: an engineering ally, a sales voice, and leadership's questions answered before the meeting.

Variation: a small vocal group signalling a serious UX problem

A small group can still point to something serious: a leading indicator (an early sign of a bigger shift, such as a fast-growing segment), a growing segment, or an accessibility failure. Watch them do the task, look for the same pattern in telemetry, and ask whether severity rather than reach is the point. Agree success criteria and a pilot, as above.

Pitfalls

• Treating panel volume as market size.
• Arriving with quotes but no number leadership recognises.
• Moving the goalposts. If the agreed bar is met, say so.

Direct answer

A workaround is customers paying in their own time and effort for something the product does badly, which makes it stronger evidence than a request for a feature. Still, not every workaround deserves a fix. I judge it with six checks, observe it live to learn the real goal behind it, size it with data, and then choose between a native fix, a lighter option, documenting it, or deliberately leaving it.

Six checks

A workaround scores as worth fixing when it is frequent, costly, persistent and in a core flow.

What I would do

1. Watch three customers perform it (screen share). Ask what the output is for. The goal behind the workaround is often narrower than the workaround itself.
2. Size it from data: support notes, usage events, account lists. Treat self-reported time as an estimate and confirm it by observation.
3. Choose a response: native fix, a lightweight version (template, export, API access), documentation that makes the workaround official, or no change with a reason.
4. Prototype with the customers who built the workaround and check whether they drop it.

Worked example (illustrative numbers)

Finance teams export invoices, re-sort by due date in a spreadsheet and email the list every Monday. Reviewing 40 accounts through support notes and calls, 14 do this weekly, about 45 minutes each (self-reported).

14 accounts x 0.75 hours x 52 weeks = 546 hours per year

That is about 14 forty-hour working weeks of customer time across only the 14 accounts found. Watching three of them shows the real goal: their manager wants a due-date-sorted list on Monday morning. These are different bases: 546 hours is recurring annual time spent by the customers' own staff (self-reported, not a cost to the vendor), while three engineer-weeks is a one-off vendor build cost, so the two are not subtracted from each other. The comparison shows that a small one-off build could remove a large recurring burden for the accounts inspected. Against a build estimate of, say, three engineer-weeks for a saved view plus scheduled email, the case is strong, and a lightweight version solves the stated goal.

Scoring the other four checks for the same workaround (illustrative):

Frequency (14 of 40 accounts weekly) and cost (45 minutes) were already assessed above, so all six checks point the same way. A workaround that scored high on one check (investment) and low on the other five (say, one customer with an elaborate macro, seen once, at the edge of the product) would instead go to documentation or a services conversation.

Trade-offs and pitfalls

• You only see workarounds from customers who stayed. Those who gave up and left left no spreadsheet behind.
• Some workarounds reflect an intentional product boundary. If the product is deliberately narrow, the right answer may be an integration.
• A workaround that is elaborate but rare (one customer, one macro) is a services conversation (a paid, customer-specific piece of help from a services or solutions team), not a roadmap item (a feature the product team plans to build for everyone).
• Do not extrapolate the 546 hours to the whole customer base without sampling; the count only covers accounts you inspected.

Direct answer

Being customer-obsessed means starting every decision from the customer's underlying problem and letting that change what you do, including when it costs you something. Being responsive means reacting quickly to what customers say. Responsiveness waits for the customer to speak; obsession goes looking for the problem behind the words, and for the customers who never speak at all.

How the ideas differ

• Customer focus is caring about customers in general. It is an attitude and does not have to change any decision.
• Customer obsession is customer focus that shows up as a changed choice: a scope cut, a delayed date, a "no" to a loud request.
• Voice of the customer (VoC) is the collected record of what customers say they want and struggle with (tickets, interviews, survey comments). It is evidence, not a decision.
• Customer advocacy is using that evidence to argue for the customer in internal decisions when a deadline or a revenue target pushes the other way. VoC informs you; advocacy is what you do with it.

Two decisions I would make differently

1. Ask what the request is for before building it. A customer asks for a CSV export of a report. A responsive team ships the export this sprint. An obsessed one asks "what do you do with the file?", learns the customer pastes it into a spreadsheet to compute one weekly figure, and builds that figure into the product. The customer gets a better outcome and nobody maintains a one-off export.
2. Protect a rough spot users hit, even at the cost of a date. Suppose first-run setup is confusing: in observed sessions people stall at the same step and support tickets mention it. A responsive team waits for enough complaints to reach a threshold. An obsessed one moves the date by a few days, fixes that step, and says openly what the delay buys. I would accept a small, stated schedule cost to avoid a large, silent cost to every new user.

Same idea, different seats

A customer success manager (CSM) asks why an account's usage is falling before the renewal call, not after. A sales engineer (SE) or solutions architect (SA) recommends the smaller design that fits the customer's need over the bigger one that is easier to sell. A user-interface (UI) designer tests the layout with the people who will use it, not only the person who bought it.

Trade-offs and pitfalls

• Obsession is not "the customer is always right". Customers describe solutions; your job is to understand the problem and weigh it against other customers and the business.
• Be honest about limits: one customer's problem is a hypothesis until you see it elsewhere.
• The tell that you are only being responsive is that your backlog is a list of requests with the customer's wording still attached.

Direct answer

A customer advisory group (a standing panel of customers who meet regularly to react to your plans) or a beta program (a limited early release to selected customers) is only as honest as its membership. So I choose members from a map of the customer base, not from my address book, and I run the sessions to reward criticism and to check what people say against what they actually do in the product.

How I choose members

1. Write down the segments that matter first: size of customer, main use case, how long they have been a customer, and role (the buyer who signs the contract versus the daily end user).
2. Fill seats against that map using usage and account data, not a salesperson's favourites. When several accounts qualify for one seat, pick by lottery so nobody can hand-pick the friendly one.
3. Reserve seats on purpose for the voices a friendly group omits: recently churned or downgraded customers, accounts with many support escalations, and brand-new customers who still see the product with fresh eyes.
4. Keep the group small enough for everyone to talk, and set a term (for example a year) with staggered rotation so it does not harden into a clique.

How I run it so feedback is honest

• Ask about behaviour, not opinions: "walk me through the last time you did this task" beats "would you use this feature?"
• Collect written input before the meeting, and offer a private channel, so the loudest person does not set the tone.
• Show two or three real options with trade-offs and ask people to rank or reject them, rather than pitching a finished plan.
• Close the loop each cycle: tell the group what you changed, and what you chose not to do and why. Members who never see an effect stop being candid.
• Treat the group as a source of hypotheses, not a vote. It is a hand-picked sample of customers, so I confirm anything important against product usage data and wider research before betting the roadmap on it.

Worked example (illustrative)

A 12-seat advisory group for a workflow product:

That is 12 seats, and 4 of them (the two churned seats, the new-customer seat and the escalation seat) exist specifically to bring in people who are not already fans. Each quarter, one pre-read of two options goes out a week ahead, the call opens with each member's own recent workflow, and the follow-up note lists decisions made and ideas declined.

Trade-offs and pitfalls

• Friendliest-customer drift happens when the account team nominates, so remove the nominators from the final pick.
• Paid or perk-heavy membership can make people polite; keep incentives modest and unconditional on praise.
• Early-access programs also skew toward tinkerers. Record which segment each piece of feedback came from and weight it by how many such customers exist.
• Promising features in the room creates false commitments. Say "we heard this, here is how we will decide."