What Not to Build

If you are starting on some new project, and your role needs you to define and prioritize requirements for a product, taking the "Breadth-First Approach" makes a lot of sense.

Getting to know the overall scope of your system should be the first target. Formulating accurate scope could get tricky at times. However, the first few questions that you should ask (to anyone else who knows even a bit more) must include:

1. Who are we doing this for? Look for proper nouns.
2. Which two main problems will our system solve?
3. Who is paying for this?
4. What is the release schedule?
5. What are the risks (as of now) and external dependencies?
6. Is someone else also doing similar work? (inside or outside your organization)

If the project is already underway, you may want to look at some inception stage sketches. If the project however is relatively young, you should draw those yourself. At some point, this effort must incorporate some kind of a conceptual domain model.
The next thing that you must think about is how would agile methodology scale to adjust with your team and the size of your product. And no one at any stage shall forget that along with the promise of delivering value pretty early, agile processes are also designed for the team to learn how to deliver value more effectively and efficiently.

Lastly, if you are much involved in capturing requirements or selling the product, you should always start to prepare (and even rehearse) your elevator pitch. You must have crystal clear, and unambiguous answers for: who you are, what you do, and why you do it better.

And finally today, I leave you with a quote that quite well summarizes the entire agile philosophy:
It’s never the size of the step that a person takes that counts, but its direction.
--Narrative Means to Therapeutic Ends, Michael White & David Epston