Voice of Customer & the Feedback Loop
Turn raw user signal into product decisions leadership acts on
Designing a Voice-of-Customer program
After this you can stand up a VoC system from near zero.
The job posting says you'll build and run the Voice-of-Customer program. That word - build - is the whole interview. Cursor is hiring someone to stand up a system where one barely exists, not to staff a process someone else designed.
At 1M+ DAU and 300-ish people, the gap between what users feel and what the product team knows is enormous and nobody is reading every Discord thread. A Product Quality Engineer closes that gap by turning a flood of raw signal into a small number of themes leadership can act on. The first thing an interviewer wants to hear is that you'd design the pipeline, not that you'd start triaging tickets harder.
Walk the program backward from the artifact it produces. The output is a weekly brief that says "here are the top five things hurting users, ranked, quantified." Everything upstream exists to feed that.
- 1Inventory the sources. List every place a user voices pain before you touch tooling. Miss a channel and you bias the whole program toward the loud ones.
- 2Define the taxonomy. Agree on a fixed set of tags - feature area, severity, sentiment, theme - so a Discord gripe and a support ticket land in the same bucket.
- 3Pick the cadence. Set a weekly or monthly brief as the heartbeat, plus a real-time path for anything that can't wait for the brief.
- 4Automate the read. At Cursor's volume you cluster and summarize with agents, then a human checks the output. Manual reading does not scale past a few hundred items.
- 5Route and close. Decide where each theme goes - engineering backlog, a leadership decision, a user reply - and track whether anything actually happened.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Sketch this in 60 seconds when asked how you'd set VoC up here.
Inventory every signal sourcethe channels users actually use
Cursor's users are developers and developers complain in public. They post on X, file forum threads, vent in Discord and leave terse one-line reviews. The structured channels (support, in-product feedback) are easier to read but underrepresent the power users who matter most. Name all of them out loud.
- Support tickets - highest intent, already somewhat structured, but only the users who bothered to write in.
- Community forum and Discord - where power users debate workarounds and model regressions in real time.
- Social and X - fast, public and where a viral complaint can become a fire before the brief ships.
- App and extension reviews plus in-product feedback - broad but shallow, good for sentiment trend.
- Sales and CS notes - the enterprise voice that never shows up in Discord but carries the ARR.
Define a consistent taxonomyso signal is comparable across channels
A theme is only countable if the same thing is tagged the same way everywhere. Pin a small, fixed vocabulary down before you ingest a single item, because retrofitting tags onto thousands of historical reports is the kind of cleanup that kills VoC programs.
- Feature area
- Tab, Agent, ⌘K, chat, indexing, models, billing - match the product's real surfaces, not vague buckets
- Severity
- Data loss / security / outage at the top, cosmetic at the bottom - drives what jumps the queue
- Sentiment
- Frustrated, confused, churning, delighted - lets you watch the emotional trend, not just volume
- Theme
- The cross-cutting label that survives ('Agent edits the wrong file') - this is what you brief on
Keep the list short. A taxonomy nobody can apply consistently is worse than none.
Every design choice - sources, tags, cadence, tooling - should be justified by whether it makes the weekly brief sharper. If a step doesn't improve the artifact leadership reads, cut it. That framing alone separates a systems-builder from a ticket-closer.
When asked "how would you set up VoC here," resist listing tools. Sketch the pipeline end to end in 60 seconds - sources in, taxonomy applied, agent-assisted clustering, human review, weekly brief out, loop closed - then say which piece you'd build first and why. Naming the first brick shows you've actually shipped one of these before.
Takeaway. Design VoC backward from the weekly brief: inventory all channels, fix a small taxonomy, set a cadence and lean on agent-assisted clustering with human review to survive 1M+ DAU.
Self-check
QWhy is defining a fixed tagging taxonomy before ingesting signal more important than at lower volume?
From anecdote to defensible signal
After this you can convert individual complaints into trends leadership can trust.
One angry tweet is an anecdote. Forty tickets, three enterprise accounts and a doubling week-over-week is a signal. The PQE's craft is turning the first into the second without overclaiming.
Leadership at a hypergrowth company is drowning in opinions, including their own. A brief earns action when it carries a number a skeptic can't wave away and a quote that makes the number feel human. Bring only the quote and you sound reactive; bring only the number and nobody remembers it.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Ranked by how hard each one is for a skeptic to wave away.
Quantify the theme four waysthe numbers that survive a skeptic
- Volume
- How many distinct reports rolled into this theme this period
- ARR affected
- Revenue tied to the accounts reporting it - the dimension that moves an exec
- Frequency
- How often a hit user hits it - once ever vs every session changes urgency
- Trend
- The delta vs last period - a theme doubling matters more than a big flat one
A theme with all four filled in is hard to argue against. A bare count is easy to dismiss.
Separate the vocal minority from broad paincounts and segments, not loudness
Five users who post ten times each can look like fifty complaints. Always count distinct users, not messages and slice by segment so you can tell "loud handful" from "quiet majority." The reverse trap is just as real: enterprise users rarely post in Discord, so a channel-blind count under-weights the accounts paying the bills.
- Reading
- Raw message count
- Looks like
- 50 complaints about Tab latency
- Actually means
- 5 power users posting repeatedly
- What to brief
- Count distinct users; note it's a vocal handful
- Reading
- Single channel
- Looks like
- Quiet on the forum, so it's fine
- Actually means
- Enterprise hits it but reports via CS
- What to brief
- Cross-reference CS notes before calling it minor
- Reading
- Flat high volume
- Looks like
- Always our #1 complaint
- Actually means
- Steady-state, already understood
- What to brief
- De-prioritize vs a fast-rising theme
- Reading
- Sudden spike
- Looks like
- 30 reports overnight
- Actually means
- Likely a regression from yesterday's release
- What to brief
- Escalate now, don't wait for the brief
| Reading | Looks like | Actually means | What to brief |
|---|---|---|---|
| Raw message count | 50 complaints about Tab latency | 5 power users posting repeatedly | Count distinct users; note it's a vocal handful |
| Single channel | Quiet on the forum, so it's fine | Enterprise hits it but reports via CS | Cross-reference CS notes before calling it minor |
| Flat high volume | Always our #1 complaint | Steady-state, already understood | De-prioritize vs a fast-rising theme |
| Sudden spike | 30 reports overnight | Likely a regression from yesterday's release | Escalate now, don't wait for the brief |
The same raw data tells opposite stories depending on whether you count users, channels and deltas.
Pair the number with a verbatimdata plus a human voice
Quote the user in their own words next to the metric. "Agent rewrote my whole file when I asked it to fix one function - I've stopped trusting it" lands harder than "trust concerns with Agent edits," and it gives the product team the exact failure to chase. One sharp verbatim per theme is plenty.
Don't dress up thin data as certainty. If a theme rests on six reports, say so and label your confidence low. Leadership will weight it accordingly and trust the next brief more. Overclaiming once - calling a fluke a trend - costs you the credibility the whole program runs on.
“This theme is 42 distinct users, four of them paid accounts worth ~$80k ARR and it doubled week-over-week - and here's what one of them actually wrote. I'd weight it high; the sample is real and the trend is moving.”
Takeaway. Make a theme defensible with volume, ARR, frequency and trend plus one verbatim quote; count distinct users not messages and state your confidence so leadership knows how much to weight it.
Self-check
Writing for the right audience
After this you can communicate the same issue effectively to users, engineers and leadership.
The same bug needs three different documents. The JD names clear multi-audience writing as a core skill and the take-home will almost certainly make you produce at least one of them cold.
A PQE is the translation layer. The user feels the pain, the engineer needs to reproduce it and the exec needs to decide whether it's worth a sprint. Each reader has a different question, so the same facts get reordered, recompressed and re-toned for each.
Lead with impact and a recommendation.
One screen, ruthlessly summarized.
Decision-oriented: what should we do?
Numbers up front, detail in an appendix.
Precise, reproducible, evidence-rich.
Steps to repro, expected vs actual, logs.
Version, OS, model, frequency named.
Low ambiguity - no 'sometimes it breaks'.
Empathetic and plain-spoken.
Honest status without overpromising.
A workaround if one exists.
No internal jargon or blame.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The leadership brief and the engineering ticket invert almost every choice.
Match altitude to audiencethe move interviewers grade
Altitude is how high you fly over the detail. An exec wants the view from 40,000 feet - impact, ask, done. An engineer wants ground level - the exact repro and the stack trace. Handing an exec the stack trace or an engineer a vague "users are unhappy," is the most common failure and it reads as not knowing who you're writing for.
- Audience
- Leadership
- Their question
- Is this worth our time?
- Lead with
- Impact, ARR, recommendation
- Avoid
- Repro steps, stack traces
- Audience
- Engineering
- Their question
- How do I reproduce and fix it?
- Lead with
- Exact steps, environment, evidence
- Avoid
- Vague severity adjectives
- Audience
- User
- Their question
- Will this get fixed and what do I do now?
- Lead with
- Empathy, status, workaround
- Avoid
- Internal jargon, false promises
| Audience | Their question | Lead with | Avoid |
|---|---|---|---|
| Leadership | Is this worth our time? | Impact, ARR, recommendation | Repro steps, stack traces |
| Engineering | How do I reproduce and fix it? | Exact steps, environment, evidence | Vague severity adjectives |
| User | Will this get fixed and what do I do now? | Empathy, status, workaround | Internal jargon, false promises |
Have one real example of each document ready to show or describe - a brief you wrote, a ticket an engineer thanked you for, a reply that calmed an angry user. The take-home and onsite test this directly and walking in with proof beats describing the skill in the abstract.
If a take-home gives you one bug and one audience, write that document tightly, then add two lines: "Here's how I'd reframe this for the other two audiences." It signals range without padding the deliverable and range is exactly what this role rewards.
Takeaway. One bug, three documents: exec brief leads with impact and an ask, engineering ticket leads with a clean repro and evidence, user reply leads with empathy and honest status.
Self-check
QYou're writing up an Agent bug. What should the leadership brief lead with and how does it differ from the engineering ticket?
Closing the loop with engineering and product
After this you can ensure feedback actually changes the product and users feel it.
A brief that nobody acts on is just a newsletter. The loop only closes when a theme becomes a shipped fix and the user who reported it hears back.
This is where most feedback programs quietly die. Signal gets collected, summarized, presented - and then evaporates, because no one owns the handoff into engineering or the trip back to the user. The PQE owns that whole arc, which is what the JD means by no-handoffs ownership.
- 1Hand off ranked, not raw. Give engineering a prioritized, quantified, reproducible item, never a dump of unread complaints. They should be able to start fixing, not start triaging.
- 2Show up as the field expert. Bring customer context into roadmap and grooming so a theme has a human advocate when priorities get cut.
- 3Track it in a shared backlog. Log every briefed theme somewhere durable so it doesn't disappear the moment the meeting ends.
- 4Close back to the user. When a fix ships, tell the people who reported it - that single act is what makes giving feedback feel worth it.
- 5Measure the loop itself. Report how many top themes turned into shipped fixes this quarter, so the program is accountable too.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Most programs die between 'brief' and 'fix' - own every step.
Why the handoff quality decides everythingengineers fix what's clean
An engineer choosing between a clean ticket and a vague one will fix the clean one every time, because it's lower risk and faster to verify. Your handoff quality directly sets how much of your signal becomes real change. A raw complaint dump pushes the triage cost onto engineering and that's exactly the work you were hired to absorb.
Measuring the loopthe program needs its own scoreboard
- Themes → fixes
- Share of top themes that became shipped fixes this quarter - the headline number
- Time to ship
- From first brief to shipped fix; rising times mean the loop is clogging
- Loop-back rate
- Share of resolved themes where users were actually told it shipped
- Recurrence
- Themes that came back after a 'fix' - flags incomplete root-cause
If you can't say what fraction of your briefs led to fixes, you can't prove the program works.
Users keep giving good feedback when they see it land. The reply that says "the Agent file-overwrite bug you reported shipped a fix in 0.42" buys you ten future reports from that user. Skipping it teaches users that writing in is pointless and the signal slowly dries up.
When asked how you'd run the feedback loop, end on measurement. Most candidates stop at "I'd brief leadership." Saying "and I'd report what fraction of briefed themes shipped, so the loop is accountable to itself" signals the ownership and rigor Cursor's bar is screening for.
Takeaway. Close the loop end to end: hand engineering ranked, reproducible items, track them in a shared backlog, tell users when fixes ship and measure what fraction of briefed themes actually shipped.
Self-check
QWhat is the single metric that best proves a VoC program is working and why does telling users about shipped fixes matter?
Being the product expert
After this you can become the trusted internal authority on how Cursor actually behaves.
Your briefs only move people if the room believes you know the product cold. Credibility is the currency and you earn it by being the person who can answer a deep Cursor question without bouncing it to engineering.
The recruiter screen probes whether you actually use Cursor day to day and the product round goes deeper. Cursor screens hard here because a quality owner who isn't a power user will mis-rank themes and miss the bugs that matter most to the people who matter most.
Know the surface area coldevery feature the brief might touch
For each surface, know not just what it does but how it fails. "Agent edited the wrong file" and "indexing never finished on a big monorepo" are the failure modes a power user has actually hit and naming them fluently is what proves you live in the product.
Keep a living map of known issuesissue, status, workaround
Maintain a written register of current bugs, their status and the workaround you'd give a user today. This is the artifact that lets you answer instantly across the org and the backbone of the VoC themes you brief. It also means you never give the same person two different answers a week apart.
- Surface
- Which feature - Agent, Tab, indexing, billing
- Symptom
- What the user sees, in their words
- Status
- Investigating, fix in progress, shipped, won't-fix
- Workaround
- What to tell a user right now while it's open
Track the competitionframe issues against alternatives
Users compare Cursor to what else they could run, so you should too. Knowing where Copilot, Windsurf and Claude Code are stronger or weaker lets you frame a theme with stakes: "users are leaving Agent for Claude Code on long refactors" is a sharper brief than "Agent has quality issues."
Deepest IDE reach and enterprise install base.
Often framed as safer / more incremental.
Useful contrast for 'why switch to Cursor'.
Closest agent-IDE competitor in positioning.
Frequent head-to-head in power-user threads.
Watch for feature-parity complaints both ways.
Terminal-native agent, strong on long tasks.
Where some users go for big refactors.
A real churn destination to track in VoC.
Reaches the JetBrains IDE loyalists.
Relevant for users who won't leave that ecosystem.
Frames the 'why not just my IDE's AI' question.
Don't fake usage. An interviewer who lives in Cursor can tell within two questions whether you actually use Agent mode or just read the docs. If you haven't used a feature heavily, say so and describe how you'd get up to speed fast - that beats bluffing a detail and getting corrected.
“I keep a living known-issues register - surface, symptom, status, workaround - so I can answer any Cursor question on the spot and so my briefs are grounded. It's also how I make sure two users with the same problem never get two different answers from me.”
Takeaway. Be the internal authority: know every Cursor surface and how it fails, keep a living known-issues register and track Copilot, Windsurf and Claude Code so you can frame themes against real alternatives.