Hello, I am Salman. Former support agent, currently making tools for small teams
Hi Product Hunt! I worked for five years in a medium-sized SaaS company responding to support tickets and saw the same issues repeating over and over again - poor onboarding experience, confusing pricing pages, no information on what a customer has done before. Finally, I got sick of writing feature requests and decided to start building.
At the moment I'm developing an experimental browser extension called Ticketlens that displays a customer's latest five actions in the helpdesk sidebar. It is still very primitive, but my two former colleagues use it every day and report bugs, which I take as a good sign.
I would like to understand how other makers deal with early feedback and to read real launch stories. If you also have come from a non-engineer background to development, tell me what you wish someone had told you in your first month.
Replies
Welcome, Salman. Five years of reading tickets is a better product education than most founders get, and "no information on what a customer has done before" is a real gap; a sidebar that shows the last five actions is the kind of small thing a support person wants and a product manager never prioritises. On early feedback, two things that worked for me. First, make the feedback carry its evidence. My app's support form prefills the user id, and Settings has a Share Logs button that sends the on device log, so a tester's "it did not work" arrives with what the app actually did. Half of early feedback is otherwise a guessing game about reproduction. Second, treat the two colleagues who use it daily as the test, not as the audience. Paid testers find crashes; people who use the thing every day find the one feature that is wrong, because they bump into it twice a day. Write down what they say in their words, not in yours, and watch what they stop doing, that is the strongest signal there is.