When the development team gets going fast enough, they start to implement stories that product owners have never refined, or even approved, and they produce features you do not want. This will make the developers uncomfortable. They don't want to be criticized for building the wrong thing. They want to bask in the glory of building the right thing. They will start to demand better product management, better stories, better design guidance. You must rise to the challenge.

Furthermore, you must do it without blocking the developers. We are going to unblock them so that after we give them an acceptable story to work on, they can work at full speed and release. We are going to move to one piece flow where we manage one feature - one story - at a time. The product owner has a responsibility to ride this process through to the end.

At Assembla, we have renamed the role "story owner." The story owner is responsible for taking stories from use cases, to design, to development, to release, to internal testing and refinement, to the big "unveil", and then to measurement.

Traditionally, the product owner started with product strategy and requirements: a study of the market, user needs, and user requirements. This is still important input. However, I think of strategy and requirements as a team sport. If you are releasing frequently, a lot of feedback about user needs reaches a lot of people in your organization. To manage this we use an "Epic" planning process, where different stakeholders can keep a list of the stories that they need, and move them through to development.