How to Listen to Users Without Building Every Feature They Request

OpenArt has 350,000 users in its Discord community. Coco Mao, the company’s CEO and co-founder, talks to about 30 of them in a typical week. Some users have her personal WhatsApp. Most founders would consider this an enviable feedback firehose. Coco considers it a trap unless you have the right filter on top of it.

The filter is a single principle: “You listen to the users, but you don’t listen to their feature requests. You listen to their problems.”

That distinction is the difference between a product team that ships every requested feature into a bloated mess, and one that pivots into a category-defining position. OpenArt’s pivot from “AI image generation” to “AI visual storytelling” came directly from applying this filter to a specific user request.

The Feature-Request Trap

Most founders, especially in AI, are trained to be customer-obsessed. They sit on Discord, respond to feedback, run user interviews. The feedback comes in like:

• “Can you add character consistency?”
• “Can you add longer videos?”
• “Can you add a background remover?”
• “Can you add multi-language support?”

If you build the requested features, you end up with a product that has all the features users asked for and zero strategic shape. Worse, you’ve optimized your roadmap to the most articulate users, who often aren’t your ICP. The users who matter most are sometimes the least articulate about what they need.

Coco names this directly: “I’ve definitely encountered a lot of people that just tell you a solution. But when they tell you a solution, it’s actually not, definitely, almost always not the right solution. Because they have limited view. You know your product better, the tech, you know everything. But their problem is real. So listen to their problem and then design the solutions for them.”

The user isn’t wrong about having a problem. They’re wrong about what the solution looks like. Your job is to translate, not to build what they say.

A Working Example: How “Consistent Characters” Became Visual Storytelling

OpenArt’s most consequential pivot came from applying this filter to one of its most requested features.

The setup: by 2024, OpenArt was the top of its category for AI image generation. Users were happy. But there was a feature request that kept coming in — “consistent characters.” Users wanted to generate multiple images that shared the same character’s face, body, and styling. Most teams would have built this as a feature, shipped it, and called it a win.

Coco asked the next question. Why does anyone need a consistent character?

“When you really understand, oh why do you need a consistent character in all your images? That’s when we realized — oh, all of these people were trying to tell a story.”

That’s the translation. The feature request was “consistent characters.” The underlying problem was “I’m trying to tell a story but I don’t know how.” Once Coco saw the real problem, the entire roadmap shifted. OpenArt added consistent characters, but they also added one-click story generation, character vlogs, music videos, explainer videos, and a video agent that breaks scripts into scene-by-scene clips. They repositioned the company around “visual storytelling” as a category — broader than image generation, broader than video, focused on the underlying need.

The competitors who heard “consistent characters” and built only that feature shipped a feature. Coco shipped a category move.

The Three-Layer Translation

There’s a structure to how Coco does this translation. It’s not magic — it’s a discipline you can practice.

Layer 1: What the user said. The feature request, verbatim. “Add consistent characters.”

Layer 2: What the user actually wants. The use case beneath the request. “I want to generate multiple images of the same character because…”

Layer 3: What the user is actually trying to accomplish. The job-to-be-done. “I’m trying to tell a story but I don’t have the production tools or skills to do it.”

Most founders stop at Layer 2 — they build the use case. Coco goes to Layer 3 and builds for the job. Layer 3 is where category moves happen because Layer 3 questions are usually broader than any single feature can answer.

The ICP Filter

There’s a second filter on top of the first. Even after you translate to problems, not all problems are worth solving. Some come from users who aren’t your ICP.

“You’ll have a wide range of audience. That’s why you need to be clear about your ICP — your ideal customer profile. So that you pick the problems of your ICP and then work on it, instead of listen to everyone’s problems and then try to solve everyone’s problems.”

OpenArt’s ICP, after Coco talked to 30 users in a week to refine it, is gen-AI social media creators and SMBs. The hobbyists who want OpenArt for personal experimentation are users, but they’re not the ICP. The Hollywood-style filmmakers who want frame-perfect cinematic control are users, but they’re not the ICP. The ICP is the user whose problem the company is structurally best positioned to solve, and whose problem solving creates the most leverage.

So the actual filter is two-stage: translate feature requests to problems, then filter problems by whose problems they are. What you’re left with is a small list of problems worth solving — and that’s your roadmap.

Why This Discipline Is Rare

Most founders skip this discipline because Layer 1 listening is faster and feels productive. You read the request, you build the feature, you ship. The user is happy because you listened. The roadmap looks busy.

But busy roadmaps are how startups die in crowded categories. AI image generation has a graveyard of products that built every feature their users asked for and never moved up the value chain. The teams that survived are the ones that did the harder, slower work of asking why behind every request — and the ones that pivoted at the category level when the answer revealed a bigger opportunity.

Coco puts it directly: “The startups that I saw that are able to survive until today — and then are still growing — the startups have been very iterative and fast at learning. That, I think, is the best or biggest trait that you need to be successful in the GenAI space.”

Iteration speed isn’t about shipping more features. It’s about translating user noise faster, more accurately, and at a deeper layer than competitors do.

FAQ

How do you actually translate a feature request into a problem statement?

Ask “why” twice. The first “why” gets the use case (“why do you need consistent characters?” → “because I want to generate a series”). The second “why” gets the job (“why do you want a series?” → “because I’m trying to tell a story”). Stop when the answer reveals a category, not a feature. That’s where the strategic insight lives.

What’s the right cadence for user interviews when you have thousands of requests?

Coco does 30 user interviews in a single focused week, then operates on those insights for weeks. The pattern is: batch your research, then batch your shipping. Don’t try to talk to users every day — you’ll lose pattern recognition. Concentrated weeks of interviews surface the patterns that distributed conversations don’t.

How do you avoid building for the loudest users instead of the highest-value ones?

Define your ICP explicitly before you start interviewing. Coco’s ICP is gen-AI social media creators and SMBs. Hobbyists are loud in Discord but not the ICP. When you sort feedback by ICP first and volume second, the loud-but-non-ICP users stop dominating the roadmap.

Should you ever just build a feature exactly as a user requested?

Sometimes — when the feature request is small, low-cost, and obviously aligned with the underlying problem. The rule is: if the request is for a tactical fix to an existing workflow, build it. If the request implies a new direction or a new market, translate it first. Most of the dangerous requests are the directional ones.

How do you say no to user requests without losing the user?

You don’t usually have to. Most users don’t track which of their feature requests got built — they care about whether the product solves their problem. Solve the underlying problem (even differently than they suggested) and the request feels addressed. OpenArt didn’t just build “consistent characters” — they built it inside a broader visual storytelling platform, which served the same user better than the literal request would have.

How does this translate to enterprise customers vs. consumer?

Enterprise customers are usually better at articulating problems instead of solutions, but they tend to over-specify the solution they want anyway. The translation discipline still applies — go from “we want this specific feature” to “what’s the workflow problem you’re trying to solve?” Consumer users are worse at problem articulation but their behavior is easier to observe directly.

What’s the difference between this and “ignore your customers”?

Ignoring customers means dismissing what they say. Translating customers means taking what they say very seriously, but at the right layer of abstraction. Coco talks to users every week. She doesn’t ignore them — she listens harder than most founders do. The “harder” is at the problem layer, not the feature layer.

Can you use this approach if you don’t have a 350K-user Discord?

Yes. The principle scales down. Twenty users with translated problem statements beats two thousand users with raw feature requests. Coco operated this way before OpenArt had a Discord at all. The discipline is about how you process feedback, not how much you have.

How does this connect to product-market fit?

Product-market fit is when you solve a real problem for a defined ICP, repeatably. If you’re listening to feature requests instead of problems, you’ll never know if you have PMF — you’ll just know you have a busy roadmap. Translating to the problem layer is what makes PMF measurable. You’re either solving the underlying problem or you aren’t.