The product owners singular purpose in getting his product narrative right is to ensure that erroneous knowledge does not invade the minds of the team members. Such knowledge is a form of bias and is very resilient, and once established is very difficult to correct.
A product owner is the products story teller, weaving his stories while holding the narrative of the product together for the duration of the product development. In his narration he mediates between the expected user experience, the narrative, and the team. The teams ability to succeed is very much dependent on the product owners storytelling prowess. Product owners have many techniques at hand to get their stories across. One of these is the well-worn formal user story with its myriad available formats. The other is face-to-face session, presentations, and documentation. A combination of all of them is probably the necessary solution for most product owners.
So how do teams still end up with erroneous knowledge about the product? One of the main reasons for this is the use of artefacts not intended for a narrative. Such artefacts may be useful, but they always present only a tiny part of the narrative and leave the rest to the imagination of the team members, which is always dangerous.
Do not use E-R (Entity-Relationship) diagrams as replacement for a narrative. An E-R diagram is an outcome of some prior analysis. It neither provides domain knowledge nor does it provide and process knowledge; it is in essence a static data model. It directs the receiver to reach a different set of conclusions than those one would expect a narrative to arouse. It tells only a very small part of the story, and it leads to erroneous knowledge. The resilience of this erroneous knowledge bias will frustrate attempted future correction. Adding more diagrams to this E-R diagram doesn’t help either, since the team was not asked to participate in the making of these diagrams.
Do not replace the narrative with the UI. The UI is how the user will experience the product. The purpose of a UI is to hide the complexity from the user, and hence it cannot both hide and reveal the complexity at the same time. Smart UI alters how the end users do their work, even importantly how they think about this work. Thus it cannot help the developer develop the smarts behind it without the rest of the narrative. The idea that the UI can be used (without other narrative artefacts) for developing an application is reminiscent of mainframe development some five to six decades back. Note we are not discussing the development of the UI itself.
Diagrams be they architectural or E-R, (or UI for that matter) do have a place in an agile developers learning curve, but these artefacts must be allowed to emerge and evolve through the development process. They cannot be handed as completed artefacts to the development team. The product owner is there to guide and help the team understand his narrative of the product.
This situation is often seen in the outsourced product development environment. One can only presume that in most cases this is due to cost saving. Although, experience shows us that the exact opposite happens, costs increase. Much of what has been said also holds true where the outsourcing is only for coding and testing. Even in this scenario benefits only accrue when the right form of narrative is used. In fact, much more effort is required to ensure that bias via erroneous knowledge is avoided.