Feature Request Management Needs Usage Data

Feature request management breaks when every request looks like an opinion.

That showed up clearly on a lab software call. The founder liked the idea of customers building small apps inside the product, but his product question was sharper: could the SaaS team see what customers were building, summarize the themes, and decide which workflows deserved to become first-party product?

That is the part most feedback systems miss. A request tells you what someone asked for. A used app tells you what someone cared enough to create, share, and keep using.

Key Takeaways

• Feature adoption measures actual usage of a feature, not just interest in it.¹
• Customer-built apps can turn feature request management into observed behavior: what was built, copied, shared, edited, and reopened.
• Product teams should promote an app into the core roadmap only when repeat usage shows the need is broad.

Why do feature requests become hard to prioritize? #

Feature requests are hard to prioritize because the request usually arrives without proof of repeated use.

A customer can ask for a dashboard during onboarding. Sales can mark it urgent because a deal depends on it. Support can hear the same kind of complaint from three accounts and still not know whether the workflow is a broad product need or a loud local edge case.

That is not a people problem. It is a signal problem. The product team is being asked to compare anecdotes that were collected in different contexts, by different teams, under different levels of pressure.

What does usage data add to feature request management? #

Usage data adds a second question after the request: did anyone keep using the thing once it existed?

Pendo defines feature adoption as usage of a specific feature, and it ties that usage to retention and expansion because unused features lower perceived value.¹ That framing matters for roadmap work. A request with no usage evidence is still worth listening to, but it should not carry the same weight as a workflow customers built, shared with teammates, and opened again the next week.

For AI-built apps inside a SaaS product, the usage trail can be even more useful than a normal feature launch. You can see the prompt, the API endpoints used, the app category, who installed it, which teams opened it, and whether the app spread beyond the original account.

What did the sales call make obvious? #

The call made one product question obvious: customer-built apps should feed the roadmap, not disappear into a side workspace.

The founder asked whether the SaaS team could see a summary of what people were building. If a majority of users were creating inventory management workflows, he wanted product to know. If only one customer built a strange internal report, that could stay as a customer-specific app.

That is a cleaner loop than a feature board. The customer does not have to predict what should be on the roadmap. They build the workflow they need. Product watches which workflows survive real use.

How should product teams track customer-built apps? #

Product teams should track app behavior the same way they track product behavior: creation, edits, installs, launches, repeat usage, sharing, and account spread.

The useful unit is not just the generated app count. A team can generate a lot of throwaway apps during exploration. The stronger signals are boring: an app is opened every day, copied by another team, installed by several users in one account, or rebuilt with the same pattern across multiple accounts.

Those events help product separate four buckets:

• one-off account workflows that should stay flexible
• common templates that belong in an app store
• repeated variants that need a better first-party workflow
• unsafe or unsupported patterns that need a guardrail

That last bucket matters too. Roadmap signal is not only what to build. It is also what customers are trying to do that the product should constrain.

When should a customer-built app become a core feature? #

A customer-built app should become a core feature when the same job appears across accounts and repeat usage proves the workflow matters.

One account building a custom birthday-triggered lab workflow does not automatically mean the core product needs birthday logic. It may be a perfect app. Ten accounts building similar inventory review workflows is different. That is a product pattern trying to surface.

The promotion rule should be conservative. Moving an app into the core product makes it easier to support, but it also adds UI, documentation, QA, and maintenance. The whole point of customer-built apps is to avoid putting every edge case into the main product too early.

What does this change for roadmap meetings? #

It gives roadmap meetings a better object to discuss.

Instead of debating whether a request sounds strategic, the team can inspect the app and the usage trail. Who built it? Which role used it? Which API data did it need? Did it get shared? Did another account build the same thing? Did usage continue after the novelty wore off?

That makes the conversation more concrete. Sales and CS still bring the customer context. Product still decides what belongs in the core platform. But the debate starts from behavior, not only from who shouted loudest in the last pipeline review.

FAQ #

Conclusion #

Feature requests are still useful. They tell you where a customer felt pain.

But the next signal is more useful: what did the customer do when they could build the workflow themselves?

If the answer is a single local app, keep it flexible. If the answer appears across accounts and keeps getting used, product has found something stronger than a request. It has found behavior.

Sources #

Footnotes #

1. Pendo. "Feature adoption." https://www.pendo.io/glossary/feature-adoption/ 2026. ↩ ↩²