Why we sometimes say no to features partners ask for

One of the most interesting parts of product discovery is uncovering the real reason behind a feature request.

A partner might come to us and say they need a new dashboard. Another might want a messaging feature. Someone else might ask for additional reporting options, a more detailed user profile, or a completely new section of the app.

At face value, those requests seem straightforward. The temptation can be to immediately start discussing functionality, timelines and technical requirements. Instead, we usually start by asking questions, and by questions, we mean LOTS of them.

Not because we're trying to challenge the idea for the sake of it, but because the feature itself is often only one possible solution to a much bigger problem.

Let's say someone asks for a messaging feature. We ask:

• Why are users struggling to communicate with each other?
• Why are important updates being missed?
• Is there a need for better visibility across teams?
• Is information getting lost in emails?

Those are all different problems, even though they initially point towards the same solution.

If your car develops a fault, you know something isn't right. You don't necessarily know which component needs replacing. If your house is losing heat, you know there's a problem. You don't automatically know whether the issue is your windows, your insulation or your heating system.

Digital products work in exactly the same way. Users understand the pain point and product teams are responsible for understanding the wider context around it.

That's why a feature request often changes shape as conversations progress. A proposed messaging system might become a notification centre. A request for additional reporting might reveal that users simply can't find the information that's already available. A complicated workflow might disappear altogether because the root cause sits elsewhere in the product.

This is where product thinking becomes valuable. Our role isn't to take a list of features and build them exactly as they've been written down. It's to understand the outcome you're trying to achieve and find the most effective way of getting there.

One of the biggest misconceptions in app development is that a feature only costs what it takes to build it. If a feature requires two weeks of development, it's easy to assume that's the full investment. But in reality, development is only the beginning.

Every feature that gets added to a product creates a long-term responsibility. It needs to be maintained, tested, updated and supported. It needs to work when operating systems change. It needs to continue functioning when new functionality is introduced elsewhere in the app. It needs to be considered every time the product evolves.

The larger a product becomes, the more these decisions start to compound. A single feature might not seem significant in isolation, but products aren't experienced in isolation. They're experienced as a whole.

There's a common misconception that the best agency-partner relationships are the ones where every request gets approved. In reality, the strongest partnerships are built on trust, honest conversations and a shared understanding that everyone is working towards the same goal: creating the best possible product.

That means there are times when challenging an idea is part of doing our job properly.

If a partner suggests a feature that we believe will genuinely improve the product, we'll be the first people championing it. But if we think it introduces unnecessary complexity, creates confusion for users or distracts from the product's core purpose, we'll say so.

This is one of the biggest differences between feature delivery and product thinking. A feature delivery mindset focuses on outputs. How many things can we build? How quickly can we release them?

A product mindset focuses on outcomes. What problem are we solving? How does this help users achieve their goals? Is there a simpler way to get the same result?

That shift in thinking changes the conversation completely.

Interestingly, some of the most valuable product work never gets seen by users. It's the complexity that never made it into the interface. The extra steps that were removed before launch. The feature that looked useful on paper but would have created friction in practice.

Users rarely notice those decisions directly. What they notice is that the product feels intuitive and helps them achieve what they need to do without getting in their way.

When discussing roadmaps, it's easy to think of features as competing for development time. In reality, they're also competing for user attention.

Every new feature asks users to learn something new, understand where it fits and decide whether it's relevant to them.

A menu that was once simple becomes crowded. A straightforward workflow becomes layered with exceptions and edge cases. An onboarding process that took minutes suddenly takes much longer because there's more functionality to explain.

The result is often a product that technically does more but feels harder to use.

We've all encountered products like this. They contain countless features, but finding the one thing you actually need feels unnecessarily difficult. That's why simplicity is so valuable. The best products aren't always the ones with the longest feature list. More often, they're the ones that help users achieve their goals with the least amount of friction.

Not every feature request falls into a simple yes or no category. Often, the answer is "not yet."

A feature can be a great idea and still not be the right priority. Perhaps there isn't enough user data available yet. Perhaps there are more pressing usability issues to solve first. Or perhaps the product is still validating its core proposition and adding more functionality would only create distraction.

This is particularly true for growing products.

The temptation is to solve every possible problem at once, but successful products tend to do the opposite. They focus on solving one problem exceptionally well before expanding into new areas.

You can see this pattern repeated across many of today's most successful digital products. Their earliest versions were often surprisingly simple because growth was driven by learning, not assumptions.

Features weren't added because they sounded good in a planning session. They were introduced because user behaviour, product strategy and real-world data demonstrated a clear need.

Prioritisation isn't about rejecting ideas. It's about making sure the right ideas happen at the right time.

Ultimately, when we challenge a feature request, we're not challenging the person who suggested it. We're exploring whether the proposed solution is the best way to achieve the desired outcome.

The goal isn't to build the biggest product or create the longest roadmap. It's to create something people genuinely want to use. Something that solves real problems, supports business objectives and continues to deliver value long after launch.

Achieving that requires discipline and, occasionally, saying no. Not because the idea lacks merit, but because there may be a better way to achieve the same result.

Feature requests are incredibly valuable. They highlight frustrations, opportunities and areas where users feel something could be improved. But great products aren't built by turning every request into functionality.

They're built through careful prioritisation, thoughtful design and a deep understanding of what users actually need. That's why we'll always explore the thinking behind a feature request before deciding whether it belongs on the roadmap.

Because sometimes the best way to improve a product is to add something new.

And sometimes it's knowing when not to.

If you're deciding what deserves a place on your roadmap, we'd love to help.