Hot Tips is a collection of candid advice by and for product people.
Found a great new way to build your roadmap? Got an awesome design or research tool you can’t live without? Unearthed the holy grail of prioritisation techniques?
Tell the JAM community! Sharing a Hot Tip is the best, fastest way to pay it forward to +3,000 makers from all over Europe. Your daily grind might be their ‘aha moment’!
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. With Hot Tips, we hope to show there’s no ‘one best way’ and it’s ok!
📖 Be as open as you can. Share your 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 like 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.
Every week, we’ll curate the best Hot Tips and share them with the community.
We all have that one book, article or talk that opened our eyes and helped us build better products. What's yours?
The Design Sprint (care of Jake Knapp at Google) is a framework I've used many times. Originally a 5 day process that takes you from discovery all the way to testing with actual customers I've found it best to take the parts you need from the process and merge them with other helpful processes.
For example, we will often fit a design sprint into 3 days. The intention of the design sprint has always been to have a working prototype to test with users quickly to validate ideas and solutions.
If you bring in some other helpful frameworks like User Story Maps (by Jeff Patton) it can add another layer of understanding and detail about what you really need to work on and what can be left until later.
And then the great thing about the design sprint is it just allows you to get much better at certain techniques. For example, if you want to hammer out a few ideas for a couple of hours on any project, take the solution sketching approach and you can just do that.
And because you will have a team in the room with you from varying disciplines it not only allows for fantastic ideation and different view points, but it shares understanding of a problem which is the fundamental basis for delivering a successful product as a disciplinary team and really avoids potential confusion later on.
The book 'What Customers Want' by Anthony W. Ulwick is my product BIBLE.
I've used the process described in the book (or a slightly lighter touch variation) to build every product I've ever worked on, including my own startup
The best part is that it forces you to speak to actual people for whom you wish to solve a problem as a starting point. Anyone who calls themselves a Product Manager but doesn't do this, and just does desk research, is not a Product Manager – they're at best an analyst and at worst some person with an opinion. Beyond that, the book gives an easy process to discover, as the name suggests, what customers want, even if the customers didn't realise themselves.