In this 2-part series, I will share two practical ways to enhance your Assumptions Mapping by combining it with two other methods to make assumption prioritisation more concrete and make productive decisions.

A simple table for deciding when an idea needs product discovery and when you should just build it, with real examples for each of the three cases.

Not every feature idea deserves the same scrutiny. How to tell an unproven assumption from an unproven implementation, with two real product examples.

Your team just spent three weeks perfecting the UX of a feature that nobody needs. Meanwhile, your competitor just launched a clunky - or thanks to AI coding an okayish - but valuable solution that's stealing your customers. This scenario plays out daily across product teams worldwide, driven by a dangerous obsession with perfect usability over actual value. It's time for some uncomfortable truths about what actually drives product success.

"Should I use Impact Mapping or an Opportunity Solution Tree (OST)?" My answer is always: “Why not use both?” Here's how I combine them.

speed without understanding isn't progress, it’s just a faster feature factory. AI can make this worse if you ship without thinking, because it makes building faster while doing nothing to improve your ability to know whether what you're building is actually worth building. That makes it an even faster feature factory. My most favourite 7 principles from the Makers Manifesto work against this trap.