Thread by @PavelASamsonov

You hear PMs talk a lot about separating the "how" and the "what". But the other ones get forgotten:
WHY are we building this? What's the value to our user?
WHERE is this value added? What is the context of the experience?
WHEN can we deliver value? How do we avoid "scrumfall"?

Leaving out the WHY leads to products that don't solve anybody's problem. The classic Build Trap - a lot of output but no outcomes (changes to user behaviour) because nobody needs it. Without a clear WHY, MVPization of product releases clobbers the value you wanted to deliver.

Context is another crucial consideration for adoption. Leaving out the WHERE means that you don't understand what input your users have for their own workflows, what knowledge they possess, and what output they must generate. Mandatory input users can't give = critical breakdown.

And of course, none of this is useful until it's in the hands of users. The WHEN is not only a release schedule, but also a schedule for testing whether your answers to the other questions are correct. The later you validate, the bigger the cost of being wrong.

That's not to say the WHAT and HOW aren't important as well. The WHAT is a North Star, a fundamental goal and vision the team must agree on. But without a clear WHY, the WHAT becomes defined by the HIPPO and not by real needs. Without the WHEN, the HOW will end up changing anyway

Also common is the belief that only "what" is UX and "how" is ENG. But slow loading, exceptions/errors, bad security - all are user experience issues. UXers need to be part of both conversations (as does ENG).

And of course, the idea that UX is only involved in the "how" is absurd. Without user-centered design being involved with the other aspects of the product, no amount of "design" can help on a purely tactical, implementation level.