Don't prioritize based on what people ask

There’s a bit of a paradox I’ve been struggling to put words on at Cycle. We’re building a tool that helps teams manage product feedback, yet we don’t believe in prioritization based on what people ask. We just don’t think that counting feature requests is a good way to decide what to work on.

There are two kinds of products in this world: those that try to please everyone and those that take a stance. We believe in products that take a stance.

So why capture product feedback anyway?

The best product teams we’ve worked with seem to use feedback not as a way to figure out what to build but rather as a way to develop product sense and build loyalty with customers. Feedback is a tool that helps them:

• Improve product quality by infusing customer quotes in the product development lifecycle.

• Close the feedback loop at each release to create trust and doing so improving retention & engagement.

These teams don’t hide behind fancy prioritization scores: they have deep empathy for customers, solid market knowledge, and strong opinions on where the product should go. They are the teams we’re building Cycle for.

Don’t get me wrong, frameworks like RICE or "Value vs Effort" can be helpful, especially to communicate the rationale behind product priorities. They are cool mental models but they're often out of touch with reality.

First, people overestimate the “objectivity” of any measurement system.
Measures are called “quantitative” data just because they have a number. The thing is most of these numbers are based on skewed assumptions so they’re just qualitative intuition masquerading as quantitative data. Even worse, people end up prioritizing making decision-making easy, not making high-quality decisions.

Second, the « Effort » side of these frameworks always felt irrelevant to me.
Effort depends on scope, which is a variable, not a constant. For any given problem to solve, there are many possible ways to fix it. Scope should come after prioritization, not before.

Finally, these systems overlook a key component of product planning: Dependency.
This includes not only technical but also design, skill, and strategic dependencies. The scores assigned by these systems don’t reflect these real-world intricacies, and this often leads to inconclusive discussions about whether a project should receive a score of 5 or 6, based on broad, subjective criteria.

But, wait, does it mean that you should never listen to customers? Not at all. By all means listen to them, but do it right:

• Customers do know what problems they have, but they usually have no clue how to solve them. It's your job as a product team to figure out what to ship. Talk to them, but in the right way. Don't ask what features they want. Ask about their goals and learn through their actions.

• Customers typically ask for something better, not different. Customer requests are the best source of prioritization for incremental improvements but don't count on them for breakthrough innovation. "Better" vs "Different" is a nice way to categorize your product work. You need both to build an exceptional product.

In conclusion, my advice is to avoid shipping what customers ask. Listen to them, understand their needs and pains but don’t hide behind scores to prioritize :-)

Thank you to Austin Yang & Brian Gibson for the great insights & convos on the topic.