Name the actual problem
Bring users, constraints, policies, existing tools and competing definitions into one view.
Understand the work before choosing the software.
A feature request is often the visible edge of a larger problem involving language, responsibility, policy or an unclear process. I start there.
Working principles
Technology should strengthen human capability.
Start with the system already in the room
I listen to how people describe the work, map what happens between teams and identify where knowledge or responsibility changes hands. Existing workarounds usually reveal both the real need and the constraints.
Make the product model legible
Names, roles, permissions and relationships are product decisions. When they are clear, people can understand what is happening and what they need to do next.
Choose tools after the problem has shape
Software is one possible intervention. A clearer workflow, better documentation or a change in responsibility may solve part of the problem before code is written.
Design for stewardship
A team needs to operate, explain and improve a product after its initial build. Maintainability includes governance and institutional knowledge, not only clean code.
In practice
From uncertainty to a product people can use.
Clarify how the parts relate
Define roles, information, decisions and workflows before committing to a feature structure.
Make the smallest useful system
Test the model through prototypes or working software, then document what the team learns.