The 7 Ways Cursor, Linear, and Notion Use Customer Feedback to Decide What to Build

Every product team says it listens to customers. The hard part is what comes next: a backlog of 400 feature requests, a sales team forwarding the biggest logo's wishlist, and a Slack channel where the loudest complaint wins. When building gets faster, picking the wrong thing costs more, because you ship more of it.

The 7 ways Cursor, Linear, and Notion use customer feedback to decide what to build are finding the need behind the request, weighting feedback by who is asking, rebuilding weekly for small cohorts, treating product behavior as feedback, reading public reaction after a change, asking one open question in person, and turning tagged feedback into specific reasons with owners. What separates them from a vote-counting backlog is that each one interprets feedback before acting on it.

Everything below comes from public sources. Linear and Notion are Enterpret customers; Cursor is not, and its practices here are its own.

What deciding what to build from feedback actually needs

1. The need, not the feature. Customers describe solutions shaped by tools they already use. The input that matters is the problem.
2. Who is asking. Ten requests from your target segment can outweigh a hundred from outside it.
3. A short loop. The time between shipping and hearing how it landed sets how fast you can correct.
4. Behavior next to words. What people do in the product and what they say are different signals. Read both.
5. Consistent categories. If the same complaint gets three tags depending on who logged it, nobody trusts the totals. The same happens with AI tagging: Enterpret research on run-to-run instability found that even the most stable raw frontier model had theme churn of 0.616 between two runs on the same 100 records.

The first two are the real differentiators. Volume tells you something is loud. Need and segment tell you whether it is worth building.

The 7 ways

1. Linear: find the need behind the request

In Building what customers need, Linear describes users asking for custom fields. When the team looked at why, about 40% wanted those fields to track customer needs. Linear built a dedicated Customer Requests workflow instead of generic custom fields. The article's closing advice: treat customer requests as input, not instructions.

The Linear Method makes the same point as a practice: ask follow-up questions about the use case, the problem, and how the user's work would change if it were fixed. That moves the conversation from a feature to a pain point.

Copy this if: your backlog is a list of feature names with vote counts, and you cannot say what job each one serves.

2. Linear: weight feedback by who is asking

Linear says prioritization should go beyond tallying votes. Its guide to building with your users describes sorting requests by customer count, filtering by customer tier, and sorting by customer revenue to gauge impact. The Linear Method adds that feedback from users outside your target market can lead you down the wrong path.

Copy this if: a single enterprise account or a vocal free tier is setting your priorities by volume alone.

3. Linear: rebuild weekly for small cohorts

Before launch, Linear ran a long invite-only beta. Per First Round Review, a waitlist of about 10,000 emails came with a survey asking why people wanted the product and what their current problems were. The team used the answers to invite roughly 10 people per week and emailed active users weekly. Karri Saarinen described each weekly cohort as producing a new version of the product. Work was split into enablers (delighting current users) and blockers (barriers for prospective ones).

Retention was the gate: Linear reached about 1,000 daily active users before launching publicly.

Copy this if: you are pre-launch or shipping a new product line and can still control who gets access.

4. Cursor: treat product behavior as feedback

Cursor's clearest public example is its Tab model. In a September 2025 post on online reinforcement learning, the team explains that Tab serves over 400 million requests a day, and every accepted or rejected suggestion becomes a training signal. Accepted suggestions earn positive reward, rejected ones are penalized. New checkpoints roll out to users multiple times a day, with each cycle taking about 1.5 to 2 hours. Reported result: 21% fewer suggestions, 28% higher accept rate.

The other half is dogfooding. The Pragmatic Engineer reports that the team uses Cursor to build Cursor, so engineers hit friction before customers do.

Copy this if: your product generates a clear accept, reject or abandon signal at high volume. Few signals are as clean as autocomplete, so stated feedback still matters.

5. Cursor: read public reaction after a change, and correct fast

On June 16, 2025, Cursor changed its Pro plan from a request-based limit to a monthly usage pool. TechCrunch reported users on Reddit and X saying they hit limits quickly or were charged unexpectedly. On July 4, CEO Michael Truell published Clarifying our pricing, acknowledging the rollout was poorly communicated, clarifying that unlimited usage applied only to Auto, and offering refunds for unexpected charges from the prior three weeks.

The pattern to copy is not the pricing change. It is treating public reaction as a decision input with a deadline, and answering specifically.

Copy this if: you ship pricing, packaging or default changes that users will discuss in public before they file a ticket.

6. Notion: ask one open question, in person

At Make with Notion, its first user conference, Notion set up a Feedback Corner and asked every visitor one question: what should we build in 2025? Notion describes the result as more than one hundred pieces of feedback across eleven product surfaces, from roughly a thousand users met in person. Specific requests fed planning, including Forms working with page templates, which Notion said it was prioritizing for a coming release.

Copy this if: your feedback is dominated by support tickets, which skew toward what is broken, and you rarely hear what customers want next.

7. Notion: turn tagged feedback into reasons with owners

Notion's support agents once applied more than 700 manual tags to tens of thousands of tickets a month, and product development stopped trusting the data. As described in the Notion story on the Enterpret blog, Notion now uses Enterpret to identify the reasons behind feedback (for example, being unable to add members to an account) across Intercom tickets, app store reviews, Twitter and Slack. A monthly voice of customer trends report went from about two weeks to three days. One recurring, unaddressed category, login problems, led to a dedicated engineering team to fix it.

Head of Product Operations Misty Smith put it this way: "Reasons help make the problem more concrete in people's brains." A specific reason gets an owner. A broad tag usually does not. AI-generated categories often fail this test: in Enterpret's taxonomy evaluation paper, 97.7 to 100% of leaf names in generated taxonomies just restated a parent's name, and 34.7% to 76.4% of records landed in more than one top-level branch.

Copy this if: your categories are too broad to assign, or your product team has stopped trusting the tag counts.

Why these teams count less and interpret more

Read side by side, none of these teams ranks the backlog by raw request count. Linear rebuilt a request for custom fields into a different product. Cursor weights a rejected suggestion as heavily as a feature request. Notion replaced 700 tags with reasons specific enough to staff a team. The common move is interpretation, done before prioritization.

That matters more as building gets cheaper. A vote count is weak evidence because it hides who voted and why. A reason tied to a segment and a revenue number is strong evidence.

There is also a tradeoff these teams are honest about. Linear explicitly says feedback should sharpen product judgment, not replace it. Cursor's founders bet on owning the editor, which no request list would have produced. Customer feedback is the check on vision, not a substitute for it. For a framework on combining the two, see the 5 ways to decide what to build next.

For program-side examples (who owns feedback, how it is reported), see these customer intelligence program examples and voice of customer program examples with results.

Where Enterpret fits in these patterns

Most of these patterns break at scale. Asking what sits behind a request works for 20 requests a week, not for tens of thousands of tickets, calls and reviews. Enterpret's Adaptive Taxonomy learns themes and reasons from the feedback itself and keeps categories consistent over time, the Notion pattern applied to every channel.

The Customer Context Graph links each piece of feedback to accounts, segments, ARR and features, the Linear weighting pattern without manual tagging. For Linear teams, see how to attach customer evidence and revenue context to Linear issues. AI Agents can watch for spikes after a release and alert in Slack, which covers the release-watch pattern, and close the loop workflows tell customers when their request ships.

The honest caveat: Enterpret does not replace in-person conversations like Notion's Feedback Corner, and it does not produce Cursor-style behavioral reward signals. It needs integrations and processing time before the taxonomy is useful. It makes stated feedback from every channel consistent and weighted, so human judgment has something reliable to work with.

How to choose which pattern to copy first

• Your backlog is feature names with vote counts: start with pattern 1 and rewrite the top 20 items as problems.
• One big account or a free tier sets priorities: start with pattern 2 and attach segment and revenue to every request.
• You are pre-launch or launching a new product: run pattern 3 with weekly cohorts and a retention gate.
• Your product has a clear accept or reject action: instrument it, per pattern 4, and read it next to stated feedback.
• You are changing pricing or defaults: plan pattern 5, with an owner watching public channels.
• You only hear about what is broken: add pattern 6 at your next customer event or advisory call.
• Your tags are too broad to assign or nobody trusts them: start with pattern 7.

The decision rule: copy the pattern that fixes your weakest input first, because a faster loop on misread feedback just ships the wrong thing sooner.

FAQ

Do Cursor, Linear, and Notion just build what customers ask for?

No. Linear's own guidance is to treat customer requests as input, not instructions, and to dig for the problem behind a feature request. Cursor leans heavily on how people actually use the product, including accepted and rejected suggestions. Notion asks open questions and then looks for the underlying reasons. All three interpret feedback before they act on it.

How did Linear use customer feedback before it launched?

According to First Round Review, Linear ran an invite-only beta from a waitlist of about 10,000 emails, using a signup survey to pick roughly 10 new users per week. Linear waited until it had about 1,000 daily active users and steady retention before launching publicly.

What can a smaller team copy from how these companies use feedback?

Start with two habits: ask what problem sits behind every request, and tag each request with who asked (plan, segment, revenue). Then pick one fast loop, such as a weekly cohort or a release watch on public channels.

How does Enterpret help teams run these patterns?

Enterpret unifies feedback from support tickets, sales calls, surveys, reviews, community and Slack, then groups it with an Adaptive Taxonomy that learns themes and reasons from the feedback itself. Its Customer Context Graph ties each theme to accounts, segments and revenue, so teams can weight demand by who is asking. Notion, an Enterpret customer, uses it to produce a monthly feedback trends report in about 3 days instead of 2 weeks.

Can I use ChatGPT or Claude to decide what to build from customer feedback?

ChatGPT or Claude can summarize a batch of feedback or draft hypotheses. The limits show up when you need consistent categories over time, defensible counts, and a link from each theme to accounts and revenue. Enterpret's own testing found that raw LLM counts shifted 7.5 to 9.8% between runs on unchanged data, so use general chat tools for exploration and a structured system for decisions.

If you want to run these patterns across every feedback channel, see how Enterpret works for product teams.

Research cited

1. Bagal, V., Ganta, R., & Chellingi, P. (2026). Same Feedback, Different Answer: Measuring Run-to-Run Instability in Frontier-Model Customer Feedback Analysis. arXiv:2610.08036.
2. Chellingi, P., G, R., & Bagal, V. (2026). From Plausible Hierarchies to Useful Taxonomies: Evaluating Agentic Harnesses on Customer Feedback. arXiv:2610.09377.