Before you even think about looking at software, you should have a solid list of requirements. What are requirements? The word comes from software engineering. The IEEE, a professional society for engineers that develops international standards, says that a requirement is a
“condition or capability needed by a user to solve a problem or achieve an objective”.
Karl Wiegers helpfully suggests expanding the definition to include stakeholders, since not all stakeholders are users.
So requirements describe what you need. You will know what you need by first creating:
1. A Problem Statement – answers the question “What problems are you trying to solve?”
2. Expected Outcomes – answers the question “What objectives are you trying to achieve?”
3. A Vision – paints a picture of your ideal future state.
Working on these documents can feel forced and artificial, especially when you use fancy language in the Vision. But it provides a foundation for the house you are trying to build. It also gives the team common language to describe the project. (A handy goal for your first round of workshops is to make sure everyone knows a three-sentence answer to the question: What are you guys working on?)