No, But Here's Something Better
Replace a feature rejection with evidence, education, and customer discovery.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 98%
No, But Here's Something Better converts a feature limitation into consultative selling. Begin with a direct answer, then uncover the assumption connecting the requested feature to the customer's desired outcome. Use relevant tests, statistics, and operational trade-offs to explain why the feature may underperform an available alternative. This changes the exchange from defensive support into useful education. After presenting the evidence, ask detailed questions about the customer's intended workflow and expectations. Those questions gather product intelligence, test demand, and reveal whether customers would pay for a better implementation. The output can include retained trust, adoption of an existing solution, clearer roadmap requirements, and a possible upsell—without pretending that an unavailable feature already exists.
Origin
Jasmine Star extracted the method from Spiffy's response to her request for Klarna or Afterpay support. The company declined, explained its test data, distinguished digital from physical products, and requested design feedback.
Core principles
- 01A rejection can become an educational sales conversation.
- 02Evidence is more persuasive than a bare product limitation.
- 03Challenge assumptions by explaining trade-offs.
- 04Feature requests are opportunities for customer discovery.
- 05Customer-success conversations can reveal viable upsells.
How to run it
- 1
Give the direct answer
State whether the requested feature or integration currently exists. Acknowledge the request and its perceived value without burying the limitation.
Pro tip Use one clear sentence before introducing nuance.
Watch out Do not imply that a roadmap item is committed when it is only being explored.
- 2
Challenge the underlying assumption
Identify the outcome the customer expects and explain why the requested feature may not achieve it. Distinguish between contexts where it works and contexts where it introduces unnecessary friction.
Pro tip Frame the discussion around the customer's desired result rather than defending the product.
Watch out Do not dismiss the customer's reasoning as ignorance.
- 3
Support the alternative with evidence
Present tests, statistics, costs, risks, or workflow constraints that justify the recommended alternative. Explain how the current product can produce the desired outcome more effectively.
Pro tip Use concrete ranges and operational consequences when the data supports them.
Watch out Unsupported numbers will reduce trust rather than increase it.
- 4
Gather implementation insight
Ask how the customer expects the requested feature to interact with related purchases, subscriptions, or workflows. Use the answers to refine product requirements and estimate genuine demand.
Pro tip Ask scenario-based questions that expose edge cases.
Watch out A long survey without a clear purpose can burden an already disappointed customer.
- 5
Test the expansion opportunity
Determine whether a well-designed version of the feature would create enough value for customers to pay more. Feed validated demand into roadmap and packaging decisions.
Pro tip Separate polite interest from demonstrated willingness to pay.
Watch out Do not promise development solely to manufacture an upsell.
In the wild
When Jasmine asked whether Spiffy supported Klarna or Afterpay, its customer-success representative said no, explained that tests had not shown higher conversions than native payment plans, outlined checkout and upsell friction, and distinguished physical-product risk from digital access. The response then asked how she expected BNPL to handle one-click upsells and related purchases.
→ The rejection changed Jasmine's view of BNPL, reinforced the value of Spiffy's existing approach, and generated detailed product feedback for the company.
A hypothetical analytics platform receives a request for hourly emailed reports. Rather than simply declining, the team explains that frequent reports create alert fatigue, shows engagement data favoring threshold-based alerts, demonstrates the existing alert rules, and asks which events truly require immediate action.
→ The customer adopts a more useful existing workflow while the platform gathers evidence for a possible premium alerting package.
Common mistakes
Stopping at no
A bare rejection leaves the customer's desired outcome unresolved and wastes an opportunity to educate, retain, and learn from them.
Overwhelming the customer with data
Evidence should clarify the decision, not bury the answer in irrelevant statistics or defensive detail.
Treating feedback as a promise
Asking how a feature should work does not mean it will be built. Teams must communicate roadmap uncertainty honestly.
Is it for you?
Best for
It is best for SaaS and service teams responding to feature requests where evidence suggests the requested option may not produce the customer's desired result.
Not ideal for
It is not ideal when the company lacks credible evidence, when the limitation creates immediate harm, or when a simple direct fix is already available.
From the transcript
“They challenge my assumption. They share their insights to change my opinion, and then they used it to get user feedback.”
“You literally use data and analytics to challenge an assumption and show me a different way.”
“Well, it educates options and offers new insights using data and analytics.”
From the episode
Old School Marketing Tactics, New School Results