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.
With new product decisions happening constantly, how do you keep people updated with what is being worked on? How do you find the balance between over-documenting and keeping everyone well informed?
First thing to establish is which “team” you’re communicating with. Both what you share and how you communicate it will differ depending on whether you’re talking to the wider, company team or the focused team of PMs.
When updating the wider team at Thinkific I focus on what and when. This involves sharing new features we launched, what’s coming up next, if there are any delays, and where we need help or involvement from other teams. This is also an occasion to communicate the broader context: our OKRs and any updates to the roadmap.
For sharing this kind of info we schedule standups, weekly portfolio updates, and use Slack for day to day communication.
When communicating with the PM team, the focus is on the why of our plans. We share one-pagers explaining the reasoning of planned features, company updates related to strategy, and...knowledge! This is when we exchange resources to read or listen to.
We’d typically do this during a weekly PM team meeting, and we also use Slack for day to day updates.
Keeping the team updated is a constant challenge for a PM. Here are a couple of tips I have found useful.
A PM has to keep many different parts of the business updated and you cannot just churn out the same update for all. Your dev team will be more interested in the near-term updates and want to delve into the tech detail. Your business stakeholders will want to know more high level and focus on a wider time period.
So, find out what level is important to your audience and update at that level only. That way you find your meetings are not only more productive as people are less likely to get bored, but also...a lot less effort on your part!
Make updating every team a regular, scheduled thing. It is so easy to let this slip if it is done "ad-hoc" and, once this happens, you are into the realm of assuming people all know everything you know (they never do, it's not their job to). Once you get into the habit you will find this less onerous in the long run.
Document the key decisions and keep them in an accessible place for everyone to access. There should be no reason to hide these from anyone in the business and having this in a central place will allow people to reference these when needed. This can be a great time saver for all involved.
You wake up and don’t remember what you decided yesterday. Ok, at least until your first coffee with MCT oil. How can you expect your team to keep track of that?
As a PM you’re the decision buffer. Just as you protect the product form excess features, you also protect the team from information overload. And, from the potential panic it can generate.
Decisions range from smaller to bigger, and so does their importance.
Communicate only what’s consequential. Not everyone needs the same information, especially in bigger organisations. A decision on tweeting 10 times a day, rather than five, is not important for the back end team. But, it might be important for design if each tweet has a bespoke image. Know which decisions impact whom.
Make information accessible. When people want to know the source of a particular decision they should know where to find it. This serves two purposes. It deflects questions which otherwise you might be getting. Also, it gives people the opportunity to learn about the works of other departments.
Document everything. While it’s not necessary to communicate everything, it's a good practice to store all ideas, decisions, and experiments. Otherwise, it’s hard to keep track of what has already been discussed. Even if you’re a memory champion and can keep it in your memory, sorry Charlie, it’s a waste of space.
Document all decisions in a concise manner. Include why an idea was considered, why it was approved or rejected. Do it even if it’s just for yourself. Next time you come u with a transformative thought — let’s all go to Bali for a company work retreat! — check your decisions' list. Chances are you thought about it before.
Open mike! Establish a regular schedule of update meetings. This is the time to communicate big decisions — those that have anything to do with the vision of the product. It gives people the opportunity to ask questions. But, be prepared to answer about your next round of funding, or why the office doesn’t yet have a jacuzzi.