@beacampos I would recommend either a video or a tldr - there's SO much information there. I'm sure it's great, but for someone who is checking to see "does this interest me or not?" it's difficult to skim for validation. Just my two cents.. I realize a lot of work went into this and do not want to discount your efforts, just a little advice for readers like me!
@vlchris i appreciate your input Chris! i understand. this is a long guide because we tried to be specific and exemplify while also suggesting methods and tools our teams actually used or use at the moment (like BRIDGeS). but noted! :)
It's absolutely essential. I'm practicing continuous discovery habits as a part of our overall product discovery and it's a must but it depends on how mature your company is and if it has a product mindset.
Once we identify a problem, I look into customer feedback, check data and recordings, outline my assumptions around the problem, and ideally start with customer interviews to validate it quickly even before we prepare designs. At the same time, I'm trying to understand the problem by looking into competitors and best practices and talking a lot with my designers (they are also part of the customer interviews).
The whole goal is really to decrease the risk of launching something bad. During the discovery, our engineering lead is part of the process to give us technical insights and together we redefine the problem, finish designs, and user test it before development.
@pm_optimizer ๐๐ agreed! it really makes a difference and helps you build your product (or anything really) right the first time. being prepared and predicting possible risks or even opportunities you wouldn't have considered otherwise will definitely help you get better results, faster and save resources. well put! thanks for your comment!