Why the “What” and “How” of A Requirement Are Not Enough

Projects rarely fail because of technology—they fail due to lack of clarity. Even well-written requirements often answer only the What and How, but miss the most critical element: the Why. Without understanding business value, refinement sessions turn into ad-hoc decisions, and developers guess what truly matters.
Use cases and user stories may look formal and include acceptance criteria, yet they often omit the value they create—the WHY. This leads to frustrating refinements where questions like “What problem should be solved?”, “Who has this problem?” and “What is the business value?” are decided on the spot or handed down to developers.
Our presentation proposes product discovery to answer “Are we building the right thing?” and “What is the real problem?”, so refinement can focus on clarifying what needs to be done and delivery on how to implement it best.
Product discovery is not a one-time task at project start; it must happen whenever new problems arise, ideas emerge, or major changes occur. While continuous delivery builds functionality when needed, continuous discovery learns and makes value-based decisions when needed.
The role of a business analyst or requirements engineer as partner of Product Owner and development team is not only writing good requirements but also:

- Differentiate problem space (WHY) from solution space (WHAT and HOW)
- Structure and answer questions on business and user value
- Make assumptions explicit
- Present results clearly to the dev team