How to Answer Tool Recommendation Requests on X

“What tool do you use for this?” looks like a request for a product name. Sometimes it is. But a useful answer also explains why the tool fits the work, what could make it a poor fit and what the person should check next.

For a founder replying on X, this is an opportunity to make a decision easier. Start with the task behind the request, then offer the smallest recommendation you can support. A shortlist without reasoning leaves the author with the same research problem.

The scenarios below are fictional examples. They illustrate how to write a recommendation, rather than endorse any real product.

01Translate the category into a task

Read the original post and the replies before suggesting anything. “Need a feedback tool” could mean collecting feature requests, organizing interview notes or keeping support conversations together. Those jobs call for different comparisons.

Write a private sentence: “This person wants to do ___, with ___.” Fill the second blank with a constraint they actually stated. If the post only names a category, do not invent their team size, budget or technical setup.

Consider this fictional request:

“Looking for a tool to collect feedback from our first customers. Two founders, no support team. Any recommendations?”

The author has supplied a team constraint but not the kind of feedback. Before listing products, establish whether they want private conversations or a public request board. That distinction is more useful than a generic ranking.

02Ask the question that changes the choice

Ask for missing information only when the answer would change your advice. A full discovery questionnaire is too much work for someone asking a quick question.

“Do you mainly need private customer conversations or a public place to collect feature requests? I'd compare those workflows separately.”

Other decisive constraints might be whether data must stay in an existing system, whether clients need access or whether the team can maintain an integration. Choose the constraint relevant to this request, not a standard list you paste into every thread.

If the author already gave enough context, answer directly. Repeating a question they answered earlier makes the exchange harder. The follow-up question guide explains how to make a question earn its place.

03Give a reason and a limitation

A recommendation becomes useful when the recipient can evaluate its logic. Use this structure: the choice, the task it fits, the limitation and one thing to verify.

Suppose the fictional author clarifies that most feedback arrives by email and neither founder wants another inbox. A reply could be:

“I'd first test whether your current inbox can handle shared ownership and a simple feedback label. That avoids adding another place to check. If you need a public request board, though, this won't cover that workflow.”

This answer does not require naming a new product. It gives the author a practical starting point and says where the suggestion stops being useful.

When you can support a specific product recommendation, explain the same tradeoff. “I use it” establishes experience, but does not explain fit. “I use it for private email feedback with one teammate” gives the recipient something they can compare with their own situation.

04Separate experience from what you have read

Make the basis of your advice visible. There is a difference between using a tool every week, testing a demo and noticing a feature in its documentation. State which one applies without turning the reply into a biography.

Before making a current claim about price, integrations, exports or permissions, check the vendor's relevant documentation. Link to the specific page that answers the author's question. If you cannot verify the requirement, say what they need to check instead of presenting it as settled.

Avoid “best” unless you explain the criteria and the comparison you actually made. You can say “worth checking for this workflow” when you have limited experience. You can also decline to name a product and offer a useful evaluation question.

If an AI draft adds personal experience you never supplied, delete that claim. Use the reply review checklist before posting a polished recommendation that may sound more certain than your evidence.

05Explain your connection when it is your product

If your own product fits the stated need, say that you build it. Then explain the relevant capability and its limit. Let the reader assess your recommendation with that context.

A fictional founder of a public feedback-board product might write:

“I build a public feature-request board, so that's my perspective here. It fits collecting and grouping requests, but it isn't a shared support inbox. If your feedback stays in email, I'd solve that workflow first.”

Do not stretch the category so every request becomes a match. Acknowledging a mismatch is more useful than sending someone to a page that cannot answer their question. If they ask to see the product, give the relevant next step; the product-interest follow-up guide covers that transition.

06Leave them with one realistic test

Finish by helping the person evaluate the suggestion. For the feedback example, that might mean taking one representative request through capture, assignment and retrieval. Use a made-up sample if the real material contains customer information.

The test should expose the constraint you identified. If the problem is duplicate work, check whether both founders can see who owns the request. If the problem is finding past feedback, check whether they can retrieve it without remembering the original wording.

For your next recommendation reply, keep three things visible: the person's job, your reason and the condition that would change your advice. If you use Replivio to prepare a draft, supply those details and review the result. A useful reply should help someone choose, including when the right choice is to keep what they already use.

07Frequently asked questions