Let's say those ideas include:
- More customer demos
- Having the implementors visit the customers as they "do work" or "live" (depending on your product)
- A better BV Model
- Don't talk to customers (they don't know they want an iPad)
- Taking BV metrics after each release
- Using the Pareto rule more to skinny down how many stories go in a release
- Better PMO governance, to assure that problem teams are helped sooner (so that deliveries happen faster)
- Improving the creativity of the Product Owners
- Better brainstorming by the Business Stakeholders (or whatever you call them...the people that 'assist' the Product Owner)
- Priority Poker (wide band delphi to estimate business value, using Fibonacci cards)
- Agile Specs
- Rely less on documentation and more on conversation to assure the Implementors understand the story
- Story Boards
- User Story Mapping
- More wireframes
- Focus on "bang for the buck"
- A story breakdown structure, to use to manage with senior Business Stakeholders
- Completing more projects "early", eg, when we see that the benefit-cost ratio of the project has deteriorated to below alternate projects (and other criteria are met).
- Light use cases
- Etc, etc, etc
First thing to observe (and the above is a short list of all the ideas out there): Too many ideas to implement all at once.
Second: Some of these ideas are contradictory.
Third: "Many seem very good ideas for us, but how do I prioritize?"
Yesterday I explained how we can use "BV process mapping" to enable us to see enough to prioritize the improvements we want to make. (This really includes more than mapping, but let's over-simplify and call it just "mapping.")
As a minor benefit, BV mapping enables you to hear talks, and identify which part of the BV engineering process the person is talking about. In other words, you can put others' ideas in a context that, hopefully, makes the ideas more useful or at least actionable.