Today I would like to share some thoughts about collecting the right requirements.
What is usually done while doing agile development is that there is a product backlog containing the users' requests. Then, regularly, the development team picks things to implement from the backlog.
That's all well and I personally work this way.
The problem is that sometimes the items in the product backlog is not really what customers are really looking for. So development teams are wasting time on things that don't matter.
The discussion here is how to make sure that the product backlog is relevant.
For sure, most items from the backlog originate from some form of request. But we have to process differently the items depending on their origin. You should give a higher priority to items that will have a positive impact on the business. The priorities in the tool you use to manage your backlog should reflect that.
Don't artificially bump the priorities of secondary requests just because you don't have enough high priority items. You should really be honest about the business value of what you are doing.
This means that sometimes the highest priority in your backlog might only be medium. That would be the case if you have no business centered items only minor technical items.
Again, what I think is important is that the priorities should be a honest representation of the business.
If you have no high priority items in your backlog, that's a valuable piece of information. Does this mean that you are not talking to the right people? Does this mean that no body care enough about the product? Is it time to pivot?
You should not hesitate to log ideas in your product backlog. But those items often need to be clarified afterwards.
Some users will give you their solution instead of the problem that need to be solved. Sometimes that's OK but you should always try to understand the real problem behind a request. Finding the problem is also a good way to understand if you are solving business issues or not.
Not all backlog items come from the business side. Some technical enhancements will also have a positive impact on the business. For example, doing backups will obviously be a very good thing for your business but no customer will create such request. Such requests should not necessarily be put lower than customer requests but this is something to consider when you evaluate the health of your backlog.
To sum up some of the parts discussed above: you should understand the business value of your product backlog items, you should review them regularly, you should distinguish solutions and problems.
I don't think there is a definitive process to handle this. Some tools and processes include notions of product backlog management. I personally don't worry to much about tools and processes. The most important part in my opinion is that you understand your own product backlog and that you don't wait for it to grow out of control.
You might use an agile methodology. That's great. But in the end it doesn't matter to be agile if you don't build the right things.
I have 2 resources that I would like to share on the topic of building the right things:
(From an entrepreneurial point of view) I really recommend this episode of "Masters of Scale": https://www.youtube.com/watch?v=jBOmj2CRYqo
(From an engineering point of view) I have also found this talk from Greg Youg very interesting: https://www.youtube.com/watch?v=GRr4xeMn1uU
I said that the process doesn't matter that much. Some people say that agile methodologies/scrum don't work. The first questions that come to mind is: did you build the right features? To be fair... I do think that the process helps. An agile process done properly should give you a fast feedback that you are not building the right features. If you didn't get this feedback, maybe you are not really agile. Agility really makes sense when implemented end to end: https://didierhoarau.com/blog/my-definition-of-agile-and-devops