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.
JTBD, popularised in 2016 by Clayton Christensen, is one of the popular frameworks in the world of PMs. Like everything, it has its plusses and minuses. When do you use it, and when do you think one should avoid it?
I think JTBD is a great discovery tool when taking bigger swings in your product. It’s a lens to remind you and the team that your users don’t ultimately want to perform tasks or activities, but rather they want to make a change in their life situation. This mindset helps you define/ prioritise user problems and sense check the solutions that flow from them, keeping your product development efforts focused on what matters.
JTBD can also lead you to re-evaluate some fundamental product/marketing assumptions — the value that your product brings to users, how should you categorise (segment) users, and who your competitors are — allowing you to think more holistically.
I find JTBD to be less useful for smaller product swings that iterate on an existing feature. There are still ‘problems to solve’ with an existing feature, but the job usually hasn’t changed. Instead you tend to be helping the user to use the feature with less friction (i.e do the job slightly better). Because JTBD encourages you to think from first principles, it can sometimes feel like overkill in these situations.
I also think that, because it’s a discovery tool, JTBD doesn’t speak to how your team and company delivers on problems/jobs. So, even if you have a great handle on discovery, the delivery side still needs to be there for you to delight your users and make a great product.
JTBD offers new lenses to approach a product challenge.
Instead of finding this answer to this question: "How our solution solves this particular problem?", we should ask two JTBD questions:
Exploring those two answers will give you a completely new perspective of your real competition and an opportunity to create innovative solutions.
My team uses JTBD before we start the design of any feature. We use JTBD to start the conversation about whether we have enough context about the problem before investigating a solution.
We don't use JTBD when it relates to something that is necessary to make another thing work, for e.g. buying email credits to send emails.
JTBD is one of the best ways to learn about what the experience is like for your target customer, in the moment that they use your product (or an alternative solution).
The framework provides a way to evaluate the "forces of progress" that hinder the customer from taking action to make progress on what they are trying to accomplish. The more you can understand what is happening in the moment the customer is struggling to make progress, the better you can cater your solution to address the root of their problem.
JTBD. There are many people whose eyes will light up when you mention this acronym. There are also many who will rather roll them. The best approach probably lies in the middle (what would that be in eyes’ terms? Squinting?)
In a nutshell, “jobs to be done” is a way of looking at a product through identifying reasons why customers buy it. It’s answering the question: What jobs are people recruiting my product for?
All PMs know it’s crucial to establish a problem a product is solving before building it. That’s a top level understanding: You’ll need to find a problem, and define the people who have it (these will be your users FYI!).
This is will tell you what you think you’ll be building and is the first stage of product development. The second stage, is JTBD— finding reasons why users “hire” your product.
JTBD lets you explore all functions the product. It reminds you who really owns what you're building. It’s the users, not you.
Understanding the extra ‘jobs’ the product is performing will help you in several ways.
One place where you need to make sure to incorporate JTBD is feedback collection. Focus on understanding the circumstances of when people use your product.
Tip. Incorporate a version of the following question into your customer interview. Imagine [insert product] disappears from your life.
This kind of research can reveal you're in a different business than you envisioned. Perhaps through matching a water bottle to a yoga mat you help your customer create a sense of belonging and balance the root chakra? You’re then in a business of chakras not water bottles.