Hot Tips is a constantly growing, curated collection of candid advice by and for product people.
Think of it as a precious piece of advice you wish you had received when you started building products. It’s a short snippet of wisdom that helps you do things differently.
Contributing a Hot Tip it the fastest way to reach 3,000+ makers from all over Europe. Your daily grind might be their ‘aha moment’!
1. Write your Tip following the guidelines below.👇
2. Submit the Tip through Typeform.
3. Wait patiently! The Tip will undergo some scrutiny by our Hot Tip Catcher, who will then decide whether to publish it (we may tweak the content for clarity).
4. Watch out! Every week we’ll pick the best Hot Tips and share them with the community in the JAM newsletter. Look out for yours! 👀
Your Tip can belong to one of the three categories.
📖 Be as open as you can: share insider knowledge, something people won’t have come across before. A Hot Tip reveals how you do things.
🎨 Show, don’t (just) tell: talking about your roadmapping process? How about including a screenshot of the tool you use? There’s nothing better than seeing your ‘behind-the-scenes’.
💌 Keep it short and personal: aim for 200 words max, and word it like you’re helping a friend out.
🔧 Share tools: offer readers an opportunity to explore the topic. Link to at least one helpful ebook or article that helped you in the past.
Feedback comes at different times and from different corners. How not to lose track, and not to get overwhelmed? What to act on and what to ignore?
Behind every piece of feedback there’s a problem that a person has with a product. While the feedback itself can take a lot of shapes and forms, the problems are much fewer and you will usually get feedback on the most urgent ones.
Documenting the problems and tracking feedback against them makes it much more manageable. That’s why it’s important to never ignore feedback, but to actually dive deeper and understand the “why” for it. The tools you can use for that vary, but here are a few I use regularly:
I'm a big believer that the best ideas always come back, whether because other customers repeatedly mention them, because they're so obvious that you keep rediscovering them in your product research, or because they're so unique that they get stuck in your memory.
We've kept a backlog of product ideas in the past, but realized that seeing the list every day was a major energy drain (think Inbox Zero!), that we rarely lacked quality ideas to work on, and in the rare instances when we did get through our entire roadmap, most ideas would be outdated anyways.
This of course assumes a small to medium-sized team and product. Once you scale your userbase and your product becomes more stable, there's certainly value in a more quantitative approach to feedback collection and prioritization.
Let’s agree on one thing first. We’re making an implicit assumption that it’s valuable to keep track of the feedback you’re receiving. (Except for the one “This sucks!” comment from you fav reddit troll.)
Two basic points:
Number three might be less obvious. There are several stakeholders who you need to consider. Each of them might have a different objective in providing you with feedback. Some are more into quick monetisation and ignore the long-term value of the product. Others want endless features and don't consider dev time and server cost.
Logging the source of feedback helps you see what degree of importance you should assign it. A voice of a VC has a higher weight than that of @MsSpandex from Tumblr (no offence to that user if they exist). Similarly, an opinion of a long-term paying user ranks higher than that of a newly logged-in one who used just 30% of the product’s features.
Most feedback will seem qualitative, but you can translate it into quantities.
An idea board with a list of features and an upvoting function is a simple way to outsource the (some of the!) decisions to your users. Options to consider:
If you have help desk with a tagging function, tag messages that include feedback. After a while you’ll be able split messages into categories, for example: feature requests, usability, speed, bugs. Periodically go through the messages and categorise them in an excel table, or on a Trello board.
Not always. Besides the rule different source = different level of importance, different categories of feedback should also be organised in a hierarchy. A function "share on slack" might have gotten 100 votes. But, if the upload button still makes the website crash…
You get the point: fixing bugs takes priority. But, other categories might be less straightforward. Establish your own hierarchy.
Once you have the feedback…
It’s time to act! Schedule regular team meetings to discuss the feedback you received and decide how it should impact product plans.
Then get back to taking over the world. Easy.