The Most Practical Product Design Framework I've Ever Used

(When I say "product", feel free to replace it with "feature")

It doesn't matter how advanced or powerful the product is. If the desire is not there, things will be difficult.

Once the discovery work is done, the first hypothesis should be formulated around: "Will people want to use the product?". All that is needed is a landing page with product mockups that show users the improved version of themselves and how this will happen. They need to identify practical, recurring, and highly emotional situations in which the product makes sense. Interviews here are primarily conversational since the goal is to confirm and understand the pain related to the problems solved by the product.

Although people might confirm they want the product, adoption depends on something else. Users must be able to use the product. The next step is to create hypotheses around the user problems that the product can support and how they would operate the interface to achieve their goals. The question becomes: "Will people be able to use the product?".

It's when a prototype is built. It must be something that feels like the actual product. Ideally, people will identify a context and find the proper solution without any assistance. Interviews are more like user testing sessions in which users perform tasks.

It isn't easy to validate the ability to use without first knowing if users want the product. However, the third type of validation, the "Can we build it?" will be improved when executed alongside the previous two phases. The gains for everyone are huge since Engineers get to early inform product and design teams about the constraints and possibilities related to the solution, for example.

This third validation helps uncover costs, time frames, resources, and skillsets that might need to be acquired for a predictable and safe execution.