Determining what product should be built, and what features the product should have, is the responsibility of stakeholders identified in a project's charter. It is never the responsibility of the Product Owner as defined by the Scrum framework.
Generating Business Ideas Isn't Product Owner's Responsibility
Are there any techniques related to the requirement sessions or Reviews which can help produce ideas? Are ideas important for these sessions?
This seems to be a fundamental misunderstanding about the roles of the Product Owner and the stakeholders in Scrum. The Product Owner is not there to help stakeholders come up with business ideas; the PO role is there to:
- Elicit product requirements from the stakeholders.
- Build consensus among stakeholders about the value proposition and priorities of product features.
- Work with stakeholders to formalize an ordinal list of features to create a sequential Product Backlog.
None of these things amount to brainstorming about potential product features. That is the responsibility of the stakeholders and executive sponsors of the Project Charter.
Scrum Guide Isn't Prescriptive About Soliciting Stakeholder Input
The Scrum Guide is not prescriptive about how the Product Owner should interact with stakeholders, but it is clear about limiting responsibility for the Product Backlog to the Product Owner. Formally, the Product Owner role is defined within the framework as the sole arbiter of the Product Backlog and the sole representative of any stakeholders in the project. The guide says, in part:
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority mustaddress the Product Owner.
Ways to Build Product Consensus
While "generating ideas for the product" isn't the responsibility of the Product Owner or Scrum Master, there are certainly techniques for building consensus around features and assigning priorities. Many of them can be found as free tools provided by Mountain Goat Software. They include:
However, you aren't limited to these techniques. Once the stakeholders know what they want the project to build or deliver, there are many business analysis techniques you can use to elicit good specifications, user stories, or feature definitions. Since the framework isn't prescriptive about how these details are gathered from the stakeholders, the Product Owner is free to use any of them, or to invent new ones as needed.