A founder tags your product on X: “Could you add PDF exports? I need something I can send to clients.” A cheerful “Great idea, coming soon!” is easy to write. It also creates an expectation you may have no basis for setting.
Use the request to understand the job behind the feature. Then explain what is possible today and what, if anything, you have decided to do next. The example throughout this guide is fictional; it illustrates a conversation method, not a feature or roadmap for Replivio.
1Acknowledge the job behind the request
Start with the useful detail the person already provided. In this example, they want to send something to clients. Repeating that goal shows what you understood and gives them a chance to correct you.
“You need a client-ready version of the report” is more specific than “Thanks for the feedback.” But do not add requirements they never mentioned. You do not yet know whether they need branding, offline access, approval signatures or a file they can archive.
If the request is attached to a complaint, acknowledge the immediate difficulty too. Someone who cannot finish a task needs a clear answer about today's product before a discussion of possible improvements. For that situation, see our guide to responding to product criticism on X.
2Ask the question that changes your understanding
A feature name describes a proposed solution. Your next question should reveal why that solution matters. Choose one missing detail that could change your answer instead of sending a discovery questionnaire.
For the fictional export request, ask: “Does the client need a file they can keep, or mainly a version they can read without signing in?” Those needs could lead to different responses. Ask this only if the distinction is genuinely unclear from the existing conversation.
Avoid questions that steer the person toward your preferred answer, such as “Wouldn't a share link be easier?” They may have a procurement process, archive requirement or recipient who only accepts attachments. Learn the constraint before recommending a substitute.
Our follow-up question guide explains how to build the next question from details someone has already shared. The purpose is to understand the request, not to make the person prove they deserve help.
3Separate current help from future possibilities
Check whether the product already supports the task. Verify the relevant capability before offering instructions, and make any limitations explicit. A workaround can be useful without being equivalent to the requested feature.
Suppose, in our fictional product, a read-only share link exists but PDF export does not. If the client only needs to read the report, the link may help. If they must retain a file, it does not solve the stated problem. Say so instead of presenting the workaround as a complete answer.
“PDFs are coming soon! Just use the share link for now.”
“PDF export isn't available today. A read-only link works for viewing, but it won't give your client a file to keep. Is retaining a copy the requirement?”
This reply names the gap, explains the existing option and asks one relevant question. It does not turn a possible future feature into a reason to keep using a product that may not meet the person's current need.
4Describe the decision you have actually made
Choose status language carefully. “I've noted the request” means you recorded it. “We're investigating it” means someone is actively examining it. “We're building it” means implementation has begun. Do not use these phrases interchangeably to make the response feel more positive.
If no decision exists, say: “We haven't committed to PDF export. I understand why a retained copy matters for your client handoff.” If the request falls outside your current direction, explain that plainly and briefly. You can respect the need while declining the proposed solution.
Only mention a delivery date when there is a real commitment you are authorized to communicate. If timing is uncertain, leave it uncertain. A vague “soon” can still sound like a promise to someone choosing how to complete their work.
5Record the need without inflating the evidence
After the exchange, save a short internal note that preserves the person's wording and the constraints you learned. Keep observations separate from your interpretation.
- Request: PDF export for client reports.
- Confirmed need: the client must retain a copy outside the product.
- Current limitation: the available link allows viewing but does not supply that file.
- Open question: whether the same need appears in other relevant workflows.
One public request is evidence of that person's need. It is not evidence that most customers want the feature, that they would pay for it, or that the suggested format is the best implementation. Reactions to the post do not answer those questions either.
Do not ask the person to post client documents, private reports or account details in the thread. If troubleshooting requires private material, direct them to your existing support channel and request only what is necessary.
6Close the loop with a concrete update
If you promised to check an existing capability, return with the answer even when it is disappointing. If you offered to notify the person about a future decision, record that commitment so it is not lost.
An update should state what changed. “We confirmed that the current export excludes attachments” is useful information. “Still on our radar” adds little when nothing has been decided. Do not manufacture progress to keep the conversation alive.
If you use Replivio to prepare reply drafts, review the draft for accidental commitments before posting. Words such as “planned,” “supported” and “soon” need factual backing. This is a specific use of the checks in our AI reply review guide.
A good final reply leaves the person knowing what works now, what remains undecided and whether they should expect another update from you.
7Frequently asked questions
Should every feature request receive a follow-up question?
No. Ask when a missing detail would change your understanding or recommendation. If the need is already clear, answer it directly and explain the current product status.
How do I decline a feature request politely?
Acknowledge the specific need, state that the feature is not planned and briefly explain the relevant product direction. Offer an existing alternative only if it actually helps.
What if I already promised a feature too quickly?
Correct the expectation in the same conversation. Explain what is actually decided, withdraw any unsupported timing and state whether you can offer a concrete next update.
