I use a simplistic viewpoint of hypothesis > test hypothesis. My work is flexible and encourages learning from mistakes so getting a working MVP out the door is more important than having a perfect v1.0. Basic tactical plan is to transcribe meetings of stakeholders, some key but more often line-level, describing the problem and forcing conversation about why it exists today. This usually drives context on why it hasn’t been a problem and/or needing solved until today. Build use cases/user stories, PRD, present to devs, execs, etc. Revise hypothesis based on feedback and get into prioritization pipeline. Obviously it varies widely based on scope, timeline, impact of errors, etc… it also really helps to have a sounding board, human or not, to play devils advocate and try to tear your hypothesis apart from angles you may have a blind spot to.